linux-kernel - Re: [PATCH 1/2] x86: Conditional init of pcengines leds/keys gpios

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: <5684534f-1280-4c37-af94-1e1bc7484585@wildgooses.com>
Date:   Thu, 22 Oct 2020 10:38:36 +0100
From:   Ed W <lists@...dgooses.com>
To:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
        linux-kernel@...r.kernel.org, Hans de Goede <hdegoede@...hat.com>
Cc:     fe@....tdt.de, hdegoede@...hat.com,
        "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: Conditional init of pcengines leds/keys gpios

On 22/10/2020 10:22, Enrico Weigelt, metux IT consult wrote:
> On 21.10.20 23:41, Ed Wildgoose wrote:
>
> Hi,
>
>> The pcengines bios/firmware includes ACPI tables (since 4.10.0.1) which
>> will cause the kernel to automatically create led + gpio_key devices for
>> the platform. This means that the platform setup now creates duplicates
>> of all these led/key devices.
>>
>> Driver conditionally initialises leds/keys only for older bios.
> still breaks existing userlands as device names change - LEDs as well as
> keys, and keycodes also change.
>
> IOW: userland needs to be depending on specific BIOS versions.
>
>
> --mtx

As a compromise can you change your userland to cope with dynamic names? I see two simple ways:

1) udev rule to set name as you wish

2) I uploaded a little script which uses simple globs to just figure out the base name depending on
the board (also handles different board types entirely as well)

I realise you have some stuff running with this, I don't know your situation specifically, but this
feels like a really, really, small change to work around? Can you elaborate a little on why your
users will be updating kernels without updating user code? Is there really no way to stick a
compatibility udev rule in for your situation?

To recap though, the situation for many years was that the naming convention was board specific.
There is then just a small window (less than a year I think?) where users saw the name change to be
non board specific (ie your new module). I would hazard a guess that given the speed of mainstream
releases, few end users actually saw this change yet, or would notice? Those who did already
accommodated the name change, so I would hazard a guess they can cope with the revert? (or not even
notice?)

Look, just propose a solution, I don't really mind. To me this is SUCH a TRIVIAL rename that I've
already incorporated support for both naming conventions into my apps. I just want to get APU5/6
support in, which is affecting some real boards I want to use in volume. I don't feel the current
situation of duplicate devices should stay though.

My opinion is that we punt "this breaks userland" to being the board vendors problem now. The board
is configured largely through ACPI, so if the upstream changes the ACPI, then it's on them, not us.
This seems to be the direction the kernel is heading, with ACPI and device trees being used to
configure the boards, in preference to heavy platform drivers?

Hans, can you arbitrate here please? Your previous suggestion was to implement a compatibility shim
for older BIOS, that's done here. Happy to implement something else, just need a guide?

Thanks all

Ed W