From: Marc Zyngier <maz@kernel.org> To: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: linux-kernel@vger.kernel.org, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <brgl@bgdev.pl>, Thierry Reding <thierry.reding@gmail.com>, Joey Gouly <joey.gouly@arm.com>, Jonathan Hunter <jonathanh@nvidia.com>, Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>, Alyssa Rosenzweig <alyssa@rosenzweig.io>, Bjorn Andersson <bjorn.andersson@linaro.org>, Andy Gross <agross@kernel.org>, Jeffrey Hugo <jeffrey.l.hugo@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Basavaraj Natikar <Basavaraj.Natikar@amd.com>, Shyam Sundar S K <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 Subject: Re: [PATCH v3 00/10] gpiolib: Handle immutable irq_chip structures Date: Thu, 12 May 2022 23:15:11 +0100 [thread overview] Message-ID: <87v8uamm8g.wl-maz@kernel.org> (raw) In-Reply-To: <Yn0/DIl3+i/heRH6@smile.fi.intel.com> On Thu, 12 May 2022 18:08:28 +0100, Andy Shevchenko <andy.shevchenko@gmail.com> 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.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org> To: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: linux-kernel@vger.kernel.org, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <brgl@bgdev.pl>, Thierry Reding <thierry.reding@gmail.com>, Joey Gouly <joey.gouly@arm.com>, Jonathan Hunter <jonathanh@nvidia.com>, Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>, Alyssa Rosenzweig <alyssa@rosenzweig.io>, Bjorn Andersson <bjorn.andersson@linaro.org>, Andy Gross <agross@kernel.org>, Jeffrey Hugo <jeffrey.l.hugo@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Basavaraj Natikar <Basavaraj.Natikar@amd.com>, Shyam Sundar S K <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 Subject: Re: [PATCH v3 00/10] gpiolib: Handle immutable irq_chip structures Date: Thu, 12 May 2022 23:15:11 +0100 [thread overview] Message-ID: <87v8uamm8g.wl-maz@kernel.org> (raw) In-Reply-To: <Yn0/DIl3+i/heRH6@smile.fi.intel.com> On Thu, 12 May 2022 18:08:28 +0100, Andy Shevchenko <andy.shevchenko@gmail.com> 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
next prev parent reply other threads:[~2022-05-12 22:15 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-19 14:18 [PATCH v3 00/10] gpiolib: Handle immutable irq_chip structures Marc Zyngier 2022-04-19 14:18 ` Marc Zyngier 2022-04-19 14:18 ` [PATCH v3 01/10] gpio: Don't fiddle with irqchips marked as immutable Marc Zyngier 2022-04-19 14:18 ` Marc Zyngier 2022-04-19 14:29 ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier 2022-04-19 14:18 ` [PATCH v3 02/10] gpio: Expose the gpiochip_irq_re[ql]res helpers Marc Zyngier 2022-04-19 14:18 ` Marc Zyngier 2022-04-19 14:29 ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier 2022-04-19 14:18 ` [PATCH v3 03/10] gpio: Add helpers to ease the transition towards immutable irq_chip Marc Zyngier 2022-04-19 14:18 ` Marc Zyngier 2022-04-19 14:29 ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier 2022-04-19 14:18 ` [PATCH v3 04/10] gpio: tegra186: Make the irqchip immutable Marc Zyngier 2022-04-19 14:18 ` Marc Zyngier 2022-04-19 14:29 ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier 2022-04-19 14:18 ` [PATCH v3 05/10] gpio: pl061: " Marc Zyngier 2022-04-19 14:18 ` Marc Zyngier 2022-04-19 14:29 ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier 2022-04-19 14:18 ` [PATCH v3 06/10] pinctrl: apple-gpio: " Marc Zyngier 2022-04-19 14:18 ` Marc Zyngier 2022-04-19 14:29 ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier 2022-04-19 14:18 ` [PATCH v3 07/10] pinctrl: msmgpio: " Marc Zyngier 2022-04-19 14:18 ` Marc Zyngier 2022-04-19 14:29 ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier 2022-04-19 14:18 ` [PATCH v3 08/10] pinctrl: amd: " Marc Zyngier 2022-04-19 14:18 ` Marc Zyngier 2022-04-19 14:29 ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier 2022-04-19 14:18 ` [PATCH v3 09/10] gpio: Update TODO to mention immutable irq_chip structures Marc Zyngier 2022-04-19 14:18 ` Marc Zyngier 2022-04-19 14:28 ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier 2022-04-19 14:18 ` [PATCH v3 10/10] Documentation: Update the recommended pattern for GPIO irqchips Marc Zyngier 2022-04-19 14:18 ` Marc Zyngier 2022-04-19 14:28 ` [irqchip: irq/irqchip-next] " irqchip-bot for Marc Zyngier 2022-04-22 21:24 ` [PATCH v3 00/10] gpiolib: Handle immutable irq_chip structures Linus Walleij 2022-04-22 21:24 ` Linus Walleij 2022-04-23 10:30 ` Marc Zyngier 2022-04-23 10:30 ` Marc Zyngier 2022-04-26 10:24 ` Andy Shevchenko 2022-04-26 10:24 ` Andy Shevchenko 2022-04-26 21:59 ` Linus Walleij 2022-04-26 21:59 ` Linus Walleij 2022-05-04 21:21 ` Linus Walleij 2022-05-04 21:21 ` Linus Walleij 2022-05-05 8:09 ` Marc Zyngier 2022-05-05 8:09 ` Marc Zyngier 2022-05-05 12:58 ` Bartosz Golaszewski 2022-05-05 12:58 ` Bartosz Golaszewski 2022-05-05 14:50 ` Linus Walleij 2022-05-05 14:50 ` Linus Walleij 2022-05-12 17:08 ` Andy Shevchenko 2022-05-12 17:08 ` Andy Shevchenko 2022-05-12 17:35 ` Andy Shevchenko 2022-05-12 17:35 ` Andy Shevchenko 2022-05-12 22:18 ` Marc Zyngier 2022-05-12 22:18 ` Marc Zyngier 2022-05-13 8:43 ` Andy Shevchenko 2022-05-13 8:43 ` Andy Shevchenko 2022-05-13 8:51 ` Marc Zyngier 2022-05-13 8:51 ` Marc Zyngier 2022-05-12 22:15 ` Marc Zyngier [this message] 2022-05-12 22:15 ` Marc Zyngier
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=87v8uamm8g.wl-maz@kernel.org \ --to=maz@kernel.org \ --cc=Basavaraj.Natikar@amd.com \ --cc=Shyam-sundar.S-k@amd.com \ --cc=agross@kernel.org \ --cc=alyssa@rosenzweig.io \ --cc=andy.shevchenko@gmail.com \ --cc=bjorn.andersson@linaro.org \ --cc=brgl@bgdev.pl \ --cc=jeffrey.l.hugo@gmail.com \ --cc=joey.gouly@arm.com \ --cc=jonathanh@nvidia.com \ --cc=kernel-team@android.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-gpio@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-tegra@vger.kernel.org \ --cc=marcan@marcan.st \ --cc=sven@svenpeter.dev \ --cc=tglx@linutronix.de \ --cc=thierry.reding@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.