Using the generic host PCIe driver

[Bjorn Helgaas]

On Mon, Feb 27, 2017 at 06:02:36PM +0100, Mason wrote:
> On 27/02/2017 17:44, Bjorn Helgaas wrote:
> 
> > On Mon, Feb 27, 2017 at 05:14:15PM +0100, Mason wrote:
> >
> >> Bug #2
> >>
> >> Bus 0 cannot be enumerated, because it reports garbage data for
> >> devices and functions other than 0, i.e. only 0/0/0 works.
> >>
> >> How do I work around that issue?
> > 
> > There are several drivers that provide their own "ECAM-like" config
> > accessors.  Look at "struct pci_ecam_ops" structures, e.g.,
> > hisi_pcie_ops, pci_thunder_ecam_ops, xgene_v1_pcie_ecam_ops, etc.
> 
> If I understand correctly, I do need to write my own driver then,
> if I need specific quirks to work around some issues?
> 
> I'm slightly confused because you originally said "The native drivers
> in drivers/pci/host are a huge maintenance hassle for no real benefit."
> 
> But I do need to write one, correct?

When I said the native drivers provide no real benefit, I meant that
they do not provide any value-add functionality beyond what a generic
driver like drivers/acpi/pci_root.c already does.

Obviously there are many different host bridges and they have
different programming models, so there has to be bridge-specific
support *somewhere*.  The question is whether that's in firmware, in
Linux, or both.  For ACPI systems, it's all in firmware.

Systems with well-behaved hardware, i.e., it supports PCIe and ECAM
without warts, firmware can initialize the bridge and tell the OS
about it via DT, and the drivers/pci/pci-host-generic.c driver can do
everything else.

For systems that aren't so well-behaved, we'll need either a full
native driver that knows how to program bridge window CSRs, set up
interrupts, etc., or a simpler native driver that papers over warts
like ECAM that doesn't work quite according to spec.

It sounds like your system falls into the latter category.

> > You can also work around Bug #1 in a custom accessor instead of a
> > quirk.
> 
> By checking for the device ID and vendor ID, and returning the
> expected class code, instead of the contents of the reg?
> 
> Do you consider this a better solution?

It's not a big deal either way.  Doing it in the accessor has the
advantage that you have to have the accessor anyway.  Doing it in a
quirk means you need to figure out where to put the quirk.  It isn't
really generic (so drivers/pci/quirks.c seems overly generic), it
isn't really arch-specific (so arch/* seems maybe *too* specific),
it's really just bridge-specific.

Bjorn