Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: l+CO9aFPPdqQQXMDOxN+j3Fw7xEbdcv+6+D10KnTIJzBx8cOF5J/tT4qYTZsOFlyZ9nN99Sc0i
 FYaGTR0anORQ==
IronPort-SDR: QTKiVcReQ5/yHaiWsHNSJYGAkv4I7n1sJ+qSQyX9M/Kjh2f/yneA+JE9/Gy/2LkFFq2t87DJLt
 verHRtbFbyyA==
Date:   Wed, 17 Mar 2021 11:52:26 +0200
From:   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     Jan Kiszka <jan.kiszka@siemens.com>
Cc:     linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
        Andy Shevchenko <andy@kernel.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>
Subject: Re: [PATCH v4 2/2] gpio: sch: Hook into ACPI SCI handler to catch
 GPIO edge events
Message-ID: <YFHRWm6YIh9NU1I/@smile.fi.intel.com>
References: <20210316162613.87710-1-andriy.shevchenko@linux.intel.com>
 <20210316162613.87710-3-andriy.shevchenko@linux.intel.com>
 <YFEZ6GYuXGaX/LP2@smile.fi.intel.com>
 <a3a6c80a-724c-e2fb-9597-b14a302c5ff4@siemens.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a3a6c80a-724c-e2fb-9597-b14a302c5ff4@siemens.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

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@siemens.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?

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

> > It took me a while to gather all bits of this puzzle.
> > 
> > At least now I get an event, but kernel oopses, I'll continue debugging
> > tomorrow.

-- 
With Best Regards,
Andy Shevchenko