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;
+}
