summaryrefslogtreecommitdiff
path: root/drivers/platform/chrome
AgeCommit message (Collapse)AuthorFilesLines
6 daysplatform/chrome: cros_ec_ishtp: Fix UAF after unbinding driverTzung-Bi Shih1-0/+1
commit 944edca81e7aea15f83cf9a13a6ab67f711e8abd upstream. After unbinding the driver, another kthread `cros_ec_console_log_work` is still accessing the device, resulting an UAF and crash. The driver doesn't unregister the EC device in .remove() which should shutdown sub-devices synchronously. Fix it. Fixes: 26a14267aff2 ("platform/chrome: Add ChromeOS EC ISHTP driver") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20251031033900.3577394-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28platform/chrome: cros_ec: Unregister notifier in cros_ec_unregister()Tzung-Bi Shih1-0/+3
[ Upstream commit e2374953461947eee49f69b3e3204ff080ef31b1 ] The blocking notifier is registered in cros_ec_register(); however, it isn't unregistered in cros_ec_unregister(). Fix it. Fixes: 42cd0ab476e2 ("platform/chrome: cros_ec: Query EC protocol version if EC transitions between RO/RW") Cc: stable@vger.kernel.org Reviewed-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20250722120513.234031-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28platform/chrome: cros_ec: remove unneeded label and if-conditionTzung-Bi Shih1-6/+4
[ Upstream commit 554ec02c97254962bbb0a8776c3160d294fc7e51 ] Both `ec_dev->ec` and `ec_dev->pd` are initialized to NULL at the beginning of cros_ec_register(). Also, platform_device_unregister() takes care if the given platform_device is NULL. Remove the unneeded goto-label and if-condition. Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20230308031247.2866401-1-tzungbi@kernel.org Stable-dep-of: e23749534619 ("platform/chrome: cros_ec: Unregister notifier in cros_ec_unregister()") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28platform/chrome: cros_ec: Use per-device lockdep keyChen-Yu Tsai1-3/+11
[ Upstream commit 961a325becd9a142ae5c8b258e5c2f221f8bfac8 ] Lockdep reports a bogus possible deadlock on MT8192 Chromebooks due to the following lock sequences: 1. lock(i2c_register_adapter) [1]; lock(&ec_dev->lock) 2. lock(&ec_dev->lock); lock(prepare_lock); The actual dependency chains are much longer. The shortened version looks somewhat like: 1. cros-ec-rpmsg on mtk-scp ec_dev->lock -> prepare_lock 2. In rt5682_i2c_probe() on native I2C bus: prepare_lock -> regmap->lock -> (possibly) i2c_adapter->bus_lock 3. In rt5682_i2c_probe() on native I2C bus: regmap->lock -> i2c_adapter->bus_lock 4. In sbs_probe() on i2c-cros-ec-tunnel I2C bus attached on cros-ec: i2c_adapter->bus_lock -> ec_dev->lock While lockdep is correct that the shared lockdep classes have a circular dependency, it is bogus because a) 2+3 happen on a native I2C bus b) 4 happens on the actual EC on ChromeOS devices c) 1 happens on the SCP coprocessor on MediaTek Chromebooks that just happens to expose a cros-ec interface, but does not have an i2c-cros-ec-tunnel I2C bus In short, the "dependencies" are actually on different devices. Setup a per-device lockdep key for cros_ec devices so lockdep can tell the two instances apart. This helps with getting rid of the bogus lockdep warning. For ChromeOS devices that only have one cros-ec instance this doesn't change anything. Also add a missing mutex_destroy, just to make the teardown complete. [1] This is likely the per I2C bus lock with shared lockdep class Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20230111074146.2624496-1-wenst@chromium.org Stable-dep-of: e23749534619 ("platform/chrome: cros_ec: Unregister notifier in cros_ec_unregister()") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28platform/chrome: cros_ec: Make cros_ec_unregister() return voidUwe Kleine-König5-7/+11
[ Upstream commit afb0a80e63d67e957b5d0eb4ade301aff6e13c8c ] Up to now cros_ec_unregister() returns zero unconditionally. Make it return void instead which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c, platform and spi remove callbacks is ignored anyway. Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20211020071753.wltjslmimb6wtlp5@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220123175201.34839-5-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: e23749534619 ("platform/chrome: cros_ec: Unregister notifier in cros_ec_unregister()") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-08-28platform/chrome: cros_ec_typec: Defer probe on missing EC parentTomasz Michalec1-2/+2
[ Upstream commit 8866f4e557eba43e991f99711515217a95f62d2e ] If cros_typec_probe is called before EC device is registered, cros_typec_probe will fail. It may happen when cros-ec-typec.ko is loaded before EC bus layer module (e.g. cros_ec_lpcs.ko, cros_ec_spi.ko). Return -EPROBE_DEFER when cros_typec_probe doesn't get EC device, so the probe function can be called again after EC device is registered. Signed-off-by: Tomasz Michalec <tmichalec@google.com> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Link: https://lore.kernel.org/r/20250610153748.1858519-1-tmichalec@google.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-02-01platform/chrome: cros_ec_typec: Check for EC driverAkihiko Odaki1-0/+3
commit 7464ff8bf2d762251b9537863db0e1caf9b0e402 upstream. The EC driver may not be initialized when cros_typec_probe is called, particulary when CONFIG_CROS_EC_CHARDEV=m. Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20220404041101.6276-1-akihiko.odaki@gmail.com Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Laura Nao <laura.nao@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-12-14platform/chrome: cros_ec_typec: fix missing fwnode reference decrementJavier Carrasco1-0/+1
commit 9c41f371457bd9a24874e3c7934d9745e87fbc58 upstream. The device_for_each_child_node() macro requires explicit calls to fwnode_handle_put() upon early exits (return, break, goto) to decrement the fwnode's refcount, and avoid levaing a node reference behind. Add the missing fwnode_handle_put() after the common label for all error paths. Cc: stable@vger.kernel.org Fixes: fdc6b21e2444 ("platform/chrome: Add Type C connector class driver") Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Link: https://lore.kernel.org/r/20241013-cross_ec_typec_fwnode_handle_put-v2-1-9182b2cd7767@gmail.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-19platform/chrome: cros_ec_proto: Lock device when updating MKBP versionPatryk Duda1-0/+2
commit df615907f1bf907260af01ccb904d0e9304b5278 upstream. The cros_ec_get_host_command_version_mask() function requires that the caller must have ec_dev->lock mutex before calling it. This requirement was not met and as a result it was possible that two commands were sent to the device at the same time. The problem was observed while using UART backend which doesn't use any additional locks, unlike SPI backend which locks the controller until response is received. Fixes: f74c7557ed0d ("platform/chrome: cros_ec_proto: Update version on GET_NEXT_EVENT failure") Cc: stable@vger.kernel.org Signed-off-by: Patryk Duda <patrykd@google.com> Link: https://lore.kernel.org/r/20240730104425.607083-1-patrykd@google.com Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-19platform/chrome: cros_ec_debugfs: fix wrong EC message versionTzung-Bi Shih1-0/+1
[ Upstream commit c2a28647bbb4e0894e8824362410f72b06ac57a4 ] ec_read_version_supported() uses ec_params_get_cmd_versions_v1 but it wrongly uses message version 0. Fix it. Fixes: e86264595225 ("mfd: cros_ec: add debugfs, console log file") Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20240611113110.16955-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-30platform/chrome: cros_ec_chardev: fix kernel data leak from ioctlTzung-Bi Shih1-1/+1
[ Upstream commit b20cf3f89c56b5f6a38b7f76a8128bf9f291bbd3 ] It is possible to peep kernel page's data by providing larger `insize` in struct cros_ec_command[1] when invoking EC host commands. Fix it by using zeroed memory. [1]: https://elixir.bootlin.com/linux/v6.2/source/include/linux/platform_data/cros_ec_proto.h#L74 Fixes: eda2e30c6684 ("mfd / platform: cros_ec: Miscellaneous character device to talk with the EC") Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Link: https://lore.kernel.org/r/20230324010658.1082361-1-tzungbi@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31platform/chrome: cros_ec_typec: zero out stale pointersVictor Ding1-0/+2
[ Upstream commit 9a8aadcf0b459c1257b9477fd6402e1d5952ae07 ] `cros_typec_get_switch_handles` allocates four pointers when obtaining type-c switch handles. These pointers are all freed if failing to obtain any of them; therefore, pointers in `port` become stale. The stale pointers eventually cause use-after-free or double free in later code paths. Zeroing out all pointer fields after freeing to eliminate these stale pointers. Fixes: f28adb41dab4 ("platform/chrome: cros_ec_typec: Register Type C switches") Fixes: 1a8912caba02 ("platform/chrome: cros_ec_typec: Get retimer handle") Signed-off-by: Victor Ding <victording@chromium.org> Acked-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20221207093924.v2.1.I1864b6a7ee98824118b93677868d22d3750f439b@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31platform/chrome: cros_ec_typec: Cleanup switch handle return pathsPrashant Malani1-4/+2
[ Upstream commit 66fe238a9bcc158f75ddecf976d1ce7efe20f713 ] Some of the return paths for the cros_typec_get_switch_handles() aren't necessary. Clean up the return paths to only undo the handle get's which succeeded. Signed-off-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20220711072333.2064341-9-pmalani@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 9a8aadcf0b45 ("platform/chrome: cros_ec_typec: zero out stale pointers") Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-12-31platform/chrome: cros_usbpd_notify: Fix error handling in ↵Yuan Can1-1/+5
cros_usbpd_notify_init() [ Upstream commit 5a2d96623670155d94aca72c320c0ac27bdc6bd2 ] The following WARNING message was given when rmmod cros_usbpd_notify: Unexpected driver unregister! WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0 Modules linked in: cros_usbpd_notify(-) CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24 ... Call Trace: <TASK> cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify] __x64_sys_delete_module+0x3c7/0x570 ? __ia32_sys_delete_module+0x570/0x570 ? lock_is_held_type+0xe3/0x140 ? syscall_enter_from_user_mode+0x17/0x50 ? rcu_read_lock_sched_held+0xa0/0xd0 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f333fe9b1b7 The reason is that the cros_usbpd_notify_init() does not check the return value of platform_driver_register(), and the cros_usbpd_notify can install successfully even if platform_driver_register() failed. Fix by checking the return value of platform_driver_register() and unregister cros_usbpd_notify_plat_driver when it failed. Fixes: ec2daf6e33f9 ("platform: chrome: Add cros-usbpd-notify driver") Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20221117080823.77549-1-yuancan@huawei.com Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-26platform/chrome: cros_ec: Notify the PM of wake events during resumeJameson Thies1-1/+7
[ Upstream commit 8edd2752b0aa498b3a61f3caee8f79f7e0567fad ] cros_ec_handle_event in the cros_ec driver can notify the PM of wake events. When a device is suspended, cros_ec_handle_event will not check MKBP events. Instead, received MKBP events are checked during resume by cros_ec_report_events_during_suspend. But cros_ec_report_events_during_suspend cannot notify the PM if received events are wake events, causing wake events to not be reported if received while the device is suspended. Update cros_ec_report_events_during_suspend to notify the PM of wake events during resume by calling pm_wakeup_event. Signed-off-by: Jameson Thies <jthies@google.com> Reviewed-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220913204954.2931042-1-jthies@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-26platform/chrome: cros_ec_typec: Correct alt mode indexPrashant Malani1-1/+1
[ Upstream commit 4e477663e396f48c5cfc5f2d75d4b514f409516a ] Alt mode indices used by USB PD (Power Delivery) start with 1, not 0. Update the alt mdoe registration code to factor this in to the alt mode descriptor. Fixes: de0f49487db3 ("platform/chrome: cros_ec_typec: Register partner altmodes") Signed-off-by: Prashant Malani <pmalani@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220819190807.1275937-3-pmalani@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-26platform/chrome: fix memory corruption in ioctlDan Carpenter1-0/+3
[ Upstream commit 8a07b45fd3c2dda24fad43639be5335a4595196a ] If "s_mem.bytes" is larger than the buffer size it leads to memory corruption. Fixes: eda2e30c6684 ("mfd / platform: cros_ec: Miscellaneous character device to talk with the EC") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/Yv8dpCFZJdbUT5ye@kili Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-26platform/chrome: fix double-free in chromeos_laptop_prepare()Rustam Subkhankulov1-11/+13
[ Upstream commit 6ad4194d6a1e1d11b285989cd648ef695b4a93c0 ] If chromeos_laptop_prepare_i2c_peripherals() fails after allocating memory for 'cros_laptop->i2c_peripherals', this memory is freed at 'err_out' label and nonzero value is returned. Then chromeos_laptop_destroy() is called, resulting in double-free error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rustam Subkhankulov <subkhankulov@ispras.ru> Fixes: 5020cd29d8bf ("platform/chrome: chromeos_laptop - supply properties for ACPI devices") Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220813220843.2373004-1-subkhankulov@ispras.ru Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-10-26platform/chrome: cros_ec_proto: Update version on GET_NEXT_EVENT failurePatryk Duda1-0/+32
commit f74c7557ed0d321947e8bb4e9d47c1013f8b2227 upstream. Some EC based devices (e.g. Fingerpint MCU) can jump to RO part of the firmware (intentionally or due to device reboot). The RO part doesn't change during the device lifecycle, so it won't support newer version of EC_CMD_GET_NEXT_EVENT command. Function cros_ec_query_all() is responsible for finding maximum supported MKBP event version. It's usually called when the device is running RW part of the firmware, so the command version can be potentially higher than version supported by the RO. The problem was fixed by updating maximum supported version when the device returns EC_RES_INVALID_VERSION (mapped to -ENOPROTOOPT). That way the kernel will use highest common version supported by RO and RW. Fixes: 3300fdd630d4 ("platform/chrome: cros_ec: handle MKBP more events flag") Cc: <stable@vger.kernel.org> # 5.10+ Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Patryk Duda <pdk@semihalf.com> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220802154128.21175-1-pdk@semihalf.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-25platform/chrome: cros_ec_proto: don't show MKBP version if unsupportedTzung-Bi Shih1-4/+4
[ Upstream commit b36f0643ff14a2fb281b105418e4e73c9d7c11d0 ] It wrongly showed the following message when it doesn't support MKBP: "MKBP support version 4294967295". Fix it. Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220609084957.3684698-14-tzungbi@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-08-17platform/chrome: cros_ec: Always expose last resume resultStephen Boyd1-4/+4
[ Upstream commit 74bb746407bf0d7c7d126c7731dbcd66d467619b ] The last resume result exposing logic in cros_ec_sleep_event() incorrectly requires S0ix support, which doesn't work on ARM based systems where S0ix doesn't exist. That's because cros_ec_sleep_event() only reports the last resume result when the EC indicates the last sleep event was an S0ix resume. On ARM systems, the last sleep event is always S3 resume, but the EC can still detect sleep hang events in case some other part of the AP is blocking sleep. Always expose the last resume result if the EC supports it so that this works on all devices regardless of S0ix support. This fixes sleep hang detection on ARM based chromebooks like Trogdor. Cc: Rajat Jain <rajatja@chromium.org> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Hsin-Yi Wang <hsinyi@chromium.org> Cc: Tzung-Bi Shih <tzungbi@kernel.org> Reviewed-by: Guenter Roeck <groeck@chromium.org> Reviewed-by: Evan Green <evgreen@chromium.org> Fixes: 7235560ac77a ("platform/chrome: Add support for v1 of host sleep event") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://lore.kernel.org/r/20220614075726.2729987-1-swboyd@chromium.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-06-09platform/chrome: Re-introduce cros_ec_cmd_xfer and use it for ioctlsGuenter Roeck2-10/+42
[ Upstream commit 57b888ca2541785de2fcb90575b378921919b6c0 ] Commit 413dda8f2c6f ("platform/chrome: cros_ec_chardev: Use cros_ec_cmd_xfer_status helper") inadvertendly changed the userspace ABI. Previously, cros_ec ioctls would only report errors if the EC communication failed, and otherwise return success and the result of the EC communication. An EC command execution failure was reported in the EC response field. The above mentioned commit changed this behavior, and the ioctl itself would fail. This breaks userspace commands trying to analyze the EC command execution error since the actual EC command response is no longer reported to userspace. Fix the problem by re-introducing the cros_ec_cmd_xfer() helper, and use it to handle ioctl messages. Fixes: 413dda8f2c6f ("platform/chrome: cros_ec_chardev: Use cros_ec_cmd_xfer_status helper") Cc: Daisuke Nojiri <dnojiri@chromium.org> Cc: Rob Barnes <robbarnes@google.com> Cc: Rajat Jain <rajatja@google.com> Cc: Brian Norris <briannorris@chromium.org> Cc: Parth Malkan <parthmalkan@google.com> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-06-09platform/chrome: cros_ec: fix error handling in cros_ec_register()Tzung-Bi Shih1-6/+10
[ Upstream commit 2cd01bd6b117df07b1bc2852f08694fdd29e40ed ] Fix cros_ec_register() to unregister platform devices if blocking_notifier_chain_register() fails. Also use the single exit path to handle the platform device unregistration. Fixes: 42cd0ab476e2 ("platform/chrome: cros_ec: Query EC protocol version if EC transitions between RO/RW") Reviewed-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-05-25platform/chrome: cros_ec_debugfs: detach log reader wq from devmTzung-Bi Shih1-6/+6
[ Upstream commit 0e8eb5e8acbad19ac2e1856b2fb2320184299b33 ] Debugfs console_log uses devm memory (e.g. debug_info in cros_ec_console_log_poll()). However, lifecycles of device and debugfs are independent. An use-after-free issue is observed if userland program operates the debugfs after the memory has been freed. The call trace: do_raw_spin_lock _raw_spin_lock_irqsave remove_wait_queue ep_unregister_pollwait ep_remove do_epoll_ctl A Python example to reproduce the issue: ... import select ... p = select.epoll() ... f = open('/sys/kernel/debug/cros_scp/console_log') ... p.register(f, select.POLLIN) ... p.poll(1) [(4, 1)] # 4=fd, 1=select.POLLIN [ shutdown cros_scp at the point ] ... p.poll(1) [(4, 16)] # 4=fd, 16=select.POLLHUP ... p.unregister(f) An use-after-free issue raises here. It called epoll_ctl with EPOLL_CTL_DEL which in turn to use the workqueue in the devm (i.e. log_wq). Detaches log reader's workqueue from devm to make sure it is persistent even if the device has been removed. Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Reviewed-by: Guenter Roeck <groeck@google.com> Link: https://lore.kernel.org/r/20220209051130.386175-1-tzungbi@google.com Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-04-08platform/chrome: cros_ec_typec: Check for EC devicePrashant Malani1-0/+6
commit ffebd90532728086007038986900426544e3df4e upstream. The Type C ACPI device on older Chromebooks is not generated correctly (since their EC firmware doesn't support the new commands required). In such cases, the crafted ACPI device doesn't have an EC parent, and it is therefore not useful (it shouldn't be generated in the first place since the EC firmware doesn't support any of the Type C commands). To handle devices which use these older firmware revisions, check for the parent EC device handle, and fail the probe if it's not found. Fixes: fdc6b21e2444 ("platform/chrome: Add Type C connector class driver") Reported-by: Alyssa Ross <hi@alyssa.is> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com> Signed-off-by: Prashant Malani <pmalani@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Alyssa Ross <hi@alyssa.is> Tested-by: Alyssa Ross <hi@alyssa.is> Link: https://lore.kernel.org/r/20220126190219.3095419-1-pmalani@chromium.org Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-04-08platform: chrome: Split trace include fileGwendal Grignou4-97/+127
commit eabd9a3807e17e211690e6c40f1405b427b64c48 upstream. cros_ec_trace.h defined 5 tracing events, 2 for cros_ec_proto and 3 for cros_ec_sensorhub_ring. These 2 files are in different kernel modules, the traces are defined twice in the kernel which leads to problem enabling only some traces. Move sensorhub traces from cros_ec_trace.h to cros_ec_sensorhub_trace.h and enable them only in cros_ec_sensorhub kernel module. Check we can now enable any single traces: without this patch, we can only enable all sensorhub traces or none. Fixes: d453ceb6549a ("platform/chrome: sensorhub: Add trace events for sample") Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220122001301.640337-1-gwendal@chromium.org Signed-off-by: Benson Leung <bleung@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-08-31platform/chrome: cros_ec_trace: Fix format warningsGwendal Grignou1-3/+3
Fix printf format issues in new tracing events. Fixes: 814318242687 ("platform/chrome: cros_ec_trace: Add fields to command traces") Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Link: https://lore.kernel.org/r/20210830180050.2077261-1-gwendal@chromium.org Signed-off-by: Benson Leung <bleung@chromium.org>
2021-08-23platform/chrome: cros_ec_typec: Use existing feature checkPrashant Malani1-22/+5
Replace the cros_typec_feature_supported() function with the pre-existing cros_ec_check_features() function which does the same thing. Signed-off-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20210803173619.91539-2-pmalani@chromium.org Signed-off-by: Benson Leung <bleung@chromium.org>
2021-07-27platform/chrome: cros_ec_proto: Send command again when timeout occursPatryk Duda1-0/+9
Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it hasn't initialized SPI yet. This can happen because FPMCU is restarted during system boot and kernel can send message in short window eg. between sysjump to RW and SPI initialization. Cc: <stable@vger.kernel.org> # 4.4+ Signed-off-by: Patryk Duda <pdk@semihalf.com> Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com Signed-off-by: Benson Leung <bleung@chromium.org>
2021-07-26platform/chrome: sensorhub: Add trace events for sampleGwendal Grignou3-1/+109
Add trace event to report samples and their timestamp coming from the EC. It allows to check if the timestamps are correct and the filter is working correctly without introducing too much latency. To enable these events: cd /sys/kernel/debug/tracing/ echo 1 > events/cros_ec/enable echo 0 > events/cros_ec/cros_ec_request_start/enable echo 0 > events/cros_ec/cros_ec_request_done/enable echo 1 > tracing_on cat trace_pipe Observe event flowing: irq/105-chromeo-95 [000] .... 613.659758: cros_ec_sensorhub_timestamp: ... irq/105-chromeo-95 [000] .... 613.665219: cros_ec_sensorhub_filter: dx: ... Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
2021-06-30Merge branch 'for-5.14/intel-ish' into for-linusJiri Kosina1-3/+1
- support for ISH DMA on EHL platform from Even Xu - various code style fixes and cleanups from Lee Jones and Uwe Kleine-König
2021-05-08Merge tag 'tag-chrome-platform-for-v5.13' of ↵Linus Torvalds4-17/+38
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux Pull chrome platform updates from Benson Leung: "cros_ec_typec: - Changes around DP mode check, hard reset, tracking port change. cros_ec misc: - wilco_ec: Convert stream-like files from nonseekable to stream open - cros_usbpd_notify: Listen to EC_HSOT_EVENT_USB_MUX host event - fix format warning in cros_ec_typec" * tag 'tag-chrome-platform-for-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_ec_lpc: Use DEFINE_MUTEX() for mutex lock platform/chrome: cros_usbpd_notify: Listen to EC_HOST_EVENT_USB_MUX host event platform/chrome: cros_ec_typec: Add DP mode check platform/chrome: cros_ec_typec: Handle hard reset platform/chrome: cros_ec: Add Type C hard reset platform/chrome: cros_ec_typec: Track port role platform/chrome: cros_ec_typec: fix clang -Wformat warning platform/chrome: cros_ec_typec: Check for device within remove function platform/chrome: wilco_ec: convert stream-like files from nonseekable_open -> stream_open
2021-04-21platform/chrome: cros_ec_lpc: Use DEFINE_MUTEX() for mutex lockYe Bin1-2/+1
mutex lock can be initialized automatically with DEFINE_MUTEX() rather than explicitly calling mutex_init(). Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Ye Bin <yebin10@huawei.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210409095138.2293869-1-yebin10@huawei.com
2021-04-21platform/chrome: cros_usbpd_notify: Listen to EC_HOST_EVENT_USB_MUX host eventPi-Hsun Shih1-1/+2
On system that use ACPI, cros_usbpd_notify gets notifications of USB MUX host event same as PD host events [1]. But currently on system that use DT, the driver only listen on EC_HOST_EVENT_PD_MCU. Add EC_HOST_EVENT_USB_MUX to the list of host events, so we have same behavior on all platforms. [1]: https://chromium.googlesource.com/chromiumos/third_party/coreboot/+/refs/heads/chromeos-2016.05/src/ec/google/chromeec/acpi/ec.asl#382 Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210414064524.2450908-1-pihsun@chromium.org
2021-04-21platform/chrome: cros_ec_typec: Add DP mode checkPrashant Malani1-0/+5
There are certain transitional situations where the dp_mode field in the PD_CONTROL response might not be populated with the right DP pin assignment value yet. Add a check for that to avoid sending an invalid value to the Type C mode switch. Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210421042108.2002-1-pmalani@chromium.org
2021-04-20platform/chrome: cros_ec_typec: Handle hard resetPrashant Malani1-0/+13
The Chrome Embedded Controller (EC) generates a hard reset type C event when a USB Power Delivery (PD) hard reset is encountered. Handle this event by unregistering the partner and cable on the associated port and clearing the event flag. Cc: Benson Leung <bleung@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210420171617.3830902-2-pmalani@chromium.org
2021-04-20platform/chrome: cros_ec_typec: Track port rolePrashant Malani1-1/+4
Stash the currently reported port role in the port struct and add a check for that too while determining whether to re-configure on-board Type C switches (this deals with cases like role swaps where the mux flags don't change, but the port role does). Signed-off-by: Prashant Malani <pmalani@chromium.org> Suggested-by: Nikunj A. Dadhania <nikunj.dadhania@intel.com> Tested-by: Deepti Deshatty <deepti.deshatty@intel.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210420171008.3829549-1-pmalani@chromium.org
2021-04-10platform/chrome: chromeos_laptop - Prepare complete software nodesHeikki Krogerus1-40/+60
The older device property API is going to be removed soon and that will affect also I2C subystem. Supplying complete software nodes instead of only the properties in them for the I2C devices. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2021-03-30platform/chrome: cros_ec_typec: fix clang -Wformat warningArnd Bergmann1-2/+2
Clang warns about using the %h format modifier to truncate an integer: drivers/platform/chrome/cros_ec_typec.c:1031:3: error: format specifies type 'unsigned char' but the argument has type 'unsigned int' [-Werror,-Wformat] typec->pd_ctrl_ver); ^~~~~~~~~~~~~~~~~~ include/linux/dev_printk.h:131:47: note: expanded from macro 'dev_dbg' dev_printk(KERN_DEBUG, dev, dev_fmt(fmt), ##__VA_ARGS__); \ ~~~ ^~~~~~~~~~~ Use an explicit bit mask to limit the number to its lower eight bits instead. Fixes: ad7c0510c99e ("platform/chrome: cros_ec_typec: Update port info from EC") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210322115602.4003221-1-arnd@kernel.org
2021-03-30platform/chrome: cros_ec_typec: Check for device within remove functionPrashant Malani1-10/+10
In a couple of call sites, we use the same pattern of checking for a partner or cable device before attempting to remove it. Simplify this by moving those checks into the remove functions. Cc: Benson Leung <bleung@chromium.org> Signed-off-by: Prashant Malani <pmalani@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/20210319015103.3751672-1-pmalani@chromium.org
2021-03-30platform/chrome: wilco_ec: convert stream-like files from nonseekable_open ↵Yang Li1-1/+1
-> stream_open Eliminate the following coccicheck warning: ./drivers/platform/chrome/wilco_ec/telemetry.c:259:1-17: WARNING: telem_fops: .read() and .write() have stream semantic; safe to change nonseekable_open -> stream_open. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Link: https://lore.kernel.org/r/1612688918-63132-1-git-send-email-yang.lee@linux.alibaba.com
2021-03-08HID: intel-ish-hid: Make remove callback return voidUwe Kleine-König1-3/+1
The driver core ignores the return value of struct bus_type::remove() because there is only little that can be done. To simplify the quest to make this function return void, let struct ishtp_cl_driver::remove() return void, too. All users already unconditionally return 0, this commit makes it obvious that returning an error value is a bad idea. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2021-02-22Merge tag 'tag-chrome-platform-for-v5.12' of ↵Linus Torvalds10-39/+66
git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux Pull chrome platform updates from Benson Leung: "Lots of changes to the cros_ec_typec driver for 5.12. A portion of this this set of cros_ec_typec driver's changes was merged through GregKH's USB tree in order to satisfy cros_ec_typec driver and typec connector class subsystem dependencies of subsequent changes. Summary: cros_ec_typec: - Registration of cable plug information - Support for SOP' plug registration and altmodes - Support for reporting number of altmodes supported by partners and plugs - Send mux configuration ack to EC via a new host command - Support mux control with no port partner present - Decouple cable removal from partner removal cros_ec misc: - Fix some event masking in cros_ec_proto. - Gwendal reworked cros_ec's top and bottom half for consistency in ishtp and rpmsg - Constify static attribute_group structs" * tag 'tag-chrome-platform-for-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_ec_typec: Flush pending work platform/chrome: cros_ec_types: Support disconnect events without partners platform/chrome: cros_ec_typec: Skip port partner check in configure_mux() platform/chrome: cros_ec_typec: Decouple partner removal platform/chrome: cros_ec: Call interrupt bottom half at probe time platform/chrome: cros_ec: Call interrupt bottom half in ISH or RPMSG mode platform/chrome: cros_ec_sysfs: Add cold-ap-off to sysfs reboot. platform/chrome: cros_ec_commands: Add host command to keep AP off after EC reset. platform/chrome: Constify static attribute_group structs platform/chrome: cros_ec_proto: Add LID and BATTERY to default mask platform/chrome: cros_ec_proto: Use EC_HOST_EVENT_MASK not BIT
2021-02-12platform/chrome: cros_ec_typec: Flush pending workPrashant Malani1-0/+1
When a PD notifier event arrives, a new work event won't be enqueued if the current one hasn't completed. This could lead to dropped events. So, flush any pending work before scheduling the new instance. Signed-off-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20210211193221.610867-1-pmalani@chromium.org Signed-off-by: Benson Leung <bleung@chromium.org>
2021-02-06platform/chrome: cros_ec_types: Support disconnect events without partnersRajmohan Mani1-7/+19
There are certain scenarios, where a disconnect event might occur on a Type-C port with no port partners. This is required to enable communication to Burnside Bridge USB4 retimers. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Reviewed-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20210205195113.20277-3-rajmohan.mani@intel.com Signed-off-by: Benson Leung <bleung@chromium.org>
2021-02-06platform/chrome: cros_ec_typec: Skip port partner check in configure_mux()Rajmohan Mani1-3/+0
For certain needs like updating the USB4 retimer firmware when no device are connected, the Type-C ports require mux configuration, to be able to communicate with the retimer. So removed the above check to allow for mux configuration of Type-C ports, to enable retimer communication. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Reviewed-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20210205195113.20277-2-rajmohan.mani@intel.com Signed-off-by: Benson Leung <bleung@chromium.org>
2021-02-04platform/chrome: cros_ec_typec: Clear Type C disc eventsPrashant Malani1-3/+26
Clear USB Type C discovery events from the Chrome EC once they've been successfully handled. Signed-off-by: Prashant Malani <pmalani@chromium.org> Reported-by: Benson Leung <bleung@chromium.org> Tested-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20210203021539.745239-2-pmalani@chromium.org Signed-off-by: Benson Leung <bleung@chromium.org>
2021-02-03platform/chrome: cros_ec_typec: Decouple partner removalPrashant Malani1-3/+2
Currently, we return if there is no partner present when !PD_CTRL_RESP_ENABLED_CONNECTED, without proceeding further. This ties partner removal to cable removal, whereas the two should be independent. Update the check to remove a partner if one was registered, but continue after that instead of returning. Signed-off-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20210202224001.3810274-1-pmalani@chromium.org Signed-off-by: Benson Leung <bleung@chromium.org>
2021-02-02platform/chrome: cros_ec_typec: Fix call to typec_partner_set_pd_revisionBenson Leung1-5/+1
typec_partner_set_pd_revision returns void now. Fixes: cefc011f8daf ("platform/chrome: cros_ec_typec: Set Partner PD revision from status") Signed-off-by: Benson Leung <bleung@chromium.org> Link: https://lore.kernel.org/r/20210202164531.3982778-1-bleung@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-02platform/chrome: cros_ec_typec: Set opmode to PD on SOP connectedBenson Leung1-0/+3
When SOP Discovery is done, set the opmode to PD if status indicates SOP is connected. SOP connected indicates a PD contract is in place, and is a solid indication we have transitioned to PD power negotiation, either as source or sink. Signed-off-by: Benson Leung <bleung@chromium.org> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Prashant Malani <pmalani@chromium.org> Link: https://lore.kernel.org/r/20210129061406.2680146-7-bleung@chromium.org Signed-off-by: Benson Leung <bleung@chromium.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-25 15:38:04 +0300