[Intel-gfx] 3.19-rc1 errors when opening LID

On Saturday, December 27, 2014 09:19:49 AM Pali Rohár wrote:
> Hello,
> 
> in attachment is output of ls -l /sys/bus/acpi/devices from both 
> 3.13 and 3.19 kernels.
>  
> Anyway Gabriele Mazzotta wrote me that new acpi devices could be 
> created after commit faae404ebdc6bba (ACPICA: Add "Windows 2013" 
> string to _OSI support).
> 
> Maybe this another output could help you:
> 
> $ cat /sys/bus/acpi/devices/INT33C5\:00/status
> 0
> $ cat /sys/bus/acpi/devices/INT33C5\:00/power_state
> (unknown)
> 
> Device INT33C5 is in that dmesg log:
> acpi INT33C5:00: Cannot transition to non-D0 state from D3

The appended patch should make these messages go away, please test.

> And status 0 in sysnode could indicate that acpi device is not 
> present right?

That's correct.

---
 drivers/acpi/device_pm.c |    7 ++++---
 include/acpi/acpi_bus.h  |    3 ++-
 2 files changed, 6 insertions(+), 4 deletions(-)

On Sat, 2014-12-27 at 21:22 +0100, Rafael J. Wysocki wrote:
[]
> +++ linux-pm/include/acpi/acpi_bus.h
> @@ -589,7 +589,8 @@ static inline u32 acpi_target_system_sta
>  
>  static inline bool acpi_device_power_manageable(struct acpi_device *adev)
>  {
> -	return adev->flags.power_manageable;
> +	return adev->flags.power_manageable
> +		&& (adev->status.present || adev->status.functional);

Most code in the kernel has these logical
continuations at the end of the previous line.

> +++ linux-pm/drivers/acpi/device_pm.c
[]
> @@ -361,7 +362,7 @@ bool acpi_bus_power_manageable(acpi_hand
>  	int result;
>  
>  	result = acpi_bus_get_device(handle, &device);
> -	return result ? false : device->flags.power_manageable;
> +	return result ? false : acpi_device_power_manageable(device);

This might read better as:

	if (acpi_bus_get_device(handle, &device))
		return false;

	return acpi_device_power_manageable(device);


--
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

On Saturday 27 December 2014 21:22:56 Rafael J. Wysocki wrote:
> On Saturday, December 27, 2014 09:19:49 AM Pali Rohár wrote:
> > Hello,
> > 
> > in attachment is output of ls -l /sys/bus/acpi/devices from
> > both 3.13 and 3.19 kernels.
> > 
> > Anyway Gabriele Mazzotta wrote me that new acpi devices
> > could be created after commit faae404ebdc6bba (ACPICA: Add
> > "Windows 2013" string to _OSI support).
> > 
> > Maybe this another output could help you:
> > 
> > $ cat /sys/bus/acpi/devices/INT33C5\:00/status
> > 0
> > $ cat /sys/bus/acpi/devices/INT33C5\:00/power_state
> > (unknown)
> > 
> > Device INT33C5 is in that dmesg log:
> > acpi INT33C5:00: Cannot transition to non-D0 state from D3
> 
> The appended patch should make these messages go away, please
> test.
> 
> > And status 0 in sysnode could indicate that acpi device is
> > not present right?
> 
> That's correct.
> 
> ---
>  drivers/acpi/device_pm.c |    7 ++++---
>  include/acpi/acpi_bus.h  |    3 ++-
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> Index: linux-pm/include/acpi/acpi_bus.h
> ==============================================================
> ===== --- linux-pm.orig/include/acpi/acpi_bus.h
> +++ linux-pm/include/acpi/acpi_bus.h
> @@ -589,7 +589,8 @@ static inline u32 acpi_target_system_sta
> 
>  static inline bool acpi_device_power_manageable(struct
> acpi_device *adev) {
> -	return adev->flags.power_manageable;
> +	return adev->flags.power_manageable
> +		&& (adev->status.present || adev->status.functional);
>  }
> 
>  static inline bool acpi_device_can_wakeup(struct acpi_device
> *adev) Index: linux-pm/drivers/acpi/device_pm.c
> ==============================================================
> ===== --- linux-pm.orig/drivers/acpi/device_pm.c
> +++ linux-pm/drivers/acpi/device_pm.c
> @@ -68,7 +68,8 @@ int acpi_device_get_power(struct acpi_de
>  {
>  	int result = ACPI_STATE_UNKNOWN;
> 
> -	if (!device || !state)
> +	if (!device || !state
> +	    || !(device->status.present ||
> device->status.functional)) return -EINVAL;
> 
>  	if (!device->flags.power_manageable) {
> @@ -156,7 +157,7 @@ int acpi_device_set_power(struct acpi_de
>  	int result = 0;
>  	bool cut_power = false;
> 
> -	if (!device || !device->flags.power_manageable
> +	if (!device || !acpi_device_power_manageable(device)
> 
>  	    || (state < ACPI_STATE_D0) || (state >
>  	    || ACPI_STATE_D3_COLD))
> 
>  		return -EINVAL;
> 
> @@ -361,7 +362,7 @@ bool acpi_bus_power_manageable(acpi_hand
>  	int result;
> 
>  	result = acpi_bus_get_device(handle, &device);
> -	return result ? false : device->flags.power_manageable;
> +	return result ? false :
> acpi_device_power_manageable(device); }
>  EXPORT_SYMBOL(acpi_bus_power_manageable);

Hello Rafael,

sorry for long delay. Now I tested your patch on top of 4.0-rc6 
version and I'm still getting one acpi error message (and lot of  
others) in dmesg each time I open LID of my laptop:

kernel: [   62.016803] acpi device:41: Cannot transition to power 
state D3cold for parent in (unknown)

If it helps here is more info about that acpi "device:41":

/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C6:00/device:41
$ grep "" *
adr:0x00000001
path:\_SB_.PCI0.SDHC.WI01
power_state:D0
status:15

And here about parent ("../")

/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C6:00
$ grep "" *
adr:0x00170000
hid:INT33C6
modalias:acpi:INT33C6:PNP0D40:
path:\_SB_.PCI0.SDHC
status:0
uevent:MODALIAS=acpi:INT33C6:PNP0D40:
uid:1

It is OK, that one device has status 0 (not present) and its 
child has non zero status? Looks like here is problem...