Re: [RFC] gpio: expose pull-up/pull-down line flags to userspace

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Sun, Oct 6, 2019 at 5:12 AM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> On Sat, Oct 05, 2019 at 07:02:58PM +0200, Linus Walleij wrote:
> > On Fri, Oct 4, 2019 at 9:22 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote:
> >
> > > The config ioctl (or
> > > something similar) you're mentioning may appear sooner actually -
> > > users of libgpiod have been requesting a way of changing the direction
> > > of a line without releasing it - something that's possible in the
> > > kernel, but not from user-space at the moment. I'll submit something
> > > that allows to change the configuration of a requested line soon.
> >
> > Hm! I guess I assumed that userspace users would be using the lines
> > for either input or output, not complex use cases like that, reversing
> > direction and what not.
> >
> > What kind of usecase is this? I certainly hope nothing like doing
> > userspace drivers for complex hardware ... those should be in
> > the kernel... the current ABI is a bit oriented around industrial
> > automation and prototyping use cases.
>
> I'm not the only one asking for this, and I can't speak to others' use
> cases, but in my case I'm prototyping and bit bashing a SPI driver for
> an ADC where the MOSI/MISO lines can be tied to save a pin. I need to
> be able to switch line direction without glitching the line and that
> can't be guaranteed with the current UAPI.
>
> Would you consider that "complex hardware"?

I see, so in the Linux kernel this is called 3-wire SPI, and we would
drive the SPI bit-banged bus using drivers/spi/spi-gpio.c and
model ADC "foo" it as an ADC in drivers/iio/adc/foo.c.

The device tree would look something like so:

spi {
    compatible = "spi-gpio";
    #address-cells = <1>;
    #size-cells = <0>;

    gpio-sck = <&gpio0 5 GPIO_ACTIVE_HIGH>;
    gpio-mosi = <&gpio0 8 GPIO_ACTIVE_HIGH>;
    cs-gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
    num-chipselects = <1>;

    adc {
        compatible = "foo";
        reg = <0>;
        spi-3wire;
    };
};

(There are ways to define devices without explicit chipselect
as well, yielding a 2-wire bus in the end.)

The goal of the bit-banged SPI GPIO driver is to have one
driver that can be reused for any GPIO bit-banged SPI.

The goal of IIO ADC is to present a uniform and scaled
ADC interface to userspace, such that userspace need not
worry which ADC it is using because they all present the
same user API. IIO further provides precise triggers
using timers or interrupt generators to provide a
continous stream of AD-converted values using a
ring buffer.

So in summary the kernels SPI, GPIO and IIO subsystems
want to abstract hardware and make userspace simpler,
and the kernel sees userspace as having no business
driving hardware.

This might be seen as a bit imperialistic, but alas, the
explicit goal of kernel development is hardware abstraction,
and what happens sometimes in the maker community
in particular is to reimplement what the kernel does in
userspace.

What we are especially worried about is that for systems
that are not one-offs and lab prototypes, something that is
getting productified, the userspace tinkering and hackering
is just preserved in resin and no transition to proper Linux
drivers happens.

So we want userspace GPIO access to be an enabler and
not a competitor to the Linux kernel.

There are other mechanisms in the kernel with this problem,
such as UIO.

There is a problem with the biases here, such that some of the
kernel people always think they are dealing with companies
and that kind of larger organizations, and I am one of those
that don't think like that.

When it does come to companies, I think
there is this quote by Fred Brooks that you should
"always plan to throw one away" so they might write a
userspace prototype, then
throw that away and write a kernel driver as one gained
knowledge of how the hardware works. It's one of the ways
to spin it. And we want to encourage that way of doing
some userspace prototyping. And if the usecase gets
complex enough it will lean toward: what about just writing
a kernel driver in the first place and refine that.

If we are thinking a hobbyist, they are thinking to drive this
thing on their table for the next two hours or as an experiment
or for fun, or semi business (a few devices, not really mass
production), like to set up a factory line or a lightshow, that
is something that should stay in userspace and has no business
in the kernel.

And we just need to know what usecase it is here. But I need
to understand.

Yours,
Linus Walleij