lkml.org 
[lkml]   [2012]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] PCI Hotplug: workaround for Thunderbolt on Acer Aspire S5
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2012-12-13 21:21    [W:0.146 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site