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@xxxxxxxxxxxxxxx> 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)?
