Re: Query regarding the use of pcie-designware-plat.c file

[Rob Herring]

On Tue, Jun 15, 2021 at 1:42 PM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
>
> On Wed, Jun 09, 2021 at 05:54:38PM +0100, Jon Hunter wrote:
> >
> > On 09/06/2021 17:30, Bjorn Helgaas wrote:
> > > On Wed, Jun 09, 2021 at 12:52:37AM +0530, Vidya Sagar wrote:
> > >> Hi,
> > >> I would like to know what is the use of pcie-designware-plat.c file. This
> > >> looks like a skeleton file and can't really work with any specific hardware
> > >> as such.
> > >> Some context for this mail thread is, if the config CONFIG_PCIE_DW_PLAT is
> > >> enabled in a system where a Synopsys DesignWare IP based PCIe controller is
> > >> present and its configuration is enabled (Ex:- Tegra194 system with
> > >> CONFIG_PCIE_TEGRA194_HOST enabled), then, it can so happen that the probe of
> > >> pcie-designware-plat.c called first (because all DWC based PCIe controller
> > >> nodes have "snps,dw-pcie" compatibility string) and can crash the system.

Linux provides no guarantees of what driver will probe if multiple
match. This has been a known 'problem' forever.

> > > What's the crash?  If a device claims to be compatible with
> > > "snps,dw-pcie" and pcie-designware-plat.c claims to know how to
> > > operate "snps,dw-pcie" devices, it seems like something is wrong.
> > >
> > > "snps,dw-pcie" is a generic device type, so pcie-designware-plat.c
> > > might not know how to operate device-specific details of some of those
> > > devices, but basic functionality should work and it certainly
> > > shouldn't crash.
> >
> > It is not really a crash but a hang when trying to access the hardware
> > before it has been properly initialised.
>
> This doesn't really answer my question.
>
> If the hardware claims to be compatible with "snps,dw-pcie" and a
> driver knows how to operate "snps,dw-pcie" devices, it should work.

I try to tell people that generic compatibles like this are pointless...

> If the hardware requires initialization that is not part of the
> "snps,dw-pcie" programming model, it should not claim to be compatible
> with "snps,dw-pcie".  Or, if pcie-designware-plat.c is missing some
> init that *is* part of the programming model, maybe it needs to be
> enhanced?

The driver will only work on an implementation with no clocks (though
the binding defines clocks), resets, phys, host specific registers or
interrupt muxing. That's practically no one. We could probably enhance
the driver to handle the first 3 if there's not differing sequencing
requirements. If we did this, we'd move the specific compatibles to
the plat driver, not add "snps,dw-pcie" to DT (because internal kernel
refactoring shouldn't require a DT change).

> > The scenario I saw was that if the Tegra194 PCIe driver was built as a
> > module but the pcie-designware-plat.c was built into the kernel, then on
> > boot we would attempt to probe the pcie-designware-plat.c driver because
> > module was not available yet and this would hang. Hence, I removed the
> > "snps,dw-pcie" compatible string for Tegra194 to avoid this and ONLY
> > probe the Tegra194 PCIe driver.
>
> Maybe something like driver_override (I know this is supported via
> sysfs, but maybe not via a kernel parameter) or a module parameter for
> pcie-designware-plat.c to keep it from claiming devices?

We could simply bail probe if "snps,dw-pcie" is not the most specific
compatible. I don't think we have a ready made helper for that, but it
would be just checking "compatible" string index 0 against
"snps,dw-pcie".

> > Sagar is wondering why this hang is only seen/reported for Tegra and
> > could this happen to other platforms? I think that is potentially could.
>
> Maybe pcie-designware-plat.c works on other platforms, i.e., they
> don't require the hardware init?

At least upstream, I don't think there are any. But a lot of platforms
have 'snps,dw-pcie' as a fallback.

Rob