Re: [PATCH] dt-bindings: usb: usb251xb: correct swap-dx-lanes type to uint32

[Marek Vasut <marex@denx.de>]

On 5/16/23 10:19, Krzysztof Kozlowski wrote:
> On 15/05/2023 15:47, Marek Vasut wrote:
>>> Please consider the environment before printing this e-mail
>>> On 15-05-2023 14:55, Marek Vasut wrote:
>>>> On 5/15/23 12:33, Krzysztof Kozlowski wrote: diff --git
>>>> a/Documentation/devicetree/bindings/usb/usb251xb.yaml
>>>> b/Documentation/devicetree/bindings/usb/usb251xb.yaml
>>>>> index 4d1530816817..ac5b99710332 100644
>>>>> --- a/Documentation/devicetree/bindings/usb/usb251xb.yaml
>>>>> +++ b/Documentation/devicetree/bindings/usb/usb251xb.yaml
>>>>> @@ -231,7 +231,7 @@ properties:
>>>>>          power-on sequence to a port until the port has adequate power.
>>>>>        swap-dx-lanes:
>>>>> -    $ref: /schemas/types.yaml#/definitions/uint8-array
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>>        description: |
>>>>>          Specifies the ports which will swap the differential-pair
>>>>> (D+/D-),
>>>>>          default is not-swapped.
>>>>
>>>> Would it make more sense to update the driver instead ? I doubt you
>>>> could have more than 256 ports on this device after all.
>>>
>>>
>>> I guess there's a bunch of devicetrees already out there using the
>>> (misdocumented) 32-bit array binding, they'd break in a bad way...
>>
>> I think it is the other way around -- if the binding was documented as
>> u8, then the existing DTs should use the u8 type if they are compliant
>> to the binding document.
>>
>> I see one board in next which uses this property and sets it to 0 , so
>> this one is not affected either way:
>> arch/arm64/boot/dts/freescale/imx8mq-zii-ultra-rmb3.dts:
>> swap-dx-lanes = <0>;
> 
> 
> First of all, the original binding did not define it as u8. It actually
> skipped the type entirely but:
>   - Example shown u32,
>   - Driver used u32,
>   - In-tree user uses u32 (although as pointed - as 0 so not really
> relevant).
> 
> Thus the ABI is rather defined by not-breaking users here, so I would
> stick to fixing it to u32.

Fine by me.