[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200207075654.GB2667@lahna.fi.intel.com>
Date: Fri, 7 Feb 2020 09:56:54 +0200
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: Michał Stanek <mst@...ihalf.com>
Cc: linux-gpio@...r.kernel.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org, stanekm@...gle.com,
stable@...r.kernel.org, Marcin Wojtas <mw@...ihalf.com>,
levinale@...omium.org, andriy.shevchenko@...ux.intel.com,
Linus Walleij <linus.walleij@...aro.org>,
bgolaszewski@...libre.com, rafael.j.wysocki@...el.com,
Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH] pinctrl: cherryview: Add quirk with custom translation
of ACPI GPIO numbers
On Thu, Feb 06, 2020 at 11:26:54PM +0100, Michał Stanek wrote:
> On Thu, Feb 6, 2020 at 9:31 AM Mika Westerberg
> <mika.westerberg@...ux.intel.com> wrote:
> >
> > On Wed, Feb 05, 2020 at 08:48:04PM +0100, Michal Stanek wrote:
> > > Dropping custom Linux GPIO translation caused some Intel_Strago based Chromebooks
> > > with old firmware to detect GPIOs incorrectly. Add quirk which restores some code removed by
> > > commit 03c4749dd6c7ff94 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation").
> >
> > Hi,
> >
> > Can you elaborate this? I was under the impression that all the
> > different Strago systems have been already worked around by patches from
> > Dmitry (Cc'd).
>
> Hi Mika,
>
> The previous patches from Dmitry handled IRQ numbering, here we have a
> similar issue with GPIO to pin translation - hardcoded values in FW
> which do not agree with the (non-consecutive) numbering in newer
> kernels.
Hmm, so instead of passing GpioIo/GpioInt resources to devices the
firmware uses some hard-coded Linux GPIO numbering scheme? Would you
able to share the exact firmware description where this happens?
> > What GPIO(s) we are talking about and how does it show up to the user?
>
> As an example, the issue manifests itself when you run 'crossystem
> wpsw_cur'. On my Kefka it incorrectly reports the value as 1 instead
> of 0 when the write protect screw is removed.
Is it poking GPIOs directly through sysfs relying the Linux GPIO
numbering (which can change and is fragile anyway)?
Powered by blists - more mailing lists