Re: [PATCH v3 1/5] ASoC: dt-bindings: fsl,imx-asrc: update port binding to support multiple paths

On 11/08/2026 04:28, Shengjiu Wang wrote:
> On Mon, Aug 10, 2026 at 3:14 PM Krzysztof Kozlowski <[email protected]> wrote:
>>
>> On Tue, Aug 04, 2026 at 06:02:14PM +0800, [email protected] wrote:
>>> From: Shengjiu Wang <[email protected]>
>>>
>>> The i.MX ASRC hardware supports up to three conversion pairs (A, B, C).
>>
>> Which SoC? Did you read this binding you are changing?
> 
> The i.MX35 ASRC (the original) already supports three conversion pairs
> (A, B, C).
> All subsequent SoCs that reuse this IP -- including i.MX53, i.MX8QM, i.MX8QXP,
> i.MX952, share the same three-pair hardware. This binding covers all of them.
> 
>>
>>> The existing binding exposed only a single generic audio-graph port,
>>> which cannot represent independent conversion paths when multiple pairs
>>> are in use simultaneously.
>>>
>>> Add a ports container that enumerates up to three sub-ports, each
>>> representing an independent conversion path:
>>>   port@0 -- conversion path 0
>>>   port@1 -- conversion path 1
>>>   port@2 -- conversion path 2
>>>
>>> Each sub-port references audio-graph-port.yaml as before. Hardware pairs
>>> are allocated dynamically at stream open time; each active stream
>>> direction (playback or capture) on a port consumes one hardware pair.
>>>
>>> For backwards compatibility, keep the old single port property but mark
>>
>> Why? Did the old hardware change that it has more ports/paths?
> 
> The hardware has always supported three pairs; the original binding simply
> did not expose them all. This patch corrects the binding to match what the
> hardware has always been capable of.
> 
>>
>>> it deprecated. A schema constraint (not: required: [port, ports]) ensures
>>> that both forms cannot be used at the same time. The binding example is
>>> updated to show the preferred ports form.
>>>
>>> No existing upstream DTS file for fsl,imx-asrc uses the previously
>>> documented single 'port' node, so this change does not break any
>>> in-tree device tree.
>>
>> Does it break other users of this binding?
> 
> No. The existing single 'port' property is kept and marked deprecated
> so that any out-of-tree device tree still works without modification.
> The new 'ports' form is additive only.
> 
>>
>> Why mentioning upstream in the first place? Either this change breaks
>> ABI or not, explain that.
> 
> The deprecated 'port' property is retained, so this change is fully backwards
> compatible and does not break ABI.

So why? Drop redundant parts.

Best regards,
Krzysztof