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