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
