Re: [PATCH resend 2/3] gpiolib: acpi: Rename honor_wakeup option to ignore_wake, add extra quirk

[Hans de Goede <hdegoede@redhat.com>]

Hi,

Thank you for looking at this.

On 2/25/20 11:54 AM, Andy Shevchenko wrote:
> On Tue, Feb 25, 2020 at 11:27:52AM +0100, Hans de Goede wrote:
>> Commit aa23ca3d98f7 ("gpiolib: acpi: Add honor_wakeup module-option +
>> quirk mechanism") was added to deal with spurious wakeups on one specific
>> model of the HP x2 10 series. In the mean time I have learned that there
>> are at least 3 variants of the HP x2 10 models:
>>
>> Bay Trail SoC + AXP288 PMIC
>> Cherry Trail SoC + AXP288 PMIC
>> Cherry Trail SoC + TI PMIC
>>
>> It turns out that the need to ignore wakeup on *all* ACPI GPIO event
>> handlers is unique to the Cherry Trail SoC + TI PMIC variant for which
>> the first quirk was added.
>>
>> The 2 variants with the AXP288 PMIC only need to have wakeup disabled on
>> the embedded-controller event handler. We want to e.g. keep wakeup on the
>> event handler connected to the GPIO for the lid open/closed sensor.
>>
>> Since the honor_wakeup option was added to be able to ignore wake events,
>> the name was perhaps not the best, this commit renames it to ignore_wake,
>> this version of the option has te following possible values:
>>
>> values >= 0: a pin number on which to ignore wakeups, the ACPI wake flag
>> will still be honored on all other pins
>> value -1: auto: check for DMI quirk, otherwise honor the flag on all pins
>> value -2: all:  ignore the flag on all pins
>> value -3: none: honor wakeups on all pins
>>
>> Note that it is possible for an ACPI table to request events on the same
>> pin-number on multiple GPIO controllers, in that case if such a pin-number
>> is used as ignore_wake value then wakeups will be ignored for that pin on
>> all GPIO controllers.
>>
>> The existing quirk for the Cherry Trail + TI PMIC models is changed to
>> IGNORE_WAKE_ALL, keeping the current behavior; and a new quirk is added
>> for the Bay Trail + AXP288 model, ignoring wakeups on the EC GPIO pin only.
> 
> In general I'm fine with this, but looking to the history of your changes I'm
> afraid that in future it will require more than one pin to be listed or
> something like this.

The only models which need this so far are the weird HP X2 models which
use an external embedded controller with the tablet version of BYT / CHT
which is just al sorts of hacked together. Also see:

https://lore.kernel.org/stable/20200223153208.312005-1-hdegoede@redhat.com/T/#u

For other parts of the same device which also rather "hacked together"
HP made these models really really interesting...

With that said I cannot guarantee that we won't need something similar
for some other botched-up device.

> ...
> 
>> +static int ignore_wake = IGNORE_WAKE_AUTO;
>> +module_param(ignore_wake, int, 0444);
>> +MODULE_PARM_DESC(ignore_wake,
>> +	"Ignore ACPI wake flag: x=ignore-for-pin-x, -1=auto, -2=all, -3=none");
> 
> Perhaps we may take list of pins or a bitmap (see bitmap list parsers API).

I guess you mean bitmap_parse_user / bitmap_print_to_pagebuf, the problem
is that for a more generic solution we need a wat to specify the
GPIO controller + the pin, so we would get a list of <name>,<pin> pairs
and then need to parse that, e.g. :

	gpiolib_acpi.ignore_wake=INT33FC:00,0x1c;INT33FC:01;0x12

I agree that if we really want to future proof this that then this is
the way we should go. This does mean adding a bunch of extra code for
parsing this, but I guess that would be better then my current hack.

Please let me know if you prefer going this route then I will respin
the patches to work this way.

> ...
> 
>> -static int honor_wakeup = -1;
>> -module_param(honor_wakeup, int, 0444);
>> -MODULE_PARM_DESC(honor_wakeup,
>> -		 "Honor the ACPI wake-capable flag: 0=no, 1=yes, -1=auto");
> 
> Isn't it now a part of ABI? I don't think we may remove it, though we may ignore it.
> Or do something else.
> 
> (One of the reasons why I hate module parameters)

I personally do not subscribe to the module parameters are part of the kernel ABI
crowd. I do not think Linus has ever stated something like that ?  For long existing
often used module parameters treating them as such makes a ton of sense, but this
one is quite new and AFAIK almost nobody is using it. So my vote would be to just
drop it. If we get push back we can easily restore it in some form.

> 
>> +			ignore_wake = (s16)(quirks & QUIRK_IGNORE_WAKE_MASK);
> 
> It's casted to signed because ..?

The high 32 bits of the quirk field is used for flags, and ignore_wake can
have a special negative value, so we need to sign extend the value stored
in the lower 16 bits of the quirk in case it is a negative value such as
IGNORE_WAKE_ALL.

Note this ugliness would go away if we switch to the string format for
the module param. Then the driver_data in the dmi matches would point
to a struct with a separate unsigned long flags field and a const char
*ignore_wake field...

Regards,

Hans