lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <ZQ2PR01MB1307A6D1E4B93A716EFFDC25E6A62@ZQ2PR01MB1307.CHNPR01.prod.partner.outlook.cn>
Date: Thu, 4 Dec 2025 13:19:53 +0000
From: Hal Feng <hal.feng@...rfivetech.com>
To: Bjorn Helgaas <helgaas@...nel.org>, Kevin Xie <kevin.xie@...rfivetech.com>
CC: Conor Dooley <conor+dt@...nel.org>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Palmer Dabbelt
	<palmer@...belt.com>, Paul Walmsley <pjw@...nel.org>, Albert Ou
	<aou@...s.berkeley.edu>, "Rafael J . Wysocki" <rafael@...nel.org>, Viresh
 Kumar <viresh.kumar@...aro.org>, Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof WilczyƄski <kwilczynski@...nel.org>, Manivannan
 Sadhasivam <mani@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>, Liam
 Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>, Emil Renner
 Berthing <emil.renner.berthing@...onical.com>, Heinrich Schuchardt
	<heinrich.schuchardt@...onical.com>, E Shattow <e@...eshell.de>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 1/6] PCI: starfive: Use regulator APIs instead of GPIO
 APIs to enable the 3V3 power supply of PCIe slots

> On 03.12.25 00:31, Bjorn Helgaas wrote:
> 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.

OK. I send another patch [1] today and add the some description to the commit
log accordingly. Please check it. Thanks for your review.

[1] https://lore.kernel.org/all/20251204064956.118747-1-hal.feng@starfivetech.com/

Best regards,
Hal

> 
> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ