On Tue, Apr 16, 2019 at 7:36 PM Enrico Weigelt, metux IT consult <lkml@xxxxxxxxx> wrote: > On 15.04.19 22:20, Andy Shevchenko wrote: ... [something wrong with text formatting in your MUA] > > You may utilize swnode API instead and have a generic driver beneath which resource provider agnostic (via device property / fwnode API). > Well, when we add oftree probing to the driver, then using fwnode api oftree -> unified device property API (if we are talking about driver) fwnode API -> swnode API (if we are talking about platform code) > for that would seems to make sense. But for now, I haven't seen a single > board with that SoC that uses either oftree, or has proper acpi tables. Make them. swnode API and preparing structures allows you to mock up the thing and test. > For the apu2/3 I don't see anything like that on the horizon - and here > it would only help us, if all existing devices would get a fw upgrade. > I'm not even sure, whether the whole thing can be expressed via ACPI > tables in the way we need it. It may. Just Do It. > Remember, we have several layers here: > > a) the gpio device within the SoC (base address, gpio registers - they > are NOT linear, ...) > b) assignment between invididual gpio's to the functional (virtual) > devices - leds, keys, rfkill, ... > > I'm really not up to date on recent acpi specs, but gpio entries only > (assuming the fw in the field actually supports it) won't be sufficient. > We'd need to express leds, keys, etc _connected_ to gpios. I do not see any issue here. Have you got familiar with meta-acpi [1] repository? There are plenty examples how to describe DT enabled drivers in ACPI tables, including gpio-keys, LEDs [2], and so on. [1]: https://github.com/westeri/meta-acpi [2]: https://github.com/westeri/meta-acpi/blob/master/recipes-bsp/acpi-tables/samples/edison/leds.asli -- With Best Regards, Andy Shevchenko
