Another common abuse in irqchip drivers (and derivatives) is to place
a string representing the underlying device in the irq_chip::name
field that gets displayed in /proc/interrupts while this should only
be an indication of the "type" of interrupt controller.

Not only this is pretty pointless (with hierarchical domains, you only
see the top chip), but it also gets in the way of making the irq_chip
structure const. For debug, we have a whole infrastructure that does
everything you can imagine (and stuff you don't want to).

We can't remove this name as it is visible from userspace and there is
a whole collection of CI scripts that parse /proc/interrupts for good
(and mostly bad) reasons. The solution is to use the irq_print_chip()
callback and to let it output whatever string is necessary.

Having done that, we can cleanup a few irqchip drivers and make their
irq_chip structure const (which requires touching a handful of core
functions). Whilst we're at it, we do the same for a couple of gpio
drivers.

This series relies on the one posted at [1].

Thanks,

	M.

[1] https://lore.kernel.org/r/20220201120310.878267-1-maz@kernel.org

Marc Zyngier (10):
  irqdomain: Let irq_domain_set_{info,hwirq_and_chip} take a const
    irq_chip
  genirq: Allow irq_chip registration functions to take a const irq_chip
  irqchip/gic: Switch to dynamic chip name output
  irqchip/lpc32xx: Switch to dynamic chip name output
  irqchip/mvebu-pic: Switch to dynamic chip name output
  irqchip/ts4800: Switch to dynamic chip name output
  irqchip/versatile-fpga: Switch to dynamic chip name output
  gpio: mt7621: Switch to dynamic chip name output
  gpio: omap: Switch to dynamic chip name output
  pinctrl: starfive: Switch to dynamic chip name output

 drivers/gpio/gpio-mt7621.c             |  12 ++-
 drivers/gpio/gpio-omap.c               |  28 ++++---
 drivers/irqchip/irq-ftintc010.c        |   1 -
 drivers/irqchip/irq-gic.c              | 102 +++++++++++++------------
 drivers/irqchip/irq-lpc32xx.c          |  34 ++++++---
 drivers/irqchip/irq-mvebu-pic.c        |  28 ++++---
 drivers/irqchip/irq-ts4800.c           |  25 ++++--
 drivers/irqchip/irq-versatile-fpga.c   |  46 ++++++-----
 drivers/pinctrl/pinctrl-starfive.c     |  11 ++-
 include/linux/irq.h                    |   7 +-
 include/linux/irqchip/versatile-fpga.h |  14 ----
 include/linux/irqdomain.h              |   5 +-
 kernel/irq/chip.c                      |   9 +--
 kernel/irq/irqdomain.c                 |   7 +-
 14 files changed, 189 insertions(+), 140 deletions(-)
 delete mode 100644 include/linux/irqchip/versatile-fpga.h

-- 
2.30.2

On Wed, Feb 9, 2022 at 5:26 PM Marc Zyngier <maz@kernel.org> wrote:

> Having done that, we can cleanup a few irqchip drivers and make their
> irq_chip structure const (which requires touching a handful of core
> functions). Whilst we're at it, we do the same for a couple of gpio
> drivers.

The series:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Since Bartosz is queueing GPIO patches and I am mostly
playing with a baby during the daytime it's good if you also
get an ACK from Bartosz on this one before applying the
series.

Yours,
Linus Walleij

On Thu, 10 Feb 2022 23:41:25 +0000,
Linus Walleij <linus.walleij@linaro.org> wrote:
> 
> On Wed, Feb 9, 2022 at 5:26 PM Marc Zyngier <maz@kernel.org> wrote:
> 
> > Having done that, we can cleanup a few irqchip drivers and make their
> > irq_chip structure const (which requires touching a handful of core
> > functions). Whilst we're at it, we do the same for a couple of gpio
> > drivers.
> 
> The series:
> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Thanks.

> Since Bartosz is queueing GPIO patches and I am mostly
> playing with a baby during the daytime it's good if you also
> get an ACK from Bartosz on this one before applying the
> series.

To be on the safe side and until I hear from Bartosz, I have dropped
the GPIO patches from the branch which I'm about to push into -next.
If Bartosz is happy with them, I'll add them to the mix. Otherwise,
they can be taken at a later time, as there is no shortage of drivers
that will need reworking once we agree on the way to resolve the
irqchip fiddling in gpiolib.

Have fun playing! :)

	M.

-- 
Without deviation from the norm, progress is not possible.

On Fri, Feb 11, 2022 at 8:31 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Feb 9, 2022 at 5:26 PM Marc Zyngier <maz@kernel.org> wrote:

...

> Since ... I am mostly
> playing with a baby during the daytime

A bit of a side topic, since I need to send a PR for fixes before my
vacation starts tomorrow, should I Cc my PR to that Linus as well, so
he can accept it?
It will contain two one-liner ID patches to pin control Intel drivers
and won't conflict with anything (as far as I am aware and know).

-- 
With Best Regards,
Andy Shevchenko

On Tue, Feb 15, 2022 at 4:38 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Fri, Feb 11, 2022 at 8:31 AM Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Wed, Feb 9, 2022 at 5:26 PM Marc Zyngier <maz@kernel.org> wrote:
>
> ...
>
> > Since ... I am mostly
> > playing with a baby during the daytime
>
> A bit of a side topic, since I need to send a PR for fixes before my
> vacation starts tomorrow, should I Cc my PR to that Linus as well, so
> he can accept it?
> It will contain two one-liner ID patches to pin control Intel drivers
> and won't conflict with anything (as far as I am aware and know).

I manage the pin control stuff but at a bit slow pace, so I'll pick
it up!

Yours,
Linus Walleij