From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8D5CC4332F for ; Thu, 12 May 2022 22:15:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354770AbiELWPW (ORCPT ); Thu, 12 May 2022 18:15:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38100 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1354300AbiELWPW (ORCPT ); Thu, 12 May 2022 18:15:22 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BA816254730; Thu, 12 May 2022 15:15:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 70549B82B63; Thu, 12 May 2022 22:15:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A6FDC385B8; Thu, 12 May 2022 22:15:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652393717; bh=fc0UztyX51O5K/1Ek3Why80En4eNCFKQYWY/tu8LjnA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=nIyMOfR1ehCwgryDuutkkX34eSooJenNfM00EH6PipdBVTeaTRJ1WYbl+1WJ98OPs dl1saOtU9ksXmx2RbXKsKmaNZod7+03vGDJbmznmblHnri5urVflxkxXCLpQQrNFrI S/FwT82WG3idnThLWphcvYqQEMHXSq07WE8Hm+RaQRN92GoFvIfXtLtKU3anTlfeHV O1UoQnz3NIpHY37LaTzfVHxYROyNAL/hdOsudWAw5YynDIKgT6yGzSJi+ayWW6Bbfo SP7uymQ16GkXlDhI1nzvy39YwEl2GcNfkhe29Cb/JApYUPKaA65BsHVL/6YHdzpmAg E4vZIL72XFqnA== Received: from ip-185-104-136-29.ptr.icomera.net ([185.104.136.29] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1npH5W-00AzV7-85; Thu, 12 May 2022 23:15:14 +0100 Date: Thu, 12 May 2022 23:15:11 +0100 Message-ID: <87v8uamm8g.wl-maz@kernel.org> From: Marc Zyngier To: Andy Shevchenko Cc: linux-kernel@vger.kernel.org, Linus Walleij , Bartosz Golaszewski , Thierry Reding , Joey Gouly , Jonathan Hunter , Hector Martin , Sven Peter , Alyssa Rosenzweig , Bjorn Andersson , Andy Gross , Jeffrey Hugo , Thomas Gleixner , Basavaraj Natikar , Shyam Sundar S K , linux-gpio@vger.kernel.org, linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v3 00/10] gpiolib: Handle immutable irq_chip structures In-Reply-To: References: <20220419141846.598305-1-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.104.136.29 X-SA-Exim-Rcpt-To: andy.shevchenko@gmail.com, linux-kernel@vger.kernel.org, linus.walleij@linaro.org, brgl@bgdev.pl, thierry.reding@gmail.com, joey.gouly@arm.com, jonathanh@nvidia.com, marcan@marcan.st, sven@svenpeter.dev, alyssa@rosenzweig.io, bjorn.andersson@linaro.org, agross@kernel.org, jeffrey.l.hugo@gmail.com, tglx@linutronix.de, Basavaraj.Natikar@amd.com, Shyam-sundar.S-k@amd.com, linux-gpio@vger.kernel.org, linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Thu, 12 May 2022 18:08:28 +0100, Andy Shevchenko wrote: > > On Tue, Apr 19, 2022 at 03:18:36PM +0100, Marc Zyngier wrote: > > This is a followup from [2]. > > > > I recently realised that the gpiolib play ugly tricks on the > > unsuspecting irq_chip structures by patching the callbacks. > > > > Not only this breaks when an irq_chip structure is made const (which > > really should be the default case), but it also forces this structure > > to be copied at nauseam for each instance of the GPIO block, which is > > a waste of memory. > > Is this brings us to the issue with IRQ chip name? > > The use case in my mind is the following: > 1) we have two or more GPIO chips that supports IRQ; > 2) the user registers two IRQs of the same (by number) pin on different chips; > 3) cat /proc/interrupt will show 'my_gpio_chip XX', where XX is the number. /proc/interrupts isn't a dumping ground for debug information. Yes, some irqchips do that, and they have been fixed by providing the irq_print_chip callback, thus ensuring that the irq_chip structure is never written to. I would have loved to simply get rid of the variable string, but this is obviously ABI, and we can't break that. > So, do I understand correct current state of affairs? > > If so, we have to fix this to have any kind of ID added to the chip name that > we can map /proc/interrupts output correctly. This is already done. That's not an excuse to add more of those though. We already have the required infrastructure in debugfs, and that's where this sort of thing should happen. M. -- Without deviation from the norm, progress is not possible.