diff mbox

ACPI / scan: set status to 0 if _STA failed

Message ID 564D3C75.60208@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Aaron Lu Nov. 19, 2015, 3:05 a.m. UTC
Some ACPI node's _STA will touch operation region field, since the
evaluation of _STA in acpi_bus_type_and_status is very early, the
operation region handler is not ready yet. Instead of fail that function
and not creating the acpi_device node consequently, set status to 0 so
that later when the driver for that device is probing, it can find
the acpi_device node and proceed normally. And at that time, the
handler for the operation region is ready and its _STA evaluation will
succeed, its present status can be checked there.

Even there will be no driver using this node later, it doesn't seem
hurt to have one more acpi_device node created with status set to 0.

This happens on Microsoft Surface 3, where the SPI device node NTRG's
_STA touches GPIO fields and the SPI core driver will only enumerate SPI
devices from ACPI if the acpi_device node is 1: created; 2: _STA
indicates it's present.

Note that due to another problem in SPI driver, for NTRG to be actually
enumerated, some changes have to be made in the SPI layer, which is
addressed by Mika(not send out yet):
https://bugzilla.kernel.org/show_bug.cgi?id=104291#c23

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=104291
Reported-by: Bastien Nocera <bugzilla@hadess.net>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
---
 drivers/acpi/scan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Mika Westerberg Nov. 19, 2015, 10:11 a.m. UTC | #1
On Thu, Nov 19, 2015 at 11:05:25AM +0800, Aaron Lu wrote:
> Some ACPI node's _STA will touch operation region field, since the
> evaluation of _STA in acpi_bus_type_and_status is very early, the
> operation region handler is not ready yet. Instead of fail that function
> and not creating the acpi_device node consequently, set status to 0 so
> that later when the driver for that device is probing, it can find
> the acpi_device node and proceed normally. And at that time, the
> handler for the operation region is ready and its _STA evaluation will
> succeed, its present status can be checked there.
> 
> Even there will be no driver using this node later, it doesn't seem
> hurt to have one more acpi_device node created with status set to 0.
> 
> This happens on Microsoft Surface 3, where the SPI device node NTRG's
> _STA touches GPIO fields and the SPI core driver will only enumerate SPI
> devices from ACPI if the acpi_device node is 1: created; 2: _STA
> indicates it's present.
> 
> Note that due to another problem in SPI driver, for NTRG to be actually
> enumerated, some changes have to be made in the SPI layer, which is
> addressed by Mika(not send out yet):
> https://bugzilla.kernel.org/show_bug.cgi?id=104291#c23
> 
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=104291
> Reported-by: Bastien Nocera <bugzilla@hadess.net>
> Signed-off-by: Aaron Lu <aaron.lu@intel.com>

I don't know any better solution to this,

Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bastien Nocera Dec. 9, 2015, 3:40 p.m. UTC | #2
On Thu, 2015-11-19 at 11:05 +0800, Aaron Lu wrote:
> Some ACPI node's _STA will touch operation region field, since the
> evaluation of _STA in acpi_bus_type_and_status is very early, the
> operation region handler is not ready yet. Instead of fail that
> function
> and not creating the acpi_device node consequently, set status to 0
> so
> that later when the driver for that device is probing, it can find
> the acpi_device node and proceed normally. And at that time, the
> handler for the operation region is ready and its _STA evaluation
> will
> succeed, its present status can be checked there.
> 
> Even there will be no driver using this node later, it doesn't seem
> hurt to have one more acpi_device node created with status set to 0.
> 
> This happens on Microsoft Surface 3, where the SPI device node NTRG's
> _STA touches GPIO fields and the SPI core driver will only enumerate
> SPI
> devices from ACPI if the acpi_device node is 1: created; 2: _STA
> indicates it's present.
> 
> Note that due to another problem in SPI driver, for NTRG to be
> actually
> enumerated, some changes have to be made in the SPI layer, which is
> addressed by Mika(not send out yet):
> https://bugzilla.kernel.org/show_bug.cgi?id=104291#c23
> 
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=104291
> Reported-by: Bastien Nocera <bugzilla@hadess.net>
> Signed-off-by: Aaron Lu <aaron.lu@intel.com>

Worked for me with the additional SPI patch on a Surface 3.

Tested-by: Bastien Nocera <hadess@hadess.net>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki Dec. 14, 2015, 11:42 p.m. UTC | #3
On Thursday, November 19, 2015 12:11:49 PM Mika Westerberg wrote:
> On Thu, Nov 19, 2015 at 11:05:25AM +0800, Aaron Lu wrote:
> > Some ACPI node's _STA will touch operation region field, since the
> > evaluation of _STA in acpi_bus_type_and_status is very early, the
> > operation region handler is not ready yet. Instead of fail that function
> > and not creating the acpi_device node consequently, set status to 0 so
> > that later when the driver for that device is probing, it can find
> > the acpi_device node and proceed normally. And at that time, the
> > handler for the operation region is ready and its _STA evaluation will
> > succeed, its present status can be checked there.
> > 
> > Even there will be no driver using this node later, it doesn't seem
> > hurt to have one more acpi_device node created with status set to 0.
> > 
> > This happens on Microsoft Surface 3, where the SPI device node NTRG's
> > _STA touches GPIO fields and the SPI core driver will only enumerate SPI
> > devices from ACPI if the acpi_device node is 1: created; 2: _STA
> > indicates it's present.
> > 
> > Note that due to another problem in SPI driver, for NTRG to be actually
> > enumerated, some changes have to be made in the SPI layer, which is
> > addressed by Mika(not send out yet):
> > https://bugzilla.kernel.org/show_bug.cgi?id=104291#c23
> > 
> > Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=104291
> > Reported-by: Bastien Nocera <bugzilla@hadess.net>
> > Signed-off-by: Aaron Lu <aaron.lu@intel.com>
> 
> I don't know any better solution to this,
> 
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Applied, thanks!

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 78d5f02a073b..ddfed0d407e5 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1461,7 +1461,7 @@  static int acpi_bus_type_and_status(acpi_handle handle, int *type,
 		*type = ACPI_BUS_TYPE_DEVICE;
 		status = acpi_bus_get_status_handle(handle, sta);
 		if (ACPI_FAILURE(status))
-			return -ENODEV;
+			*sta = 0;
 		break;
 	case ACPI_TYPE_PROCESSOR:
 		*type = ACPI_BUS_TYPE_PROCESSOR;