All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Alexey Charkov <alchark@flipper.net>
Cc: Badhri Jagan Sridharan <badhri@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	RD Babiera <rdbabiera@google.com>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH 0/5] usb: typec: cable comms on RT1711H-compatible TCPCs and FUSB302
Date: Wed, 11 Nov 2026 15:00:15 +0100	[thread overview]
Message-ID: <avR073vYmypIFVGY@black.igk.intel.com> (raw)
In-Reply-To: <20261103-husb311-cable-comm-v1-0-6217dabc1a85@flipper.net>

On Tue, Nov 03, 2026 at 03:21:21PM +0400, Alexey Charkov wrote:
> Neither the RT1711H family (including the HUSB311 and ET7304) nor the
> FUSB302 lets TCPM talk to cable plugs today, so cable discovery is
> skipped, and with it the cable's current and speed ratings.
> 
> The RT1711H family handles SOP' like any other TCPCI-compliant TCPC, but
> enabling it exposed a problem in the TCPCI core: it set SOP' in
> RECEIVE_DETECT whenever the TCPC can talk to cables, regardless of who
> sources VCONN. With the partner as the VCONN Source, the port then acks
> and processes the partner's own traffic with the cable plug.
> 
> Patch 1 fixes a TCPM bug that cable communication on the FUSB302 made
> visible: after a VCONN swap, a source resets the cable plug twice.
> Patch 2 lets a TCPCI TCPC receive SOP' only while it sources VCONN,
> which also affects the Maxim TCPCs, the only ones that enable SOP'
> today. Patch 3 enables SOP' on the RT1711H family. Patches 4 and 5 add
> SOP' to the FUSB302 driver, receiving it under the same VCONN rule.
> 
> Tested on an RK3576 EVB1 (HUSB311, source-only) and Flipper One boards
> (FUSB302B):
> - Without patch 2, a FUSB302 sink sent SOP' Discover Identity over a
>   cable with no e-marker, so the HUSB311 had no VCONN to source. The
>   HUSB311 acked each one and its TCPM answered over SOP, after which the
>   sink soft reset the contract every time.
> - With patch 2, the same messages went unacked and the HUSB311 port
>   correctly ignored them.
> - Over an e-marked 5A EPR cable, the HUSB311 sourced VCONN, read the
>   cable identity and completed discovery, while the FUSB302 sink kept
>   SOP' reception off.
> - With a FUSB302 as source on the same cable, it sourced VCONN, read
>   the cable identity and completed discovery. The cable plug accepted
>   the FUSB302's automatic GoodCRC to its replies, which the datasheet
>   leaves undocumented for SOP'.
> - Between two FUSB302 ports on the same cable, VCONN swaps both ways
>   moved SOP' reception along with VCONN, and each new VCONN Source
>   soft reset the cable plug over SOP'. Without patch 1, the source did
>   so twice.
> 
> Signed-off-by: Alexey Charkov <alchark@flipper.net>

These look okay to me, but let's still wait for Badhri and RD.

Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>

> ---
> Alexey Charkov (5):
>       usb: typec: tcpm: Stop a source from repeating a cable Soft_Reset
>       usb: typec: tcpci: Receive SOP' only while sourcing VCONN
>       usb: typec: tcpci_rt1711h: Enable SOP' communication
>       usb: typec: fusb302: Tell SOP' messages apart from SOP
>       usb: typec: fusb302: Enable SOP' communication
> 
>  drivers/usb/typec/tcpm/fusb302.c       | 63 ++++++++++++++++++++++++++---
>  drivers/usb/typec/tcpm/fusb302_reg.h   | 10 +++++
>  drivers/usb/typec/tcpm/tcpci.c         | 72 +++++++++++++++++++++++-----------
>  drivers/usb/typec/tcpm/tcpci_rt1711h.c |  1 +
>  drivers/usb/typec/tcpm/tcpm.c          |  2 +
>  5 files changed, 119 insertions(+), 29 deletions(-)
> ---
> base-commit: 2637bdec0535a2044cd830eba9a79363651d9043
> change-id: 20261103-husb311-cable-comm-46f2e77e4c18
> 
> Best regards,
> --  
> Alexey Charkov <alchark@flipper.net>

-- 
heikki

      parent reply	other threads:[~2026-11-11 14:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-03 11:21 [PATCH 0/5] usb: typec: cable comms on RT1711H-compatible TCPCs and FUSB302 Alexey Charkov
2026-11-03 11:21 ` [PATCH 1/5] usb: typec: tcpm: Stop a source from repeating a cable Soft_Reset Alexey Charkov
2026-11-03 11:34   ` sashiko-bot
2026-11-03 11:21 ` [PATCH 2/5] usb: typec: tcpci: Receive SOP' only while sourcing VCONN Alexey Charkov
2026-11-03 11:39   ` sashiko-bot
2026-11-12  0:26   ` Sebastian Reichel
2026-11-03 11:21 ` [PATCH 3/5] usb: typec: tcpci_rt1711h: Enable SOP' communication Alexey Charkov
2026-11-03 11:43   ` sashiko-bot
2026-11-12  0:27   ` Sebastian Reichel
2026-11-03 11:21 ` [PATCH 4/5] usb: typec: fusb302: Tell SOP' messages apart from SOP Alexey Charkov
2026-11-03 11:47   ` sashiko-bot
2026-11-11 23:16   ` Sebastian Reichel
2026-11-03 11:21 ` [PATCH 5/5] usb: typec: fusb302: Enable SOP' communication Alexey Charkov
2026-11-03 11:51   ` sashiko-bot
2026-11-11 23:16   ` Sebastian Reichel
2026-11-11 14:00 ` Heikki Krogerus [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=avR073vYmypIFVGY@black.igk.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=alchark@flipper.net \
    --cc=badhri@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rdbabiera@google.com \
    --cc=sebastian.reichel@collabora.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.