kernel/drivers/platform/chrome/cros_ec_debugfs.c, branch linux-6.9.y

platform/chrome: cros_ec_debugfs: Fix permissions for panicinfo

2023-11-21T20:10:44Z

The debugfs_create_blob() function has been used to create read-only binary blobs in debugfs. The function filters out permissions, other than S_IRUSR, S_IRGRP and S_IROTH, provided while creating the blobs. The very behavior though is being changed through previous patch in the series (fs: debugfs: Add write functionality to debugfs blobs) which makes the binary blobs writable by owners. Thus, all permissions provided while creating the blobs, except S_IRUSR,S_IWUSR, S_IRGRP, S_IROTH, will be filtered by debugfs_create_blob(). As such, rectify the permissions of panicinfo file since the S_IFREG flag was anyways being filtered out by debugfs_create_blob(). Moreover, the very flag will always be set be set for the panicinfo file through __debugfs_create_file(). Signed-off-by: Avadhut Naik Reviewed-by: Greg Kroah-Hartman Reviewed-by: Tony Luck Signed-off-by: Rafael J. Wysocki

platform/chrome: cros_ec_debugfs: Convert to platform remove callback returning void

2023-09-28T05:18:06Z

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20230927081040.2198742-3-u.kleine-koenig@pengutronix.de Signed-off-by: Tzung-Bi Shih

platform/chrome: cros_ec_debugfs: fix kernel-doc warning

2023-04-24T05:35:12Z

Fix the following kernel-doc warning: $ ./scripts/kernel-doc -none drivers/platform/chrome/* [...] warning: This comment starts with '/**', but isn't a kernel-doc comment. Fixes: 14bb09b32f43 ("platform/chrome: cros_ec: Separate logic for getting panic info") Reported-by: kernel test robot Signed-off-by: Tzung-Bi Shih Reviewed-by: Benson Leung Link: https://lore.kernel.org/r/20230411053308.1572493-1-tzungbi@kernel.org

platform/chrome: cros_ec: Separate logic for getting panic info

2023-04-24T05:35:12Z

Create a separate function called cros_ec_get_panicinfo for getting panic info from EC. Currently cros_ec_create_panicinfo is the only caller. Signed-off-by: Rob Barnes Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230410165817.932449-1-robbarnes@google.com

platform/chrome: fix kernel-doc warnings for panic notifier

2023-01-13T01:30:49Z

Fix the following kernel-doc warnings: $ ./scripts/kernel-doc -none drivers/platform/chrome/* drivers/platform/chrome/cros_ec_debugfs.c:54: warning: Function parameter or member 'notifier_panic' not described in 'cros_ec_debugfs' $ ./scripts/kernel-doc -none include/linux/platform_data/cros_ec_proto.h include/linux/platform_data/cros_ec_proto.h:187: warning: Function parameter or member 'panic_notifier' not described in 'cros_ec_device' Cc: Rob Barnes Fixes: d90fa2c64d59 ("platform/chrome: cros_ec: Poll EC log on EC panic") Signed-off-by: Tzung-Bi Shih Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20230111055728.708990-2-tzungbi@kernel.org

platform/chrome: cros_ec: Poll EC log on EC panic

2023-01-06T03:48:06Z

Add handler for CrOS EC panic events. When a panic is reported, immediately poll for EC log. This should result in the log leading to the EC panic being preserved. ACPI_NOTIFY_CROS_EC_PANIC is defined in coreboot at https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/ec/google/chromeec/acpi/ec.asl Signed-off-by: Rob Barnes Reviewed-by: Prashant Malani Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230104011524.369764-2-robbarnes@google.com

platform/chrome: cros_ec_debugfs: Set PROBE_PREFER_ASYNCHRONOUS

2022-11-02T04:28:47Z

This driver takes on the order of 40ms to start on some systems. It shouldn't have many cross-device dependencies to race with, nor racy access to shared state with other drivers, so this should be a relatively low risk change. This driver was pinpointed as part of a survey of top slowest initcalls (i.e., are built in, and probing synchronously) on a lab of ChromeOS systems. Signed-off-by: Brian Norris Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20221101152132.v2.3.Ic9a4f378f73319da323cd55940012fa6b1de24f4@changeid

platform/chrome: cros_ec: Expose suspend_timeout_ms in debugfs

2022-08-24T02:37:07Z

In modern Chromebooks, the embedded controller has a mechanism where it will watch a hardware-controlled line that toggles in suspend, and wake the system up if an expected sleep transition didn't occur. This can be very useful for detecting power management issues where the system appears to suspend, but doesn't actually reach its lowest expected power states. Sometimes it's useful in debug and test scenarios to be able to control the duration of that timeout, or even disable the EC timeout mechanism altogether. Add a debugfs control to set the timeout to values other than the EC-defined default, for more convenient debug and development iteration. Signed-off-by: Evan Green Reviewed-by: Prashant Malani Reviewed-by: Stephen Boyd Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20220822144026.v3.1.Idd188ff3f9caddebc17ac357a13005f93333c21f@changeid [tzungbi: fix one nit in Documentation/ABI/testing/debugfs-cros-ec.] Signed-off-by: Tzung-Bi Shih

platform/chrome: cros_ec_debugfs: detach log reader wq from devm

2022-03-31T23:56:48Z

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 Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20220209051130.386175-1-tzungbi@google.com Signed-off-by: Benson Leung

platform/chrome: cros_ec_debugfs: Control uptime information request

2020-06-19T17:16:18Z

When EC does not support uptime command (EC_CMD_GET_UPTIME_INFO), do not create the uptime sysfs entry point. User space application will not probe the file needlessly. The EC console log will not contain EC_CMD_GET_UPTIME_INFO anymore. Signed-off-by: Gwendal Grignou Signed-off-by: Enric Balletbo i Serra