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@xxxxxxxxxxx> >>>> >>>> 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