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

[Marek Vasut]

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.