kernel/linux.git/drivers/usb/typec, branch v6.1.168

usb: typec: ucsi: psy: Fix voltage and current max for non-Fixed PDOs

2026-03-04T12:20:33+00:00

[ Upstream commit 6811e0a08bdce6b2767414caf17fda24c2e4e032 ] ucsi_psy_get_voltage_max and ucsi_psy_get_current_max are calculated using whichever pdo is in the last position of the src_pdos array, presuming it to be a fixed pdo, so the pdo_fixed_voltage or pdo_max_current helpers are used on that last pdo. However, non-Fixed PDOs such as Battery PDOs, Augmented PDOs (used for AVS and for PPS) may exist, and are always at the end of the array if they do. In the event one of these more advanced chargers are attached the helpers for fixed return mangled values. Here's an example case of a Google Pixel Flex Dual Port 67W USB-C Fast Charger with PPS support: POWER_SUPPLY_NAME=ucsi-source-psy-cros_ec_ucsi.4.auto2 POWER_SUPPLY_TYPE=USB POWER_SUPPLY_CHARGE_TYPE=Standard POWER_SUPPLY_USB_TYPE=C [PD] PD_PPS PD_DRP POWER_SUPPLY_ONLINE=1 POWER_SUPPLY_VOLTAGE_MIN=5000000 POWER_SUPPLY_VOLTAGE_MAX=13400000 POWER_SUPPLY_VOLTAGE_NOW=20000000 POWER_SUPPLY_CURRENT_MAX=5790000 POWER_SUPPLY_CURRENT_NOW=3250000 Voltage Max is reading as 13.4V, but that's an incorrect decode of the PPS APDO in the last position. Same goes for CURRENT_MAX. 5.79A is incorrect. Instead, enumerate through the src_pdos and filter just for Fixed PDOs for now, and find the one with the highest voltage and current respectively. After, from the same charger: POWER_SUPPLY_NAME=ucsi-source-psy-cros_ec_ucsi.4.auto2 POWER_SUPPLY_TYPE=USB POWER_SUPPLY_CHARGE_TYPE=Standard POWER_SUPPLY_USB_TYPE=C [PD] PD_PPS PD_DRP POWER_SUPPLY_ONLINE=1 POWER_SUPPLY_VOLTAGE_MIN=5000000 POWER_SUPPLY_VOLTAGE_MAX=20000000 POWER_SUPPLY_VOLTAGE_NOW=20000000 POWER_SUPPLY_CURRENT_MAX=4000000 POWER_SUPPLY_CURRENT_NOW=3250000 Signed-off-by: Benson Leung Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/20251208174918.289394-3-bleung@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: typec: ucsi: Handle incorrect num_connectors capability

2026-01-11T14:18:49+00:00

[ Upstream commit 30cd2cb1abf4c4acdb1ddb468c946f68939819fb ] The UCSI spec states that the num_connectors field is 7 bits, and the 8th bit is reserved and should be set to zero. Some buggy FW has been known to set this bit, and it can lead to a system not booting. Flag that the FW is not behaving correctly, and auto-fix the value so that the system boots correctly. Found on Lenovo P1 G8 during Linux enablement program. The FW will be fixed, but seemed worth addressing in case it hit platforms that aren't officially Linux supported. Signed-off-by: Mark Pearson Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250821185319.2585023-1-mpearson-lenovo@squebb.ca Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: typec: ucsi: psy: Set max current to zero when disconnected

2025-12-06T21:12:45+00:00

[ Upstream commit 23379a17334fc24c4a9cbd9967d33dcd9323cc7c ] The ucsi_psy_get_current_max function defaults to 0.1A when it is not clear how much current the partner device can support. But this does not check the port is connected, and will report 0.1A max current when nothing is connected. Update ucsi_psy_get_current_max to report 0A when there is no connection. Fixes: af833e7f7db3 ("usb: typec: ucsi: psy: Set current max to 100mA for BC 1.2 and Default") Cc: stable@vger.kernel.org Signed-off-by: Jameson Thies Reviewed-by: Benson Leung Reviewed-by: Heikki Krogerus Reviewed-by: Sebastian Reichel Tested-by: Kenneth R. Crudup Rule: add Link: https://lore.kernel.org/stable/20251017000051.2094101-1-jthies%40google.com Link: https://patch.msgid.link/20251106011446.2052583-1-jthies@google.com Signed-off-by: Greg Kroah-Hartman [ adapted UCSI_CONSTAT() macro to direct flag access ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

usb: typec: tipd: Clear interrupts first

2025-10-15T09:56:41+00:00

commit be5ae730ffa6fd774a00a4705c1e11e078b08ca1 upstream. Right now the interrupt handler first reads all updated status registers and only then clears the interrupts. It's possible that a duplicate interrupt for a changed register or plug state comes in after the interrupts have been processed but before they have been cleared: * plug is inserted, TPS_REG_INT_PLUG_EVENT is set * TPS_REG_INT_EVENT1 is read * tps6598x_handle_plug_event() has run and registered the plug * plug is removed again, TPS_REG_INT_PLUG_EVENT is set (again) * TPS_REG_INT_CLEAR1 is written, TPS_REG_INT_PLUG_EVENT is cleared We then have no plug connected and no pending interrupt but the tipd core still thinks there is a plug. It's possible to trigger this with e.g. a slightly broken Type-C to USB A converter. Fix this by first clearing the interrupts and only then reading the updated registers. Fixes: 45188f27b3d0 ("usb: typec: tipd: Add support for Apple CD321X") Fixes: 0a4c005bd171 ("usb: typec: driver for TI TPS6598x USB Power Delivery controllers") Cc: stable@kernel.org Reviewed-by: Heikki Krogerus Reviewed-by: Neal Gompa Signed-off-by: Sven Peter Link: https://lore.kernel.org/r/20250914-apple-usb3-tipd-v1-1-4e99c8649024@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

usb: typec: fusb302: cache PD RX state

2025-08-28T14:26:11+00:00

[ Upstream commit 1e61f6ab08786d66a11cfc51e13d6f08a6b06c56 ] This patch fixes a race condition communication error, which ends up in PD hard resets when losing the race. Some systems, like the Radxa ROCK 5B are powered through USB-C without any backup power source and use a FUSB302 chip to do the PD negotiation. This means it is quite important to avoid hard resets, since that effectively kills the system's power-supply. I've found the following race condition while debugging unplanned power loss during booting the board every now and then: 1. lots of TCPM/FUSB302/PD initialization stuff 2. TCPM ends up in SNK_WAIT_CAPABILITIES (tcpm_set_pd_rx is enabled here) 3. the remote PD source does not send anything, so TCPM does a SOFT RESET 4. TCPM ends up in SNK_WAIT_CAPABILITIES for the second time (tcpm_set_pd_rx is enabled again, even though it is still on) At this point I've seen broken CRC good messages being send by the FUSB302 with a logic analyzer sniffing the CC lines. Also it looks like messages are being lost and things generally going haywire with one of the two sides doing a hard reset once a broken CRC good message was send to the bus. I think the system is running into a race condition, that the FIFOs are being cleared and/or the automatic good CRC message generation flag is being updated while a message is already arriving. Let's avoid this by caching the PD RX enabled state, as we have already processed anything in the FIFOs and are in a good state. As a side effect that this also optimizes I2C bus usage :) As far as I can tell the problem theoretically also exists when TCPM enters SNK_WAIT_CAPABILITIES the first time, but I believe this is less critical for the following reason: On devices like the ROCK 5B, which are powered through a TCPM backed USB-C port, the bootloader must have done some prior PD communication (initial communication must happen within 5 seconds after plugging the USB-C plug). This means the first time the kernel TCPM state machine reaches SNK_WAIT_CAPABILITIES, the remote side is not sending messages actively. On other devices a hard reset simply adds some extra delay and things should be good afterwards. Fixes: c034a43e72dda ("staging: typec: Fairchild FUSB302 Type-c chip driver") Cc: stable Signed-off-by: Sebastian Reichel Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250704-fusb302-race-condition-fix-v1-1-239012c0e27a@kernel.org Signed-off-by: Greg Kroah-Hartman [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

usb: typec: ucsi: Update power_supply on power role change

2025-08-28T14:26:03+00:00

commit 7616f006db07017ef5d4ae410fca99279aaca7aa upstream. The current power direction of an USB-C port also influences the power_supply's online status, so a power role change should also update the power_supply. Fixes an issue on some systems where plugging in a normal USB device in for the first time after a reboot will cause upower to erroneously consider the system to be connected to AC power. Cc: stable Fixes: 0e6371fbfba3 ("usb: typec: ucsi: Report power supply changes") Signed-off-by: Myrrh Periwinkle Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250721-fix-ucsi-pwr-dir-notify-v1-1-e53d5340cb38@qtmlabs.xyz Signed-off-by: Greg Kroah-Hartman

usb: typec: intel_pmc_mux: Defer probe if SCU IPC isn't present

2025-08-28T14:25:54+00:00

[ Upstream commit df9a825f330e76c72d1985bc9bdc4b8981e3d15f ] If pmc_usb_probe is called before SCU IPC is registered, pmc_usb_probe will fail. Return -EPROBE_DEFER when pmc_usb_probe doesn't get SCU IPC device, so the probe function can be called again after SCU IPC is initialized. Signed-off-by: Tomasz Michalec Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250610154058.1859812-1-tmichalec@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: typec: ucsi: psy: Set current max to 100mA for BC 1.2 and Default

2025-08-28T14:25:52+00:00

[ Upstream commit af833e7f7db3cf4c82f063668e1b52297a30ec18 ] ucsi_psy_get_current_max would return 0mA as the maximum current if UCSI detected a BC or a Default USB Power sporce. The comment in this function is true that we can't tell the difference between DCP/CDP or SDP chargers, but we can guarantee that at least 1-unit of USB 1.1/2.0 power is available, which is 100mA, which is a better fallback value than 0, which causes some userspaces, including the ChromeOS power manager, to regard this as a power source that is not providing any power. In reality, 100mA is guaranteed from all sources in these classes. Signed-off-by: Benson Leung Reviewed-by: Jameson Thies Reviewed-by: Heikki Krogerus Reviewed-by: Sebastian Reichel Link: https://lore.kernel.org/r/20250717200805.3710473-1-bleung@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach

2025-08-15T10:04:50+00:00

commit bec15191d52300defa282e3fd83820f69e447116 upstream. This patch fixes Type-C compliance test TD 4.7.6 - Try.SNK DRP Connect SNKAS. tVbusON has a limit of 275ms when entering SRC_ATTACHED. Compliance testers can interpret the TryWait.Src to Attached.Src transition after Try.Snk as being in Attached.Src the entire time, so ~170ms is lost to the debounce timer. Setting the data role can be a costly operation in host mode, and when completed after 100ms can cause Type-C compliance test check TD 4.7.5.V.4 to fail. Turn VBUS on before tcpm_set_roles to meet timing requirement. Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable Signed-off-by: RD Babiera Reviewed-by: Badhri Jagan Sridharan Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250618230606.3272497-2-rdbabiera@google.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

usb: typec: tcpm: allow switching to mode accessory to mux properly

2025-08-15T10:04:50+00:00

commit 8a50da849151e7e12b43c1d8fe7ad302223aef6b upstream. The funciton tcpm_acc_attach is not setting the proper state when calling tcpm_set_role. The function tcpm_set_role is currently only handling TYPEC_STATE_USB. For the tcpm_acc_attach to switch into other modal states tcpm_set_role needs to be extended by an extra state parameter. This patch is handling the proper state change when calling tcpm_acc_attach. Signed-off-by: Michael Grzeschik Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250404-ml-topic-tcpm-v1-3-b99f44badce8@pengutronix.de Stable-dep-of: bec15191d523 ("usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman