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 for Android: free password hash cracker in your pocket

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

Message-ID: <fbc56ced-ad76-492d-b446-630f97d427b1@linux.dev>
Date: Thu, 29 Jan 2026 12:51:47 -0500
From: Sean Anderson <sean.anderson@...ux.dev>
To: Andrew Lunn <andrew@...n.ch>
Cc: Vincenzo Frascino <vincenzo.frascino@....com>,
 Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 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 1/29/26 12:37, Andrew Lunn wrote:
>> -	ret = of_property_read_u32(node, "xlnx,num-channels", &drv_data->channels);
>> -	if (ret < 0) {
>> -		dev_err(dev, "cannot get supported channels\n");
>> -		return ret;
>> -	}
> 
> I don't know this device at all, so i might be asking dumb
> questions....
> 
> It is possible that the device supports multiple channels, but the use
> case is mono, and so xlnx,num-channels is 1 in DT? Would that break
> given your change?

drv_data->channels is multiplied by 2, so there is always an even number
of channels. Pairs of channels are always muxed together and AFAICT
there's no way to disable them individually.

>> -	ret = of_property_read_u32(node, "xlnx,dwidth", &drv_data->data_width);
> 
> Could it be the device supports 24 bits, but the use case only wants
> 16, and so has this property set to 16?

I don't think that's possible. There's an option to output 32-bit audio,
but none to reduce 24-bit audio to 16 bit.

For some perspective, this is a soft core and these properties reflect
the configuration chosen when the core was built. The data path is fixed
and these devicetree properties exist to tell the driver how the core
was configured. If you set xlnx,dwidth to 16 and the core was configured
for 24-bit audio, you will silently get 24-bit audio (and the clocks
will be incorrect).

--Sean