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

["Jamet, Michael" <michael.jamet@intel.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4241 bytes --]

> -----Original Message-----
> From: Bjorn Helgaas [mailto:bhelgaas@google.com]
> Sent: Wednesday, December 03, 2014 02:19
> To: One Thousand Gnomes
> Cc: Jamet, Michael; linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org;
> Levy, Amir (Jer); Alloun, Dan; Rafael Wysocki; Andreas Noever
> Subject: Re: [PATCH] pci: support Thunderbolt requirements for I/O resources.
> 
> On Mon, Nov 24, 2014 at 2:17 AM, One Thousand Gnomes
> <gnomes@lxorguk.ukuu.org.uk> 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

The actual problem the patch is meant to address is related to the PCI 
limitation of 64KB I/O space and the fact that allocations are 
performed in chunks of 4KB behind PCI-to-PCI bridges.
After a certain amount of devices the I/O resources may be exhausted. 
This is indeed a general issue, not only related to Thunderbolt, and 
as Bjorn suggested a general fix is advised.
 
Following further investigations it seems that we may not really need 
this patch for the following reasons:

1. It seems that the controller issues (written on the changelog) were 
related to the lack of support of hotplug topology changes in the old 
tested kernel (3.15) rather than the I/O space issue.

2. Kernel PCI driver handles properly allocations of I/O resources and 
prevents I/O resources exhaustion which may have caused issues (if not 
handled properly) to any PCI or Thunderbolt controller. Looks like 
first device asking I/O is the first served and this mechanism works fine.

3. For most devices supported today on Thunderbolt such as AHCI or  
iGB (E1000E), if no I/O resources is allocated, the device seems to 
continue to operate through the memory BARs.
 
/Michael
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥