RE: [PATCH v2 3/3] dt-bindings: Input: da9062 - fix dlg,disable-key-power description

On 07 January 2020 08:09, Marco Felsch wrote:

Hi Adam, Dmitry,

On 19-12-12 10:08, Adam Thomson wrote:

quoted

On 10 December 2019 08:28, Marco Felsch wrote:

quoted

Hi Adam,

On 19-12-02 12:15, Adam Thomson wrote:

quoted

On 27 November 2019 13:23, Marco Felsch wrote:

quoted

There was a bug within the driver since commit f889beaaab1c ("Input:
da9063 - report KEY_POWER instead of KEY_SLEEP during power
key-press"). Since we fixed the bug the KEY_POWER will be reported
always so we need to adapt the dt-bindings too. Make the description
more precise while on it.

Signed-off-by: Marco Felsch <redacted>
---
v2:
- change description according Dmitry's suggestion.

 Documentation/devicetree/bindings/input/da9062-onkey.txt | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt

b/Documentation/devicetree/bindings/input/da9062-onkey.txt
index 0005b2bdcdd7..9f895454179d 100644

--- a/Documentation/devicetree/bindings/input/da9062-onkey.txt
+++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt

@@ -15,9 +15,8 @@ Required properties:

 Optional properties:

-- dlg,disable-key-power : Disable power-down using a long key-press. If

this

quoted

quoted

quoted

quoted

-    entry exists the OnKey driver will remove support for the KEY_POWER

key

quoted

quoted

quoted

quoted

-    press when triggered using a long press of the OnKey.
+- dlg,disable-key-power : If this property is present, the host will not be
+    issuing shutdown command over I2C in response to a long key-press.

This also changes behaviour of button press reporting as the driver will not
report a longer press (i.e. a button hold where the driver polls for release).
It will only report a short key press to user-space with this property

provided.

quoted

quoted

quoted

The question here is do we still want to support long press reporting but
without the I2C sequence for shutdown? If so the driver needs to be

updated

quoted

quoted

to

quoted

work this way as right now it doesn't.

Good point. I checked the driver and the documentation for the
da9062/3 again and it seems that we interrupt the pmic hw by doing the
shutdown by itself. As the documentation says:

DA9063:
If the hardware reset was initiated by a (debounced) press of nONKEY (or
GPIO14 and GPIO15 together) longer than SD_DELAY, the DA9063 initially
only asserts control bit KEY_RESET in the fault register and signals a
non-maskable interrupt allowing the host to clear the armed reset
sequence within 1 s. If the host does not clear KEY_RESET then a
shutdown to RESET mode is executed. KEY_SD_MODE determines if normal
power sequence timing or a fast shutdown is implemented.

DA9062:
If the reset was initiated by a user’s long press of nONKEY, initially
only KEY_RESET is set and the nIRQ port will be asserted. KEY_RESET
signals the host that a shutdown sequence is started. If the host does
not then clear KEY_RESET within 1 s by writing a 1 to the related bit in
register FAULT_LOG, the shutdown sequence will complete. When the reset
condition has disappeared, DA9062 requires a supply (VSYS >
VDD_FAULT_UPPER) that provides enough power to start-up from the
POWERDOWN mode.

So we don't need to check for the KEY_RESET? This would cleanup the code
a bit.

We could remove that but I think the intention originally was to have this code
there in case there was some way to more gracefully shutdown the system in

this

quoted

scenario. Right now that's not the case as the code simply calls to shutdown
the pmic via a manual register call, but maybe in the future this could be made
more gracful. Another slight advantage of leaving that code in is that we're
not waiting for another second delay for the PMIC to pull the plug.

With regards to this patch and the subsequent one to update the OnKey driver,

I

quoted

think we should deprecate this property. The OnKey mode binding you added

in

quoted

a different patch will configure the OnKey according to how you want it to
behave in hardware so I don't think this property makes much sense anymore.

We

quoted

can then remove the need for 'key_power' usage in the driver.

Is it okay for you both to drop this patch from this series and open a
new 'rework' series?

I have no issues with this.