Received-SPF: pass (google.com: domain of linux-kernel+bounces-22164-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <20240109135952.77458-1-warthog618@gmail.com> <20240109135952.77458-2-warthog618@gmail.com>
 <CA+kSVo_347gS+w_7ZXFDi9qDtT1aw15qoWRJZAVSkfbHShz7kQ@mail.gmail.com>
In-Reply-To: <CA+kSVo_347gS+w_7ZXFDi9qDtT1aw15qoWRJZAVSkfbHShz7kQ@mail.gmail.com>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Wed, 10 Jan 2024 14:20:18 +0200
Message-ID: <CAHp75VdQFE8aA0wmDZ6KSE8xfKptzXasQz=AdzQpSRr2gwt6wQ@mail.gmail.com>
Subject: Re: [PATCH 1/7] Documentation: gpio: add chardev userspace API documentation
To: Phil Howard <phil@gadgetoid.com>
Cc: Kent Gibson <warthog618@gmail.com>, linux-kernel@vger.kernel.org, 
	linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org, brgl@bgdev.pl, 
	linus.walleij@linaro.org, andy@kernel.org, corbet@lwn.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 10, 2024 at 1:40=E2=80=AFPM Phil Howard <phil@gadgetoid.com> wr=
ote:
> On Tue, 9 Jan 2024 at 14:00, Kent Gibson <warthog618@gmail.com> wrote:

..

> > +   Read Documentation/driver-api/gpio/drivers-on-gpio.rst to avoid rei=
nventing
> > +   kernel wheels in userspace.
>
> I realise this is in part an emotional response, but very much
> "citation needed" on
> this one. While I believe Kernel drivers for things are a good idea, I
> don't believe
> userspace libraries are necessarily bad or wrong. They might be the first
> experience a future kernel dev has with hardware. Either way there are mu=
ltiple
> ecosystems of userspace drivers both existing and thriving right now, and=
 there
> are good reasons to reinvent kernel wheels in userspace.
>
> At least some of these reasons relate to the (incorrectly assumed)
> insurmountable
> nature of kernel development vs just throwing together some Python. Inclu=
ding
> this loaded language just serves to reinforce that.
>
> You catch more flies with honey than with vinegar, so I'd probably soften=
 to:
>
> Before abusing userspace APIs to bitbash drivers for your hardware you sh=
ould
> read Documentation/driver-api/gpio/drivers-on-gpio.rst to see if your dev=
ice has
> an existing kernel driver. If not, please consider contributing one.

I believe this note was motivated by the quite popular pyGPIO for RPi
and MRAA for some platforms, which are the examples of how _not_ do
things.

..

> > +Each chip supports a number of GPIO lines,
> > +:c:type:`chip.lines<gpiochip_info>`. Lines on the chip are identified =
by an
> > +``offset`` in the range from 0 to ``chip.lines - 1``, i.e. `[0,chip.li=
nes)`.
>
> I don't recognise this syntax "`[0,chip.lines)`", typo, or me being cluel=
ess?

It's called "open interval", a mathematical term.

..

> > +    -  -  ``EFAULT``

Wondering if these constants can be referenced via % and if it makes sense.

..

> > +The size of the kernel event buffer is fixed at the time of line reque=
st
> > +creation, and can be influenced by the
> > +:c:type:`request.event_buffer_size<gpio_v2_line_request>`.
> > +The default size is 16 times the number of lines requested.
>
> This might explain why I could never quite get high-speed pulse counting =
to feel
> right. Thank you!

GPIO is just not a good tool for this kind of measurement.

--=20
With Best Regards,
Andy Shevchenko