[PATCH] arm: dts: sun50i-h6-orangepi-3: disable aldo2 regulator

[Maxim Karasev]

>What are you packaging, exactly? (And for what distro?) I guess it's some
>kind of U-Boot/firmware package [1]?

Yes, it's U-Boot + ATF at Alpine and Linux + WiFi/BT firmware at postmarketOS.

>So you build this per device then?

Well, not exactly. Alpine builds one shared ATF package that includes TF-A for several SoCs, plus U-Boot is a metapackage, which means that all device targets are built at the same time from the same source and then split into subpackages. Alpine wouldn't want to include separate board-specific U-Boot or ATF packages.

pmOS accepts such workarounds on the other hand, but it's still unwanted way.

>And this might not have been clear, but I was more asking for a *test* of
>this approach (rather than a random hack in your tree). I don't have
>this device, so I cannot test that easily.
>I made an easy patch the other day which introduces a TF-A build time
>option, so you would just build it for the OPi3 with
>"SUNXI_SKIP_REGULATOR_SETUP=1" on the make command line. Eventually, once
>U-Boot takes over the regulator setup, this would probably become the
>default, but for now this would just be a workaround for OPi3 users.
>It would be good to know if that fixes your problem.

Following patch workarounds the issue:

diff --git a/drivers/allwinner/axp/common.c b/drivers/allwinner/axp/common.c
index e98b16fdb..111a4d0d7 100644
--- a/drivers/allwinner/axp/common.c
+++ b/drivers/allwinner/axp/common.c
@@ -98,8 +98,9 @@ static int setup_regulator(const void *fdt, int node,

 static bool should_enable_regulator(const void *fdt, int node)
 {
-       if (fdt_getprop(fdt, node, "phandle", NULL) != NULL)
-               return true;
+//XXX: no need to enable referenced regulators
+//     if (fdt_getprop(fdt, node, "phandle", NULL) != NULL)
+//             return true;
        if (fdt_getprop(fdt, node, "regulator-always-on", NULL) != NULL)
                return true;
        return false;

However, idk if disabling regulator setup entirely won't break anything. I may test it, but I haven't got your patch.

Such config option would be pretty usable, e.g. creating a arm-trusted-firmware-no-reg-setup subpackage, which is built from same source, but with that config option, would be clean enough to be accepted in Alpine.

>It's a workaround, yes. But what I was actually wondering about: where in
>the DT you use the MAC and those regulators? I don't see any mentioning of
>that in the kernel or U-Boot tree. So is this some off-tree .dts?

Yes, kernel source we use at pmOS for allwinner is megous.com/git/linux plus some extra device-specific patches.

>Please note that I consider *distros* packaging *firmware* the wrong
>approach. Firmware is device specific, not distro-specific. There should
>be no reason that the Debian firmware for some device is different from
>the Arch Linux firmware.
>I am asking for years for people to coordinate, and publish distro-generic
>firmware. This mostly works already with current mainline U-Boot & TF-A,
>but would need some testing and fine-tuning.

Hm, I've heard about UEFI on U-Boot before and it sounds interesting, but I've never seen it in reality.

However, I see nothing wrong with distro providing a pre-build mainline U-Boot and ATF binaries somewhere at /usr/share to save user's time. It needs to be installed to the board somehow anyway, so, if not packaging, everyone would have to compile it for themselves.

pmOS just automates the process of creating a ready-to-go system images and provides useful tools and tolerance to hacks for supporting as many devices as possible.