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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250828192054.GA957771@bhelgaas>
Date: Thu, 28 Aug 2025 14:20:54 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Christian Bruel <christian.bruel@...s.st.com>
Cc: lpieralisi@...nel.org, kwilczynski@...nel.org, mani@...nel.org,
	robh@...nel.org, bhelgaas@...gle.com, krzk+dt@...nel.org,
	conor+dt@...nel.org, mcoquelin.stm32@...il.com,
	alexandre.torgue@...s.st.com, linus.walleij@...aro.org,
	corbet@....net, p.zabel@...gutronix.de, shradha.t@...sung.com,
	mayank.rana@....qualcomm.com, namcao@...utronix.de,
	qiang.yu@....qualcomm.com, thippeswamy.havalige@....com,
	inochiama@...il.com, quic_schintav@...cinc.com,
	johan+linaro@...nel.org, linux-pci@...r.kernel.org,
	devicetree@...r.kernel.org,
	linux-stm32@...md-mailman.stormreply.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-gpio@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH v13 06/11] PCI: stm32: Add PCIe Endpoint support for
 STM32MP25

On Thu, Aug 28, 2025 at 09:06:33PM +0200, Christian Bruel wrote:
> On 8/28/25 19:22, Bjorn Helgaas wrote:
> > On Wed, Aug 20, 2025 at 09:54:06AM +0200, Christian Bruel wrote:
> > > Add driver to configure the STM32MP25 SoC PCIe Gen1 2.5GT/s or Gen2 5GT/s
> > > controller based on the DesignWare PCIe core in endpoint mode.
> > > ...
> > 
> > > +static int stm32_pcie_start_link(struct dw_pcie *pci)
> > > +{
> > > +	struct stm32_pcie *stm32_pcie = to_stm32_pcie(pci);
> > > +	int ret;
> > > +
> > > +	if (stm32_pcie->link_status == STM32_PCIE_EP_LINK_ENABLED) {
> > > +		dev_dbg(pci->dev, "Link is already enabled\n");
> > > +		return 0;
> > > +	}
> > 
> > While looking at the "incorrectly reset" comment, I noticed
> > stm32_pcie->link_status and wondered why it exists.  It looks like
> > it's only used in stm32_pcie_start_link() and stm32_pcie_stop_link(),
> > and I don't see similar tracking in other drivers.
> > 
> > It feels a little racy because the link might go down for reasons
> > other than calling stm32_pcie_stop_link().
> 
> I think that as an excess of paranoid that was meant to protect against a
> driver unbind when the link hasn’t started yet. In that case,
> stm32_pcie_remove() would disable a link that’s already disabled.
> 
> But that shouldn’t be a problem to disable twice the ltssm enable bit, as
> well as the perst irq. I’ll look into removing it. Is it okay if I do this
> with a fixup patch?

Sure.  We'll put it in pci/next as-is, and if/when you post a patch to
remove link_status, we'll squash it in.

Bjorn

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ