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: <8058a804-a793-a5f8-d086-0bb0f600aef9@metux.net>
Date:   Mon, 12 Oct 2020 21:39:30 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     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 22.09.20 00:17, Ed W wrote:
> 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. 

NAK. Breaks existing userlands in the field (literally field), forcing
users to fw upgrade is not an option (field roll would be realy expensive).

> 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.

leds-apu is only for *OLD* apu1 - it does *not* work with v2/3/4,
completely different chipset.

> 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

Dont break existing userlands.

> 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. 

This is planned to be moved to either an own subsystem or into rfkill
(which would have to be extended for such things).

Using raw gpio's isn't a good idea - it's not portable.

> 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. 

Exactly. That's why they should be bound to more high level drivers.
Gpio numbers are anything but stable.


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