ACPI / scan: set status to 0 if _STA failed
PATCH 1/1 ACPI / scan: set status to 0 if _STA failed
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
--- drivers/acpi/scan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/scan.c +1 -1
@@ -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 ;
Signature · 6 lines
2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 17 lines · Aaron Lu
Some ACPI node's
_STAwill touch operation region field, since the evaluation of_STAinacpi_bus_type_and_statusis very early, the operation region handler is not ready yet. Instead of fail that function and not creating theacpi_devicenode consequently, set status to 0 so that later when the driver for that device is probing, it can find theacpi_devicenode and proceed normally. And at that time, the handler for the operation region is ready and its_STAevaluation 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_devicenode created with status set to 0.This happens on Microsoft Surface 3, where the SPI device node NTRG's
_STAtouches GPIO fields and the SPI core driver will only enumerate SPI devices from ACPI if theacpi_devicenode is 1: created; 2:_STAindicates it's present.
Quoted 8 lines
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#c23Reported-by Bastien Nocera <[email protected]>Signed-off-by Aaron Lu <[email protected]>
I don't know any better solution to this,
Quoted 27 lines · Aaron Lu
Some ACPI node's
_STAwill touch operation region field, since the evaluation of_STAinacpi_bus_type_and_statusis very early, the operation region handler is not ready yet. Instead of fail that function
and not creating theacpi_devicenode consequently, set status to 0 so
that later when the driver for that device is probing, it can find theacpi_devicenode and proceed normally. And at that time, the handler for the operation region is ready and its_STAevaluation 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_devicenode created with status set to 0.This happens on Microsoft Surface 3, where the SPI device node NTRG's
_STAtouches GPIO fields and the SPI core driver will only enumerate SPI
devices from ACPI if theacpi_devicenode is 1: created; 2:_STAindicates 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
Quoted 3 lines
Reported-by Bastien Nocera <[email protected]>Signed-off-by Aaron Lu <[email protected]>
Worked for me with the additional SPI patch on a Surface 3.
Rafael J. Wysocki
AppliedQuoted 23 lines · Mika Westerberg
Quoted 22 lines · Aaron Lu
Some ACPI node's
_STAwill touch operation region field, since the evaluation of_STAinacpi_bus_type_and_statusis very early, the operation region handler is not ready yet. Instead of fail that function and not creating theacpi_devicenode consequently, set status to 0 so that later when the driver for that device is probing, it can find theacpi_devicenode and proceed normally. And at that time, the handler for the operation region is ready and its_STAevaluation 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_devicenode created with status set to 0.This happens on Microsoft Surface 3, where the SPI device node NTRG's
_STAtouches GPIO fields and the SPI core driver will only enumerate SPI devices from ACPI if theacpi_devicenode is 1: created; 2:_STAindicates 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
Quoted 7 lines
Quoted 3 lines
Reported-by Bastien Nocera <[email protected]>Signed-off-by Aaron Lu <[email protected]>I don't know any better solution to this,
Applied, thanks!
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html