[PATCH 2/2] ASoC: xilinx: xlnx_i2s: Discover parameters from registers

[Mark Brown]

On Thu, Jan 29, 2026 at 12:46:27PM -0500, Sean Anderson wrote:
> On 1/29/26 12:27, Mark Brown wrote:
> > On Thu, Jan 29, 2026 at 12:23:15PM -0500, Sean Anderson wrote:

> >> -	ret = of_property_read_u32(node, "xlnx,num-channels", &drv_data->channels);

> >> -	ret = of_property_read_u32(node, "xlnx,dwidth", &drv_data->data_width);

> > Given that the properties already exist it seems wise to continue to
> > parse them if available and prefer them over what we read from the
> > hardware, it would not shock me to discover that hardware exists where
> > the registers are inaccurate or need overriding due to bugs.

> I would be surprised if such hardware exists. These properties are
> automatically generated by Xilinx's tools based on the HDL core's
> properties. This has a few consequences:

> - They always exactly match the hardware unless someone has gone in and
>   modified them. I think this is unlikely in this case because they
>   directly reflect parameters that should not need to be adjusted.
> - 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?  

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260129/9460e51c/attachment.sig>