linux/drivers/platform/chrome, branch v6.3

platform/chrome: cros_ec_chardev: fix kernel data leak from ioctl

2023-03-24T02:56:28Z

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 Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20230324010658.1082361-1-tzungbi@kernel.org

platform/chrome: cros_ec_typec: Fix spelling mistake

2023-02-08T18:21:03Z

There is a spelling mistake in a dev_warn message, make it lower case and fix the spelling. Signed-off-by: Colin Ian King Reviewed-by: Tzung-Bi Shih Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20230207091443.143995-1-colin.i.king@gmail.com Signed-off-by: Prashant Malani [pmalani fixed up commit message based on tzungbi comment]

platform/chrome: cros_typec_vdm: Add Attention support

2023-01-31T18:12:18Z

Add support to retrieve VDM attention messages and forward them to the appropriate alt mode driver. Signed-off-by: Prashant Malani Reviewed-by: Benson Leung Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20230126205620.3714994-2-pmalani@chromium.org

platform/chrome: cros_typec_vdm: Fix VDO copy

2023-01-24T19:02:38Z

The usage of memcpy() affects the representation of the VDOs as they are copied to the EC Host Command buffer. Specifically, all higher order bits get dropped (for example: a VDO of 0x406 just gets copied as 0x6). Avoid this by explicitly copying each VDO in the array. The number of VDOs generated by alternate mode drivers in their VDMs is almost always just 1 (apart from the header) so this doesn't affect performance in a meaningful way). Fixes: 40a9b13a09ef ("platform/chrome: cros_typec_vdm: Add VDM send support") Signed-off-by: Prashant Malani Reviewed-by: Benson Leung Link: https://lore.kernel.org/r/20230113182626.1149539-1-pmalani@chromium.org Signed-off-by: Prashant Malani

platform/chrome: cros_ec_typec: allow deferred probe of switch handles

2023-01-24T19:02:38Z

`fwnode_typec_{retimer,mux,switch}_get()` could return `-EPROBE_DEFER`, which is called from `cros_typec_get_switch_handles`. When this happens, it does not indicate absence of switches; instead, it only hints that probing of switches should occur at a later time. Progagate `-EPROBE_DEFER` to upper layer logic so that they can re-try probing switches as a better time. Signed-off-by: Victor Ding Reviewed-by: Benson Leung Reviewed-by: Guenter Roeck Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20230124075555.v3.1.I6c0a089123fdf143f94ef4cca8677639031856cf@changeid Signed-off-by: Prashant Malani

platform/chrome: cros_ec_proto: remove big stub objects from stack

2023-01-18T02:57:56Z

sizeof(struct device) = 680 sizeof(struct cros_ec_dev) = 720 They tend to exceed the stack frame size limit in some specific environment which results in the following compilation error: >> drivers/platform/chrome/cros_ec_proto_test.c:2530:13: error: stack frame size (2128) exceeds limit (2048) in 'cros_ec_proto_test_get_sensor_count_legacy' Remove the big stub objects from stack. This is: $ sed -i 's/struct cros_ec_dev /static struct cros_ec_dev /' \ drivers/platform/chrome/cros_ec_proto_test.c Reported-by: kernel test robot Signed-off-by: Tzung-Bi Shih Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20230117080254.2725536-1-tzungbi@kernel.org

platform/chrome: cros_ec_uart: fix negative type promoted to high

2023-01-18T02:57:51Z

serdev_device_write_buf() returns negative numbers on errors. When the return value compares to unsigned integer `len`, it promotes to quite large positive number. Fix it. Fixes: 04a8bdd135cc ("platform/chrome: cros_ec_uart: Add transport layer") Reported-by: Dan Carpenter Signed-off-by: Tzung-Bi Shih Reviewed-by: Dan Carpenter Reviewed-by: Benson Leung Link: https://lore.kernel.org/r/20230109081554.3792547-1-tzungbi@kernel.org

platform/chrome: cros_ec: Use per-device lockdep key

2023-01-13T01:30:50Z

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 Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230111074146.2624496-1-wenst@chromium.org

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_lpc: initialize the buf variable

2023-01-11T03:27:56Z

Clang static analysis reports this problem drivers/platform/chrome/cros_ec_lpc.c:379:13: warning: The left operand of '!=' is a garbage value [core.UndefinedBinaryOperatorResult] if (buf[0] != 'E' || buf[1] != 'C') { ~~~~~~ ^ The check depends on the side effect of the read. When the read fails or is short, a buf containing garbage could be mistaken as correct. Signed-off-by: Tom Rix Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20230110193611.3573777-1-trix@redhat.com