<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/include/linux/usb/tcpm.h, branch v6.6.131</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.131</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.131'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2025-02-08T08:52:37+00:00</updated>
<entry>
<title>usb: typec: tcpci: Prevent Sink disconnection before vPpsShutdown in SPR PPS</title>
<updated>2025-02-08T08:52:37+00:00</updated>
<author>
<name>Kyle Tso</name>
<email>kyletso@google.com</email>
</author>
<published>2025-01-14T14:24:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6f10f641b489a89cbb858fa26a3e5b90fcca8396'/>
<id>urn:sha1:6f10f641b489a89cbb858fa26a3e5b90fcca8396</id>
<content type='text'>
commit 4d27afbf256028a1f54363367f30efc8854433c3 upstream.

The Source can drop its output voltage to the minimum of the requested
PPS APDO voltage range when it is in Current Limit Mode. If this voltage
falls within the range of vPpsShutdown, the Source initiates a Hard
Reset and discharges Vbus. However, currently the Sink may disconnect
before the voltage reaches vPpsShutdown, leading to unexpected behavior.

Prevent premature disconnection by setting the Sink's disconnect
threshold to the minimum vPpsShutdown value. Additionally, consider the
voltage drop due to IR drop when calculating the appropriate threshold.
This ensures a robust and reliable interaction between the Source and
Sink during SPR PPS Current Limit Mode operation.

Fixes: 4288debeaa4e ("usb: typec: tcpci: Fix up sink disconnect thresholds for PD")
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Kyle Tso &lt;kyletso@google.com&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Reviewed-by: Badhri Jagan Sridharan &lt;badhri@google.com&gt;
Link: https://lore.kernel.org/r/20250114142435.2093857-1-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: Add callbacks to mitigate wakeups due to contaminant</title>
<updated>2023-01-17T16:29:23+00:00</updated>
<author>
<name>Badhri Jagan Sridharan</name>
<email>badhri@google.com</email>
</author>
<published>2023-01-14T09:32:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=599f008c257d913674b2b2f2fa9e273c1058ec2e'/>
<id>urn:sha1:599f008c257d913674b2b2f2fa9e273c1058ec2e</id>
<content type='text'>
On some of the TCPC implementations, when the Type-C port is exposed
to contaminants, such as water, TCPC stops toggling while reporting OPEN
either by the time TCPM reads CC pin status or during CC debounce
window. This causes TCPM to be stuck in TOGGLING state. If TCPM is made
to restart toggling, the behavior recurs causing redundant CPU wakeups
till the USB-C port is free of contaminant.

[206199.287817] CC1: 0 -&gt; 0, CC2: 0 -&gt; 0 [state TOGGLING, polarity 0, disconnected]
[206199.640337] CC1: 0 -&gt; 0, CC2: 0 -&gt; 0 [state TOGGLING, polarity 0, disconnected]
[206199.985789] CC1: 0 -&gt; 0, CC2: 0 -&gt; 0 [state TOGGLING, polarity 0, disconnected]

(or)

[ 7853.867577] Start toggling
[ 7853.889921] CC1: 0 -&gt; 0, CC2: 0 -&gt; 0 [state TOGGLING, polarity 0, disconnected]
[ 7855.698765] CC1: 0 -&gt; 0, CC2: 0 -&gt; 5 [state TOGGLING, polarity 0, connected]
[ 7855.698790] state change TOGGLING -&gt; SNK_ATTACH_WAIT [rev3 NONE_AMS]
[ 7855.698826] pending state change SNK_ATTACH_WAIT -&gt; SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS]
[ 7855.703559] CC1: 0 -&gt; 0, CC2: 5 -&gt; 5 [state SNK_ATTACH_WAIT, polarity 0, connected]
[ 7855.856555] CC1: 0 -&gt; 0, CC2: 5 -&gt; 0 [state SNK_ATTACH_WAIT, polarity 0, disconnected]
[ 7855.856581] state change SNK_ATTACH_WAIT -&gt; SNK_ATTACH_WAIT [rev3 NONE_AMS]
[ 7855.856613] pending state change SNK_ATTACH_WAIT -&gt; SNK_UNATTACHED @ 170 ms [rev3 NONE_AMS]
[ 7856.027744] state change SNK_ATTACH_WAIT -&gt; SNK_UNATTACHED [delayed 170 ms]
[ 7856.181949] CC1: 0 -&gt; 0, CC2: 0 -&gt; 0 [state TOGGLING, polarity 0, disconnected]
[ 7856.187896] CC1: 0 -&gt; 0, CC2: 0 -&gt; 0 [state TOGGLING, polarity 0, disconnected]
[ 7857.645630] CC1: 0 -&gt; 0, CC2: 0 -&gt; 0 [state TOGGLING, polarity 0, disconnected]
[ 7857.647291] CC1: 0 -&gt; 0, CC2: 0 -&gt; 5 [state TOGGLING, polarity 0, connected]
[ 7857.647298] state change TOGGLING -&gt; SNK_ATTACH_WAIT [rev3 NONE_AMS]
[ 7857.647310] pending state change SNK_ATTACH_WAIT -&gt; SNK_DEBOUNCED @ 170 ms [rev3 NONE_AMS]
[ 7857.808106] CC1: 0 -&gt; 0, CC2: 5 -&gt; 0 [state SNK_ATTACH_WAIT, polarity 0, disconnected]
[ 7857.808123] state change SNK_ATTACH_WAIT -&gt; SNK_ATTACH_WAIT [rev3 NONE_AMS]
[ 7857.808150] pending state change SNK_ATTACH_WAIT -&gt; SNK_UNATTACHED @ 170 ms [rev3 NONE_AMS]
[ 7857.978727] state change SNK_ATTACH_WAIT -&gt; SNK_UNATTACHED [delayed 170 ms]

To mitigate redundant TCPM wakeups, TCPCs which do have the needed hardware
can implement the check_contaminant callback which is invoked by TCPM
to evaluate for presence of contaminant. Lower level TCPC driver can
restart toggling through TCPM_PORT_CLEAN event when the driver detects
that USB-C port is free of contaminant. check_contaminant callback also
passes the disconnect_while_debounce flag which when true denotes that
the CC pins transitioned to OPEN state during the CC debounce window.

Signed-off-by: Badhri Jagan Sridharan &lt;badhri@google.com&gt;
Acked-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230114093246.1933321-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: Move TCPC to APPLY_RC state during PR_SWAP</title>
<updated>2021-05-21T18:05:56+00:00</updated>
<author>
<name>Badhri Jagan Sridharan</name>
<email>badhri@google.com</email>
</author>
<published>2021-05-17T19:21:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=59d4d06c8ab0375dcc4bab329e6ecd44dd46373e'/>
<id>urn:sha1:59d4d06c8ab0375dcc4bab329e6ecd44dd46373e</id>
<content type='text'>
When vbus auto discharge is enabled, TCPCI based TCPC transitions
into Attached.SNK/Attached.SRC state. During PR_SWAP, TCPCI based
TCPC would disconnect when partner changes power roles. TCPC has
to be moved APPLY RC state during PR_SWAP. This is done by
ROLE_CONTROL.CC1 != ROLE_CONTROL.CC2 and
POWER_CONTROL.AutodischargeDisconnect is 0. Once the swap sequence
is done, AutoDischargeDisconnect is re-enabled.

Fixes: f321a02caebd ("usb: typec: tcpm: Implement enabling Auto Discharge disconnect support")
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Acked-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Badhri Jagan Sridharan &lt;badhri@google.com&gt;
Link: https://lore.kernel.org/r/20210517192112.40934-3-badhri@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: Add Callback to Usb Communication capable partner</title>
<updated>2021-02-02T16:38:05+00:00</updated>
<author>
<name>Badhri Jagan Sridharan</name>
<email>badhri@google.com</email>
</author>
<published>2021-02-02T00:30:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a69bdb283f79949b67632878ef1822badae9299f'/>
<id>urn:sha1:a69bdb283f79949b67632878ef1822badae9299f</id>
<content type='text'>
The USB Communications Capable bit indicates if port
partner is capable of communication over the USB data lines
(e.g. D+/- or SS Tx/Rx). Notify the status of the bit to low
level drivers to perform chip specific operation.
For instance, low level driver enables USB switches on D+/D-
lines to set up data path when the bit is set.

Refactored from patch initially authored by
Kyle Tso &lt;kyletso@google.com&gt;

Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Badhri Jagan Sridharan &lt;badhri@google.com&gt;
Link: https://lore.kernel.org/r/20210202003101.221145-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: AMS and Collision Avoidance</title>
<updated>2021-01-21T11:23:32+00:00</updated>
<author>
<name>Kyle Tso</name>
<email>kyletso@google.com</email>
</author>
<published>2021-01-14T14:50:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0908c5aca31eb5e0c72d7a5dba422629b88e877d'/>
<id>urn:sha1:0908c5aca31eb5e0c72d7a5dba422629b88e877d</id>
<content type='text'>
This patch provides the implementation of Collision Avoidance introduced
in PD3.0. The start of each Atomic Message Sequence (AMS) initiated by
the port will be denied if the current AMS is not interruptible. The
Source port will set the CC to SinkTxNG if it is going to initiate an
AMS, and SinkTxOk otherwise. Meanwhile, any AMS initiated by a Sink port
will be denied in TCPM if the port partner (Source) sets SinkTxNG except
for HARD_RESET and SOFT_RESET.

Tested-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Kyle Tso &lt;kyletso@google.com&gt;
Link: https://lore.kernel.org/r/20210114145053.1952756-2-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: Introduce vsafe0v for vbus</title>
<updated>2020-12-09T13:49:54+00:00</updated>
<author>
<name>Badhri Jagan Sridharan</name>
<email>badhri@google.com</email>
</author>
<published>2020-12-02T04:08:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=28b43d3d746b89fc112fe681e018b39b43495dad'/>
<id>urn:sha1:28b43d3d746b89fc112fe681e018b39b43495dad</id>
<content type='text'>
TCPM at present lacks the notion of VSAFE0V. There
are three vbus threshold levels that are critical to track:
a. vSafe5V         - VBUS “5 volts” as defined by the USB
                     PD specification.
b. vSinkDisconnect - Threshold used for transition from
                     Attached.SNK to Unattached.SNK.
c. vSafe0V         - VBUS “0 volts” as defined by the USB
                     PD specification.

Tracking vSafe0V is crucial for entry into Try.SNK and
Attached.SRC and turning vbus back on by the source in
response to hard reset.

&gt;From "4.5.2.2.8.2 Exiting from AttachWait.SRC State" section
in the Type-C spec:

"The port shall transition to Attached.SRC when VBUS is at
vSafe0V and the SRC.Rd state is detected on exactly one of
the CC1 or CC2 pins for at least tCCDebounce."

"A DRP that strongly prefers the Sink role may optionally
transition to Try.SNK instead of Attached.SRC when VBUS
is at vSafe0V and the SRC.Rd state is detected on exactly
one of the CC1 or CC2 pins for at least tCCDebounce."

&gt;From "7.1.5 Response to Hard Resets" section in the PD spec:

"After establishing the vSafe0V voltage condition on VBUS,
the Source Shall wait tSrcRecover before re-applying VCONN
and restoring VBUS to vSafe5V."

vbus_present in the TCPM code tracks vSafe5V(vbus_present is true)
and vSinkDisconnect(vbus_present is false).

This change adds is_vbus_vsafe0v callback which when set makes
TCPM query for vSafe0V voltage level when needed.

Since not all TCPC controllers might have the capability
to report vSafe0V, TCPM assumes that vSafe0V is same as
vSinkDisconnect when is_vbus_vsafe0v callback is not set.
This allows TCPM to continue to support controllers which don't
have the support for reporting vSafe0V.

Introducing vSafe0V helps fix the failure reported at
"Step 15. CVS verifies PUT remains in AttachWait.SRC for 500ms"
of "TD 4.7.2 Try. SNK DRP Connect DRP Test" of
"Universal Serial Bus Type-C (USB Type-C) Functional Test
Specification Chapters 4 and 5". Here the compliance tester
intentionally maintains vbus at greater than vSafe0V and expects
the Product under test to stay in AttachWait.SRC till vbus drops
to vSafe0V.

Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Acked-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Badhri Jagan Sridharan &lt;badhri@google.com&gt;
Link: https://lore.kernel.org/r/20201202040840.663578-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: Pass down negotiated rev to update retry count</title>
<updated>2020-12-09T13:42:10+00:00</updated>
<author>
<name>Badhri Jagan Sridharan</name>
<email>badhri@google.com</email>
</author>
<published>2020-12-02T03:17:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e4a9378083c57a22624cda8b780ff5f5da4de7ef'/>
<id>urn:sha1:e4a9378083c57a22624cda8b780ff5f5da4de7ef</id>
<content type='text'>
nRetryCount was updated from 3 to 2 between PD2.0 and PD3.0 spec.
nRetryCount in "Table 6-34 Counter parameters" of the PD 2.0
spec is set to 3, whereas, nRetryCount in "Table 6-59 Counter
parameters" is set to 2.

Pass down negotiated rev in pd_transmit so that low level chip
drivers can update the retry count accordingly before attempting
packet transmission.

This helps in passing "TEST.PD.PORT.ALL.02" of the
"Power Delivery Merged" test suite which was initially failing
with "The UUT did not retransmit the message nReryCount times"

In fusb302 &amp; tcpci drivers, by default the driver sets the retry
count to 3 (Default for PD 2.0). Update this to 2,
if the negotiated rev is PD 3.0.

In wcove, since the retry count is intentionally set to max, leaving
it as is.

Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Acked-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Badhri Jagan Sridharan &lt;badhri@google.com&gt;
Link: https://lore.kernel.org/r/20201202031733.647808-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: Implement enabling Auto Discharge disconnect support</title>
<updated>2020-11-18T11:57:49+00:00</updated>
<author>
<name>Badhri Jagan Sridharan</name>
<email>badhri@google.com</email>
</author>
<published>2020-10-29T06:31:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f321a02caebdd0c56e167610cda2fa148cd96e8b'/>
<id>urn:sha1:f321a02caebdd0c56e167610cda2fa148cd96e8b</id>
<content type='text'>
TCPCI spec allows TCPC hardware to autonomously discharge the vbus
capacitance upon disconnect. The expectation is that the TCPM enables
AutoDischargeDisconnect while entering SNK/SRC_ATTACHED states. Hardware
then automously discharges vbus when the vbus falls below a certain
threshold i.e. VBUS_SINK_DISCONNECT_THRESHOLD.

Apart from enabling the vbus discharge circuit, AutoDischargeDisconnect
is also used a flag to move TCPCI based TCPC implementations into
Attached.Snk/Attached.Src state as mentioned in
Figure 4-15. TCPC State Diagram before a Connection of the
USB Type-C Port Controller Interface Specification.
In such TCPC implementations, setting AutoDischargeDisconnect would
prevent TCPC into entering "Connection_Invalid" state as well.

Signed-off-by: Badhri Jagan Sridharan &lt;badhri@google.com&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20201029063138.1429760-8-badhri@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: frs sourcing vbus callback</title>
<updated>2020-11-18T11:56:58+00:00</updated>
<author>
<name>Badhri Jagan Sridharan</name>
<email>badhri@google.com</email>
</author>
<published>2020-10-29T06:31:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a30a00e37ceb094f949e4d96c2c586e6503b5d1d'/>
<id>urn:sha1:a30a00e37ceb094f949e4d96c2c586e6503b5d1d</id>
<content type='text'>
During FRS hardware autonomously starts to source vbus. Provide
callback to perform chip specific operations.

Signed-off-by: Badhri Jagan Sridharan &lt;badhri@google.com&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20201029063138.1429760-5-badhri@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)</title>
<updated>2020-10-08T07:28:22+00:00</updated>
<author>
<name>Badhri Jagan Sridharan</name>
<email>badhri@google.com</email>
</author>
<published>2020-10-08T06:15:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8dc4bd073663fa8aba2fae08b1c23ab41a2e97a2'/>
<id>urn:sha1:8dc4bd073663fa8aba2fae08b1c23ab41a2e97a2</id>
<content type='text'>
PD 3.0 spec defines a new mechanism for power role swap called
Fast role swap. This change enables TCPM to support FRS when
acting as sink.

Once the explicit contract is negotiated, sink port is
expected to query the source port for sink caps to
determine whether the source is FRS capable.
Bits 23 &amp; 24 of fixed pdo of the sink caps from the source, when
set, indicates the current needed by the source when fast role
swap is in progress(Implicit contract phasae). 0 indicates that
the source does not support Fast Role Swap.

Upon receiving the FRS signal from the source,
TCPC(TCPM_FRS_EVENT) informs TCPM to start the Fast role swap sequence.

1. TCPM sends FRS PD message: FR_SWAP_SEND
2. If response is not received within the expiry of
   SenderResponseTimer, Error recovery is triggered.:
   FR_SWAP_SEND_TIMEOUT
3. Upon receipt of the accept message, TCPM waits for
   PSSourceOffTimer for PS_READY message from the partner:
   FR_SWAP_SNK_SRC_NEW_SINK_READY.

TCPC is expected to autonomously turn on vbus once the FRS
signal is received and vbus voltage falls below vsafe5v within
tSrcFrSwap. This is different from traditional power role swap
where the vbus sourcing is turned on by TCPM.

4. By this time, TCPC most likely would have started to
   source vbus, TCPM waits for tSrcFrSwap to see  if the
   lower level TCPC driver signals TCPM_SOURCING_VBUS event:
   FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED.
5. When TCPC signals sourcing vbus, TCPM sends PS_READY msg and
   changes the CC pin from Rd to Rp. This is the end of fast
   role swap sequence and TCPM initiates the sequnce to negotiate
   explicit contract by transitioning into SRC_STARTUP after
   SwapSrcStart.

The code is written based on the sequence described in "Figure 8-107:
Dual-role Port in Sink to Source Fast Role Swap State Diagram" of
USB Power Delivery Specification Revision 3.0, Version 1.2.

Signed-off-by: Badhri Jagan Sridharan &lt;badhri@google.com&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20201008061556.1402293-7-badhri@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
