Marek Vasut writes: > 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.
Yes, we discussed a lot. I guess most people lost track of where we stand. I'd suggest you send a V2 of the patch, picking up all the proposed changes. If you feel the part about `gpios-states' property is too controversial, then maybe split it in two patches: The first containing the non-controversial changes and the second improving `gpios-states' description, so that maintainers can ACK them independently. best regards, Harald
