[PATCH 1/2] dt-bindings: arm: fsl: rename gw7905 to gw75xx

Rob Herring robh at kernel.org
Tue May 28 08:58:08 PDT 2024


On Sat, May 25, 2024 at 12:58:18PM -0700, Tim Harvey wrote:
> On Sat, May 25, 2024 at 11:34 AM Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org> wrote:
> >
> > On 24/05/2024 20:40, Conor Dooley wrote:
> > > On Thu, May 23, 2024 at 04:04:50PM -0700, Tim Harvey wrote:
> > >> On Thu, May 23, 2024 at 7:47 AM Conor Dooley <conor at kernel.org> wrote:
> > >>>
> > >>> On Thu, May 23, 2024 at 09:02:46AM +0200, Krzysztof Kozlowski wrote:
> > >>>> On 22/05/2024 23:50, Tim Harvey wrote:
> > >>>>> The GW7905 was renamed to GW7500 before production release.
> > >>>>>
> > >>>>> Signed-off-by: Tim Harvey <tharvey at gateworks.com>
> > >>>>> ---
> > >>>>>  Documentation/devicetree/bindings/arm/fsl.yaml | 4 ++--
> > >>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
> > >>>>>
> > >>>>> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> > >>>>> index 0027201e19f8..d8bc295079e3 100644
> > >>>>> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> > >>>>> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> > >>>>> @@ -920,8 +920,8 @@ properties:
> > >>>>>                - fsl,imx8mm-ddr4-evk       # i.MX8MM DDR4 EVK Board
> > >>>>>                - fsl,imx8mm-evk            # i.MX8MM EVK Board
> > >>>>>                - fsl,imx8mm-evkb           # i.MX8MM EVKB Board
> > >>>>> +              - gateworks,imx8mm-gw75xx-0x # i.MX8MM Gateworks Board
> > >>>>
> > >>>> That's not even equivalent. You 7500 != 75xx.
> > >>>>
> > >>>
> > >>>>>                - gateworks,imx8mm-gw7904
> > >>>>> -              - gateworks,imx8mm-gw7905-0x # i.MX8MM Gateworks Board
> > >>>>
> > >>>> Compatibles do not change. It's just a string. Fixed string.
> > >>>
> > >>> I think there's justification here for removing it, per the commit
> > >>> message, the rename happened before the device was available to
> > >>> customers.
> > >>> Additionally, I think we can give people that upstream things before they're
> > >>> publicly available a bit of slack, otherwise we're just discouraging
> > >>> people from upstreaming early.
> > >>
> > >> Hi Conor,
> > >>
> > >> Thanks for understanding - that's exactly what happened. I'm in the
> > >> habit of submitting patches early and often and it's no fun when
> > >> something like a silly product name gets changed and breaks all the
> > >> hard work.
> > >>
> > >> The board model number is stored in an EEPROM at manufacturing time
> > >> and that EEPROM model is used to build a dt name. So instead of GW7905
> > >> which would be a one-off custom design it was decided to change the
> > >> product to a GW75xx. The difference between GW7500 and GW75xx is
> > >> because we subload components on boards between GW7500/GW7501/GW7502
> > >> etc but the dt is the same.
> > >>
> > >> If there is resistance to a patch that renames it then I guess I'll
> > >> have to submit a patch that removes the obsolete board, then adds back
> > >> the same board under a different name. Shall I do that?
> > >
> > > I think this patch is fine - other than the inconsistency that Krzysztof
> > > pointed out between the "renamed to gw7500" and the "gw75xx" in the new
> > > compatible.
> >
> > I am not a fan of renaming compatibles because of marketing change,
> > because compatible does not have to reflect the marketing name, but
> > there was already precedent from Qualcomm which I did not nak, so fine
> > here as well. Double wildcard 75xx is however a bit worrying.
> >
> 
> Hi Krzysztof,
> 
> Thanks for understanding. The double-wildcard is again a marketing
> tool. All GW75** use the same device-tree by design. The boot firmware
> that chooses the device-tree understands this and for a GW7521 for
> example would look for gw7521 first, gw752x next, gw75xx last.

You haven't documented the other 2 though.

How do "all GW75** use the same device-tree", but then there are 3 
possible DTs for just 1 board?

Selecting a DT is not a unique problem. We don't need unique 
solutions. There's the QCom board-id proposal[1] and OS provided DT[2] 
which are addressing similar issues.

Rob

[1] https://lore.kernel.org/all/20240521-board-ids-v3-0-e6c71d05f4d2@quicinc.com/
[2] https://lists.linaro.org/archives/list/boot-architecture@lists.linaro.org/thread/DZCZSOCRH5BN7YOXEL2OQKSDIY7DCW2M/



More information about the linux-arm-kernel mailing list