On Thu, Nov 10, 2022 at 04:31:06PM +0000, Richard Fitzgerald wrote: > On 10/11/2022 15:13, Marc Zyngier wrote: > > > If we put them in the MFD with DT definitions it would make a > > > circular dependency between MFD and its child, which is not a great > > > situation. If it's these handlers that are bothering you, we could move > > > them to the audio driver. > > And what's left? Nothing. > Ah, I see. You've missed that the bulk of the implementation re-uses > existing library code from regmap. It does say this in the commit > message. > "the generic regmap_irq functionality is used to do most of the work." > and I've also said this in previous replies. The thread prompted me to have a look at regmap-irq earlier today and see what it's still doing that peers into the regmap core internals and it seems it's just getting the register stride which has had an external API added already and getting the device for the regmap. It should be straightforward to repaint it and move it into the irqchip subsystem which would be a much more sensible home for a library for implementing irqchips in this day and age. I started looking at the code changes for that a bit. > This is no way driver that does nothing. There's over 1000 lines of code > handling the PIC and dispatching its interrupts to other drivers that > want to bind to them. It's just that it makes no sense to duplicate 1300 > lines of interrupt handling code from elsewhere when we can re-use that > by calling regmap_add_irq_chip(). That gives us all the interrupt- > controller-handling code in drivers/base/regmap/regmap-irq.c TBF that's 1000 lines of overly generic code, a bunch of it is conditional stuff and it's unlikely that any individual driver would want all of it. Equally it does mean that all the users are just providing data rather than writing any code which generally makes things easier to maintain and was the main goal.
Attachment:
signature.asc
Description: PGP signature
