Re: Pointers for writing a good PCIe driver

[Mason <slash.tmp@free.fr>]

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.