linux-kernel - Re: [PATCH AUTOSEL 5.18 089/159] ASoC: tscs454: Add endianness flag in snd_soc_component

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]

Date:   Mon, 30 May 2022 15:42:40 +0000
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Mark Brown <broonie@...nel.org>
CC:     Sasha Levin <sashal@...nel.org>, <linux-kernel@...r.kernel.org>,
        <stable@...r.kernel.org>, <steven.eckhoff.opensource@...il.com>,
        <lgirdwood@...il.com>, <perex@...ex.cz>, <tiwai@...e.com>,
        <alsa-devel@...a-project.org>
Subject: Re: [PATCH AUTOSEL 5.18 089/159] ASoC: tscs454: Add endianness flag
 in snd_soc_component_driver

On Mon, May 30, 2022 at 04:20:02PM +0200, Mark Brown wrote:
> On Mon, May 30, 2022 at 09:23:14AM -0400, Sasha Levin wrote:
> > From: Charles Keepax <ckeepax@...nsource.cirrus.com>
> > 
> > [ Upstream commit ff69ec96b87dccb3a29edef8cec5d4fefbbc2055 ]
> > 
> > The endianness flag is used on the CODEC side to specify an
> > ambivalence to endian, typically because it is lost over the hardware
> > link. This device receives audio over an I2S DAI and as such should
> > have endianness applied.
> > 
> > A fixup is also required to use the width directly rather than relying
> > on the format in hw_params, now both little and big endian would be
> > supported. It is worth noting this changes the behaviour of S24_LE to
> > use a word length of 24 rather than 32. This would appear to be a
> > correction since the fact S24_LE is stored as 32 bits should not be
> > presented over the bus.
> 
> This series of commits doesn't feel like a good idea for stable,
> it will probably be safe but it's effectively new feature stuff
> so out of scope and there's some possibility we might uncover
> some bug which might've been being masked.

Strongly agree here, no need to back port these to stable.

Thanks,
Charles