linux-kernel - Re: [PATCH v13 06/11] PCI: stm32: Add PCIe Endpoint support for STM32MP25

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: <0fbf4be0-af6e-4119-a838-e3fc9ab1fc9d@foss.st.com>
Date: Thu, 28 Aug 2025 21:06:33 +0200
From: Christian Bruel <christian.bruel@...s.st.com>
To: Bjorn Helgaas <helgaas@...nel.org>
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 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?

thank you
Christian


> 
>> +	dev_dbg(pci->dev, "Enable link\n");
>> +
>> +	ret = stm32_pcie_enable_link(pci);
>> +	if (ret) {
>> +		dev_err(pci->dev, "PCIe cannot establish link: %d\n", ret);
>> +		return ret;
>> +	}
>> +
>> +	enable_irq(stm32_pcie->perst_irq);
>> +
>> +	stm32_pcie->link_status = STM32_PCIE_EP_LINK_ENABLED;
>> +
>> +	return 0;
>> +}
>> +
>> +static void stm32_pcie_stop_link(struct dw_pcie *pci)
>> +{
>> +	struct stm32_pcie *stm32_pcie = to_stm32_pcie(pci);
>> +
>> +	if (stm32_pcie->link_status == STM32_PCIE_EP_LINK_DISABLED) {
>> +		dev_dbg(pci->dev, "Link is already disabled\n");
>> +		return;
>> +	}
>> +
>> +	dev_dbg(pci->dev, "Disable link\n");
>> +
>> +	disable_irq(stm32_pcie->perst_irq);
>> +
>> +	stm32_pcie_disable_link(pci);
>> +
>> +	stm32_pcie->link_status = STM32_PCIE_EP_LINK_DISABLED;
>> +}