On Thu, Mar 02, 2023 at 10:54:57AM +0800, Kever Yang wrote: > Hi Linus, > > On 2023/2/23 16:59, Linus Walleij wrote: > > On Mon, Feb 13, 2023 at 11:28 PM Chris Morgan <macroalph...@gmail.com> > > wrote: > > > > > From: Chris Morgan <macromor...@hotmail.com> > > > > > > Use the new devicetree property of gpio-ranges to determine the GPIO > > > bank ID. Preserve the "old" way of doing things too, so that boards > > > can be migrated and tested gradually (I only have a 3566 and 3326 to > > > test). > > > > > > Signed-off-by: Chris Morgan <macromor...@hotmail.com> > > gpio-ranges are not supposed to be used like this, because there is > > no semantic restrictions on how gpio-ranges are set up. For example: > > > > gpio-ranges = <&pfc 0 0 32>; > > > > that looks nice for this usecase, and I guess this is something > > like what you have but then look at this from arch/arm/boot/dts/hi3620.dtsi: > > > > gpio-ranges = < &pmx0 0 14 1 &pmx0 1 15 1 &pmx0 2 > > 16 1 > > &pmx0 3 16 1 &pmx0 4 16 1 &pmx0 5 > > 16 1 > > &pmx0 6 16 1 &pmx0 7 16 1>; > > I can understand the gpio-ranges and pinctrl framework are flexible enough > for different hardware. > > Rockchip SoC do not have this kind of GPIO/PINMUX hardware, one bank GPIO is > always > > in one pinctrl/ioc for now, so this driver do work for rockchip platform in > U-Boot for now. > > > Thanks, > > - Kever
I think I jumped the gun (sorry, just anxious to get my hardware supported) and it looks like Linux is going in a different direction. I'm going to work with this for now, but once Linux decides on a correct direction I'll update the driver in U-Boot to match the Linux behavior. Thank you. > > > > > This is perfectly fine as well. Ranges can start anywhere in the hardware > > offsets and go anywhere, and be set up in smaller chunks however > > the author of the DTS file wants it. > > > > I am pretty sure the same discontiguous > > ranges can be encoded into the rk_gpio relevant DTS files as well, > > so this is not a good solution to your problem. > > > > What has been used in the past is just some unique hardware ID in the > > device tree, so I would just add that. > > > > Yours, > > Linus Walleij