[PATCH 1/4] dt-bindings: pinctrl: Combine MediaTek MT67xx pinctrl binding docs

yassine.oudjana at gmail.com yassine.oudjana at gmail.com
Wed Sep 21 02:25:20 PDT 2022


On Wed, Sep 21 2022 at 09:20:43 AM +0200, Krzysztof Kozlowski 
<krzysztof.kozlowski at linaro.org> wrote:
> On 19/09/2022 19:01, Yassine Oudjana wrote:
>>  From: Yassine Oudjana <y.oudjana at protonmail.com>
>> 
>>  Documents for MT6779, MT6795 and MT6797 that currently exist share
>>  most properties, and each one has slightly differently worded
>>  descriptions for those properties. Combine all three documents into
>>  one common document for all MT67xx SoC pin controllers, picking a 
>> few
>>  parts from each and accounting for differences such as items in reg
>>  and reg-names properties. Also document the MT6765 pin controller
>>  which currently has a driver but no DT binding documentation. It 
>> should
>>  be possible to also include bindings for MT8183 and MT8188, but 
>> these
>>  have some additional properties that might complicate things a bit,
>>  so they are left alone for now.
>> 
> 
>>   properties:
>>     compatible:
>>  -    const: mediatek,mt6795-pinctrl
>>  +    oneOf:
>>  +      - enum:
>>  +          - mediatek,mt6765-pinctrl
>>  +          - mediatek,mt6795-pinctrl
>>  +          - mediatek,mt6797-pinctrl
>>  +      - items:
>>  +          - const: mediatek,mt6779-pinctrl
>>  +          - const: syscon
> 
> No, this is not like old bindings at all. It's not merging, it's a
> change sneaked inside huge diff. Also - probably totally untested on 
> DTS
> (or old bindings were broken).


Actually this change was made specifically so that it remains (probably 
becomes?) compatible with existing DTS and passes checks. mt6779.dtsi 
currently has the syscon compatible string but it wasn't listed along 
with mediatek,mt6779-pinctrl in the old document, but instead there was 
something in the description about putting the pinctrl node under a 
syscon node, which isn't the case in the existing DTS. This patch 
passed both dt_binding_check and dtbs_check. Anyway, I see how I failed 
to describe this change, so I'll go through the patch again and try to 
find any other small changes I might've made and forgotten about, and 
either put them in separate patches or describe them in the commit 
message, whichever one you think is better. Also, do I make those 
changes in the original documents then combine or combine first then 
make them in the new one?

Thanks,
Yassine

(Sorry for the spam, my client was misconfigured so it previously sent 
HTML instead of plain text.)

> 
> That's a no-go.
> 
> Best regards,
> Krzysztof





More information about the linux-arm-kernel mailing list