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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y20s6UCsYyB+/nfK@sirena.org.uk>
Date:   Thu, 10 Nov 2022 16:55:05 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Richard Fitzgerald <rf@...nsource.cirrus.com>
Cc:     Marc Zyngier <maz@...nel.org>, lee@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, linus.walleij@...aro.org,
        tglx@...utronix.de, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org, patches@...nsource.cirrus.com
Subject: Re: [PATCH 09/12] irqchip: cirrus: Add driver for Cirrus Logic
 CS48L31/32/33 codecs

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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)