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.shute...@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.shute...@linux.intel.com>
> >> Signed-off-by: Mika Westerberg <mika.westerb...@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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
