<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/usb/typec, branch v6.6.39</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.39</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.39'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2024-07-05T07:33:59+00:00</updated>
<entry>
<title>usb: ucsi: stm32: fix command completion handling</title>
<updated>2024-07-05T07:33:59+00:00</updated>
<author>
<name>Fabrice Gasnier</name>
<email>fabrice.gasnier@foss.st.com</email>
</author>
<published>2024-06-12T12:46:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e63059271945c7ce2992844849ef0ba989bfe710'/>
<id>urn:sha1:e63059271945c7ce2992844849ef0ba989bfe710</id>
<content type='text'>
commit 8e1ec117efdfd4b2f59f57bd0ad16b4edf5b963f upstream.

Sometimes errors are seen, when doing DR swap, like:
[   24.672481] ucsi-stm32g0-i2c 0-0035: UCSI_GET_PDOS failed (-5)
[   24.720188] ucsi-stm32g0-i2c 0-0035: ucsi_handle_connector_change:
 GET_CONNECTOR_STATUS failed (-5)

There may be some race, which lead to read CCI, before the command complete
flag is set, hence returning -EIO. Similar fix has been done also in
ucsi_acpi [1].

In case of a spurious or otherwise delayed notification it is
possible that CCI still reports the previous completion. The
UCSI spec is aware of this and provides two completion bits in
CCI, one for normal commands and one for acks. As acks and commands
alternate the notification handler can determine if the completion
bit is from the current command.

To fix this add the ACK_PENDING bit for ucsi_stm32g0 and only complete
commands if the completion bit matches.

[1] https://lore.kernel.org/lkml/20240121204123.275441-3-lk@c--e.de/

Fixes: 72849d4fcee7 ("usb: typec: ucsi: stm32g0: add support for stm32g0 controller")
Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@foss.st.com&gt;
Link: https://lore.kernel.org/stable/20240612124656.2305603-1-fabrice.gasnier%40foss.st.com
Cc: stable &lt;stable@kernel.org&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240612124656.2305603-1-fabrice.gasnier@foss.st.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: ucsi: glink: fix child node release in probe function</title>
<updated>2024-07-05T07:33:59+00:00</updated>
<author>
<name>Javier Carrasco</name>
<email>javier.carrasco.cruz@gmail.com</email>
</author>
<published>2024-06-13T12:14:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=519610e20e8a57850694ba95cb732b3c091c1185'/>
<id>urn:sha1:519610e20e8a57850694ba95cb732b3c091c1185</id>
<content type='text'>
commit c68942624e254a4e8a65afcd3c17ed95acda5489 upstream.

The device_for_each_child_node() macro requires explicit calls to
fwnode_handle_put() in all early exits of the loop if the child node is
not required outside. Otherwise, the child node's refcount is not
decremented and the resource is not released.

The current implementation of pmic_glink_ucsi_probe() makes use of the
device_for_each_child_node(), but does not release the child node on
early returns. Add the missing calls to fwnode_handle_put().

Cc: stable@vger.kernel.org
Fixes: c6165ed2f425 ("usb: ucsi: glink: use the connector orientation GPIO to provide switch events")
Signed-off-by: Javier Carrasco &lt;javier.carrasco.cruz@gmail.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240613-ucsi-glink-release-node-v1-1-f7629a56f70a@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: ucsi: Ack also failed Get Error commands</title>
<updated>2024-07-05T07:33:43+00:00</updated>
<author>
<name>Heikki Krogerus</name>
<email>heikki.krogerus@linux.intel.com</email>
</author>
<published>2024-05-31T10:46:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d9933caf865e9826dee0d75b273e3cdf11ed1855'/>
<id>urn:sha1:d9933caf865e9826dee0d75b273e3cdf11ed1855</id>
<content type='text'>
[ Upstream commit 8bdf8a42bca4f47646fd105a387ab6926948c7f1 ]

It is possible that also the GET_ERROR command fails. If
that happens, the command completion still needs to be
acknowledged. Otherwise the interface will be stuck until
it's reset.

Reported-by: Ammy Yi &lt;ammy.yi@intel.com&gt;
Fixes: bdc62f2bae8f ("usb: typec: ucsi: Simplified registration and I/O API")
Cc: stable@vger.kernel.org
Signed-off-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Link: https://lore.kernel.org/r/20240531104653.1303519-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: ucsi: Never send a lone connector change ack</title>
<updated>2024-07-05T07:33:43+00:00</updated>
<author>
<name>Christian A. Ehrhardt</name>
<email>lk@c--e.de</email>
</author>
<published>2024-03-27T22:45:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=64ab9d2d1bd0229ef3aa3deb42cd36e1eb519cb0'/>
<id>urn:sha1:64ab9d2d1bd0229ef3aa3deb42cd36e1eb519cb0</id>
<content type='text'>
[ Upstream commit de52aca4d9d56c3b2f00b638d457075914b1a227 ]

Some PPM implementation do not like UCSI_ACK_CONNECTOR_CHANGE
without UCSI_ACK_COMMAND_COMPLETE. Moreover, doing this is racy
as it requires sending two UCSI_ACK_CC_CI commands in a row and
the second one will be started with UCSI_CCI_ACK_COMPLETE already
set in CCI.

Bundle the UCSI_ACK_CONNECTOR_CHANGE with the UCSI_ACK_COMMAND_COMPLETE
for the UCSI_GET_CONNECTOR_STATUS command that is sent while
handling a connector change event.

Signed-off-by: Christian A. Ehrhardt &lt;lk@c--e.de&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Tested-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Link: https://lore.kernel.org/r/20240327224554.1772525-3-lk@c--e.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Stable-dep-of: 8bdf8a42bca4 ("usb: typec: ucsi: Ack also failed Get Error commands")
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: ucsi_glink: drop special handling for CCI_BUSY</title>
<updated>2024-06-27T11:49:04+00:00</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@linaro.org</email>
</author>
<published>2024-04-08T01:04:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=38e6a5296615e68c967f90602adec56335c9dec7'/>
<id>urn:sha1:38e6a5296615e68c967f90602adec56335c9dec7</id>
<content type='text'>
[ Upstream commit 1a395af9d53c6240bf7799abc43b4dc292ca9dd0 ]

Newer Qualcomm platforms (sm8450+) successfully handle busy state and
send the Command Completion after sending the Busy state. Older devices
have firmware bug and can not continue after sending the CCI_BUSY state,
but the command that leads to CCI_BUSY is already forbidden by the
NO_PARTNER_PDOS quirk.

Follow other UCSI glue drivers and drop special handling for CCI_BUSY
event. Let the UCSI core properly handle this state.

Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240408-qcom-ucsi-fixes-bis-v1-3-716c145ca4b1@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: Ignore received Hard Reset in TOGGLING state</title>
<updated>2024-06-21T12:38:23+00:00</updated>
<author>
<name>Kyle Tso</name>
<email>kyletso@google.com</email>
</author>
<published>2024-05-20T15:48:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ad47b23e470450cbbb5e221cb52dc951940cf8cc'/>
<id>urn:sha1:ad47b23e470450cbbb5e221cb52dc951940cf8cc</id>
<content type='text'>
commit fc8fb9eea94d8f476e15f3a4a7addeb16b3b99d6 upstream.

Similar to what fixed in Commit a6fe37f428c1 ("usb: typec: tcpm: Skip
hard reset when in error recovery"), the handling of the received Hard
Reset has to be skipped during TOGGLING state.

[ 4086.021288] VBUS off
[ 4086.021295] pending state change SNK_READY -&gt; SNK_UNATTACHED @ 650 ms [rev2 NONE_AMS]
[ 4086.022113] VBUS VSAFE0V
[ 4086.022117] state change SNK_READY -&gt; SNK_UNATTACHED [rev2 NONE_AMS]
[ 4086.022447] VBUS off
[ 4086.022450] state change SNK_UNATTACHED -&gt; SNK_UNATTACHED [rev2 NONE_AMS]
[ 4086.023060] VBUS VSAFE0V
[ 4086.023064] state change SNK_UNATTACHED -&gt; SNK_UNATTACHED [rev2 NONE_AMS]
[ 4086.023070] disable BIST MODE TESTDATA
[ 4086.023766] disable vbus discharge ret:0
[ 4086.023911] Setting usb_comm capable false
[ 4086.028874] Setting voltage/current limit 0 mV 0 mA
[ 4086.028888] polarity 0
[ 4086.030305] Requesting mux state 0, usb-role 0, orientation 0
[ 4086.033539] Start toggling
[ 4086.038496] state change SNK_UNATTACHED -&gt; TOGGLING [rev2 NONE_AMS]

// This Hard Reset is unexpected
[ 4086.038499] Received hard reset
[ 4086.038501] state change TOGGLING -&gt; HARD_RESET_START [rev2 HARD_RESET]

Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)")
Cc: stable@vger.kernel.org
Signed-off-by: Kyle Tso &lt;kyletso@google.com&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240520154858.1072347-1-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: fix use-after-free case in tcpm_register_source_caps</title>
<updated>2024-06-21T12:38:23+00:00</updated>
<author>
<name>Amit Sunil Dhamne</name>
<email>amitsd@google.com</email>
</author>
<published>2024-05-14T22:01:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=04c05d50fa79a41582f7bde8a1fd4377ae4a39e5'/>
<id>urn:sha1:04c05d50fa79a41582f7bde8a1fd4377ae4a39e5</id>
<content type='text'>
commit e7e921918d905544500ca7a95889f898121ba886 upstream.

There could be a potential use-after-free case in
tcpm_register_source_caps(). This could happen when:
 * new (say invalid) source caps are advertised
 * the existing source caps are unregistered
 * tcpm_register_source_caps() returns with an error as
   usb_power_delivery_register_capabilities() fails

This causes port-&gt;partner_source_caps to hold on to the now freed source
caps.

Reset port-&gt;partner_source_caps value to NULL after unregistering
existing source caps.

Fixes: 230ecdf71a64 ("usb: typec: tcpm: unregister existing source caps before re-registration")
Cc: stable@vger.kernel.org
Signed-off-by: Amit Sunil Dhamne &lt;amitsd@google.com&gt;
Reviewed-by: Ondrej Jirman &lt;megi@xff.cz&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Link: https://lore.kernel.org/r/20240514220134.2143181-1-amitsd@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: ucsi: simplify partner's PD caps registration</title>
<updated>2024-06-12T09:12:15+00:00</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@linaro.org</email>
</author>
<published>2024-03-29T06:15:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=32f615e0a580db81a289544ce8251510efdf7b0e'/>
<id>urn:sha1:32f615e0a580db81a289544ce8251510efdf7b0e</id>
<content type='text'>
[ Upstream commit 41e1cd1401fcd1f1ae9e47574af2d9fc44a870b3 ]

In a way similar to the previous commit, move
typec_partner_set_usb_power_delivery() to be called after reading the PD
caps. This also removes calls to
usb_power_delivery_unregister_capabilities() from the error path. Keep
all capabilities registered until they are cleared by
ucsi_unregister_partner_pdos().

Fixes: b04e1747fbcc ("usb: typec: ucsi: Register USB Power Delivery Capabilities")
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-5-0f5d37ed04db@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: ucsi: always register a link to USB PD device</title>
<updated>2024-06-12T09:12:15+00:00</updated>
<author>
<name>Dmitry Baryshkov</name>
<email>dmitry.baryshkov@linaro.org</email>
</author>
<published>2024-03-29T06:15:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ad864c123b7a302547eb122aa667b67404688053'/>
<id>urn:sha1:ad864c123b7a302547eb122aa667b67404688053</id>
<content type='text'>
[ Upstream commit c0f66d78f42353d38b9608c05f211cf0773d93ac ]

UCSI driver will attempt to set a USB PD device only if it was able to
read PDOs from the firmware. This results in suboptimal behaviour, since
the PD device will be created anyway. Move calls to
typec_port_set_usb_power_delivery() out of conditional code and call it
after reading capabilities.

Fixes: b04e1747fbcc ("usb: typec: ucsi: Register USB Power Delivery Capabilities")
Signed-off-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20240329-qcom-ucsi-fixes-v2-4-0f5d37ed04db@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tipd: fix event checking for tps6598x</title>
<updated>2024-05-25T14:22:54+00:00</updated>
<author>
<name>Javier Carrasco</name>
<email>javier.carrasco@wolfvision.net</email>
</author>
<published>2024-04-29T13:35:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=40b963e45cbbf3769fd784faebc660dabd74edc0'/>
<id>urn:sha1:40b963e45cbbf3769fd784faebc660dabd74edc0</id>
<content type='text'>
commit 409c1cfb5a803f3cf2d17aeaf75c25c4be951b07 upstream.

The current interrupt service routine of the tps6598x only reads the
first 64 bits of the INT_EVENT1 and INT_EVENT2 registers, which means
that any event above that range will be ignored, leaving interrupts
unattended. Moreover, those events will not be cleared, and the device
will keep the interrupt enabled.

This issue has been observed while attempting to load patches, and the
'ReadyForPatch' field (bit 81) of INT_EVENT1 was set.

Given that older versions of the tps6598x (1, 2 and 6) provide 8-byte
registers, a mechanism based on the upper byte of the version register
(0x0F) has been included. The manufacturer has confirmed [1] that this
byte is always 0 for older versions, and either 0xF7 (DH parts) or 0xF9
(DK parts) is returned in newer versions (7 and 8).

Read the complete INT_EVENT registers to handle all interrupts generated
by the device and account for the hardware version to select the
register size.

Link: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1346521/tps65987d-register-command-to-distinguish-between-tps6591-2-6-and-tps65987-8 [1]
Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers")
Cc: stable@vger.kernel.org
Signed-off-by: Javier Carrasco &lt;javier.carrasco@wolfvision.net&gt;
Link: https://lore.kernel.org/r/20240429-tps6598x_fix_event_handling-v3-2-4e8e58dce489@wolfvision.net
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
