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. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
