Re: [PATCH 1/3] PCI Hotplug: workaround for Thunderbolt on Acer Aspire S5

["Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]

On Thu, Dec 13, 2012 at 10:44:41AM -0800, Greg KH wrote:
> On Thu, Dec 13, 2012 at 05:31:46PM +0200, Kirill A. Shutemov wrote:
> > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> > 
> > Correct ACPI PCI hotplug imeplementation should have _RMV method in a
> > PCI slot (device under pci bridge). In Acer Aspire S5 case we have it
> > deeper in hierarchy:
> > 
> > Device (RP05)
> > {
> >    // ...
> >    Device (HRUP)
> >    {
> >        // ...
> >        Device (HRDN)
> >        {
> >            // ...
> >            Device (EPUP)
> >            {
> >                // ...
> >                Method (_RMV, 0, NotSerialized)  // _RMV: Removal Status
> >                {
> >                    Return (One)
> >                }
> >            }
> >        }
> >    }
> > }
> > 
> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > ---
> >  drivers/pci/hotplug/acpi_pcihp.c |   13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/drivers/pci/hotplug/acpi_pcihp.c b/drivers/pci/hotplug/acpi_pcihp.c
> > index 2a47e82..d92ebfb 100644
> > --- a/drivers/pci/hotplug/acpi_pcihp.c
> > +++ b/drivers/pci/hotplug/acpi_pcihp.c
> > @@ -422,6 +422,19 @@ static int pcihp_is_ejectable(acpi_handle handle)
> >  	status = acpi_evaluate_integer(handle, "_RMV", NULL, &removable);
> >  	if (ACPI_SUCCESS(status) && removable)
> >  		return 1;
> > +
> > +	/*
> > +	 * Workaround for Thunderbolt implementation on Acer Aspire S5.
> > +	 *
> > +	 * Correct ACPI PCI hotplug imeplementation has _RMV method in a PCI
> > +	 * slot (device under pci bridge). In Acer Aspire S5 case we have it
> > +	 * deeper in hierarchy.
> > +	 */
> > +	status = acpi_evaluate_integer(handle, "HRDN.EPUP._RMV", NULL,
> > +			&removable);
> > +	if (ACPI_SUCCESS(status) && removable)
> > +		return 1;
> 
> I have no objection to this patch as-is, but I wonder how will other
> BIOSes implement this "incorrectly" in the future.  Should we always
> just try to walk the whole PCI slot heirachy looking for the _RMV
> attribute?  That should solve the problem where someone else places this
> at another location for the slot, right?

I'm new with PCI and I'm not sure what problems can cause false positive
here.
What will heppend if we find yet another PCI-to-PCI bridge in the hierarchy
and some of slots of that bridge will have _RMV method? Is it possible,
right?

I prefer postpone any generalization before we will find any similar bug
on other HW. (I naively hope BIOS developers will not repeat theirs bugs).

> Is there any test for Windows that ensures that this gets placed in the
> "correct" location that we can rely on?

No idea. I haven't seen any Windows.

-- 
 Kirill A. Shutemov

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]