linux-kernel - RE: [PATCH] ASoC/HDA cs35l56: Remove redundant IRQ handling

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: <006301dafee5$fdb00c70$f9102550$@opensource.cirrus.com>
Date: Wed, 4 Sep 2024 17:17:51 +0100
From: Simon Trimmer <simont@...nsource.cirrus.com>
To: 'Mark Brown' <broonie@...nel.org>
CC: <tiwai@...e.com>, <linux-sound@...r.kernel.org>,
        <alsa-devel@...a-project.org>, <linux-kernel@...r.kernel.org>,
        <patches@...nsource.cirrus.com>
Subject: RE: [PATCH] ASoC/HDA cs35l56: Remove redundant IRQ handling

On Wed, Sep 04, 2024 at 13:47:00PM +0000, Simon Trimmer wrote:
> On Wed, Sep 04, 2024 at 12:25:00PM +0000, Mark Brown wrote:
> > On Wed, Sep 04, 2024 at 12:07:00PM +0000, Simon Trimmer wrote:
> > > The IRQ handling in the cs35l56 driver was purely informational. It
was
> > > not necessary to support the HDA or ASoC driver functionality and
added
> > > unnecessary complexity to the drivers.
> > >
> > > As the IRQ signal GPIO line could be connected and shared with other
> > > components the handling is replaced with a regmap patch to ensure the
> > > cs35l56 IRQ sources are masked and will not generate interrupts that
go
> > > unhandled.
> >
> > Given that the code is there now and has been since the driver was
> > introduced about 18 months ago what's the ongoing cost of having it?
> > The information it's providing is notification of hardware faults,
> > reporting those does seem useful.
> 
> Originally we were expecting to use the IRQ mechanism for an event logging
> stream that would function in a similar manner to compressed streams to be
> able to get an information feed for debug and tuning tools, but those were
> never created and the logging infrastructure not implemented.
> 
> It's quite a spread of code and a lot of complexity in the regular
execution
> paths managing them / synchronizing the contexts, there is more going on
in
> the SoundWire bus variant compared to the conventional i2c/spi that it is
> hard to justify maintaining it all for a couple of log messages - in the
> event that someone did encounter the two situations being reported the
> regmap dump would point us to the cause pretty quickly.

Hi Mark and Takashi,
Hold off merging this one - we should think about it a bit more and people
are off on PTO.
-Simon