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

[Marek Vasut <marek.vasut@gmail.com>]

On 3/3/19 5:07 PM, Harald Geyer wrote:
> 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.

Well what are the proposed changes ? I don't think there was any
agreement on them.

-- 
Best regards,
Marek Vasut