[RFC] Addition of kernel

[RFC] Addition of kernel

[Martyn Welch]

Hi Linus, Bartosz,

We are currently in the position that we would like to pre-configure
some GPIOs at boot time and be able to later affect the state of GPIOs
configured as outputs or read the state of GPIOs previously configured
as inputs.

The device tree property `gpios-line-names` gives a very useful
mechanism for identifying the correct GPIO to use/read for a given
purpose in user space, but doesn't provide any guidance on how that
line is expected to be used. The gpio-hogging functionality enables us
to configure GPIOs during boot, ensuring that the correct state is
present on the relevant GPIO lines, but does not provide the ability to
modify or read these GPIOs at runtime.

I understand that a lot of people have requested such functionality in
the past, but I'm not sure if anything concrete has ever been
submitted. I'm interested in determining what the general feeling
towards adding such functionality would be and to gain some input with
regards to how this should/could be implemented (assuming the general
concept is acceptable).

Initially we are thinking of providing a device-tree node containing a
"gpio-default" property and would contain a lot of the same properties
as "gpio-hog".

Code wise, it would seem to need to follow roughly the same flow as
gpio-hog, but avoid running "gpiod_request_commit()" so that the GPIO
line could later be requested by user space.

I suspect there's a whole load of details that I'm missing at this
stage and I've not fully thought through the implications for later
removal.

Does something like this seem viable upstream?

Martyn

Re: [RFC] Addition of kernel

[Phil Reid]

G'day Martyn,

On 17/06/2019 16:29, Martyn Welch wrote:
> Hi Linus, Bartosz,
> 
> We are currently in the position that we would like to pre-configure
> some GPIOs at boot time and be able to later affect the state of GPIOs
> configured as outputs or read the state of GPIOs previously configured
> as inputs.
> 
> The device tree property `gpios-line-names` gives a very useful
> mechanism for identifying the correct GPIO to use/read for a given
> purpose in user space, but doesn't provide any guidance on how that
> line is expected to be used. The gpio-hogging functionality enables us
> to configure GPIOs during boot, ensuring that the correct state is
> present on the relevant GPIO lines, but does not provide the ability to
> modify or read these GPIOs at runtime.
> 
> I understand that a lot of people have requested such functionality in
> the past, but I'm not sure if anything concrete has ever been
> submitted. I'm interested in determining what the general feeling
> towards adding such functionality would be and to gain some input with
> regards to how this should/could be implemented (assuming the general
> concept is acceptable).
> 
> Initially we are thinking of providing a device-tree node containing a
> "gpio-default" property and would contain a lot of the same properties
> as "gpio-hog".
> 
> Code wise, it would seem to need to follow roughly the same flow as
> gpio-hog, but avoid running "gpiod_request_commit()" so that the GPIO
> line could later be requested by user space.
> 
> I suspect there's a whole load of details that I'm missing at this
> stage and I've not fully thought through the implications for later
> removal.
> 
> Does something like this seem viable upstream?
> 

I'd find something like this useful.
If we know enough to name the gpio lines, we more than likely also know enough
to restrict the IO configuration to input only in the DT.

There's a new driver recently posted that solves some of this:
"Add virtual controller for gpio configuration"
https://www.spinics.net/lists/linux-gpio/msg39681.html

It solves a number of problems except for restricting user-space from
configuring a pin for output that should never be an output.



-- 
Regards
Phil Reid

Re: [RFC] Addition of kernel

[Linus Walleij]

Hi Martyn,

On Mon, Jun 17, 2019 at 10:29 AM Martyn Welch
<martyn.welch@collabora.com> wrote:

> We are currently in the position that we would like to pre-configure
> some GPIOs at boot time and be able to later affect the state of GPIOs
> configured as outputs or read the state of GPIOs previously configured
> as inputs.

I have discussed this several times in the past, I soon have to
make a collection of links to the old discussions so we don't have
to repeat ourselves :)

Here are some:

Discussion with Rob Herring:
https://marc.info/?l=linux-gpio&m=145749645728713&w=2

https://marc.info/?l=linux-gpio&m=153440711326259&w=2
In response to:
https://marc.info/?l=linux-kernel&m=153436471811875&w=2

> Initially we are thinking of providing a device-tree node containing a
> "gpio-default" property and would contain a lot of the same properties
> as "gpio-hog".
>
> Code wise, it would seem to need to follow roughly the same flow as
> gpio-hog, but avoid running "gpiod_request_commit()" so that the GPIO
> line could later be requested by user space.
>
> I suspect there's a whole load of details that I'm missing at this
> stage and I've not fully thought through the implications for later
> removal.
>
> Does something like this seem viable upstream?

I am all for it, the trick is to come up with a syntax that passes the
review of the device tree people. They did not like the idea to extend
the hogs, and dislike the way hogs were made in the first place.

I would suspect that something more similar to gpio-line-names
sits better with them, like gpio-initial-states = in -, out 1, out 0, in -. ...
however that would work.

There are some custom bindings for this already that should
ideally be phased over to the generic bindings as part of the
patch set.

Yours,
Linus Walleij

Re: [RFC] Addition of kernel

[Enrico Weigelt, metux IT consult]

On 17.06.19 10:29, Martyn Welch wrote:

Hi,

> We are currently in the position that we would like to pre-configure
> some GPIOs at boot time and be able to later affect the state of GPIOs
> configured as outputs or read the state of GPIOs previously configured
> as inputs.

what's the actual use case you've got in mind ?

I've got the feeling that these lines aren't really so "generic" in
your case, but attached to something that has a particular meaning.

So, maybe something that deserves it's own driver ?


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

Re: [RFC] Addition of kernel

[Martyn Welch]

On Mon, 2019-06-17 at 14:39 +0200, Enrico Weigelt, metux IT consult
wrote:
> On 17.06.19 10:29, Martyn Welch wrote:
> We are currently in the position that we would like to pre-
> > configure
> > some GPIOs at boot time and be able to later affect the state of
> > GPIOs
> > configured as outputs or read the state of GPIOs previously
> > configured
> > as inputs.
> 
> what's the actual use case you've got in mind ?
> 
> I've got the feeling that these lines aren't really so "generic" in
> your case, but attached to something that has a particular meaning.
> 
> So, maybe something that deserves it's own driver ?
> 

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.

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.

Martyn

Re: [RFC] Addition of kernel

[Enrico Weigelt, metux IT consult]

On 19.06.19 13:54, Martyn Welch wrote:

Hi,

> 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.

Looks like a case for rfkill, pm, etc.

> 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.

IMHO, the best way for getting things upstream are generic (but
configurable) drivers, or improving existing ones.

If it's just about getting some gpios in a specific state at bootup,
why not doing that in an init script ?

Your description feels a bit like trying to introduce some workarounds
for some not so well designed proprietary legacy code. If your
application directly drives raw gpio's (something I'd do only in really,
exceptionally rare cases), but needs something else to do some tweaks
first, that looks like a broken application. OTOH, I don't think that
applications should do such low level hardware access in the first
place.


--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

Re: [RFC] Addition of kernel

[Linus Walleij]

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

Re: [RFC] Addition of kernel

[Enrico Weigelt, metux IT consult]

On 24.06.19 23:46, Linus Walleij wrote:

> 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

yes, since serdev we can also easily drive serial-connected devices
(which many gps receivers are) from inside the kernel. there're also
composite devices (eg. combined basebands) which also have gps amongst
other things, so an own subsystem for gps devices is the way to go.

> 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

Those are cases which probably nobody wants to have special support
in the mainline kernel ... i recall some rules about no kernel drivers
without corresponding free userland ...

> factory lines with a myriad of relays (some PLC usecases),
> door openers (we don't want drivers/dooropener) 

Actually, I've got something like that in the pipeline: a generic relais
subsystem for anything that just switches on/off. Haven't gathered all
requirements yet - for now just abusing LED for that (yes, also actually
door openers). Okay, door openers could be a complex matter on their
own, depending on how it electrically/mechanically works - some devices
let motors spin until an end reached, etc. ... but haven't had an
actual usecase for putting such things into the kernel.

> or fire alarm button

Button -> input subsystem ?

> (but definately any elaborate IIO sensors
> goes into drivers/iio) so it is a bit on case-by-case intuition
> here.

yes, and it's primarily about high level functionality. in industrial
world we often have composite devices that span multiple subsystems.

I any case, for a good decision we need to know what exactly some
individual device actually does.

--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287