linux-kernel - Re: [PATCH 2/2] ASoC: xilinx: xlnx_i2s: Discover parameters from registers

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: <06b3d7e0-27b5-433c-85db-23e4c5ef5472@sirena.org.uk>
Date: Thu, 29 Jan 2026 18:46:23 +0000
From: Mark Brown <broonie@...nel.org>
To: Sean Anderson <sean.anderson@...ux.dev>
Cc: Vincenzo Frascino <vincenzo.frascino@....com>,
	Liam Girdwood <lgirdwood@...il.com>, linux-sound@...r.kernel.org,
	Jaroslav Kysela <perex@...ex.cz>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Michal Simek <michal.simek@....com>, Takashi Iwai <tiwai@...e.com>
Subject: Re: [PATCH 2/2] ASoC: xilinx: xlnx_i2s: Discover parameters from
 registers

On Thu, Jan 29, 2026 at 01:17:45PM -0500, Sean Anderson wrote:
> On 1/29/26 13:09, Mark Brown wrote:

> >> - Driver authors tend to use them even when there are hardware registers
> >>   available with the same information, as Xilinx has not always been
> >>   consistent in adding such registers.

> > I'm not sure I follow your second point - driver authors tend to use
> > what?  

> Authors look at the devicetree node and see something like 

> and go "Ah, there are the properties I need." On some Xilinx cores this
> is the only way to discover certain properties, so people have gotten into
> the habit of using them even when these properties can be read from the
> device itself.

Oh.  If the properties are there it's reasonable and sensible to use
them, them being redundant is a concern when specifying the binding but
once things are there any discrepency should usually be resolved in
favour of the binding.

> >> I am not aware of any errata regarding incorrect generation of
> >> properties for this device or cases where the number of channels or bit
> >> depth was incorrect.

> > I'd still rather see the properties get used if present, worst case
> > they're redundant best case we avoid regressing a currently working
> > system.  The code is already there, it just needs tweaking to make parse
> > failures non-fatal.

> I would rather remove it for the code size reduction and simplication.

We're talking a couple of function calls with no error handling here,
I'm not sure anyone concerned about that kind of impact is running
Linux.

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