On 15.04.19 22:20, Andy Shevchenko wrote: >> 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.> > 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 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. 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. 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. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@xxxxxxxxx -- +49-151-27565287
