Re: [PATCH] pinctrl: cherryview: Add quirk with custom translation of ACPI GPIO numbers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux