linux-kernel - Re: [PATCH 1/2] x86: Remove led/gpio setup from pcengines platform driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e727d039-8dea-1a40-48b9-792b6053807c@metux.net>
Date:   Mon, 19 Oct 2020 17:44:27 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Hans de Goede <hdegoede@...hat.com>, Ed W <lists@...dgooses.com>,
        linux-kernel@...r.kernel.org
Cc:     fe@....tdt.de, "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH 1/2] x86: Remove led/gpio setup from pcengines platform
 driver

On 14.10.20 10:41, Hans de Goede wrote:

Hi,

> Keep the current LED/gpio setup code, but make executing it conditional
> on the BIOS version and skip the LED/gpio setup when the new BIOS is
> present to avoid having duplicate LED entries, etc. in that case.
> 
> I guess this would still break userspace because if I understand things
> correctly the new ACPI based setup uses different LED names ? That
> seems unfortunate, but I guess that from the kernel pov we can just
> blame the BIOS for this, and since we definitely do not want duplicate
> LED entries for the same LED, this seems the least bad choice.

Sorry, but not fine. When a newer box is taken from storage into
production (eg. replacement or new installation), application breaks.
LED isn't the only problem, also affects buttons.

The whole reaons why I invested all the time for writing general
purpose drivers (fch-gpio is separate from board driver) and bringing
it to mainline was having clean and generic support for these boards,
instead of having to carry around special patch queues forever and
in near future just using stock distro kernel. I guess that's the
main reason for very most mainlined drivers. This will be defeated
as soon as the whole thing becomes board/bios specific again.

I purposely slept ofter the naming several times, to make sure it's
future proof and tells exactly what these leds are for. Otherwise I
could just have picked numbers and fruits.

Please don't change the names. Field relies on them.

Actually, I've already considered adding another workaround for removing
the ACPI gpio/leds. Haven't had the time for a close analysis the acpi
bytecode actually does, and what the kernel actually makes out of it.
As soon as I encounter an conflict (eg. locks the iomem from gpio-amd
fch, messes up gpio states, etc), I'll have to go that route. There
already have been bug reports in that direction (eg. simsw and reset
issues), which I could not yet reproduce (on the older bios versions).

--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287