On 07/02/2017 22:47, Bjorn Helgaas wrote: > On Tue, Feb 07, 2017 at 02:06:56PM -0600, Bjorn Helgaas wrote: >> On Tue, Feb 07, 2017 at 04:55:28PM +0100, Mason wrote: >>> On 06/02/2017 16:54, Mason wrote: >>> >>>> My platform ( arch/arm/mach-tango ) provides a PCIe controller from PLDA. >>>> >>>> I do have access to a driver that works for a few PCIe boards, but it's >>>> an ancient out-of-tree driver (targeting v3.4). Also, I'm not sure it >>>> follows the best-practice guidelines (e.g. it hard-codes a few >>>> work-arounds directly in drivers/pci/probe.c) >> >> Indeed, having to change drivers/pci/probe.c doesn't sound like a best >> practice :) If you can share details of what changes you need, people >> could probably suggest other ways to do it within the generic PCI >> framework. >> >>>> If I understand correctly, while PCIe is a standard, it is not codified >>>> as much as USB (XHCI) or SATA (AHCI), which means the register layout >>>> (and possibly other things) are left up to the integrator? Which means >>>> there cannot be some kind of "generic" driver that works for a random >>>> PCIe controller? >> >> There is no standardization of registers in MMIO or I/O port space. >> The size, location, and type of those registers is configurable in a >> generic way via the BARs, of course. But that tells you nothing about >> the *functionality* of those MMIO or I/O port registers. >> >> For config space, the first 64 bytes (the PCIe r3.0 spec calls it the >> "PCI 3.0 Compatible Configuration Space Header") are completely >> standardized. This is where device IDs, BARs, and other generic >> registers are. >> >> PCIe devices can implement up to 4096 bytes of config space. The >> space after the 64-byte header can contain a list of standardized >> PCI/PCIe Capabilities, non-standardized device-specific registers, or >> both. There is a way to include device-specific registers in a >> "Vendor Defined" Capability -- that way drivers can use generic >> mechanisms to find registers so they don't have to hard-code register >> layout assumptions. >> >>>> I guess my main question is: do you have pointers on getting started >>>> writing a PCIe driver good enough for upstream? >>>> >>>> Is Documentation/PCI/PCIEBUS-HOWTO.txt still a relevant resource? >> >> PCIEBUS-HOWTO.txt is still relevant, but only to drivers for services >> of PCIe ports, e.g., hotplug, error reporting, etc. It's not relevant >> to PCIe endpoint drivers. >> >>>> Are there good resources to get up to speed on the PCIe terminology? >>> >>> I'm also wondering: in many Linux subsystems, there are often >>> several drivers of different quality; some are obsolescent and >>> have not been updated in a while, while some are recent and >>> follow all the latest best-practice guidelines (and the rest >>> is somewhere in the middle). >>> >>> Are there 1 or 2 very good PCIe drivers to take as examples >>> as good starting points? (Perhaps a simple driver, and a >>> more complex driver.) >> >> I'm not really the best person to ask about this because I deal more >> with the PCI core than with the drivers that use the core. If I were >> looking, I might start with drivers/nvme/host/pci.c or >> drivers/usb/host/xhci-pci.c. > > I should have also mentioned Documentation/PCI/pci.txt. That's a > pretty good place to start. Hello Bjorn, Thanks for these pointers, I will study them with care. Who would review my PCIe driver if I ever submitted one? :-) Regards.
