[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAH1PCMbEcVa6mAvw9UAG2T2Jy0W-+nEcw79nTHDJr9xgEdm0VA@mail.gmail.com>
Date: Sun, 25 Jan 2026 12:27:40 +0800
From: Guodong Xu <guodong@...cstar.com>
To: Vivian Wang <wangruikang@...as.ac.cn>
Cc: Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Yixun Lan <dlan@...too.org>,
Alex Elder <elder@...cstar.com>, Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Troy Mitchell <troy.mitchell@...ux.spacemit.com>, Paul Walmsley <pjw@...nel.org>,
Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
Alexandre Ghiti <alex@...ti.fr>, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org, spacemit@...ts.linux.dev,
devicetree@...r.kernel.org
Subject: Re: [PATCH v2 0/4] regulator: spacemit-p1: Fix voltage ranges and
support board power tree
On Sun, Jan 25, 2026 at 12:18 PM Guodong Xu <guodong@...cstar.com> wrote:
>
> On Sat, Jan 24, 2026 at 2:25 PM Vivian Wang <wangruikang@...as.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
Powered by blists - more mailing lists