linux-kernel - Re: [PATCH 7/7] ASoC: dt-bindings: mediatek,mt8188-afe: add audio properties

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: <382bc15e-f4e3-3a9f-9dbc-4d46ac1d76d6@collabora.com>
Date:   Mon, 17 Apr 2023 09:55:16 +0200
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Trevor Wu (吳文良) <Trevor.Wu@...iatek.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski@...aro.org" <krzysztof.kozlowski@...aro.org>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "tiwai@...e.com" <tiwai@...e.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "perex@...ex.cz" <perex@...ex.cz>
Cc:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 7/7] ASoC: dt-bindings: mediatek,mt8188-afe: add audio
 properties

Il 17/04/23 04:44, Trevor Wu (吳文良) ha scritto:
> On Sat, 2023-04-15 at 11:00 +0200, Krzysztof Kozlowski wrote:
>>
>> On 13/04/2023 12:47, Trevor Wu wrote:
>>> Assign top_a1sys_hp clock to 26M, and add apll1_d4 to clocks for
>>> switching
>>> the parent of top_a1sys_hp dynamically
>>> On the other hand, "mediatek,infracfg" is included for bus
>>> protection.
>>>
>>> Signed-off-by: Trevor Wu <trevor.wu@...iatek.com>
>>> ---
>>>   .../bindings/sound/mediatek,mt8188-afe.yaml    | 18
>>> ++++++++++++++++++
>>>   1 file changed, 18 insertions(+)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
>>> b/Documentation/devicetree/bindings/sound/mediatek,mt8188-afe.yaml
>>> index 82ccb32f08f2..03301d5082f3 100644
>>> --- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-
>>> afe.yaml
>>> +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-
>>> afe.yaml
>>> @@ -29,6 +29,10 @@ properties:
>>>       $ref: /schemas/types.yaml#/definitions/phandle
>>>       description: The phandle of the mediatek topckgen controller
>>>
>>> +  mediatek,infracfg:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description: The phandle of the mediatek infracfg controller
>>> +
>>>     power-domains:
>>>       maxItems: 1
>>>
>>> @@ -37,6 +41,7 @@ properties:
>>>         - description: 26M clock
>>>         - description: audio pll1 clock
>>>         - description: audio pll2 clock
>>> +      - description: audio pll1 divide 4
>>>         - description: clock divider for i2si1_mck
>>>         - description: clock divider for i2si2_mck
>>>         - description: clock divider for i2so1_mck
>>> @@ -58,6 +63,7 @@ properties:
>>>         - const: clk26m
>>>         - const: apll1
>>>         - const: apll2
>>> +      - const: apll1_d4
>>
>> Why do you add clocks in the middle? The order is strict, so you just
>> broke all DTS.
>>
> 
> In DTS file, I only need to make sure that the order in clocks should
> be the same as clock-names, so I misunderstood that I can add the clock
> in the middle based on the clock type.
> 
> Sorry, I didn't know the order is strict. I will move the new clock to
> the last one in v2.
> 

Actually, doing that is borderline-ok... there's no devicetree for MT8188
upstream, so that's not breaking anything at all.
In any case, I agree that you should generally avoid doing that but I think
that in this specific case it's fine; I'm not a devicetree maintainer though.

P.S.: Trevor, next time please make reviewers aware of the fact that no 8188
       devicetree is present upstream!

Regards,
Angelo