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 A122BC433EF for ; Fri, 13 May 2022 08:53:22 +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=m7fMNz2NeLltOIU0gSjXQ+G8eM+VmHRJ7LsKUt8EsH8=; b=c2OhrWBcETso/v lAyVuetgHpLfh2Or4tXAgHJUKhBQxcHodn0h/DbA2HnuGdADRJAPvV6hpALIyOq+XabYZBKML5uZI Dz2N9guLsVqddV8p4FlwBvsS8vEXuE9xPsc7NYPuCjF21+y1A7/gXB1Hmg2AO4gxDVcTC8mchH7IZ OlRx6xB76dy78Qdc6Z+fdcpspM8V5/Ln1gbQc5JvooN+YsYWlDyZUE4yinm2FPdtNEUtXjiPLN3n7 7AhTLMkehgfTwb1RHxRFNLB/TXeF1tBBabGTMyGKF+AIqs6x9hCvFCJgQTJmZouOeQwy/eYtrH/5O AddxmL4q2Uvz+qNiIPbg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1npR1p-00FC8R-8C; Fri, 13 May 2022 08:52:05 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1npR1j-00FC6i-D3 for linux-arm-kernel@lists.infradead.org; Fri, 13 May 2022 08:52:01 +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 ams.source.kernel.org (Postfix) with ESMTPS id 4E5AFB82C43; Fri, 13 May 2022 08:51:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BEE8C34100; Fri, 13 May 2022 08:51:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652431916; bh=Z9GNVgKPYgZkKWB6ukAD87t5wipTy5BqfBoBFI3+5tE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=hLLoD0NB9PRvpctpe75eS4G7itCJY3McuHxXJrSO0E2FCQs3vBTR8RbexYLO6/Zst 4hNP80cRsC3y9ngKTwTeNhhjyiMXQnjqLKPSDIeEu+NrhLu0bQtxJ0nm0GlUJgGVdA iW/lOBhXMjExq7yhfs5u1rIXd0HVDkIPQ2meN1UOkBcMmV9FH1OLkhCRZX4myQKrgC URfZQTiTtQgJdWFi+lc8wrO+oeDd6VeTMJ32ECNYgAh45nR6/kq3MV8fhaRB0q8lGh MbQ/5Gb6UjO9Bup4Pf7oBUBvpsEfo1Qk1ZqdZgwDT58CZubHJ2bp5Yt34Q0cignsA8 HPgv+QbI3lxdA== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.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 1npR1d-00B4kN-9C; Fri, 13 May 2022 09:51:53 +0100 Date: Fri, 13 May 2022 09:51:53 +0100 Message-ID: <87tu9t6cie.wl-maz@kernel.org> From: Marc Zyngier To: Andy Shevchenko Cc: Linux Kernel Mailing List , 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 , "open list:GPIO SUBSYSTEM" , linux-tegra , linux-arm Mailing List , linux-arm-msm@vger.kernel.org, Android Kernel Team Subject: Re: [PATCH v3 00/10] gpiolib: Handle immutable irq_chip structures In-Reply-To: References: <20220419141846.598305-1-maz@kernel.org> <87tu9umm3k.wl-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.219.108.64 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-20220513_015159_811015_EA94139A X-CRM114-Status: GOOD ( 40.90 ) 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 Fri, 13 May 2022 09:43:29 +0100, Andy Shevchenko wrote: > > On Fri, May 13, 2022 at 12:18 AM Marc Zyngier wrote: > > On Thu, 12 May 2022 18:35:55 +0100, > > Andy Shevchenko wrote: > > > > > > On Thu, May 12, 2022 at 08:08:28PM +0300, 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. > > > > > > > > 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. > > > > > > Hmm... Some drivers are using static names, some -- dynamically > > > prepared (one way or another). Either way I think the ID is good to > > > have if we still miss it. > > > > No, this is a terrible idea. /proc/interrupts gives you a hint of > > which driver/subsystem deals with the interrupt. This isn't a source > > of topological information. /sys/kernel/debug/irq has all the > > information you can dream of, and much more. Just make use of it. > > Okay, so IIUC the mapping is that: I got a vIRQ number from > /proc/interrupts, but then I have to mount debugfs and look into it > for a detailed answer of which chip/domain this vIRQ belongs to. Normal users shouldn't care about irqdomains. If you are developing, you already have debugfs enabled and mounted on your system. > Also /sys/kernel/irq rings a bell, but not sure if it's related. This is the same thing as /proc/interrupt, just dumped with a different format. 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