Re: [RFC] GPIO User I/O

[Rodolfo Giometti <giometti@xxxxxxxxxxxx>]

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.

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