Re: [RFC] Addition of kernel

[Linus Walleij <linus.walleij@linaro.org>]

On Wed, Jun 19, 2019 at 1:54 PM Martyn Welch <martyn.welch@collabora.com> wrote:

> You're right, the lines we wish to use this with aren't generic gpios,
> they are primarily control lines for specific peripherals on the
> device. I believe you are right, in an ideal world we could write
> drivers for some of the functionality currently being exposed to user
> space. But I'm fairly sure some of the lines don't have a sensible
> driver model in which to fit them, specifically I can think of the
> reset, boot mode control and interrupt lines for the GPS unit embedded
> in the device I'm working on.

A GPS unit should be handled using the GNSS subsystem in
drivers/gnss:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gnss

The device tree bindings actually mention some of what you
already line up (timepulse-gpios for example):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/gnss

> We are also not in the position to make major changes to how
> functionality on this device has already been implemented and whilst we
> are hoping to move to using proper drivers in some places, this is not
> going to be tenable in all cases and we would ideally like to avoid
> utilising a home grown (and certainly unlikely to be upstreamable)
> solution for exposing these GPIOs.

While we do encourage to use the right subsystems for this kind
of stuff there are certain cases we do defer to be handled in userspace,
but not many. These include one-off things like prototypes and
factory lines with a myriad of relays (some PLC usecases),
door openers (we don't want drivers/dooropener) or fire
alarm button (but definately any elaborate IIO sensors
goes into drivers/iio) so it is a bit on case-by-case intuition
here.

Yours,
Linus Walleij