Received-SPF: pass (google.com: domain of linux-kernel+bounces-149586-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 18 Apr 2024 08:33:55 +0200
From: Dragan Simic <dsimic@manjaro.org>
To: FUKAUMI Naoki <naoki@radxa.com>
Cc: Chukun Pan <amadeus@jmu.edu.cn>, jonas@kwiboo.se, conor+dt@kernel.org,
 devicetree@vger.kernel.org, heiko@sntech.de, krzk+dt@kernel.org,
 linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
 linux-rockchip@lists.infradead.org, robh@kernel.org
Subject: Re: [PATCH 2/2] arm64: dts: rockchip: Add Radxa ROCK3 Model C
In-Reply-To: <9e915ef29a2b49ce56446ec9d474eb64@manjaro.org>
References: <d7de2213-8dd2-42ec-9a30-a569ac71be3e@kwiboo.se>
 <20240417133016.62753-1-amadeus@jmu.edu.cn>
 <a144c052fcc2460a615a754a64a8f739@manjaro.org>
 <B26C732A4DCEA9B3+282b8775-601b-4d4a-a513-4924b7940076@radxa.com>
 <9e915ef29a2b49ce56446ec9d474eb64@manjaro.org>
Message-ID: <ebf7b5f5ff4cd3c8cbee36f35df6ef5d@manjaro.org>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit

Hello all,

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.