Re: [PATCH v3 1/5] PCI: Make sure all bridges reserve at least one bus number

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux