Re: [PATCH] regulator: gpio: Reword the binding document

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux