[PATCH 09/12] irqchip: cirrus: Add driver for Cirrus Logic CS48L31/32/33 codecs

Mark Brown broonie at kernel.org
Thu Nov 10 17:55:05 CET 2022


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20221110/963a4195/attachment.sig>


More information about the Alsa-devel mailing list