Re: [PATCH v4 1/6] PCI: starfive: Use regulator APIs instead of GPIO APIs to enable the 3V3 power supply of PCIe slots

[Bjorn Helgaas <helgaas@kernel.org>]

On Tue, Dec 02, 2025 at 03:02:48AM +0000, Kevin Xie wrote:
> ...

> > > On Tue, Nov 25, 2025 at 03:55:59PM +0800, Hal Feng wrote:
> > > > The "enable-gpio" property is not documented in the dt-bindings and
> > > > using GPIO APIs is not a standard method to enable or disable PCIe
> > > > slot power, so use regulator APIs to replace them.
> > >
> > > I can't tell from this whether existing DTs will continue to work
> > > after this change.  It looks like previously we looked for an
> > > "enable-gpios" or "enable-gpio" property and now we'll look for a
> > > "vpcie3v3-supply" regulator property.
> > >
> > > I don't see "enable-gpios" or "enable-gpio" mentioned in any of the DT
> > > patches in this series, so maybe that property was never actually used
> > > before, and the code for pcie->power_gpio was actually dead?
> > 
> > pcie->power_gpio is used in the our JH7110 EVB, it share the same
> > pcie pcie->controller driver with VisionFive2 board. Although
> > JH7110 was not upstreamed, we still hope to maintain the
> > compatibility of the driver.
> 
> Sorry, I missed the background information regarding replacing
> enable_gpio with regulator APIs. I agree with this change.

OK, thanks.  I would still like to have something added to the commit
log to the effect that this change will break any DTs that use
"enable-gpios" or "enable-gpio", but that's not a problem because such
DTs were only internal to StarFive and we are OK with updating them
and dealing with the fact that the DT is rev-locked with the kernel
version (old kernels would require an old DT with "enable-gpio" and
new kernels require an updated DT with "vpcie3v3-supply").  Or DTs
using "enable-gpio" never existed in the first place.

Or whatever.  I just want the commit log to be clear that
"enable-gpio" is no longer supported and "vpcie3v3-supply" must be
included instead, AND that you are aware of the breaking nature of the
change and here is why that's not an issue.

We can't make kernel changes that require end users to upgrade the DT
when they update the kernel or downgrade the DT when rolling back.

Bjorn