replacement for persistence of values written to sysfs files

replacement for persistence of values written to sysfs files

[Rasmus Villemoes]

Hi,

I'm sure this has been asked before, so please just refer to me any old
thread(s) where this has been discussed.

In the bad old sysfs days, the value assigned to the gpio via the
/sys/class/... interface was persistent. So it was easy to use in shell
scripts etc. But gpioset very clearly states

Note: the state of a GPIO line controlled over the character device
reverts to default
when the last process referencing the file descriptor representing the
device file exits.
This means that it's wrong to run gpioset, have it exit and expect the
line to continue
being driven high or low. It may happen if given pin is floating but it
must be interpreted
as undefined behavior.

and I don't see anything in v2 of the uapi changing that.

So how is one supposed to get the kernel to set and maintain a value for
a gpio, without having to keep a dummy process around? Also, with the
sysfs interface, another process can later change the gpio value; I
don't think that's possible with a dummy process hanging onto it.

So, for example, one init script we have first configures a temperature
sensor with a high-temp alert threshold, and after that value has been
written, sets a gpio that will make such an alert trigger a reset of the
board. That gpio must of course stay set, but it cannot be set before
the threshold has been programmed. Then the init script starts a simple
service that periodically logs the temperature reading. A human being
working on the board can temporarily disable the alert-triggered reset
by just writing 0 to the gpio.

The README says

Additionally this project contains a set of command-line tools that should
allow an easy conversion of user scripts to using the character device.

but I don't see how to achieve the persistence (or ability by
third-party to temporarily change the value) provided by sysfs.

Rasmus

Re: replacement for persistence of values written to sysfs files

[Andy Shevchenko]

On Mon, Mar 15, 2021 at 1:53 PM Rasmus Villemoes
<linux@rasmusvillemoes.dk> wrote:
>
> Hi,
>
> I'm sure this has been asked before, so please just refer to me any old
> thread(s) where this has been discussed.
>
> In the bad old sysfs days, the value assigned to the gpio via the
> /sys/class/... interface was persistent. So it was easy to use in shell
> scripts etc. But gpioset very clearly states
>
> Note: the state of a GPIO line controlled over the character device
> reverts to default
> when the last process referencing the file descriptor representing the
> device file exits.
> This means that it's wrong to run gpioset, have it exit and expect the
> line to continue
> being driven high or low. It may happen if given pin is floating but it
> must be interpreted
> as undefined behavior.
>
> and I don't see anything in v2 of the uapi changing that.
>
> So how is one supposed to get the kernel to set and maintain a value for
> a gpio, without having to keep a dummy process around? Also, with the
> sysfs interface, another process can later change the gpio value; I
> don't think that's possible with a dummy process hanging onto it.
>
> So, for example, one init script we have first configures a temperature
> sensor with a high-temp alert threshold, and after that value has been
> written, sets a gpio that will make such an alert trigger a reset of the
> board. That gpio must of course stay set, but it cannot be set before
> the threshold has been programmed. Then the init script starts a simple
> service that periodically logs the temperature reading. A human being
> working on the board can temporarily disable the alert-triggered reset
> by just writing 0 to the gpio.
>
> The README says
>
> Additionally this project contains a set of command-line tools that should
> allow an easy conversion of user scripts to using the character device.
>
> but I don't see how to achieve the persistence (or ability by
> third-party to temporarily change the value) provided by sysfs.

My understanding is that the character device interface lacks some
kind of (D-Bus based) daemon for this.

Note, the state of values (their persistence) depends on the hardware
driver as far as I can see in case of x86 (so, we have the gpioset,
while being context less,  be persistent). But I completely agree
that's undefined behaviour.

-- 
With Best Regards,
Andy Shevchenko

Re: replacement for persistence of values written to sysfs files

[Enrico Weigelt, metux IT consult]

On 15.03.21 12:46, Rasmus Villemoes wrote:

Hi,

> So how is one supposed to get the kernel to set and maintain a value for
> a gpio, without having to keep a dummy process around? Also, with the
> sysfs interface, another process can later change the gpio value; I
> don't think that's possible with a dummy process hanging onto it.

I've got a few remaining legacy systems in the field, where I still use
the classic sysfs interface for exactly that reason: separate 
short-running programs (shell scripts) do certain things on the gpio and 
then
exit.

For newer applications, I don't use raw gpios anymore (except for rare
things like generic PLCs, where I have no influence on the actual
workloads)

> So, for example, one init script we have first configures a temperature
> sensor with a high-temp alert threshold, and after that value has been
> written, sets a gpio that will make such an alert trigger a reset of the
> board.

Bind a proper driver to it. Either IIO or hwmon (depending on what that
sensor is actually for).


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287