On Sat, Mar 31, 2018 at 11:12 AM, Lukas Wunner <lukas@xxxxxxxxx> wrote: > On Sat, Mar 31, 2018 at 11:58:52AM +0300, Mika Westerberg wrote: >> On Sat, Mar 31, 2018 at 10:29:03AM +0200, Lukas Wunner wrote: >> > On Thu, Mar 29, 2018 at 02:59:11PM +0300, Mika Westerberg wrote: >> > > On Wed, Mar 28, 2018 at 01:09:06PM -0500, Bjorn Helgaas wrote: >> > > > The same issue could happen on any system where we use acpiphp, so I >> > > > don't think Thunderbolt is really relevant here, and it's easy to >> > > > confuse things by mentioning it. >> > > >> > > This issue can happen regardless whether acpiphp is used or not. >> > >> > If the platform has yielded hotplug control to the OS via _OSC, >> > I don't see how the platform could hot-add devices. So surely >> > reserving a bus number for a bridge without anything below it >> > can be constrained to the !pciehp_is_native(bridge) case? >> >> Nothing prevents ACPI Notify() happening while native PCIe hotplug is >> used on non-hotplug ports (the ones not controlled by pciehp). And it >> cannot be constrained to !pciehp_is_native(bridge) because it is the >> root port that has the _OSC but below it can be non-hotplug ports where >> ACPI Notify() is used to bring in additional devices. > > That sounds like a violation of the spec to me. > > ACPI 6.1 table 6-178 says if OS is granted control over PCIe hotplug, > the firmware "must ensure that all hot plug events are routed to device > interrupts", which wouldn't be the case for Notify() because the > interrupt generated is an SCI, not an MSI or INTx interrupt for the > hotplug port itself. > > Moreover, "after control is transferred to the OS, firmware must not > update the state of hot plug slots, including the state of the > indicators and power controller." > > Maybe I've misunderstood the spec all the time, my understanding was > that if OS is granted control, the firmware won't do anything with > hotplug ports below the host bridge, period. This is in agreement with my understanding of it. The _OSC at a root port should cover the entire hierarchy below that port. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
