This series fixes hardware voltage constraints and enables flexible power
tree configurations for the SpacemiT P1 PMIC.

In v2, rebased to Spacemit SoC's k1/dt-for-next and added power tree
definition for K1 Milkv Jupiter.

Patch 1, n_voltages is corrected to match hardware register widths, as the
previous values prevented regulators from reaching higher operational
voltages (e.g., 3.3V on LDOs).

Patch 2-4, hardcoded supply assumptions are replaced with explicit
devicetree properties. PMIC supply connections are board-design decisions.
Moving this to DT allows supporting varied topologies without driver
modifications.

Note: Patch 3 introduces a bisect breakage by transitioning to
pin-specific supply names. Probe failures will occur on existing boards
until Patch 4 updates the corresponding DTS file.

Changes in v2:
- Patch 2: dt-bindings, remove providers from the example dts.
- Patch 4: Added the pmic supply properties for K1 Milkv Jupiter.
           Updated the commit message accordingly.
- Link to v1: https://lore.kernel.org/r/20260122-spacemit-p1-v1-0-309be27fbff9@riscstar.com

Signed-off-by: Guodong Xu <guodong@riscstar.com>
---
Guodong Xu (4):
      regulator: spacemit-p1: Fix n_voltages for BUCK and LDO regulators
      dt-bindings: mfd: spacemit,p1: Add individual regulator supply properties
      regulator: spacemit-p1: Update supply names
      riscv: dts: spacemit: Update PMIC supply properties for BPI-F3 and Jupiter

 .../devicetree/bindings/mfd/spacemit,p1.yaml       | 49 +++++++++++++++++++++-
 arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts    | 12 +++++-
 arch/riscv/boot/dts/spacemit/k1-milkv-jupiter.dts  | 12 +++++-
 drivers/regulator/spacemit-p1.c                    | 25 ++++++-----
 4 files changed, 81 insertions(+), 17 deletions(-)
---
base-commit: 5164e95565d3fd508ca8a95351323f5716dfb695
change-id: 20260122-spacemit-p1-ae596efe885f

Best regards,
-- 
Guodong Xu <guodong@riscstar.com>

On 1/24/26 08:20, Guodong Xu wrote:
> [...]
>
> Note: Patch 3 introduces a bisect breakage by transitioning to
> pin-specific supply names. Probe failures will occur on existing boards
> until Patch 4 updates the corresponding DTS file.

Ouch, that's not a bisect breakage, that's an *ABI breakage*. And AFAICT
this is still not okay in 2026,
see Documentation/devicetree/bindings/ABI.rst

So the bindings would need to be changed to accept both the new and old way.

Driver-wise, at a cursory look from someone not familiar with the
regulator stuff, maybe we can make it compatible with old DTS by adding
the new names as aliases ({devm_,}regulator_register_supply_alias?) as
"vin" or "buck5", if we see the old vin-supply definitions?

On Sat, Jan 24, 2026 at 2:25 PM Vivian Wang <wangruikang@iscas.ac.cn> wrote:
>
>
> On 1/24/26 08:20, Guodong Xu wrote:
> > [...]
> >
> > Note: Patch 3 introduces a bisect breakage by transitioning to
> > pin-specific supply names. Probe failures will occur on existing boards
> > until Patch 4 updates the corresponding DTS file.
>
> Ouch, that's not a bisect breakage, that's an *ABI breakage*. And AFAICT
> this is still not okay in 2026,
> see Documentation/devicetree/bindings/ABI.rst
>
> So the bindings would need to be changed to accept both the new and old way.

Ideally yes. However, considering this ABI change's actual effect, the two
K1 boards (BPI-F3 and Jupiter) in the kernel get their power settings
from boot firmware as well, and the types of peripherals enabled in the .dts
files are very limited, the probe failure of the pmic regulator doesn't
affect much. So, I think this breakage is acceptable.

>
> Driver-wise, at a cursory look from someone not familiar with the
> regulator stuff, maybe we can make it compatible with old DTS by adding
> the new names as aliases ({devm_,}regulator_register_supply_alias?) as
> "vin" or "buck5", if we see the old vin-supply definitions?
>

We can do that of course. My hesitation is, however, it makes the driver take
extra code which may not be needed once all .dts files have been updated. The
driver code will be left there forever.

BR,
Guodong Xu

On Sun, Jan 25, 2026 at 12:18 PM Guodong Xu <guodong@riscstar.com> wrote:
>
> On Sat, Jan 24, 2026 at 2:25 PM Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> >
> >
> > On 1/24/26 08:20, Guodong Xu wrote:
> > > [...]
> > >
> > > Note: Patch 3 introduces a bisect breakage by transitioning to
> > > pin-specific supply names. Probe failures will occur on existing boards
> > > until Patch 4 updates the corresponding DTS file.
> >
> > Ouch, that's not a bisect breakage, that's an *ABI breakage*. And AFAICT
> > this is still not okay in 2026,
> > see Documentation/devicetree/bindings/ABI.rst
> >
> > So the bindings would need to be changed to accept both the new and old way.
>
> Ideally yes. However, considering this ABI change's actual effect, the two
> K1 boards (BPI-F3 and Jupiter) in the kernel get their power settings
> from boot firmware as well, and the types of peripherals enabled in the .dts
> files are very limited, the probe failure of the pmic regulator doesn't
> affect much. So, I think this breakage is acceptable.
>
> >
> > Driver-wise, at a cursory look from someone not familiar with the
> > regulator stuff, maybe we can make it compatible with old DTS by adding
> > the new names as aliases ({devm_,}regulator_register_supply_alias?) as
> > "vin" or "buck5", if we see the old vin-supply definitions?
> >
>
> We can do that of course. My hesitation is, however, it makes the driver take
> extra code which may not be needed once all .dts files have been updated. The
> driver code will be left there forever.
>

Mark gave his opinion in v1 review [1], please allow me to partially quote
here: "(it's an ABI change so shouldn't really happen, but perhaps there are
few enough users for everyone to coordinate and it's what you all prefer)."

I do expect to collect more ideas before I decide whether and what to do in
v3, or maybe v3 is not required.

Link: https://lore.kernel.org/all/2e2c2754-fd3e-4fd3-aae4-d7af63e3b528@sirena.org.uk/
[1]

> BR,
> Guodong Xu

Hi Guodong,

On 12:27 Sun 25 Jan     , Guodong Xu wrote:
> On Sun, Jan 25, 2026 at 12:18 PM Guodong Xu <guodong@riscstar.com> wrote:
> >
> > On Sat, Jan 24, 2026 at 2:25 PM Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> > >
> > >
> > > On 1/24/26 08:20, Guodong Xu wrote:
> > > > [...]
> > > >
> > > > Note: Patch 3 introduces a bisect breakage by transitioning to
> > > > pin-specific supply names. Probe failures will occur on existing boards
> > > > until Patch 4 updates the corresponding DTS file.
> > >
> > > Ouch, that's not a bisect breakage, that's an *ABI breakage*. And AFAICT
> > > this is still not okay in 2026,
> > > see Documentation/devicetree/bindings/ABI.rst
> > >
> > > So the bindings would need to be changed to accept both the new and old way.
> >
> > Ideally yes. However, considering this ABI change's actual effect, the two
> > K1 boards (BPI-F3 and Jupiter) in the kernel get their power settings
> > from boot firmware as well, and the types of peripherals enabled in the .dts
> > files are very limited, the probe failure of the pmic regulator doesn't
> > affect much. So, I think this breakage is acceptable.
> >
> > >
> > > Driver-wise, at a cursory look from someone not familiar with the
> > > regulator stuff, maybe we can make it compatible with old DTS by adding
> > > the new names as aliases ({devm_,}regulator_register_supply_alias?) as
> > > "vin" or "buck5", if we see the old vin-supply definitions?
> > >
> >
> > We can do that of course. My hesitation is, however, it makes the driver take
> > extra code which may not be needed once all .dts files have been updated. The
> > driver code will be left there forever.
> >
> 
> Mark gave his opinion in v1 review [1], please allow me to partially quote
> here: "(it's an ABI change so shouldn't really happen, but perhaps there are
> few enough users for everyone to coordinate and it's what you all prefer)."
> 
> I do expect to collect more ideas before I decide whether and what to do in
> v3, or maybe v3 is not required.
> 
As I checked the dts tree (DT queued for v6.20), although we introduced the
regulator of P1/PMIC, but there is no consumers so far, so in real life, we
shouldn't break anything. In this case, I'd suggest we just give up for doing
the ABI backward compatible work which should simplify our life..

> Link: https://lore.kernel.org/all/2e2c2754-fd3e-4fd3-aae4-d7af63e3b528@sirena.org.uk/
> [1]
> 
> > BR,
> > Guodong Xu
> 

-- 
Yixun Lan (dlan)

On 1/25/26 19:03, Yixun Lan wrote:
> Hi Guodong,
>
> On 12:27 Sun 25 Jan     , Guodong Xu wrote:
>> On Sun, Jan 25, 2026 at 12:18 PM Guodong Xu <guodong@riscstar.com> wrote:
>>> On Sat, Jan 24, 2026 at 2:25 PM Vivian Wang <wangruikang@iscas.ac.cn> wrote:
>>>>
>>>> On 1/24/26 08:20, Guodong Xu wrote:
>>>>> [...]
>>>>>
>>>>> Note: Patch 3 introduces a bisect breakage by transitioning to
>>>>> pin-specific supply names. Probe failures will occur on existing boards
>>>>> until Patch 4 updates the corresponding DTS file.
>>>> Ouch, that's not a bisect breakage, that's an *ABI breakage*. And AFAICT
>>>> this is still not okay in 2026,
>>>> see Documentation/devicetree/bindings/ABI.rst
>>>>
>>>> So the bindings would need to be changed to accept both the new and old way.
>>> Ideally yes. However, considering this ABI change's actual effect, the two
>>> K1 boards (BPI-F3 and Jupiter) in the kernel get their power settings
>>> from boot firmware as well, and the types of peripherals enabled in the .dts
>>> files are very limited, the probe failure of the pmic regulator doesn't
>>> affect much. So, I think this breakage is acceptable.
>>>
>>>> Driver-wise, at a cursory look from someone not familiar with the
>>>> regulator stuff, maybe we can make it compatible with old DTS by adding
>>>> the new names as aliases ({devm_,}regulator_register_supply_alias?) as
>>>> "vin" or "buck5", if we see the old vin-supply definitions?
>>>>
>>> We can do that of course. My hesitation is, however, it makes the driver take
>>> extra code which may not be needed once all .dts files have been updated. The
>>> driver code will be left there forever.
>>>
>> Mark gave his opinion in v1 review [1], please allow me to partially quote
>> here: "(it's an ABI change so shouldn't really happen, but perhaps there are
>> few enough users for everyone to coordinate and it's what you all prefer)."
>>
>> I do expect to collect more ideas before I decide whether and what to do in
>> v3, or maybe v3 is not required.
>>
> As I checked the dts tree (DT queued for v6.20), although we introduced the
> regulator of P1/PMIC, but there is no consumers so far, so in real life, we
> shouldn't break anything. In this case, I'd suggest we just give up for doing
> the ABI backward compatible work which should simplify our life..

Having checked again, I agree that this is not that big of a problem.
The breakage with old DT is limited to an otherwise harmless error on
boot that doesn't affect functionality since there are no users.

Vivian "dramforever" Wang.