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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3759FC433F5 for ; Thu, 12 May 2022 22:16:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tWb5Pxpye2kWfhRWK3xVoorU4njWwX54InQiZdZAsYA=; b=b0vmjUuSE1tvcY x2Rq1lWOK6nwBb0mJpn1YPssAiSnsoHvLPrE26iDJjys25FdT1mfY+ld2xvplg9C5eKssFc7FixBT J26v6g8FutJczqJzY+luHWzwRR/f2fPtZH/4WFbDxG7DTA6xpp+JB3E54fMGoaDxwQ0TXzoonjjKQ NaXTdO+ZJFsU1+B0uzTTNC7pWMBTIWt6rBLOFdm/pSHTdEuoD3UmD6xaIytMkjW6dIp/eIv1fxEmQ vuKpiwemldVRwdw6HBrZNLgU82gV+vR01VfVPU3qMqV4ue/17L9F2zzfceSIx/J9LOcdsGxXU05wR LdOzzTzED/hBh1xtB78A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1npH5d-00DiVS-Kt; Thu, 12 May 2022 22:15:21 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1npH5a-00DiUP-LE for linux-arm-kernel@lists.infradead.org; Thu, 12 May 2022 22:15:20 +0000 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 dfw.source.kernel.org (Postfix) with ESMTPS id C87D761F90; Thu, 12 May 2022 22:15:17 +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") 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220512_151518_817396_5C0A8532 X-CRM114-Status: GOOD ( 27.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel