New Surface 3 (atom x7) having problems with ACPI regions

New Surface 3 (atom x7) having problems with ACPI regions

[Benjamin Tissoires]

Hey,

Bastien (CC-ed) has troubles having the touchscreen of the new Surface
3 (atom based) showing up.
He raised a kernel bugzilla [1] and the dmesg shows:
ACPI Error: Region GeneralPurposeIo (ID=8) has no handler (20150619/exfldio-297)

Which seems to interrupt the parsing of the DSDT.

I am not sure about the status of ACPI regions in the latest acpi tree
so I prefer asking here. Does this error actually prevents the
touchscreen to be loaded by i2c-hid or is there something else
preventing the enumeration?

Cheers,
Benjamin

[1] https://bugzilla.kernel.org/show_bug.cgi?id=104291

Re: New Surface 3 (atom x7) having problems with ACPI regions

[Aaron Lu]

On 09/09/2015 09:51 PM, Benjamin Tissoires wrote:
> Hey,
> 
> Bastien (CC-ed) has troubles having the touchscreen of the new Surface
> 3 (atom based) showing up.
> He raised a kernel bugzilla [1] and the dmesg shows:
> ACPI Error: Region GeneralPurposeIo (ID=8) has no handler (20150619/exfldio-297)
> 
> Which seems to interrupt the parsing of the DSDT.
> 
> I am not sure about the status of ACPI regions in the latest acpi tree
> so I prefer asking here. Does this error actually prevents the
> touchscreen to be loaded by i2c-hid or is there something else
> preventing the enumeration?

There is GPIO operation region handler support in the kernel and
according to the dsdt table provided in bugzilla, Surface 3 is using
cherryview GPIO controller(_HID INT33FF) that is supported by the
pinctrl-cherryview driver. The problem here is, the device node NTRG is
accessing some GPIO operation region field in its _STA control method
and since _STA for ACPI device node is called very early, before any of
the GPIO drivers(where the GPIO operation region handler is installed)
are probed, the error message appeared.

I'm not so sure of the below part:
"
The failure of executing the _STA control method will cause the device
node not having the acpi_device structure created and then in the SPI
ACPI enumerate function acpi_spi_add_device, it will not be created and
used.
"

I guess we need to handle _STA for the _DEP case someway.

Regards,
Aaron

> Cheers,
> Benjamin
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=104291
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: New Surface 3 (atom x7) having problems with ACPI regions

[Aaron Lu]

On Thu, Sep 10, 2015 at 11:46:50AM +0800, Aaron Lu wrote:
> I'm not so sure of the below part:
> "
> The failure of executing the _STA control method will cause the device
> node not having the acpi_device structure created and then in the SPI
> ACPI enumerate function acpi_spi_add_device, it will not be created and
> used.
> "

With the above said, I wonder if the following patch which ignores the
error return of the _STA and set status to 0 makes any difference?


diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index ec256352f423..418c8a7cec91 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2293,7 +2293,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;

Re: New Surface 3 (atom x7) having problems with ACPI regions

[Bastien Nocera]

On Thu, 2015-09-10 at 15:35 +0800, Aaron Lu wrote:
> On Thu, Sep 10, 2015 at 11:46:50AM +0800, Aaron Lu wrote:
> > I'm not so sure of the below part:
> > "
> > The failure of executing the _STA control method will cause the
> > device
> > node not having the acpi_device structure created and then in the
> > SPI
> > ACPI enumerate function acpi_spi_add_device, it will not be created
> > and
> > used.
> > "
> 
> With the above said, I wonder if the following patch which ignores
> the
> error return of the _STA and set status to 0 makes any difference?

For the lurkers on the list, the discussion is happening in bugzilla
now, and the aforementioned patch didn't make a difference:
https://bugzilla.kernel.org/show_bug.cgi?id=104291

Cheers