[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130702104406.4473EE0090@blue.fi.intel.com>
Date: Tue, 2 Jul 2013 13:44:06 +0300 (EEST)
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Yinghai Lu <yinghai@...nel.org>, john.ronciak@...el.com,
miles.j.penner@...el.com, bruce.w.allan@...el.com,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
x86@...nel.org
Subject: RE: [PATCH 5/6] PCI: acpiphp: look _RMV method a bit deeper in the
hierarhcy
Mika Westerberg wrote:
> The acpiphp driver finds out whether the device is hotpluggable by checking
> whether it has _RMV method behind it (and if it returns 1). However, at
> least Acer Aspire S5 with Thunderbolt host router has this method placed
> behind device called EPUP (endpoint upstream port?) and not directly behind
> the root port as can be seen from the ASL code below:
>
> Device (RP05)
> {
> ...
> Device (HRUP)
> {
> Name (_ADR, Zero)
> Name (_PRW, Package (0x02)
> {
> 0x09,
> 0x04
> })
> Device (HRDN)
> {
> Name (_ADR, 0x00040000)
> Name (_PRW, Package (0x02)
> {
> 0x09,
> 0x04
> })
> Device (EPUP)
> {
> Name (_ADR, Zero)
> Method (_RMV, 0, NotSerialized)
> {
> Return (One)
> }
> }
> }
> }
>
> If we want to support such machines we must look for the _RMV method a bit
> deeper in the hierarchy. Fix this by changing pcihp_is_ejectable() to check
> few more devices down from the root port.
We found that this approach is broken. We've got false positive: host
bridge itself was detected as hotplugable slot %) I think it's not
acceptable.
Mika has tried few more approaches, but we haven't found anything better
then hardcoded path like in original workaround patch[1]. It's not generic
at all, but safe from false positives.
Any thoughts?
[1] http://article.gmane.org/gmane.linux.kernel.pci/19102
--
Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists