Re: [PATCH 2/2] arm64: dts: rockchip: Add Radxa ROCK3 Model C

[Dragan Simic]

On 2024-04-18 08:33, Dragan Simic wrote:
> On 2024-04-18 07:55, Dragan Simic wrote:
> > On 2024-04-18 07:52, FUKAUMI Naoki wrote:
> > > this is Naoki @ Radxa.
> > >
> > > thank you for your great work!
> > >
> > > On 4/18/24 02:02, Dragan Simic wrote:
> > > > Hello Chukun,
> > > >
> > > > On 2024-04-17 15:30, Chukun Pan wrote:
> > > > > Hi Jonas,
> > > > > > > +    model = "Radxa ROCK3 Model C";
> > > > > >
> > > > > > The marketing name seems to be "Radxa ROCK 3C" according to the 
> > > > > > product
> > > > > > page at [1].
> > > > > >
> > > > > > [1] https://radxa.com/products/rock3/3c
> > > > >
> > > > > According to https://wiki.radxa.com/Rock3/3c , it should be called
> > > > > "Radxa ROCK 3 Model C". I copied rock3a here without paying 
> > > > > attention.
> > >
> > > sorry, wiki.radxa.com is outdated.
> > >
> > > docs.radxa.com is correct one and maintained.
> > > (but it still has some errors, sorry)
> > >
> > > > If I may interject, here's the result of a quick qrep:
> > > >
> > > > ./rk3399pro-rock-pi-n10.dts:    model = "Radxa ROCK Pi N10";
> > > > ./rk3399-rock-pi-4a-plus.dts:    model = "Radxa ROCK Pi 4A+";
> > > > ./rk3588s-rock-5a.dts:    model = "Radxa ROCK 5 Model A";
> > > > ./rk3588-rock-5b.dts:    model = "Radxa ROCK 5 Model B";
> > > > ./rk3399-rock-4c-plus.dts:    model = "Radxa ROCK 4C+";
> > > > ./rk3399-rock-pi-4b-plus.dts:    model = "Radxa ROCK Pi 4B+";
> > > > ./rk3399-rock-pi-4b.dts:    model = "Radxa ROCK Pi 4B";
> > > > ./rk3399-rock-pi-4c.dts:    model = "Radxa ROCK Pi 4C";
> > > > ./rk3308-rock-pi-s.dts:    model = "Radxa ROCK Pi S";
> > > > ./rk3399-rock-pi-4a.dts:    model = "Radxa ROCK Pi 4A";
> > > > ./rk3399-rock-4se.dts:    model = "Radxa ROCK 4SE";
> > > > ./rk3328-rock-pi-e.dts:    model = "Radxa ROCK Pi E";
> > > > ./rk3568-rock-3a.dts:    model = "Radxa ROCK3 Model A";
> > > >
> > > > Based on that, I think that "Radxa ROCK 3 Model C" would actually
> > > > be the preferred name...  Perhaps?
> > > >
> > > > If we end up following that approach, the last board dts on the list
> > > > above should also be fixed to read "Radxa ROCK 3 Model A".
> > > >
> > > > Either that, or all "Model " strings should be stripped out from
> > > > all board dts files that currently contain it.
> > >
> > > we have a document named "Radxa Product Naming Convention".
> > > there are "full name" and "short name". "Model" is used in "full
> > > name", but it's not used in "short name". both are correct.
> > >
> > > but, we preferred to use "short name" for "model = " in mainline 
> > > linux/u-boot.
> > >
> > > for ROCK 3C, please use
> > >
> > >  model = "Radxa ROCK 3C";
> > >
> > > for ROCK 5A/5B and ROCK 3A,
> > >
> > >  model = "Radxa ROCK 5A";
> > >  model = "Radxa ROCK 5B";
> > >  model = "Radxa ROCK 3A";
> > >
> > > are preferred.
> > >
> > > we need to fix this inconsistency. (include our docs)
> >
> > Great, thanks for this detailed clarification!
>
> I went ahead and prepared a patch that cleans up currently present
> naming inconsistencies for the Radxa boards.  AFAICT, there should
> be no issues arising from the changes in the "model" and "compatible"
> strings, because they aren't used anywhere in the drivers.  There
> are no board-specific ALSA UCM2 profiles, which could be affected
> by those changes.  U-Boot is also fine.
>
> I'll think a bit more about it, and I'll send the patch over a bit
> later.  If it goes well, I'll prepare and send one more similar patch,
> for some other boards.

Actually, a couple of board dts(i) files, listed below, need to
be renamed to add dashes into their names.  That, together with
the other naming cleanups I've already prepared, would make the
naming cleanup of the Radxa boards complete.

- arch/arm/boot/dts/rockchip/rk3288-rock2-som.dtsi
  (-> arch/arm/boot/dts/rockchip/rk3288-rock-2-som.dtsi)
- arch/arm/boot/dts/rockchip/rk3288-rock2-square.dts
  (-> arch/arm/boot/dts/rockchip/rk3288-rock-2-square.dts)

I see no possible issues in the kernel arising from these two
file renames, with the other related changes applied, of course,
but there are some issues in U-Boot.  Luckily, overcoming those
issues shouldn't be too hard, and I've already submitted a small
preparatory patch to the U-Boot mailing list. [1]  We'll see
how it goes.

[1] 
https://lore.kernel.org/u-boot/369151a2b8d73d733ca79eca98d4d5958f90d491.1713423687.git.dsimic@xxxxxxxxxxx/