Re: [PATCH] acpi: trigger wakeup key event from power button

[Ken Xue <Ken.Xue@amd.com>]

On 2023/9/11 17:42, Andy Shevchenko wrote:
> On Fri, Sep 08, 2023 at 05:57:49PM +0800, Ken Xue wrote:
>> Andorid can wakeup from various wakeup sources,
>> but only several wakeup sources can wake up screen
>> with right events(POWER, WAKEUP) from input device.
>>
>> Regarding pressing acpi power button, it can resume system and
>> ACPI_BITMASK_WAKE_STATUS and ACPI_BITMASK_POWER_BUTTON_STATUS
>> are set in pm1a_sts, but kernel does not report any key
>> event to user space during resume by default.
>>
>> So, trigger wakeup key event to user space during resume
>> from power button.
>> Reported-by: kernel test robot <lkp@intel.com>
> Are you sure?

Thanks for review. Sorry for confusion.

1)The patch is trying to fix the android wakeup from power button issue

I can see Android can resume from S3 and wake up screen from USB keyboard.

but Android only can resume from S3 and fail to wake up screen from 
power button.


opensource android-x86 tried to fix this issue with a patch

(https://git.osdn.net/view?p=android-x86/system-hardware-interfaces.git;a=commit;h=78688b149314ec16cb2d90507a5908e5f2ba0fda) 


in upper layer system_suspend service as a WA.  It  emulates wakeup key 
during resume in a user space thread. And it is still not part of 
upstream Android.


I believe the root cause is no wakeup key event being reported in kernel 
during the resume from acpi power button.

And I have verified this patch on linux also, it seems no side effect 
for Linux resume with this patch.


2) test robot reported some compile warnings and errors detected by test 
robot which is fixed in V2.


>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202309080315.txQUEyHQ-lkp@intel.com/
>> Closes: https://lore.kernel.org/oe-kbuild-all/202309080239.IiC7uLpW-lkp@intel.com/
>> Closes: https://lore.kernel.org/oe-kbuild-all/202309080351.xHt2qhP2-lkp@intel.com/
> Are you sure?

Just some errors/warnings from the v1 patch.


>
>>
> Blank lines are not allowed in the tag block.
>
>> Signed-off-by: Ken Xue <Ken.Xue@amd.com>
>> ---
> How this change is different to the previous patch you sent?
> Do you forgot versioning?
> Do you forgot changelog?
>
> Please, read Submitting Patches documentation before trying again.
> It will help to make your contribution nice and understandable.
>
> ...

sorry.

I will add V3 and change log later.


>
>> +	if (button->type == ACPI_BUTTON_TYPE_POWER) {
> 	if (... != )
> 		return;
>
> ?
>
>> +		input = button->input;
>> +		input_report_key(input, KEY_WAKEUP, 1);
>> +		input_sync(input);
>> +		input_report_key(input, KEY_WAKEUP, 0);
>> +		input_sync(input);
>> +	}
> ...
>
>> +#include <linux/acpi.h>
> There is no users of this header.
>
> Check how forward declaration can be used (as it's done in many other headers).
>
Yes, "struct acpi_device" is defined in "include/acpi/acpi_bus.h", but include acpi_bus.h alone

will lead to more compile issues.

Regarding "forward declaration", how about

typedef struct acpi_device *acpi_device;

>> +extern void acpi_power_button_wakeup(struct acpi_device *device);
> ...
>
>> +static inline void acpi_power_button_wakeup(struct acpi_device *device)
>> +{
>> +}
> This can be done on a single line.
>
Ack.