Hi,
On 2/2/19 12:25 AM, Andy Shevchenko wrote:
On Sat, Feb 2, 2019 at 12:52 AM Hans de Goede <hdego...@redhat.com> wrote:
On 1/31/19 8:47 PM, Maxim Mikityanskiy wrote:
On Mon, Sep 24, 2018 at 5:37 PM Hans de Goede <hdego...@redhat.com> wrote:
We were relying on the interrupt being shared with the ACPI SCI and the
ACPI core calling irq_set_wake. But that does not always happen on
Bay Trail devices, so we should do it ourselves.
This fixes wake from USB not working on various Bay Trail devices.
This patch breaks suspend on ASUS E202SA (bisecting pointed me to this
patch, and if I revert it and build 4.20.5 without this patch,
everything works flawlessly).
Thank you for the bug report, can you please test 4.20.5 with the attached
patch on top? That should fix it. Once I've confirmation that this fixes
things I will submit the patch upstream.
Thanks for fast reply, Hans!
I looked at the patch and would propose one modification, i.e. use
INTEL_CPU_FAM6() macro instead of ICPU().
I just tried and I like the idea, but this does not work.
The problem is that macro assumes that the driver_data being passed is
always a struct and the & to take the address of the struct is part of
the macro instead of passed with the argument, making it impossible to
pass a simple integer value or a bunch of flags (in a bitmask).
IMHO this is a shortcoming of the macro and should be fixed, moving
the & to the callers of the macro.
Given that this patch needs to go to stable to fix the regression I
think it is best to just keep the patch as is. And then for -next, once
the macro is fixed we can convert the int0002_vgpio driver to use it.
Regards,
Hans
