linux-kernel - Re: [PATCH v4 2/2] gpio: sch: Hook into ACPI SCI handler to catch GPIO edge events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <86f3a770-3b90-5fdb-7811-789118dad375@siemens.com>
Date:   Wed, 17 Mar 2021 10:57:39 +0100
From:   Jan Kiszka <jan.kiszka@...mens.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
        Andy Shevchenko <andy@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>
Subject: Re: [PATCH v4 2/2] gpio: sch: Hook into ACPI SCI handler to catch
 GPIO edge events

On 17.03.21 10:52, Andy Shevchenko wrote:
> On Wed, Mar 17, 2021 at 07:57:44AM +0100, Jan Kiszka wrote:
>> On 16.03.21 21:49, Andy Shevchenko wrote:
>>> On Tue, Mar 16, 2021 at 06:26:13PM +0200, Andy Shevchenko wrote:
>>>> From: Jan Kiszka <jan.kiszka@...mens.com>
>>>>
>>>> Neither the ACPI description on the Quark platform provides the required
>>>> information is to do establish generic handling nor hardware capable of
>>>> doing it. According to the datasheet the hardware can generate SCI events.
>>>> Therefore, we need to hook from the driver directly into SCI handler of
>>>> the ACPI subsystem in order to catch and report GPIO-related events.
>>>>
>>>> Validated on the Quark-based IOT2000 platform.
>>>
>>> This patch must be dropped completely. SCI handler is not correct way to do
>>> this. The proper way (and we have already few examples in the kernel) is to
>>> register GPE event.
>>
>> As explained above, this is not supported by the preexisting firmware,
>> and there won't be any updates to it anymore.
>>
>> This platform is history, the SoC was discontinued by Intel long ago,
>> and our devices reaching their support end as well. The race to upstream
>> was lost in this case - backlog too long, we being too slow.
> 
> So you have no device to test and there is actually no device which has this
> capability in the wild.
> 
> Am I reading this correct?

No. We do have devices but we don't have the time to invest further into
bringing missing features upstream - not to speak of changing the
firmware in order to support cleaner upstream integration.

For the remaining lifetime of the devices, we are stuck on 4.4.y-cip
with a few additional patches, including this one.

> 
> In any case, we have platforms in the wild that actually support GPEs and this
> makes sense for them.

Sure, I don't want to judge for them. Just our original target of this
patch is no longer relevant for upstream.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux