linux.git/drivers/usb/typec/ucsi, branch v6.14 Linux kernel source tree usb: typec: ucsi: Fix NULL pointer access 2025-03-06T15:55:46+00:00 Andrei Kuchynski akuchynski@chromium.org 2025-03-05T11:17:39+00:00 b13abcb7ddd8d38de769486db5bd917537b32ab1 Resources should be released only after all threads that utilize them have been destroyed. This commit ensures that resources are not released prematurely by waiting for the associated workqueue to complete before deallocating them. Cc: stable <stable@kernel.org> Fixes: b9aa02ca39a4 ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking") Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250305111739.1489003-2-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Resources should be released only after all threads that utilize them
have been destroyed.
This commit ensures that resources are not released prematurely by waiting
for the associated workqueue to complete before deallocating them.

Cc: stable <stable@kernel.org>
Fixes: b9aa02ca39a4 ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking")
Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250305111739.1489003-2-akuchynski@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: ucsi: increase timeout for PPM reset operations 2025-02-19T14:19:56+00:00 Fedor Pchelkin boddah8794@gmail.com 2025-02-17T10:54:40+00:00 bf4f9ae1cb08ccaafbe6874be6c46f59b83ae778 It is observed that on some systems an initial PPM reset during the boot phase can trigger a timeout: [ 6.482546] ucsi_acpi USBC000:00: failed to reset PPM! [ 6.482551] ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed Still, increasing the timeout value, albeit being the most straightforward solution, eliminates the problem: the initial PPM reset may take up to ~8000-10000ms on some Lenovo laptops. When it is reset after the above period of time (or even if ucsi_reset_ppm() is not called overall), UCSI works as expected. Moreover, if the ucsi_acpi module is loaded/unloaded manually after the system has booted, reading the CCI values and resetting the PPM works perfectly, without any timeout. Thus it's only a boot-time issue. The reason for this behavior is not clear but it may be the consequence of some tricks that the firmware performs or be an actual firmware bug. As a workaround, increase the timeout to avoid failing the UCSI initialization prematurely. Fixes: b1b59e16075f ("usb: typec: ucsi: Increase command completion timeout value") Cc: stable <stable@kernel.org> Signed-off-by: Fedor Pchelkin <boddah8794@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250217105442.113486-3-boddah8794@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
It is observed that on some systems an initial PPM reset during the boot
phase can trigger a timeout:

[    6.482546] ucsi_acpi USBC000:00: failed to reset PPM!
[    6.482551] ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed

Still, increasing the timeout value, albeit being the most straightforward
solution, eliminates the problem: the initial PPM reset may take up to
~8000-10000ms on some Lenovo laptops. When it is reset after the above
period of time (or even if ucsi_reset_ppm() is not called overall), UCSI
works as expected.

Moreover, if the ucsi_acpi module is loaded/unloaded manually after the
system has booted, reading the CCI values and resetting the PPM works
perfectly, without any timeout. Thus it's only a boot-time issue.

The reason for this behavior is not clear but it may be the consequence
of some tricks that the firmware performs or be an actual firmware bug.
As a workaround, increase the timeout to avoid failing the UCSI
initialization prematurely.

Fixes: b1b59e16075f ("usb: typec: ucsi: Increase command completion timeout value")
Cc: stable <stable@kernel.org>
Signed-off-by: Fedor Pchelkin <boddah8794@gmail.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250217105442.113486-3-boddah8794@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
acpi: typec: ucsi: Introduce a ->poll_cci method 2025-02-19T14:19:52+00:00 Christian A. Ehrhardt lk@c--e.de 2025-02-17T10:54:39+00:00 976e7e9bdc7719a023a4ecccd2e3daec9ab20a40 For the ACPI backend of UCSI the UCSI "registers" are just a memory copy of the register values in an opregion. The ACPI implementation in the BIOS ensures that the opregion contents are synced to the embedded controller and it ensures that the registers (in particular CCI) are synced back to the opregion on notifications. While there is an ACPI call that syncs the actual registers to the opregion there is rarely a need to do this and on some ACPI implementations it actually breaks in various interesting ways. The only reason to force a sync from the embedded controller is to poll CCI while notifications are disabled. Only the ucsi core knows if this is the case and guessing based on the current command is suboptimal, i.e. leading to the following spurious assertion splat: WARNING: CPU: 3 PID: 76 at drivers/usb/typec/ucsi/ucsi.c:1388 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi] CPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 Not tainted 6.12.11-200.fc41.x86_64 #1 Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023 Workqueue: events_long ucsi_init_work [typec_ucsi] RIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi] Call Trace: <TASK> ucsi_init_work+0x3c/0xac0 [typec_ucsi] process_one_work+0x179/0x330 worker_thread+0x252/0x390 kthread+0xd2/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> Thus introduce a ->poll_cci() method that works like ->read_cci() with an additional forced sync and document that this should be used when polling with notifications disabled. For all other backends that presumably don't have this issue use the same implementation for both methods. Fixes: fa48d7e81624 ("usb: typec: ucsi: Do not call ACPI _DSM method for UCSI read operations") Cc: stable <stable@kernel.org> Signed-off-by: Christian A. Ehrhardt <lk@c--e.de> Tested-by: Fedor Pchelkin <boddah8794@gmail.com> Signed-off-by: Fedor Pchelkin <boddah8794@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250217105442.113486-2-boddah8794@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
For the ACPI backend of UCSI the UCSI "registers" are just a memory copy
of the register values in an opregion. The ACPI implementation in the
BIOS ensures that the opregion contents are synced to the embedded
controller and it ensures that the registers (in particular CCI) are
synced back to the opregion on notifications. While there is an ACPI call
that syncs the actual registers to the opregion there is rarely a need to
do this and on some ACPI implementations it actually breaks in various
interesting ways.

The only reason to force a sync from the embedded controller is to poll
CCI while notifications are disabled. Only the ucsi core knows if this
is the case and guessing based on the current command is suboptimal, i.e.
leading to the following spurious assertion splat:

WARNING: CPU: 3 PID: 76 at drivers/usb/typec/ucsi/ucsi.c:1388 ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]
CPU: 3 UID: 0 PID: 76 Comm: kworker/3:0 Not tainted 6.12.11-200.fc41.x86_64 #1
Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN45WW 03/17/2023
Workqueue: events_long ucsi_init_work [typec_ucsi]
RIP: 0010:ucsi_reset_ppm+0x1b4/0x1c0 [typec_ucsi]
Call Trace:
 <TASK>
 ucsi_init_work+0x3c/0xac0 [typec_ucsi]
 process_one_work+0x179/0x330
 worker_thread+0x252/0x390
 kthread+0xd2/0x100
 ret_from_fork+0x34/0x50
 ret_from_fork_asm+0x1a/0x30
 </TASK>

Thus introduce a ->poll_cci() method that works like ->read_cci() with an
additional forced sync and document that this should be used when polling
with notifications disabled. For all other backends that presumably don't
have this issue use the same implementation for both methods.

Fixes: fa48d7e81624 ("usb: typec: ucsi: Do not call ACPI _DSM method for UCSI read operations")
Cc: stable <stable@kernel.org>
Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
Tested-by: Fedor Pchelkin <boddah8794@gmail.com>
Signed-off-by: Fedor Pchelkin <boddah8794@gmail.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250217105442.113486-2-boddah8794@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: ucsi: Add a macro definition for UCSI v1.0 2025-01-17T11:38:43+00:00 Pengyu Luo mitltlatltl@gmail.com 2025-01-13T17:51:25+00:00 06c47f203222c93dbec85950d976637aedd54514 Many platforms from Qualcomm(before X elite) still use UCSI v1.0, part of them hardcoded the version number to dsdt, add this for them. Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250113175131.590683-1-mitltlatltl@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Many platforms from Qualcomm(before X elite) still use UCSI v1.0,
part of them hardcoded the version number to dsdt, add this for them.

Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250113175131.590683-1-mitltlatltl@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge 6.13-rc7 into usb-next 2025-01-13T05:11:06+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2025-01-13T05:11:06+00:00 2919c4a3d883361105185f9d2f658e1a4545a1a7 We need the USB fixes in here as well for testing. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
We need the USB fixes in here as well for testing.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: cros-ec-ucsi: Mark cros_ucsi_ops static/const 2025-01-11T16:02:30+00:00 Stephen Boyd swboyd@chromium.org 2025-01-09T22:06:53+00:00 a181c8ef0b745cdb61151c710f0880d00b8442b7 This structure isn't used outside this file and can be marked const so that it gets moved to read-only memory. Cc: Pavan Holla <pholla@chromium.org> Cc: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Cc: Łukasz Bartosik <ukaszb@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Łukasz Bartosik <ukaszb@chromium.org> Link: https://lore.kernel.org/r/20250109220655.1677506-3-swboyd@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This structure isn't used outside this file and can be marked const so
that it gets moved to read-only memory.

Cc: Pavan Holla <pholla@chromium.org>
Cc: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Cc: Łukasz Bartosik <ukaszb@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Łukasz Bartosik <ukaszb@chromium.org>
Link: https://lore.kernel.org/r/20250109220655.1677506-3-swboyd@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: cros-ec-ucsi: Add newlines to printk messages 2025-01-11T16:02:29+00:00 Stephen Boyd swboyd@chromium.org 2025-01-09T22:06:52+00:00 8ec7cac600ee761ed3fa9fb52a164b1a5507b280 These printks need newlines. Add them and convert to dev_err_probe() in cros_ucsi_probe() to simplify code. Cc: Pavan Holla <pholla@chromium.org> Cc: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Cc: Łukasz Bartosik <ukaszb@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Łukasz Bartosik <ukaszb@chromium.org> Link: https://lore.kernel.org/r/20250109220655.1677506-2-swboyd@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
These printks need newlines. Add them and convert to dev_err_probe() in
cros_ucsi_probe() to simplify code.

Cc: Pavan Holla <pholla@chromium.org>
Cc: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Cc: Łukasz Bartosik <ukaszb@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Łukasz Bartosik <ukaszb@chromium.org>
Link: https://lore.kernel.org/r/20250109220655.1677506-2-swboyd@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: fix pm usage counter imbalance in ucsi_ccg_sync_control() 2025-01-07T10:43:08+00:00 GONG Ruiqi gongruiqi1@huawei.com 2025-01-07T01:57:50+00:00 b0e525d7a22ea350e75e2aec22e47fcfafa4cacd The error handling for the case `con_index == 0` should involve dropping the pm usage counter, as ucsi_ccg_sync_control() gets it at the beginning. Fix it. Cc: stable <stable@kernel.org> Fixes: e56aac6e5a25 ("usb: typec: fix potential array underflow in ucsi_ccg_sync_control()") Signed-off-by: GONG Ruiqi <gongruiqi1@huawei.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20250107015750.2778646-1-gongruiqi1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The error handling for the case `con_index == 0` should involve dropping
the pm usage counter, as ucsi_ccg_sync_control() gets it at the
beginning. Fix it.

Cc: stable <stable@kernel.org>
Fixes: e56aac6e5a25 ("usb: typec: fix potential array underflow in ucsi_ccg_sync_control()")
Signed-off-by: GONG Ruiqi <gongruiqi1@huawei.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20250107015750.2778646-1-gongruiqi1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: ucsi: Implement ChromeOS UCSI driver 2025-01-03T10:14:17+00:00 Pavan Holla pholla@chromium.org 2024-12-31T13:10:47+00:00 f1a2241778d9627f8b41829c6ca0735b683a9c68 Implementation of a UCSI transport driver for ChromeOS. This driver will be loaded if the ChromeOS EC implements a PPM. Signed-off-by: Pavan Holla <pholla@chromium.org> Co-developed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Co-developed-by: Łukasz Bartosik <ukaszb@chromium.org> Signed-off-by: Łukasz Bartosik <ukaszb@chromium.org> Link: https://lore.kernel.org/r/20241231131047.1757434-3-ukaszb@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Implementation of a UCSI transport driver for ChromeOS.
This driver will be loaded if the ChromeOS EC implements a PPM.

Signed-off-by: Pavan Holla <pholla@chromium.org>
Co-developed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Co-developed-by: Łukasz Bartosik <ukaszb@chromium.org>
Signed-off-by: Łukasz Bartosik <ukaszb@chromium.org>
Link: https://lore.kernel.org/r/20241231131047.1757434-3-ukaszb@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: typec: ucsi: make yoga_c630_ucsi_ops be static 2024-12-27T12:06:53+00:00 Pei Xiao xiaopei01@kylinos.cn 2024-12-27T08:54:50+00:00 da31486bf2348078b6542eeed152caca74154bd5 sparse warnings: drivers/usb/typec/ucsi/ucsi_yoga_c630.c:101:30: sparse: sparse: symbol 'yoga_c630_ucsi_ops' was not declared. Should it be static? Add static to fix sparse warnings. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202412102033.J4vZNaaR-lkp@intel.com/ Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Link: https://lore.kernel.org/r/cefe3bc20b2ddaee2a0924ba32243f035e92a025.1735289530.git.xiaopei01@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
sparse warnings:
    drivers/usb/typec/ucsi/ucsi_yoga_c630.c:101:30: sparse: sparse:
    symbol 'yoga_c630_ucsi_ops' was not declared. Should it be static?

Add static to fix sparse warnings.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202412102033.J4vZNaaR-lkp@intel.com/
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://lore.kernel.org/r/cefe3bc20b2ddaee2a0924ba32243f035e92a025.1735289530.git.xiaopei01@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>