On 4/15/19 1:12 PM, Enrico Weigelt, metux IT consult wrote:
On 12.04.19 20:20, Jacek Anaszewski wrote:
They now provide full support for the APU2/3 front peripherals,
LEDs as well as front key. The key cannot be used w/ the old led-only
driver.
Then I propose to add missing functionalities to the LED subsystem
driver.
So, the led driver should also register an generic gpio, and an
input device as well - and so duplicate code that naturally belongs
into different subsystems ?
Maybe I should be a bit more clear on the situation here:
* the AMD G-series SoCs have an integrated gpio controller, which is
used in various ways, depending on the actual board.
* apu2/apu3 is one of many boards using G-series SoCs.
* on apu2/apu3 the gpio's are used for different things, eg. leds,
keys, simcard slots, etc.
According to the LDM, the gpio controller is one device, and the other
things, eg. leds or keys, are their own devices, that just happen to
be connected to the gpio controller.
That's also the usual way we do it in embedded world: we don't write
specific-purpose drivers for each single board, but instead generic
ones that are just configured for in the individual board's oftree.
Unfotunately, we don't have the luxury of oftree on x86, nor automatic
overlays on dmi-basis, yet - that's why the platform driver.
OTOH, if you wanna rewrite the old leds-only driver to support all the
other functions, you'd end up w/ pretty much a complete rewrite: at
least you'd have to factor-out the gpio stuff, so it can be called from
separate sub-drivers, and then write several sub-drivers based on that.
I have no problem with doing it the other way round, i.e. moving all
functionality provided by the LED subsystem driver to the x86 platform
one. Just make sure that from userspace perspective nothing will change.
--
Best regards,
Jacek Anaszewski
