[PATCH] PCI: ACPI: Fix ThunderX PEM initialization

[Bjorn Helgaas]

On Tue, Jan 31, 2017 at 02:28:30AM -0800, Vadim Lomovtsev wrote:
> Hi Bjorn,
> 
> On Mon, Jan 30, 2017 at 03:12:37PM -0600, Bjorn Helgaas wrote:
> > Hi Vadim,
> > 
> > On Mon, Jan 30, 2017 at 08:25:52AM -0800, Vadim Lomovtsev wrote:
> > > This patch is to address PEM initialization issue
> > > which causes network issues.
> > > 
> > > It is necessary to search for _HID:PNP0A08 while requesting
> > > PEM resources via ACPI instead of "THRX0002".
> > > 
> > > Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev at caviumnetworks.com>
> > > ---
> > >  drivers/pci/host/pci-thunder-pem.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c
> > > index af722eb..aec30b8 100644
> > > --- a/drivers/pci/host/pci-thunder-pem.c
> > > +++ b/drivers/pci/host/pci-thunder-pem.c
> > > @@ -331,7 +331,7 @@ static int thunder_pem_acpi_init(struct pci_config_window *cfg)
> > >  	if (!res_pem)
> > >  		return -ENOMEM;
> > >  
> > > -	ret = acpi_get_rc_resources(dev, "THRX0002", root->segment, res_pem);
> > > +	ret = acpi_get_rc_resources(dev, "PNP0A08", root->segment, res_pem);
> > 
> > This doesn't smell right: PNP0A08 is the generic ACPI ID.  There's no
> > guarantee that if we find a PNP0A08 device, it is a ThunderX device.
> > 
> > I think the only way to call thunder_pem_acpi_init() is via an MCFG
> > quirk that mentions thunder_pem_ecam_ops, which means we only call it
> > if we find an MCFG with "CAVIUM" "THUNDERX" OEM and table IDs, so it's
> > probably safe in that sense.
> 
> Agree, it is not the best solution.
> We will implement such approach and send for review. 
> 
> > 
> > But it's an abuse of the ACPI _HID model.  If you match a device using
> > PNP0A08, all you can assume about it is that it uses the generic
> > PNP0A08 programming model, and I don't think that includes "the first
> > memory resource in _CRS contains ECAM space and MSI-X tables."
> > 
> > I expect this is a teething issue because you have firmware in the
> > field that uses PNP0A08 and it's not feasible to update it.  If that's
> > the case, the changelog should have details about it and we should
> > have a comment in the code, because I don't think this is the model we
> > want to end up with in future releases.
> 
> It could become so. However, for now I didn't get any reports on that,
> (may be I miss something) except some internal emailings.
> At my testing HW I was able to see some issues related to acpi-PEM stuff.
> 
> Thanks for feed-back, we will prepare another patch or patchset
> implementing approach you've highlighted.

The approach I would like best is to search for THRX0002, because then
you know you have a ThunderX PEM device, and you can assume
device-specific details about its _CRS.

But that's what the existing code does, and apparently that doesn't
work.  My guess is that you have firmware in the field where the host
bridge has only PNP0A08 (and maybe PNP0A03) as device IDs.

Per spec, the OS can only assume the generic PCI host bridge
programming model in that case.  It can't use any device-specific
features, like the register space you're extracting here, since
there's no way to tell what specific device you have.

If the OS needs to use device-specific features, there must be a
device-specific _HID, i.e., THRX0002.  This is the important thing to
get right in the future.

If existing firmware in the field has no device-specific _HID, we
might need something like this as a quirk to work around that firmware
deficiency.  If that's the case, all I'm really asking for is:

  - Some indication that you have a plan to change the firmware
    strategy so future releases don't require similar quirks, and

  - Some comments in the code pointing out that this is a workaround
    for a firmware deficiency.

As I mentioned, I think this change should be safe because we only run
this code if we find a CAVIUM THUNDERX MCFG table, and we search for a
PNP0A08 device that matches the segment from MCFG.

The only way we could accidentally match the wrong device would be if
we had another bridge in the same segment.  Maybe we should have made
acpi_get_rc_resources() match on the bus range as well as the segment.
But that feels like just a "pedantically correct" sort of thing and
probably over-engineering for this situation; I don't think it would
solve any current problem.

I know you'd like to see this in v4.10, so we need to sort this out
ASAP.

Bjorn