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

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

Message-ID: <f7b1e54804317616f964d669425a247edc0f21eb.camel@mediatek.com>
Date:   Thu, 20 Apr 2023 06:25:16 +0000
From:   Trevor Wu (吳文良) <Trevor.Wu@...iatek.com>
To:     "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>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>
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

On Tue, 2023-04-18 at 14:25 +0200, Krzysztof Kozlowski wrote:
> On 18/04/2023 12:23, Trevor Wu (吳文良) wrote:
> > > 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!
> > > 
> > 
> > Got it. Thanks.
> > 
> > 
> > Hi krzysztof,
> > 
> > Because there is no upstream mt8188 DTS, should I move the new
> > clock to
> > the end of clock list?
> 
> What is the reason to add them in the middle? So far there was no
> argument, so always add at the end. If you have an argument, let's
> discuss it.
> 
No special reason. Just hope to sort the clock by the clock type.
But it's possible to extend the clock list after we upstream MT8188
DTS, so it won't follow the order finally.
I think it is fine to put the clock at the end. I will move it to the
end in V2.

> > 
> > If I move "apll1_d4" to the end of the list at binding file, when I
> > upstream the devicetree node existing clocks and clock-names
> > properties
> > , should I follow the sequence defined in dt-bindings
> 
> If you do not follow the sequence of bindings, you upstream incorrect
> DTS which does not follow ABI and fails the tests. Therefore yes, use
> the same order as your bindings define.
> 
> > or can I have a
> > new sequence based on the clock type or alphabet?
> 
> Sorry, I don't know what is the order of clock type and alphabet. If
> you
> mean anything else than bindings, then no, because how is it supposed
> to
> work then?
> 
> 
Got it. Thanks for the detailed explanation.
I will follow the order as bindings when I update the DTS node.


Thanks,
Trevor