On 2/19/19 11:10 AM, Harald Geyer wrote: > 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. OK, so how can we move forward with this ? We discussed a lot, but I don't know what we should do about the patch. -- Best regards, Marek Vasut
