[PATCH v2 1/4] riscv: dts: spacemit: k1-bananapi-f3: Add vcc5v0_sys regulator for Banana Pi F3

[Anand Moon]

Hi Yixun,

On Mon, 11 May 2026 at 12:23, Yixun Lan <dlan at kernel.org> wrote:
>
> Hi Anand,
>
> On 20:48 Sat 09 May     , Anand Moon wrote:
> > Hi Yixun,
> >
> > On Sat, 9 May 2026 at 17:48, Yixun Lan <dlan at kernel.org> wrote:
> > >
> > > Hi Anand,
> > >
> > > On 13:06 Fri 08 May     , Anand Moon wrote:
> > > > Hi Yixun,
> > > >
> > > > Thanks for your review comments.
> > > >
> > > > On Thu, 7 May 2026 at 08:15, Yixun Lan <dlan at kernel.org> wrote:
> > > > >
> > > > > Hi Anand,
> > > > >
> > > > > On 10:48 Sat 02 May     , Anand Moon wrote:
> > > > > > Define the system 5V fixed regulator (vcc5v0_sys) supplied by the
> > > > > > DC input. As per the schematics, vcc5v0_sys is the input power source
> > > > > > for the VCC5V0_HUB and 5V_VBUS reglators. Update these regulators
> > > > > > to correctly reference vcc5v0_sys as their parent (vin-supply).
> > > > > >
> > > > > > Cc: Han Gao <gaohan at iscas.ac.cn>
> > > > > > Cc: Ze Huang <huang.ze at linux.dev>
> > > > > > Cc: Chukun Pan <amadeus at jmu.edu.cn>
> > > > > > Signed-off-by: Anand Moon <linux.amoon at gmail.com>
> > > > > > ---
> > > > > >  arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 12 ++++++++++++
> > > > > >  1 file changed, 12 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> > > > > > index 5790d927b93d..9727ecdd9f6b 100644
> > > > > > --- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> > > > > > +++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
> > > > > > @@ -50,6 +50,16 @@ reg_dc_in: regulator-dc-in-12v {
> > > > > >               regulator-always-on;
> > > > > >       };
> > > > > >
> > > > > > +     reg_vcc5v0_sys: regulator-vcc5v0-sys {
> > > > > This will fall into the catogery of "non-controllable & serve no devices"
> > > > > see similar comment for 'reg_dc_in' which raised by Krzysztof
> > > > >
> > > > > https://lore.kernel.org/all/6530526f-59ca-4753-a068-46c62a1a1fed@kernel.org/
> > > > >
> > > > > or should I ask, what's the real problem if regulator has no vin-supply?
> > > >
> > > > If the device tree is not configured with the correct power source it
> > > > will affect performance.
> > > >
> > > Please elaborate, or provide enough evidence to prove this, because the
> > > conclusion you gave here contradicts with what Krzysztof pointed out
> > I don’t have the schematic for that board, so I skipped replying.
> >
> No, you didn't answer my question, I was asking why "affect performance",
> and you just gave me the opposite conclusion
>
I tried to justify my changes according to the schematic I understood.

> Let me elaborate, the reg_vcc5v0_sys is a regulator that has no software
> or GPIO control, so no need software control from the kernel/driver perspective,
> which also mean it will be automatically enabled from hardware perspective
> once the board power up - "non-controllable" in Krzysztof's reply
>
> the reg_vcc5v0_sys currently only serve as vin for other regulator which
> is not a device (e.g not USB, PCIe, eMMC..) - "serve no devices" in
> Krzysztof's reply..
>
Many development boards follow a similar regulator structure, with
fixed regulators assigned to USB, PCIe, and other internal subsystems.
This design is consistent with the semantics diagram, so I’m not
introducing anything new.
> and by introducing reg_vcc5v0_sys, kernel driver need to do additional
> work to go through probe procedure and register the regulator device,
> consumer depend on it need to wait, this will hurt performance, slow
> down system boot and even consume more memory..
>
No, it simply defines the power hierarchy to ensure that each device receives
the appropriate power source.

> By dropping reg_vcc5v0_sys, it will result as a stripped power source
> tree, this is only downside I can see, but doesn't really hurt..
>
No issue. If my changes are breaking your development board, please drop this.

> > Please refer to the POWER TREE diagram, which provides a clear
> > visualization of the power sources.
> >
> > This board accepts two primary power sources: a 12 V DC input and USB
> > Type‑C power.
> > From the schematic’s power tree (page 4):
> >
> > Type‑C → DC_IN→ SY8386J (Uxxx) → PI PMIC
> >
> > According to the block diagram, the SY8386J regulator IC is
> > responsible for generating the VCC5V0_SYS rail  VCC4V0_SYS (see page
> > 13).
> >
> > USBVBUS → SY8386J → VCC5V0_SYS
> > USBVBUS → SY8386J → VCC4V0_SYS
> >
> > USBVBUS ( TypeC port) --> DC_IN--> 12V
> >
> > In this design, the SY8386J operates as a step‑down converter, supplying
> > both VCC4V0_SYS and VCC5V0_SYS rails and P! PMIC.
> >
> > SY8386 is a high-efficiency synchronous step-down DC/DC regulator
> > capable of delivering up to 6A with wide input voltage support and multiple
> > protection features.
> > Datasheet [1] https://datasheet4u.com/download_new.php?id=1604744
> so right, SY8386 is a passive device which need no software control,
> non-controllable..
>
Not all regulators are software-controlled.
If the K1 P1 power management IC provides 5 V rails, these can be
utilized to supply internal peripherals
> >
> > I have tried to elaborate as clearly as I can.
> > >
> > > > > Any probe failure or something bad happen? (besides /sys/../regulator_summay)
> > > >
> > > > Not really; the regulator summary just confirms the PMIC used the
> > > > correct power source.
> > > > with te device ip blocks.
> > > >
> > > then I see it's unnecessary to add this
> > >
> > > > Bananapi F3 schematics.
> > > > [1] https://drive.google.com/file/d/19iLJ5xnCB_oK8VeQjkPGjzAn39WYyylv/view
> > > > (page 24)
> > > >
> > > > Please check the shematics VCC5V0_SYS page 4
> > > > VCC5V0_SYS->USB_VCC5V0->HDMI_VCC5V0->FAN_VCC5V0->VCC3V3_SYS
> > > >
> > > > Please check the shematics VCC5V0_SYS page 24
> > > > VCC5V0_SYS input for VCC5V0_HUB and 5V_VBUS give the USB hub,
> > > > which is enabled by USB3_PWREN (gpio pin)>
> > > >
> > > > Plese check power tree page 4
> > > > USBVBUS->SY8386J UXXX -> PCIE_VCC3V3 for pcie vin source
> > > >
> > > > So, this series tries to fix the vin source for USB 3.0 and PCIe nodes.
> > > >
> > > This is not what I ask..
> > Opps, I tried, but I wasn’t able to clearly elaborate on how the power sources
> > are distributed across the various peripherals.
>
> Hope I make it clear this time..
I tried to elaborate, but wasn’t successful.
>
> --
> Yixun Lan (dlan)
Thanks
-Anand