[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMRc=Me=VTqTfa4=p3HOa4_NmE3W6h+YyPLZGKXZo6dqUoxWmg@mail.gmail.com>
Date: Tue, 8 Feb 2022 12:13:19 +0100
From: Bartosz Golaszewski <brgl@...ev.pl>
To: Marc Zyngier <maz@...nel.org>
Cc: "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"moderated list:ARM/Mediatek SoC..."
<linux-mediatek@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux-OMAP <linux-omap@...r.kernel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Grygorii Strashko <grygorii.strashko@...com>,
Santosh Shilimkar <ssantosh@...nel.org>,
Kevin Hilman <khilman@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Avi Fishman <avifishman70@...il.com>,
Tomer Maimon <tmaimon77@...il.com>,
Tali Perry <tali.perry1@...il.com>,
Emil Renner Berthing <kernel@...il.dk>
Subject: Re: [PATCH 00/12] genirq: Move irqchip runtime PM over to irq domain
On Tue, Feb 1, 2022 at 1:03 PM Marc Zyngier <maz@...nel.org> wrote:
>
> Our irq_chip data structure currently suffers from two problems:
>
> (1) the 'name' field is often dynamically populated with a reference
> to the underlying HW (DT node dame, for example)
>
> (2) the 'parent_device' which is used to implement runtime PM is also
> dynamically populated
>
> (3) there is at least one instance of a subsystem messing with the
> internals of irq_chip structures (gpiochip_set_irq_hooks is
> what I know about)
>
> These things mean that although the primary use of irq_chip is to only
> contain function pointers and other *static* information, the above
> two fields result in these structures being copied in a number of
> drivers. Eventually, it would be much better if the various drivers
> would use irq_chip as an 'ops' data structure (potentially made
> read-only), and keep the dynamic information somewhere more suitable.
>
> For (2) we already have the irqdomain structure that is designed to
> deal with the context in which interrupts are used, and it makes sense
> to move the 'parent_device' field over to this structure. This is what
> this small series is doing, with some minor cleanup on the way.
>
> (1) and (3) will be dealt in separate series (and I don't have a good
> solution for (3) yet).
>
> Thanks,
>
> M.
>
> Marc Zyngier (12):
> genirq: Allow the PM device to originate from irq domain
> irqchip/gic: Move PM device over to irq domain
> irqchip/renesas-intc-gpio: Move PM device over to irq domain
> irqchip/renesas-irqc: Move PM device over to irq domain
> irqchip/imx-intmux: Move PM device over to irq domain
> gpio: mt7621: Kill parent_device usage
> gpio: omap: Move PM device over to irq domain
> gpio: rcar: Move PM device over to irq domain
> gpio: tpmx86: Move PM device over to irq domain
> pinctrl: npcm: Fix broken references to chip->parent_device
> pinctrl: starfive: Move PM device over to irq domain
> genirq: Kill irq_chip::parent_device
>
> drivers/gpio/gpio-mt7621.c | 1 -
> drivers/gpio/gpio-omap.c | 7 ++++---
> drivers/gpio/gpio-rcar.c | 2 +-
> drivers/gpio/gpio-tqmx86.c | 3 ++-
> drivers/irqchip/irq-gic.c | 12 +++++------
> drivers/irqchip/irq-imx-intmux.c | 8 +++-----
> drivers/irqchip/irq-renesas-intc-irqpin.c | 3 ++-
> drivers/irqchip/irq-renesas-irqc.c | 3 ++-
> drivers/pinctrl/nuvoton/pinctrl-npcm7xx.c | 25 +++++++++++------------
> drivers/pinctrl/pinctrl-starfive.c | 3 ++-
> include/linux/irq.h | 2 --
> include/linux/irqdomain.h | 10 +++++++++
> kernel/irq/chip.c | 20 +++++++++++++-----
> 13 files changed, 59 insertions(+), 40 deletions(-)
>
> --
> 2.30.2
>
The changes for GPIO are small so:
Acked-by: Bartosz Golaszewski <brgl@...ev.pl>
You can take it through your tree and if there are any conflicts, I'll
just ask for an immutable branch.
Bart
Powered by blists - more mailing lists