Re: [PATCH 3/6] dt-bindings: HID: i2c-hid: elan: add 'no-reset-on-power-off' property

[Krzysztof Kozlowski]

On 02/05/2024 11:56, Johan Hovold wrote:
> Hi Krzysztof,
> 
> and sorry about the late reply. Got side-tracked.
> 
> On Thu, Apr 25, 2024 at 11:39:24AM +0200, Krzysztof Kozlowski wrote:
>> On 24/04/2024 09:34, Johan Hovold wrote:
>>> On Tue, Apr 23, 2024 at 06:29:44PM +0200, Krzysztof Kozlowski wrote:
>>>> On 23/04/2024 15:46, Johan Hovold wrote:
>>>>> When the power supply is shared with other peripherals the reset line
>>>>> can be wired in such a way that it can remain deasserted regardless of
>>>>> whether the supply is on or not.
> 
>>>>> This is important as it can be used to avoid holding the controller in
>>>>> reset for extended periods of time when it remains powered, something
>>>>> which can lead to increased power consumption. Leaving reset deasserted
>>>>> also avoids leaking current through the reset circuitry pull-up
>>>>> resistors.
>>>>>
>>>>> Add a new 'no-reset-on-power-off' devicetree property which can be used
>>>>> by the OS to determine when reset needs to be asserted on power down.
>>>>>
>>>>> Note that this property can also be used when the supply cannot be
>>>>> turned off by the OS at all.
>>>
>>>>>    reset-gpios:
>>>>>      description: Reset GPIO; not all touchscreens using eKTH6915 hook this up.
>>>>>  
>>>>> +  no-reset-on-power-off:
>  
>>>> Anyway, the property sounds like what the OS should be doing, which is
>>>> not what we want. You basically instruct driver what to do. We want a
>>>> described hardware configuration or hardware specifics.
>>>
>>> Right, and this was why I at first rejected a property name like this in
>>> favour of 'reset-pulled-to-supply' in my first draft. That name
>>> obviously does not work as the 'supply' suffix is already claimed, but I
>>> also realised that it doesn't really describe the hardware property that
>>> allows the reset line to remain asserted.
>>>
>>> The key feature in this hardware design is that the reset line will not
>>> just be pulled to the supply voltage (what other voltage would it be
>>> pulled to), but that it is also pulled to ground when the supply is
>>> disabled.
>>
>> OK, if the property was specific to the hardware, then I would propose
>> something more hardware-related, e.g. "reset-supply-tied". However :
>>
>>> Rather than trying to encode this in the property name, I settled on the
>>> descriptive 'no-reset-on-power-off' after the seeing the prior art in
>>> 'goodix,no-reset-during-suspend' property. The latter is too specific
>>> and encodes policy, but the former could still be considered hardware
>>> description and would also apply to other designs which have the
>>> property that the reset line should be left deasserted.
>>>
>>> One such example is when the supply can not be disabled at all (e.g. the
>>> Goodix case), but I can imagine there being more than one way to design
>>> such reset circuits.
>>
>> It seems it is common problem. LEDs have property
>> "retain-state-shutdown", to indicate that during system shutdown we
>> should not touch them (like power off). Would some variant be applicable
>> here? First, do we talk here about power off like system shutdown or
>> runtime PM, thus suspend?
> 
> A name like 'retain-state-shutdown' would also be too specific as what
> I'm describing here is that the reset line should be (or can be) left
> deasserted whenever the OS wants to power off the device.

I don't think it is more specific than yours. It is actually more
generic. First, shutdown=poweroff, so that part is the same.
retain-state means keep things enabled, asserted, deasserted, etc, so
multiple cases. Your wording is specific - only one state is kept during
power off: reset deassert.

Best regards,
Krzysztof