| Message ID | 20230914003154.27977-1-michael@allwinnertech.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org>
Delivered-To: ouuuleilei@gmail.com
Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp22287vqi;
Wed, 13 Sep 2023 17:32:55 -0700 (PDT)
X-Google-Smtp-Source:
AGHT+IEdMnbHuiPVsuF4KJuPF7GCkG+BNerk2L0g+rZlxxIuQDzlzSnKJ+HKfhdMre/zuxSLMv7L
X-Received: by 2002:a17:90b:4acf:b0:263:f4cc:a988 with SMTP id
mh15-20020a17090b4acf00b00263f4cca988mr3898390pjb.5.1694651575096;
Wed, 13 Sep 2023 17:32:55 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1694651575; cv=none;
d=google.com; s=arc-20160816;
b=HW0jXvk1eKjGCaPfqnklgqEQcsXPiweeU6LZob+nrpaQWQ9nNvcwruai455Bgmu+Iw
ZOUyLQ5yCWsO/xL4P+toowZYU17CpwvrBllRD+zzMOSp/t2YWy3TEk5K/td1M1vzq3zd
n/1KXQ1HDQBoLWljKgM8MyrrSVjnqVW47W7oBhYcH3Ry5nR8M4jVT2CUWByA9hASEKyb
sAjEGif1OLeArldUJQw0c8yGpm3Y4SY4KpIc190j8vLm7xzUWrJcS6ZWlB8JraLK3vCo
CONzcZoqYtMNqWx0bDenPHfHY7fCO8to91Tj+iumsanze7BnbIjtZizTwJERWlDYlSOn
UfMA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20160816;
h=list-id:precedence:content-transfer-encoding:mime-version
:message-id:date:subject:cc:to:from;
bh=LIVxaQtqy2k8E9cHGvugEAGL21PUcJXYYsu8RN2SB0Y=;
fh=9heofhu7MvbjDjs1Hguzot+SUMn0EWL0acDv2wGVjxY=;
b=nVzn3mdV3pzSWQoPrwYbWTtp7EMUxG3vmAoqGQiom7S+eYAlQE8j880lONe4z7xhWF
Fi8UfDpk9LMxY0JmdPNyLN+ooB5Lon/c6n0aFvmwtQEUaAqiDysGGzgK3jy42wVkPC2y
HWMGCtFoKiMh/7VumP47LFL73ly5YMdIPS4a5I1eGBKP+8cVJMv214JzJzXvMoBuGyA2
1RlU3P9nbItmPnUaUqa+Qg5B6WBV+K5OfiNezKoz7uDVLuwgNCkb0jMLeV7OIz+CxTNa
DKweGqnqvGzF7OKMvQ2q72M5rQ3uiJahIfldjxzmvg26qeBfFOjz7Chec9LgGfc3FeHo
WmkQ==
ARC-Authentication-Results: i=1; mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::3:8 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org
Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8])
by mx.google.com with ESMTPS id
l10-20020a17090aec0a00b00267ba1c43adsi433739pjy.101.2023.09.13.17.32.54
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 13 Sep 2023 17:32:55 -0700 (PDT)
Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::3:8 as permitted sender)
client-ip=2620:137:e000::3:8;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org
designates 2620:137:e000::3:8 as permitted sender)
smtp.mailfrom=linux-kernel-owner@vger.kernel.org
Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0])
by fry.vger.email (Postfix) with ESMTP id D553F827043B;
Wed, 13 Sep 2023 17:32:08 -0700 (PDT)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S232888AbjINAcA (ORCPT <rfc822;chrisfriedt@gmail.com>
+ 35 others); Wed, 13 Sep 2023 20:32:00 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43716 "EHLO
lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S231223AbjINAb4 (ORCPT
<rfc822;linux-kernel@vger.kernel.org>);
Wed, 13 Sep 2023 20:31:56 -0400
Received: from out28-122.mail.aliyun.com (out28-122.mail.aliyun.com
[115.124.28.122])
by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6695F1727;
Wed, 13 Sep 2023 17:31:52 -0700 (PDT)
X-Alimail-AntiSpam:
AC=CONTINUE;BC=0.3083717|-1;CH=green;DM=|CONTINUE|false|;DS=CONTINUE|ham_system_inform|0.00366759-0.000116842-0.996216;FP=0|0|0|0|0|-1|-1|-1;HT=ay29a033018047203;MF=michael@allwinnertech.com;NM=1;PH=DS;RN=5;RT=5;SR=0;TI=SMTPD_---.UeY3CYB_1694651508;
Received: from SunxiBot.allwinnertech.com(mailfrom:michael@allwinnertech.com
fp:SMTPD_---.UeY3CYB_1694651508)
by smtp.aliyun-inc.com;
Thu, 14 Sep 2023 08:31:49 +0800
From: Michael Wu <michael@allwinnertech.com>
To: linux@roeck-us.net, heikki.krogerus@linux.intel.com,
gregkh@linuxfoundation.org
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH] usb:typec:tcpm:support double Rp to Vbus cable as sink
Date: Thu, 14 Sep 2023 08:31:54 +0800
Message-Id: <20230914003154.27977-1-michael@allwinnertech.com>
X-Mailer: git-send-email 2.29.0
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test,
not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]);
Wed, 13 Sep 2023 17:32:08 -0700 (PDT)
X-Spam-Status: No,
score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY
autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email
X-getmail-retrieved-from-mailbox: INBOX
X-GMAIL-THRID: 1776970969953035015
X-GMAIL-MSGID: 1776970969953035015
|
| Series |
usb:typec:tcpm:support double Rp to Vbus cable as sink
|
|
Commit Message
Michael Wu
Sept. 14, 2023, 12:31 a.m. UTC
The USB Type-C Cable and Connector Specification defines the wire
connections for the USB Type-C to USB 2.0 Standard-A cable assembly
(Release 2.2, Chapter 3.5.2).
The Notes says that Pin A5 (CC) of the USB Type-C plug shall be connected
to Vbus through a resister Rp.
However, there is a large amount of such double Rp connected to Vbus
non-standard cables which produced by UGREEN circulating on the market, and
it can affects the normal operations of the state machine easily,
especially to CC1 and CC2 be pulled up at the same time.
In fact, we can regard those cables as sink to avoid abnormal state.
Message as follow:
[ 58.900212] VBUS on
[ 59.265433] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected]
[ 62.623308] CC1: 3 -> 0, CC2: 3 -> 0 [state TOGGLING, polarity 0, disconnected]
[ 62.625006] VBUS off
[ 62.625012] VBUS VSAFE0V
Signed-off-by: Michael Wu <michael@allwinnertech.com>
---
drivers/usb/typec/tcpm/tcpm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On Thu, Sep 14, 2023 at 08:31:54AM +0800, Michael Wu wrote: > The USB Type-C Cable and Connector Specification defines the wire > connections for the USB Type-C to USB 2.0 Standard-A cable assembly > (Release 2.2, Chapter 3.5.2). > The Notes says that Pin A5 (CC) of the USB Type-C plug shall be connected > to Vbus through a resister Rp. > However, there is a large amount of such double Rp connected to Vbus > non-standard cables which produced by UGREEN circulating on the market, and > it can affects the normal operations of the state machine easily, > especially to CC1 and CC2 be pulled up at the same time. > In fact, we can regard those cables as sink to avoid abnormal state. > > Message as follow: > [ 58.900212] VBUS on > [ 59.265433] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] > [ 62.623308] CC1: 3 -> 0, CC2: 3 -> 0 [state TOGGLING, polarity 0, disconnected] > [ 62.625006] VBUS off > [ 62.625012] VBUS VSAFE0V > > Signed-off-by: Michael Wu <michael@allwinnertech.com> > --- > drivers/usb/typec/tcpm/tcpm.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c > index d962f67c95ae6..beb7143128667 100644 > --- a/drivers/usb/typec/tcpm/tcpm.c > +++ b/drivers/usb/typec/tcpm/tcpm.c > @@ -519,7 +519,8 @@ static const char * const pd_rev[] = { > > #define tcpm_port_is_sink(port) \ > ((tcpm_cc_is_sink((port)->cc1) && !tcpm_cc_is_sink((port)->cc2)) || \ > - (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1))) > + (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1)) || \ > + (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2))) > > #define tcpm_cc_is_source(cc) ((cc) == TYPEC_CC_RD) > #define tcpm_cc_is_audio(cc) ((cc) == TYPEC_CC_RA) This look OK to me, but I would still like to wait for comments from Guenter - just in case. thanks,
On 9/18/23 03:31, Heikki Krogerus wrote: > On Thu, Sep 14, 2023 at 08:31:54AM +0800, Michael Wu wrote: >> The USB Type-C Cable and Connector Specification defines the wire >> connections for the USB Type-C to USB 2.0 Standard-A cable assembly >> (Release 2.2, Chapter 3.5.2). >> The Notes says that Pin A5 (CC) of the USB Type-C plug shall be connected >> to Vbus through a resister Rp. >> However, there is a large amount of such double Rp connected to Vbus >> non-standard cables which produced by UGREEN circulating on the market, and >> it can affects the normal operations of the state machine easily, >> especially to CC1 and CC2 be pulled up at the same time. >> In fact, we can regard those cables as sink to avoid abnormal state. >> >> Message as follow: >> [ 58.900212] VBUS on >> [ 59.265433] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected] >> [ 62.623308] CC1: 3 -> 0, CC2: 3 -> 0 [state TOGGLING, polarity 0, disconnected] >> [ 62.625006] VBUS off >> [ 62.625012] VBUS VSAFE0V >> >> Signed-off-by: Michael Wu <michael@allwinnertech.com> >> --- >> drivers/usb/typec/tcpm/tcpm.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c >> index d962f67c95ae6..beb7143128667 100644 >> --- a/drivers/usb/typec/tcpm/tcpm.c >> +++ b/drivers/usb/typec/tcpm/tcpm.c >> @@ -519,7 +519,8 @@ static const char * const pd_rev[] = { >> >> #define tcpm_port_is_sink(port) \ >> ((tcpm_cc_is_sink((port)->cc1) && !tcpm_cc_is_sink((port)->cc2)) || \ >> - (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1))) >> + (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1)) || \ >> + (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2))) >> >> #define tcpm_cc_is_source(cc) ((cc) == TYPEC_CC_RD) >> #define tcpm_cc_is_audio(cc) ((cc) == TYPEC_CC_RA) > > This look OK to me, but I would still like to wait for comments from > Guenter - just in case. > Look at the conditions. Reordered, we end up with (tcpm_cc_is_sink((port)->cc1) && !tcpm_cc_is_sink((port)->cc2)) || (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2)) which simplifies to tcpm_cc_is_sink((port)->cc1) making the complete expression tcpm_cc_is_sink((port)->cc1) || (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1)) which simplifies further to tcpm_cc_is_sink((port)->cc1) || tcpm_cc_is_sink((port)->cc2) The simplified expression doesn't conflict with other detections, so I am ok with it. It might be worthwhile adding a comment to the code, though, explaining the reason. Guenter > thanks, >
On 2023/9/18 22:22, Guenter Roeck wrote: > On 9/18/23 03:31, Heikki Krogerus wrote: >> On Thu, Sep 14, 2023 at 08:31:54AM +0800, Michael Wu wrote: >>> The USB Type-C Cable and Connector Specification defines the wire >>> connections for the USB Type-C to USB 2.0 Standard-A cable assembly >>> (Release 2.2, Chapter 3.5.2). >>> The Notes says that Pin A5 (CC) of the USB Type-C plug shall be >>> connected >>> to Vbus through a resister Rp. >>> However, there is a large amount of such double Rp connected to Vbus >>> non-standard cables which produced by UGREEN circulating on the >>> market, and >>> it can affects the normal operations of the state machine easily, >>> especially to CC1 and CC2 be pulled up at the same time. >>> In fact, we can regard those cables as sink to avoid abnormal state. >>> >>> Message as follow: >>> [ 58.900212] VBUS on >>> [ 59.265433] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, >>> connected] >>> [ 62.623308] CC1: 3 -> 0, CC2: 3 -> 0 [state TOGGLING, polarity 0, >>> disconnected] >>> [ 62.625006] VBUS off >>> [ 62.625012] VBUS VSAFE0V >>> >>> Signed-off-by: Michael Wu <michael@allwinnertech.com> >>> --- >>> drivers/usb/typec/tcpm/tcpm.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/usb/typec/tcpm/tcpm.c >>> b/drivers/usb/typec/tcpm/tcpm.c >>> index d962f67c95ae6..beb7143128667 100644 >>> --- a/drivers/usb/typec/tcpm/tcpm.c >>> +++ b/drivers/usb/typec/tcpm/tcpm.c >>> @@ -519,7 +519,8 @@ static const char * const pd_rev[] = { >>> #define tcpm_port_is_sink(port) \ >>> ((tcpm_cc_is_sink((port)->cc1) && >>> !tcpm_cc_is_sink((port)->cc2)) || \ >>> - (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1))) >>> + (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1)) >>> || \ >>> + (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2))) >>> #define tcpm_cc_is_source(cc) ((cc) == TYPEC_CC_RD) >>> #define tcpm_cc_is_audio(cc) ((cc) == TYPEC_CC_RA) >> >> This look OK to me, but I would still like to wait for comments from >> Guenter - just in case. >> > > Look at the conditions. Reordered, we end up with > (tcpm_cc_is_sink((port)->cc1) && !tcpm_cc_is_sink((port)->cc2)) || > (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2)) > which simplifies to > tcpm_cc_is_sink((port)->cc1) > making the complete expression > tcpm_cc_is_sink((port)->cc1) || > (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1)) > which simplifies further to > tcpm_cc_is_sink((port)->cc1) || tcpm_cc_is_sink((port)->cc2) > > The simplified expression doesn't conflict with other detections, so I am > ok with it. It might be worthwhile adding a comment to the code, though, > explaining the reason > Guenter > >> thanks, >> Dear Guenter, I have modified it according to your opinion, and resend it as patch v2[1]. Please review. [1] https://lore.kernel.org/all/20230920063030.66312-1-michael@allwinnertech.com/
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index d962f67c95ae6..beb7143128667 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -519,7 +519,8 @@ static const char * const pd_rev[] = { #define tcpm_port_is_sink(port) \ ((tcpm_cc_is_sink((port)->cc1) && !tcpm_cc_is_sink((port)->cc2)) || \ - (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1))) + (tcpm_cc_is_sink((port)->cc2) && !tcpm_cc_is_sink((port)->cc1)) || \ + (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2))) #define tcpm_cc_is_source(cc) ((cc) == TYPEC_CC_RD) #define tcpm_cc_is_audio(cc) ((cc) == TYPEC_CC_RA)