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: <004601dafed0$d8ff8cd0$8afea670$@opensource.cirrus.com>
Date: Wed, 4 Sep 2024 14:46:30 +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 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.

-Simon