[0/5] gpiolib: Handle immutable irq_chip structures

Message ID	20220223154405.54912-1-maz@kernel.org (mailing list archive)
Headers	show Return-Path: <linux-arm-msm-owner@kernel.org> From: Marc Zyngier <maz@kernel.org> To: linux-kernel@vger.kernel.org Cc: 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>, Thomas Gleixner <tglx@linutronix.de>, 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: [PATCH 0/5] gpiolib: Handle immutable irq_chip structures Date: Wed, 23 Feb 2022 15:44:00 +0000 Message-Id: <20220223154405.54912-1-maz@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk
Series	gpiolib: Handle immutable irq_chip structures \| expand [0/5] gpiolib: Handle immutable irq_chip structures [1/5] gpio: Don't fiddle with irqchips marked as immutable [2/5] gpio: Expose the gpiochip_irq_re[ql]res helpers [3/5] pinctrl: apple-gpio: Make the irqchip immutable [4/5] pinctrl: msmgpio: Make the irqchip immutable [5/5] gpio: tegra186: Make the irqchip immutable

Marc Zyngier Feb. 23, 2022, 3:44 p.m. UTC

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.

My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
which does what it says on the tin: don't you dare writing there.
Gpiolib is further updated not to install its own callbacks, and it
becomes the responsibility of the driver to call into the gpiolib when
required. This is similar to what we do for other subsystems such as
PCI-MSI.

3 drivers are updated to this new model: M1, QC and Tegra, as I
actively use them (though Tegra is hosed at the moment), keeping a
single irq_chip structure, marking it const, and exposing the new
flag.

Nothing breaks, the volume of change is small, the memory usage goes
down and we have fewer callbacks that can be used as attack vectors.

Another approach was to let gpiolib provide its own irq_chip structure
and stack it, but:
- only a few drivers are hierarchy aware
- the diversity of interrupt flows makes it impractical

I'd welcome comments on the approach. If deemed acceptable, there are
another 300+ drivers to update! Not to mention the documentation. I
appreciate that this is a lot of potential changes, but the current
situation is messy.

Note that these patches are on top of irqchip-next, which contains
more constifying work.

	M.

Marc Zyngier (5):
  gpio: Don't fiddle with irqchips marked as immutable
  gpio: Expose the gpiochip_irq_re[ql]res helpers
  pinctrl: apple-gpio: Make the irqchip immutable
  pinctrl: msmgpio: Make the irqchip immutable
  gpio: tegra186: Make the irqchip immutable

 drivers/gpio/gpio-tegra186.c         | 33 ++++++++++++-----
 drivers/gpio/gpiolib.c               | 13 +++++--
 drivers/pinctrl/pinctrl-apple-gpio.c | 30 +++++++++-------
 drivers/pinctrl/qcom/pinctrl-msm.c   | 53 +++++++++++++++++-----------
 include/linux/gpio/driver.h          |  4 +++
 include/linux/irq.h                  |  2 ++
 kernel/irq/debugfs.c                 |  1 +
 7 files changed, 91 insertions(+), 45 deletions(-)

Thierry Reding Feb. 24, 2022, 4:40 p.m. UTC | #1

On Wed, Feb 23, 2022 at 03:44:00PM +0000, Marc Zyngier wrote:
> 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.
> 
> My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
> which does what it says on the tin: don't you dare writing there.
> Gpiolib is further updated not to install its own callbacks, and it
> becomes the responsibility of the driver to call into the gpiolib when
> required. This is similar to what we do for other subsystems such as
> PCI-MSI.
> 
> 3 drivers are updated to this new model: M1, QC and Tegra, as I
> actively use them (though Tegra is hosed at the moment), keeping a

Hosed in what way? Anything I can help with?

Thierry

Marc Zyngier Feb. 24, 2022, 5:42 p.m. UTC | #2

On 2022-02-24 16:40, Thierry Reding wrote:
> On Wed, Feb 23, 2022 at 03:44:00PM +0000, Marc Zyngier wrote:
>> 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.
>> 
>> My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
>> which does what it says on the tin: don't you dare writing there.
>> Gpiolib is further updated not to install its own callbacks, and it
>> becomes the responsibility of the driver to call into the gpiolib when
>> required. This is similar to what we do for other subsystems such as
>> PCI-MSI.
>> 
>> 3 drivers are updated to this new model: M1, QC and Tegra, as I
>> actively use them (though Tegra is hosed at the moment), keeping a
> 
> Hosed in what way? Anything I can help with?

Tegra186 doesn't boot as host1x is been broken since -rc1.

I have been carrying this[1] patch which has been in -next for
some time, but still not merged AFAICS.

         M.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/gpio-immutable&id=58d1d925f05485020306e5141336cfd2989843dc

Marc Zyngier March 4, 2022, 5:19 p.m. UTC | #3

On Thu, 24 Feb 2022 17:42:02 +0000,
Marc Zyngier <maz@kernel.org> wrote:
> 
> On 2022-02-24 16:40, Thierry Reding wrote:
> > On Wed, Feb 23, 2022 at 03:44:00PM +0000, Marc Zyngier wrote:
> >> 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.
> >> 
> >> My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
> >> which does what it says on the tin: don't you dare writing there.
> >> Gpiolib is further updated not to install its own callbacks, and it
> >> becomes the responsibility of the driver to call into the gpiolib when
> >> required. This is similar to what we do for other subsystems such as
> >> PCI-MSI.
> >> 
> >> 3 drivers are updated to this new model: M1, QC and Tegra, as I
> >> actively use them (though Tegra is hosed at the moment), keeping a
> > 
> > Hosed in what way? Anything I can help with?
> 
> Tegra186 doesn't boot as host1x is been broken since -rc1.
> 
> I have been carrying this[1] patch which has been in -next for
> some time, but still not merged AFAICS.

Looks like it finally made it -rc6.

Thanks,

	M.

Linus Walleij March 15, 2022, 12:44 a.m. UTC | #4

On Wed, Feb 23, 2022 at 4:44 PM Marc Zyngier <maz@kernel.org> wrote:

> I recently realised that the gpiolib play ugly tricks on the
> unsuspecting irq_chip structures by patching the callbacks.

Sorry about that...

> My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
> which does what it says on the tin: don't you dare writing there.
> Gpiolib is further updated not to install its own callbacks, and it
> becomes the responsibility of the driver to call into the gpiolib when
> required. This is similar to what we do for other subsystems such as
> PCI-MSI.

OK if there is a precedent it is usually wise to follow.

> I'd welcome comments on the approach. If deemed acceptable, there are
> another 300+ drivers to update! Not to mention the documentation. I
> appreciate that this is a lot of potential changes, but the current
> situation is messy.

I'm happy with this approach as long as the 300+ drivers get fixed
and the old way of doing it gets deleted.

Yours,
Linus Walleij

Marc Zyngier March 15, 2022, 9:35 a.m. UTC | #5

On 2022-03-15 00:44, Linus Walleij wrote:
> On Wed, Feb 23, 2022 at 4:44 PM Marc Zyngier <maz@kernel.org> wrote:
> 
>> I recently realised that the gpiolib play ugly tricks on the
>> unsuspecting irq_chip structures by patching the callbacks.
> 
> Sorry about that...

No worries. It probably did seem like a good idea at the
time, and I have the benefit of hindsight here...

> 
>> My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
>> which does what it says on the tin: don't you dare writing there.
>> Gpiolib is further updated not to install its own callbacks, and it
>> becomes the responsibility of the driver to call into the gpiolib when
>> required. This is similar to what we do for other subsystems such as
>> PCI-MSI.
> 
> OK if there is a precedent it is usually wise to follow.
> 
>> I'd welcome comments on the approach. If deemed acceptable, there are
>> another 300+ drivers to update! Not to mention the documentation. I
>> appreciate that this is a lot of potential changes, but the current
>> situation is messy.
> 
> I'm happy with this approach as long as the 300+ drivers get fixed
> and the old way of doing it gets deleted.

Of course. Note that it will take some time before it actually happens.
My current plan is to stick in a pr_warn() each time a driver
following the old scheme gets registered, as a nudge for people to
update their driver if they care about it.

Regarding documentation, are you OK with me simply replacing the
current code samples with the new approach? It will at least avoid
giving people the wrong idea. I also want to write a brief migration
guide that people willing to bump up their patch count can follow.

I'll repost something once -rc1 is out.

Thanks,

         M.

Linus Walleij March 24, 2022, 10:30 p.m. UTC | #6

On Tue, Mar 15, 2022 at 10:35 AM Marc Zyngier <maz@kernel.org> wrote:

> > I'm happy with this approach as long as the 300+ drivers get fixed
> > and the old way of doing it gets deleted.
>
> Of course. Note that it will take some time before it actually happens.
> My current plan is to stick in a pr_warn() each time a driver
> following the old scheme gets registered, as a nudge for people to
> update their driver if they care about it.

Fair enough, we have a bunch of those WIP churn tasks in
GPIO anyways.

What about adding a blurb to:
drivers/gpio/TODO
so we have it on the radar?

> Regarding documentation, are you OK with me simply replacing the
> current code samples with the new approach? It will at least avoid
> giving people the wrong idea. I also want to write a brief migration
> guide that people willing to bump up their patch count can follow.

Yup

> I'll repost something once -rc1 is out.

Sounds good!

Yours,
Linus Walleij

[0/5] gpiolib: Handle immutable irq_chip structures

Message

Comments