[0/2] arm64: dts: rockchip: add SPI controller aliases to RK3399

  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.

Helios64 is the only RK3399-based device that defined aliases for SPI
controllers, but since they are now in RK3399 main DTSI, let's remove
the duplication.

Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
Quentin Schulz (2):
      arm64: dts: rockchip: add spi controller aliases on rk3399
      arm64: dts: rockchip: remove duplicate SPI aliases for helios64

 arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts | 3 ---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi               | 6 ++++++
 2 files changed, 6 insertions(+), 3 deletions(-)
---
base-commit: 9f8413c4a66f2fb776d3dc3c9ed20bf435eb305e
change-id: 20240109-rk3399-spi-aliases-a2ce468a04a3

Best regards,
-- 
Quentin Schulz <quentin.schulz@theobroma-systems.com>
  

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 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
  

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