[PATCH 1/3] arm64: dts: rk3399: sync rk3399.dtsi from 6.1-rc1

[Quentin Schulz]

Hi Peter,

On 1/3/23 13:54, Peter Robinson wrote:
> Hi Quentin,
> 
>> On 10/25/22 09:52, Peter Robinson wrote:
[...]
>>> -             gpio0: gpio0 at ff720000 {
>>> +             gpio0: gpio at ff720000 {
>>
>> Thanks for looking at this update, I myself was playing with this for
>> all Rockchip devices but it's really not that easy to do unfortunately.
>>
>> Please note that this will break the gpio driver, c.f. the logic here:
>> https://urldefense.com/v3/__https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/gpio/rk_gpio.c*L154-L157__;Iw!!OOPJP91ZZw!hLFFb5olGCLZCouGdY-bivknYF7_oYLhWwjT1EpkCC38BLNtmJodAnbrmQD2y7-74oP8jX4ToE6scPcAvFHMWJgfvKQORGtO5g$
> 
> If you check v2 of this patch series I've currnently dropped this patch for now.
> 
>> Please DO NOT use the logic used in the kernel, it's broken and works by
>> chance and will not work in U-Boot.
>>
>> I'm tempted to add a new DT property like:
>> rockchip,gpio-controller = <0>;
>> in gpio0,
>> rockchip,gpio-controller = <1>;
>> in gpio1, etc....
>>
>> I don't think U-boot cares too much about DT backward compatibility so
>> this wouldn't be much of a problem. It's a different issue in the Linux
>> kernel but that's not the place to discuss this :)
> 
> Well we do because for a SystemReady IR platform the firmware provides
> the DT and that's not a differnt DT to the one used in U-Boot.
> 
> So what ever that gets added in U-Boot needs to go upstream else it
> will just end up in a world of pain. Ultimately one way or the other
> this problem is going to have to be solved in U-Boot too.
> 

I guess that's what Simon was working on in the last few months? c.f. 
https://lore.kernel.org/u-boot/20221102031312.216353-1-sjg@chromium.org/

Is the plan to get rid of those -u-boot.dtsi and have those properties 
replaced with the ones specified in the link above, directly in DTS in 
the Linux kernel? Otherwise I'm quite curious on how you plan to achieve 
this for SystemReady IR platforms? Or are you using U-Boot's DT for the 
kernel?

For now, like Jagan suggested, we could have those U-Boot-specific 
properties in the -u-boot.dtsi, if there's a need for a new DT property 
(which the kernel probably won't go for since that would break backward 
compatibility).

Another thought I had was to just check the register address of the gpio 
controller and do the mapping in the driver directly. Not nice, but the 
most straightforward fix I think.

> Kever: what's the Rockchip plan here to sort this out?
> 

I've notified Heiko about the shortcomings of the kernel implementation 
but unless the probe order of the gpio controllers in the pinctrl node 
is not stable or someone specifies gpio aliases which aren't matching 
the same numbering scheme as the SoC GPIO controllers, there is no hurry 
to fix it.

Cheers,
Quentin