Messages in this thread | | | Date | Fri, 7 Feb 2020 09:56:54 +0200 | From | Mika Westerberg <> | 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@linux.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)?
| |