linux-kernel - [PATCH 08/11 v3] staging: typec: tcpm: add cc change handling in src states

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20170828172322.7166-8-Badhri@google.com>
Date:   Mon, 28 Aug 2017 10:23:19 -0700
From:   Badhri Jagan Sridharan <badhri@...gle.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Guenter Roeck <linux@...ck-us.net>
Cc:     devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
        Badhri Jagan Sridharan <Badhri@...gle.com>
Subject: [PATCH 08/11 v3] staging: typec: tcpm: add cc change handling in src states

In the case that the lower layer driver reports a cc change directly
from SINK state to SOURCE state, TCPM doesn't handle these cc change
in SRC_SEND_CAPABILITIES, SRC_READY states. And with SRC_ATTACHED
state, the change is not handled as the port is still considered
connected.

[49606.131672] state change DRP_TOGGLING -> SRC_ATTACH_WAIT
[49606.131701] pending state change SRC_ATTACH_WAIT -> SRC_ATTACHED @
200 ms
[49606.329952] state change SRC_ATTACH_WAIT -> SRC_ATTACHED [delayed 200
ms]
[49606.329978] polarity 0
[49606.329989] Requesting mux mode 1, config 0, polarity 0
[49606.349416] vbus:=1 charge=0
[49606.372274] pending state change SRC_ATTACHED -> SRC_UNATTACHED @ 480
ms
[49606.372431] VBUS on
[49606.372488] state change SRC_ATTACHED -> SRC_STARTUP
...
(the lower layer driver reports a direct change from source to sink)
[49606.536927] pending state change SRC_SEND_CAPABILITIES ->
SRC_SEND_CAPABILITIES @ 150 ms
[49606.547244] CC1: 2 -> 5, CC2: 0 -> 0 [state SRC_SEND_CAPABILITIES,
polarity 0, connected]

This can happen when the lower layer driver and/or the hardware
handles a portion of the Type-C state machine work, and quietly goes
through the unattached state.

Originally-from: Yueyao Zhu <yueyao@...gle.com>
Signed-off-by: Badhri Jagan Sridharan <Badhri@...gle.com>
Reviewed-by: Guenter Roeck <linux@...ck-us.net>
---
Changelog since previous version:
- Only one previous version of the patch was sent.
  Numbering this V3 instead of V2 to keep the sequence
  number in sync with the rest of the patches in the
  patch list.
- added Reviewed-by: Guenter Roeck <linux@...ck-us.net>
- fixed version/sequence numbers

 drivers/staging/typec/tcpm.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
index 645f43ee83df..1f6827f32b29 100644
--- a/drivers/staging/typec/tcpm.c
+++ b/drivers/staging/typec/tcpm.c
@@ -2874,10 +2874,12 @@ static void _tcpm_cc_change(struct tcpm_port *port, enum typec_cc_status cc1,
 			tcpm_set_state(port, SRC_ATTACH_WAIT, 0);
 		break;
 	case SRC_ATTACHED:
-		if (tcpm_port_is_disconnected(port))
+	case SRC_SEND_CAPABILITIES:
+	case SRC_READY:
+		if (tcpm_port_is_disconnected(port) ||
+		    !tcpm_port_is_source(port))
 			tcpm_set_state(port, SRC_UNATTACHED, 0);
 		break;
-
 	case SNK_UNATTACHED:
 		if (tcpm_port_is_sink(port))
 			tcpm_set_state(port, SNK_ATTACH_WAIT, 0);
-- 
2.14.1.342.g6490525c54-goog