Re: [PATCH] pci: support Thunderbolt requirements for I/O resources.

[Bjorn Helgaas]

On Mon, Nov 24, 2014 at 2:17 AM, One Thousand Gnomes
<gnomes@xxxxxxxxxxxxxxxxxxx> wrote:
>> > This was also discussed internally and the only way to identify Thunderbolt devices is to check the device IDs.
>> > As you said, this will require us to maintain and keep the list up-to-date as we deliver new devices.
>>
>> I don't really see how this can work.  You're asking me to put changes
>> based on a secret spec into generic code that is used on every machine
>> with PCI.  I have no way to maintain something like that.
>
>>
>> This seems like a major screw up in the design and documentation of Thunderbolt.
>
> See
> https://developer.apple.com/library/mac/documentation/HardwareDrivers/Conceptual/ThunderboltDevGuide/ThunderboltDevGuide.pdf
>
> page 10 for one of the brief public notes on the not relying on I/O space.

I agree with that recommendation not to rely on I/O space.  It applies
equally to *all* PCI devices, not just to Thunderbolt.

Presumably this patch fixes a problem.  The changelog says:

    Kernel shouldn't allocate the PCI I/O resources
    as it interferes with BIOS operation.
    Doing this may cause the devices in the Thunderbolt chain
    not being detected or added, or worse to stuck the
    Thunderbolt Host controller.

The problem of devices not being detected sounds like a general
problem (I assume the problem is actually that we do enumerate the
device, but we may not be able to assign I/O port space to it, which
means we may not be able to operate it).  This could happen with any
device.  If you can come up with a generic way to deal with it, that
might work.  Note that we do already have pci_enable_device_mem() for
drivers that don't need I/O space to operate their device.

If assigning I/O port space to a device can hang the Thunderbolt
controller, that sounds like a controller defect, and maybe you could
write a quirk to work around it.  I'm not opposed to adding
device-specific workarounds for things like that.  I just have trouble
with putting undocumented workarounds in the common path that
everybody uses.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/