Re: [PATCH v5 1/3] ASoC: dt-bindings: qcom,q6apm-lpass-dais: Document DAI subnode

[Krzysztof Kozlowski <krzk@kernel.org>]

On 15/07/2026 08:58, Mohammad Rafi Shaik wrote:
> 
> 
> On 7/15/2026 11:35 AM, Krzysztof Kozlowski wrote:
>> On Tue, Jul 14, 2026 at 08:22:48PM +0530, Mohammad Rafi Shaik wrote:
>>> Extend the qcom,q6apm-lpass-dais device tree binding to explicitly
>>> describe Digital Audio Interface (DAI) child nodes.
>>>
>>> Add #address-cells and #size-cells to allow representation of multiple
>>> DAI instances as child nodes, and define a dai@<id> pattern to document
>>> per-DAI properties such as the interface ID and associated clocks.
>>>
>>> On platforms such as Monaco and Lemans, third-party codecs are hardware
>>> wired to the SoC and do not always have an in-tree codec driver to manage
>>> their clocks. For these designs, clock line enablement must be driven
>>> from the platform side, and this series provides the necessary support
>>> for that.
>>>
>>> On QAIF-based platforms such as Shikra and Hawi, responsibility for voting
>>> I2S MCLK and BCLK has moved from the DSP to the kernel. This series
>>> introduces the required device tree binding support to represent and
>>> vote for these clocks from the kernel.
>>>
>>> Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
>>> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
>>> ---
>>>   .../bindings/sound/qcom,q6apm-lpass-dais.yaml | 89 +++++++++++++++++++
>>>   1 file changed, 89 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>>> index 2fb95544d..b37c62ccd 100644
>>> --- a/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>>> +++ b/Documentation/devicetree/bindings/sound/qcom,q6apm-lpass-dais.yaml
>>> @@ -21,6 +21,82 @@ properties:
>>>     '#sound-dai-cells':
>>>       const: 1
>>>   
>>> +  '#address-cells':
>>> +    const: 1
>>> +
>>> +  '#size-cells':
>>> +    const: 0
>>> +
>>> +# Digital Audio Interfaces
>>> +patternProperties:
>>> +  '^dai@[0-9a-f]+$':
>>> +    type: object
>>> +    description:
>>> +      Q6DSP Digital Audio Interfaces.
>>> +
>>> +    properties:
>>> +      reg:
>>> +        maxItems: 1
>>> +        description:
>>> +          Digital Audio Interface ID
>>> +
>>> +      clocks:
>>> +        minItems: 1
>>> +        maxItems: 2
>>> +        description: MI2S clocks (mclk, bclk and/or eclk).
>>> +
>>> +      clock-names:
>>> +        minItems: 1
>>> +        maxItems: 2
>>> +
>>> +    allOf:
>>> +      - oneOf:
>>> +          - properties:
>>
>> Please don't do such stuff. Did you find it somewhere? If yes, then
>> where - so we can remove it?
>>
> 
> It was not copied from another binding.
> 
> It was my attempt to model the valid clock combinations.
> 
>> I gave you the close-to-exact syntax I expect. It was nothing like this.
> 
> clocks:
>    minItems: 1
>    maxItems: 3
> 
> 
> clock-names:
>    minItems: 1
>    maxItems: 3
>    items:
>      enum:
>        - mclk
>        - bclk
>        - eclk

But I did not wrote anything like that.

> 
> The enum version does not enforce the positional relationship between 
> clocks and clock-names,

So you do not use my code, but something completely different and does
not work, therefore you come up with another approach.

I don't know what to advise, but repeating myself seems pointless.

Previous review stays valid.



> 
> which is why I tried the oneOf approach.
> 
> My concern with the suggested syntax is that mclk is not mandatory for 
> all platforms.
> 
> For example, HAWI only requires bclk and does not use mclk, so requiring 
> mclk as the first clock-name would reject valid DTs.

Luckily I did not require mclk as first, so I do not understand why you
refer to something like that.


Best regards,
Krzysztof