lkml.org 
[lkml]   [2013]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 6/8] PCI: acpiphp: workaround for Thunderbolt on Acer Aspire S5
Date
On Thursday, July 18, 2013 09:57:23 PM Robert Hancock wrote:
> On 07/03/2013 03:40 PM, Rafael J. Wysocki wrote:
> > On Wednesday, July 03, 2013 05:04:53 PM Mika Westerberg 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>
> >> Signed-off-by: Mika Westerberg <mika.westerberg@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);
> >
> > Well, calling stuff like this directly from a general function is kind of ugly.
> >
> > Can we use something like a quirk instead? A DMI check or something?
>
> Presumably this device functions under Windows so clearly Windows is
> capable of dealing with this case, so we should too.
>
> There are way too many of these silly DMI checks in the kernel - we
> should be way more hesitant to add more of them. They're almost
> guaranteed to be incomplete. I would say they should be avoided whenever
> possible unless there's some reason why a general workaround can't be used.

This horse is already dead. :-)

Please check the series I posted the day before yesterday.

Thanks,
Rafael


--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


\
 
 \ /
  Last update: 2013-07-19 15:01    [W:1.173 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site