diff mbox

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

Message ID 1355412708-20046-2-git-send-email-kirill.shutemov@linux.intel.com (mailing list archive)
State New, archived
Delegated to: Bjorn Helgaas
Headers show

Commit Message

Kirill A . Shutemov Dec. 13, 2012, 3:31 p.m. UTC 
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(+)

Comments

Greg KH Dec. 13, 2012, 6:44 p.m. UTC | #1 
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?

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

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kirill A . Shutemov Dec. 13, 2012, 7:35 p.m. UTC | #2 
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.
Bjorn Helgaas Dec. 14, 2012, 12:22 a.m. UTC | #3 
[+cc Rafael]

On Thu, Dec 13, 2012 at 8:31 AM, Kirill A. Shutemov
<kirill.shutemov@linux.intel.com> 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);

I don't think encoding an ACPI path from the BIOS of a random machine
here is the right approach.  The path components are completely
implementation-dependent, and we'll end up carrying this test forever,
long after the last Aspire S5 is in the landfill.

We need a more generic approach that covers this case.  It would be
interesting to see the rest of the ACPI namespace details under
RP05.HRUP.  I guess we have RP05.HRUP._ADR, at least.  I'm not sure
what the BIOS is trying to tell us by providing
RP05.HRUP.HRDN.EPUP._RMV, but maybe we could figure it out if we knew
more about HRDN and EPUP.

> +       if (ACPI_SUCCESS(status) && removable)
> +               return 1;
> +
>         return 0;
>  }
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kirill A . Shutemov Dec. 14, 2012, 10:46 a.m. UTC | #4 
On Thu, Dec 13, 2012 at 05:22:25PM -0700, Bjorn Helgaas wrote:
> [+cc Rafael]
> 
> On Thu, Dec 13, 2012 at 8:31 AM, Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com> 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);
> 
> I don't think encoding an ACPI path from the BIOS of a random machine
> here is the right approach.  The path components are completely
> implementation-dependent, and we'll end up carrying this test forever,
> long after the last Aspire S5 is in the landfill.
> 
> We need a more generic approach that covers this case.  It would be
> interesting to see the rest of the ACPI namespace details under
> RP05.HRUP.  I guess we have RP05.HRUP._ADR, at least.  I'm not sure
> what the BIOS is trying to tell us by providing
> RP05.HRUP.HRDN.EPUP._RMV, but maybe we could figure it out if we knew
> more about HRDN and EPUP.

My guesses about acronyms:
HRUP -- host router upstream port (connected to PCI root port).
HRDN -- host router downstream port.
EPUP -- end point upstream port.

Looks like BIOS developers tried to be smart and described actual hierarchy
from root port to end point.
The problem is that it doesn't fit to ACPI PCI hotplug. :(

Don't see anything useful in RP05.HRUP:

Device (HRUP)
{
    Name (_ADR, Zero)  // _ADR: Address
    Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
    {
        0x09, 
        0x04
    })
    Device (HRDN)
    {
        Name (_ADR, 0x00040000)  // _ADR: Address
        Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
        {
            0x09, 
            0x04
        })
        Device (EPUP)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Method (_RMV, 0, NotSerialized)  // _RMV: Removal Status
            {
                Return (One)
            }
        }
    }
}
diff mbox

Patch

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;
+
 	return 0;
 }