On 07/07/2020 09:41, Geert Uytterhoeven wrote: > Hi Rodolfo, > > CC devicetree > > On Tue, Jul 7, 2020 at 9:17 AM Rodolfo Giometti <giometti@xxxxxxxxxxxx> wrote: >> On 06/07/2020 23:00, Geert Uytterhoeven wrote: >>> On Mon, Jul 6, 2020 at 10:38 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >>>> On Mon, Jul 6, 2020 at 5:33 PM Rodolfo Giometti <giometti@xxxxxxxxxxxx> wrote: >>>>>> With Geert's GPIO aggregator userspace and device tree can conjure >>>>>> special per-usecase gpio chips as pointed out by Drew: this is >>>>>> very useful when you want some kernel-managed yet >>>>>> usecase-specific GPIO lines in a special "container" chip. >>>>>> To me this is the best of two worlds. (Kernelspace and userspace.) >>>>> >>>>> Maybe this is the "best of two worlds" as you say but the problem is that board >>>>> manufactures need a way to well-define how a GPIO line must be used for within >>>>> the device-tree and without the need of patches! In this point of view neither >>>>> the "driver_override" way nor adding a compatible value to >>>>> gpio_aggregator_dt_ids[] can help (this last solution requires a patch for each >>>>> board!). That's why at the moment they prefer not specify these GPIO lines at >>>>> all or (improperly) use the gpio-leds and gpio-uinput interfaces to keep it >>>>> simple... >>>> >>>> I think the idea is to add a very generic DT compatible to the >>>> gpio_aggregator_dt_ids[]. That way, any DT can use the aggregator >>>> to create a new chip with named lines etc. >>>> >>>> But Geert can speak of that. >>> >>> The idea is to describe the real device in DT, and add it's compatible value >>> to gpio_aggregator_dt_ids[], or enable support for it dynamically using >>> driver_override. >>> The former indeed requires modifying the driver. >> >> I see. >> >>> Note that if you ever want to write a pure kernelspace driver, you do need >>> a proper compatible value anyway. >> >> OK, but for our purposes we need just one compatible value. >> >>> I do agree that it's annoying to have "gpio-leds", but not "gpio-motors" >>> or "gpio-relays". However, you can always propose bindings for the >>> latter, and, when they have been accepted, add those compatible >>> values to upstream gpio_aggregator_dt_ids[]. >> >> Having gpio-uio with proper names within it as motor0, motor1, relay0, etc. as >> in my solution would be suffice. However, after these discussions, are there any >> chances my patch (with needed modifications and documentation) may be accepted? :) >> >> Thanks for your time and answers. > > Let's ask the DT people... I think I need an OK from GPIO SUBSYSTEM's maintainers first... Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@xxxxxxxxxxxx Linux Device Driver giometti@xxxxxxxx Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti
