Re: [PATCH v6 1/8] dt-bindings: pinctrl: mediatek,mt6779-pinctrl: Pull pinctrl node changes from MT6795 document

[AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>]

Il 11/10/24 18:56, Rob Herring ha scritto:
> On Fri, Oct 11, 2024 at 03:03:46PM +0300, Yassine Oudjana wrote:
>> From: Yassine Oudjana <y.oudjana@protonmail.com>
>>
>> mediatek,pinctrl-mt6795.yaml has different node name patterns which match
>> bindings of other MediaTek pin controllers, ref for pinmux-node.yaml which
>> has a description of the pinmux property, as well as some additional
>> descriptions for some pin configuration properties. Pull those changes
>> into mediatek,mt6779-pinctrl.yaml and adjust the example DTS to match in
>> preparation to combine the MT6795 document into it.
>>
>> Signed-off-by: Yassine Oudjana <y.oudjana@protonmail.com>
>> ---
>>   .../pinctrl/mediatek,mt6779-pinctrl.yaml      | 38 ++++++++++++++-----
>>   1 file changed, 28 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml
>> index 3bbc00df5548d..352a88d7b135e 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml
>> +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml
>> @@ -111,12 +111,12 @@ allOf:
>>           - "#interrupt-cells"
>>   
>>   patternProperties:
>> -  '-[0-9]*$':
>> +  '-pins$':
> 
> Worst case, this could be an ABI break. Best case, it's churn for
> mt6779. Is it worth unifying?
> 
All those MediaTek pinctrl bindings are mostly the same, where only the pin
definitions in the binding header does actually change.

I think that it's worth unifying them, not only to get rid of the duplication
but mostly for consistency between all of those subnode names which are wildly
differing for no real reason... and consistency is a long time issue with
MediaTek bindings/dts in general (which is way way way better now, but still)...

Besides - just for context and nothing else: the driver doesn't care about
the names of the subnodes, anyway... so while this is technically an ABI break
it's not really creating any functionality issue, and then, actually, Yassine
is also modifying the devicetrees to comply with his consistency changes, so,
in my own perspective, it's still acceptable.

If you think otherwise, though, I'm still fine with your POV.

Cheers,
Angelo