[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