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]

Date:   Mon, 21 Sep 2020 23:17:54 +0100
From:   Ed W <lists@...dgooses.com>
To:     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

Hi, I've been adding support for the PC Engines APU5 board, which is a variant of the APU 2-4 boards
with some nice features. The current platform driver for pcengines boards has some redundant
features with regards to recent bios/firmware packages for the board as they now set the ACPI tables
to indicate GPIOs for keys and leds. So I've submitted a patch to eliminate this. It could be argued
that it's useful to support older firmware versions, but there is also a 'leds-apu' driver which a)
probably ought to be marked deprecated with a view to removing it and b) implements the leds even on
antique firmware versions.

In implementing the APU5 I changed some of the exported gpio names to make them more closely match
functionality across all the boards. For example APU2 vs APU4 both support 2x LTE options, but in
different mpcie slots and this affects the numbering of options, but not the sense of them (so I
renamed them based on the intention of the option). This is particularly true on APU5 which supports
3x LTE cards

Can I get some advice: It would be helpful if the kernel would export the GPIOs to user-space
automatically since toggling SIM slots is fairly useful task in userspace. At least for me the gpio
numbers seem to jump around depending on the order of module loading, so doing something involving
/sys/class/gpio/export isn't obviously an easy process. Reviewing the fine documentation suggests
that I need to use gpio_export() to achieve this, but I concede I'm really not clear how to
implement this in the platform module as currently structured... Any tips please?

Thanks

Ed W