[PATCH 3/3] arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E
Heiko Stübner
heiko at sntech.de
Mon Jan 11 02:50:33 EST 2021
Am Montag, 11. Januar 2021, 04:27:47 CET schrieb Chen-Yu Tsai:
> On Mon, Jan 11, 2021 at 4:06 AM Heiko Stübner <heiko at sntech.de> wrote:
> >
> > Hi,
> >
> > Am Sonntag, 10. Januar 2021, 16:37:15 CET schrieb Chen-Yu Tsai:
> > > > > + vcc_sd: sdmmc-regulator {
> > > > > + compatible = "regulator-fixed";
> > > > > + gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>;
> > > > > + pinctrl-names = "default";
> > > > > + pinctrl-0 = <&sdmmc0m1_pin>;
> > > >
> > > > > + regulator-boot-on;
> > > > > + regulator-name = "vcc_sd";
> > > >
> > > > regulator-name above other regulator properties
> > >
> > > That is actually what I was used to, but some other rockchip dts files
> > > have all the properties sorted alphabetically. So I stuck with what I
> > > saw.
> >
> > I try to keep it alphabetical except for the exceptions :-D .
> >
> > regulator-name is such an exception. Similar to compatibles, the
> > regulator-name is an entry needed to see if you're at the right node,
> > so I really like it being the topmost regulator-foo property - just makes
> > reading easier.
> >
> > (same for the compatible first, then regs, interrupts parts, as well
> > as "status-last")
> >
> > But oftentimes, I just fix the ordering when applying - but seem to have
> > missed this somewhere in those "other Rockchip dts files" ;-) .
>
> I was slightly confused. I looked again and yes regulator-name is always the
> first regulator related property. What's off is that in some cases min/max
> voltage comes before always-on/boot-on, and in others vice versa.
>
> For example in the Rock64 and ROC-RK3328-CC device trees, in the fixed
> regulators, always-on/boot-on come before min/max voltage, while in the
> PMIC the other order is used.
That's likely undecidednes on my part ;-)
There could be an argument for a "name, voltages, flags" sorting, but on
the other hand just keeping it alphabetical with the naming on top
creates less special cases.
Heiko
More information about the linux-arm-kernel
mailing list