Re: [PATCH v4 3/9] gpiolib: acpi: Take into account debounce settings

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

Hi,

On 11/9/20 12:45 PM, Andy Shevchenko wrote:
> On Sun, Nov 08, 2020 at 10:31:32AM +0100, Hans de Goede wrote:
>> On 11/7/20 4:26 PM, Andy Shevchenko wrote:
>>> On Sat, Nov 7, 2020 at 4:49 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>>> On 11/6/20 8:22 PM, Andy Shevchenko wrote:
> 
> ...
> 
>>> Thank you very much for the testing! I remember that I fixed debounce
>>> for BayTrail, but it seems I have yet to fix Cherry Trail pin control
>>> as a prerequisite to this patch.
>>>
>>> And like I said this series is definitely not for backporting.
>>
>> Independent of fixing the CherryTrail pinctrl driver to support this,
>> I strongly believe that -ENOTSUPP should be ignored (treated as success)
>> by this patch. Remember ACPI is not only used on x86 but also on ARM
>> now a days. We simply cannot guarantee that all pinctrls will support
>> (let alone implement) debounce settings. E.g. I'm pretty sure that
>> the pinctrl on the popular Allwinner A64 does not support debouncing
>> and there are builts using a combination of uboot + EDK2 to boot!
>>
>> The documentation for gpiod_set_debounce even explicitly mentioned that
>> -ENOTSUPP is an error which one may expect (and thus treat specially).
>>
>> The same goes for the bias stuff too.
> 
> While for debounce I absolutely agree with you I don't think it applies to
> bias. ACPI table is coupled with a platform and setting bias == !PullNone
> implies that bias is supported.

What about PullDefault ? I can easily see DSDT writers using PullDefault
on platforms where bias setting is not supported.

> If we break something with this it means:
> - ACPI table is broken and we need a quirk

Broken ACPI tables are as common as rain in the Netherlands, where ever
possible we want to deal with these / workaround the brokenness
without requiring per device quirks. Requiring a per device quirk for
every broken ACPI table out there does not scale.

> - GPIO library is broken on architectural level and needs not to return
>   ENOTSUPP for the flags configuration.

Usually we handle features not being implemented gracefully. E.g chances
are good that whatever bias is required was already setup by the firmware
(or bootloader in the uboot + EDK2 case). Making bias set failures a
critical error will likely regress working platforms in various cases.

Keep in mind we have an existing userbase where things is working fine
without taking the bias settings into account now. So if we hit the
-ENOTSUPP case on any platform out there, then that is a regression
plain and simple and as you know regressions are a big red flag.

Since it is really easy to avoid the regression here we really
should avoid it IMHO. What about just printing a warning on ENOTSUPP
when setting the bias instead ?

Regards,

Hans