On Thu, Dec 13, 2012 at 12:30:04PM -0800, Linus Torvalds wrote: > On Thu, Dec 13, 2012 at 12:25 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote: > > > > Linus will not be happy with those kind of delay. > > Indeed. And the DMI check is bogus too, since the "there can be > delays" is apparently part of the pcie hotplug spec. > > So do the sane thing. Retry a few times, with increasingly long delays > (ie something like start with 10ms, then double the delay until you > hit 1s, and then just give up: end result, ~2s total wait, but 10ms > for any sane device that doesn't suck). > > No DMI checks, no hacks, not insane default delays. I've realized that there's no strong criteria of hotplug success in ACPI PCI Hotplug. We can't know when we should stop retrying. In Thunderbolt case before any devices hotplugged you only see a root port. Thunderbolt host controller is powered off and kernel can't see it. On hotplug BIOS enables the host controller, initialize it and notify OS about hotplug. Normally kernel will enumerate 6 ports on Thunderbolt host controller, 2 ports on device Thunderbolt controller and target device itself. All this for simple non-chained case. With device chaining the hierarchy is even more complex. On DZ77RE-75K motherboard without the workaround kernel will discover only ports on host controller, but not device ports or device. So kernel will find devices on broken implementation, not all of them. Even worse: there's no way to distinguish between plug and unplug events and kernel uses the same code path for both cases. -- Kirill A. Shutemov
Attachment:
signature.asc
Description: Digital signature
