lkml.org 
[lkml]   [2020]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] x86: Remove led/gpio setup from pcengines platform driver
From
Date
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@metux.net -- +49-151-27565287

\
 
 \ /
  Last update: 2020-10-12 21:40    [W:0.174 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site