From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

There are 6 SPI controllers on RK3399 and they are all numbered in the
TRM, so let's add the appropriate aliases to the main DTSI so that any
RK3399-based board doesn't need to define the aliases themselves to
benefit from stable SPI indices in userspace.

Cc: Quentin Schulz <foss+kernel@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index da0dfb237f853..7b04ba526fd59 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -34,6 +34,12 @@ aliases {
 		serial2 = &uart2;
 		serial3 = &uart3;
 		serial4 = &uart4;
+		spi0 = &spi0;
+		spi1 = &spi1;
+		spi2 = &spi2;
+		spi3 = &spi3;
+		spi4 = &spi4;
+		spi5 = &spi5;
 	};
 
 	cpus {

-- 
2.43.0

On 09/01/2024 14:35, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> 
> There are 6 SPI controllers on RK3399 and they are all numbered in the
> TRM, so let's add the appropriate aliases to the main DTSI so that any
> RK3399-based board doesn't need to define the aliases themselves to
> benefit from stable SPI indices in userspace.

But that contradicts the point that board should define aliases for
exposable interfaces. Sorry, that's a NAK.

> 
> Cc: Quentin Schulz <foss+kernel@0leil.net>

No need to Cc yourself...

> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---

Best regards,
Krzysztof

Hi Krzysztof,

Am Dienstag, 9. Januar 2024, 16:15:30 CET schrieb Krzysztof Kozlowski:
> On 09/01/2024 14:35, Quentin Schulz wrote:
> > From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> > 
> > There are 6 SPI controllers on RK3399 and they are all numbered in the
> > TRM, so let's add the appropriate aliases to the main DTSI so that any
> > RK3399-based board doesn't need to define the aliases themselves to
> > benefit from stable SPI indices in userspace.
> 
> But that contradicts the point that board should define aliases for
> exposable interfaces. Sorry, that's a NAK.

didn't we have this same discussion some weeks ago? ;-) .

I.e. spi2 on Rockchip socs is called spi2 in _all_ SoC documentation,
lines in _all_ schematics are also always called spi2_foo , so as before
I really don't see any value in repeating the very same aliases in
_every_ board.

Same for i2c, uart .


It is of course different for non-numerable interfaces - like the mmcX
aliases - where the controller is named sdhci, sdmmc, sdio ... and
similar cases. These get to stay in the board dts files of course.


Heiko

> > Cc: Quentin Schulz <foss+kernel@0leil.net>
> 
> No need to Cc yourself...
> 
> > Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> > ---
> 
> Best regards,
> Krzysztof
> 
>

On 09/01/2024 16:22, Heiko Stübner wrote:
> Hi Krzysztof,
> 
> Am Dienstag, 9. Januar 2024, 16:15:30 CET schrieb Krzysztof Kozlowski:
>> On 09/01/2024 14:35, Quentin Schulz wrote:
>>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>>
>>> There are 6 SPI controllers on RK3399 and they are all numbered in the
>>> TRM, so let's add the appropriate aliases to the main DTSI so that any
>>> RK3399-based board doesn't need to define the aliases themselves to
>>> benefit from stable SPI indices in userspace.
>>
>> But that contradicts the point that board should define aliases for
>> exposable interfaces. Sorry, that's a NAK.
> 
> didn't we have this same discussion some weeks ago? ;-) .

We could have and my feedback might be repeated every time someone does
something against common policy or common sense without explaining it.

> 
> I.e. spi2 on Rockchip socs is called spi2 in _all_ SoC documentation,

This does not matter.

> lines in _all_ schematics are also always called spi2_foo , so as before

If you mean board schematics, then this matters.


> I really don't see any value in repeating the very same aliases in
> _every_ board.
> 
> Same for i2c, uart .
> 

The same as in all previous discussions: the board labels them and these
should match the board labeling.

https://lore.kernel.org/linux-rockchip/CAK8P3a25iYksubCnQb1-e5yj=crEsK37RB9Hn4ZGZMwcVVrG7g@mail.gmail.com/

https://lore.kernel.org/all/27455049.omNFrla0xU@wuerfel/

These are replies from your upstream maintainer, if you disagree with me.

Best regards,
Krzysztof

On 2024-01-09 16:22, Heiko Stübner wrote:
> Am Dienstag, 9. Januar 2024, 16:15:30 CET schrieb Krzysztof Kozlowski:
>> On 09/01/2024 14:35, Quentin Schulz wrote:
>> > From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>> >
>> > There are 6 SPI controllers on RK3399 and they are all numbered in the
>> > TRM, so let's add the appropriate aliases to the main DTSI so that any
>> > RK3399-based board doesn't need to define the aliases themselves to
>> > benefit from stable SPI indices in userspace.
>> 
>> But that contradicts the point that board should define aliases for
>> exposable interfaces. Sorry, that's a NAK.
> 
> didn't we have this same discussion some weeks ago? ;-) .
> 
> I.e. spi2 on Rockchip socs is called spi2 in _all_ SoC documentation,
> lines in _all_ schematics are also always called spi2_foo , so as 
> before
> I really don't see any value in repeating the very same aliases in
> _every_ board.
> 
> Same for i2c, uart .

Yes, and the RK356x SoC dtsi already defines the spiX aliases in the 
same way as Quentin proposed.  Taking that as an additional example, the 
RK3399 dtsi can do the same.

> It is of course different for non-numerable interfaces - like the mmcX
> aliases - where the controller is named sdhci, sdmmc, sdio ... and
> similar cases. These get to stay in the board dts files of course.
> 
> 
> Heiko
> 
>> > Cc: Quentin Schulz <foss+kernel@0leil.net>
>> 
>> No need to Cc yourself...
>> 
>> > Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>> > ---
>> 
>> Best regards,
>> Krzysztof
>> 
>> 
> 
> 
> 
> 
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip