Re: [PATCH 3/4 v3] PCI: s32g: Add initial PCIe support (RC)

[Bjorn Helgaas <helgaas@kernel.org>]

[+cc imx6, layerscape, stm32 maintainers for possible suspend bug]

On Fri, Oct 24, 2025 at 08:50:46AM +0200, Vincent Guittot wrote:
> On Wed, 22 Oct 2025 at 21:04, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Wed, Oct 22, 2025 at 07:43:08PM +0200, Vincent Guittot wrote:
> > > Add initial support of the PCIe controller for S32G Soc family. Only
> > > host mode is supported.

> > > +static void s32g_init_pcie_controller(struct s32g_pcie *s32g_pp)
> > > +{
> > > ...
> > > +     /*
> > > +      * Make sure we use the coherency defaults (just in case the settings
> > > +      * have been changed from their reset values)
> > > +      */
> > > +     s32g_pcie_reset_mstr_ace(pci, memblock_start_of_DRAM());
> >
> > This seems sketchy and no other driver uses memblock_start_of_DRAM().
> > Shouldn't a physical memory address like this come from devicetree
> > somehow?
> 
> I was using DT but has been asked to not use it and was proposed to
> use memblock_start_of_DRAM() instead

Can you point me to that conversation?

> > > +     s32g_pp->ctrl_base = devm_platform_ioremap_resource_byname(pdev, "ctrl");
> > > +     if (IS_ERR(s32g_pp->ctrl_base))
> > > +             return PTR_ERR(s32g_pp->ctrl_base);
> >
> > This looks like the first DWC driver that uses a "ctrl" resource.  Is
> > this something unique to s32g, or do other drivers have something
> > similar but use a different name?
> 
> AFAICT this seems to be s32g specific in the RM

It does look like there's very little consistency in reg-names across
drivers, so I guess it's fine.

> > > +static int s32g_pcie_suspend_noirq(struct device *dev)
> > > +{
> > > +     struct s32g_pcie *s32g_pp = dev_get_drvdata(dev);
> > > +     struct dw_pcie *pci = &s32g_pp->pci;
> > > +
> > > +     if (!dw_pcie_link_up(pci))
> > > +             return 0;
> >
> > Does something bad happen if you omit the link up check and the link
> > is not up when we get here?  The check is racy (the link could go down
> > between dw_pcie_link_up() and dw_pcie_suspend_noirq()), so it's not
> > completely reliable.
> >
> > If you have to check, please add a comment about why this driver needs
> > it when no other driver does.
> 
> dw_pcie_suspend_noirq returns an error and the suspend fails

The implication is that *every* user of dw_pcie_suspend_noirq() would
have to check for the link being up.  There are only three existing
callers:

  imx_pcie_suspend_noirq()
  ls_pcie_suspend_noirq()
  stm32_pcie_suspend_noirq()

but none of them checks for the link being up.

> I will add a comment
> /*
>  * If the link is not up, there is nothing to suspend and resume

Sometimes true, but still racy as I mentioned, and doesn't explain why
s32g is different from imx, ls, and stm32.

> > > +     return dw_pcie_suspend_noirq(pci);
> > > +}