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: <d4b2045c-769b-4998-64cc-682c01c105fb@wildgooses.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ