Marek Vasut writes:
> On 2/18/19 11:18 PM, Harald Geyer wrote:
> > From the explanations provided by Mark it is clear that this property
> > is an artifact of the implementation in linux. I think we should document
> > is as such. How about:
> > 
> > gpios-states : On operating systems, that don't support reading back gpio
> >            values in output mode (most notably linux), this array
> >            provides the state of GPIO pins set when requesting them
> >            from the gpio controller.
> That's good.
> > Systems, that are capable of
> >            preserving state when requesting the lines, are free to
> >            ignore this property.
> Are they ?

I think so. Also this seems to be what Mark wrote yesterday:

| With the GPIO API as it stands it is unfortunately not possible to
| preserve the state, if the API were fixed we'd preserve state.

> I think there are systems which depend on preconfiguring the
> GPIO according to this property.

These systems need to preconfigure the GPIOs in firmware anyway, so
they should be fine so long as the driver preserves state.

Since the original wording doesn't give any guarantees, I think the
new wording doesn't change anything. It just makes it clearer, that
there are no guarantees and that some drivers will happily overwrite
state when this property is absent.


If you want to support my work:
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w

Reply via email to