kernel/git/next/linux-next.git/drivers/platform/chrome, branch master

Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git

2026-07-10T12:28:29+00:00

Replace by more specific (c files)

2026-07-03T05:38:17+00:00

Replace the #include of by the more specific where applicable. For most cases the include can be dropped completely, only a few drivers need one or two headers added. Acked-by: Danilo Krummrich Acked-by: Takashi Sakamoto Acked-by: Bjorn Helgaas Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com Signed-off-by: Uwe Kleine-König (The Capable Hub)

platform/chrome: sensorhub: Fix memory overread in ring handler

2026-07-03T03:29:07+00:00

`max_response` and `sensor_num` are read from different EC commands: - `max_response` is from cros_ec_get_proto_info(). ec_dev->max_response = info->max_response_packet_size - sizeof(struct ec_host_response); - `sensor_num` is from cros_ec_get_sensor_count(). sensor_num = cros_ec_get_sensor_count(ec); With a malfunctioning EC firmware, it is possible that the `msg->insize` (i.e., `fifo_info_length` in the context) could be clamped in cros_ec_cmd_xfer() because `msg->insize` is greater than `max_response`. int fifo_info_length = sizeof(struct ec_response_motion_sense_fifo_info) + sizeof(u16) * sensorhub->sensor_num; This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in cros_ec_sensorhub_ring_handler() overreads the `resp->fifo_info` buffer. Check the return value of cros_ec_cmd_xfer_status() and abort if the number of bytes read does not match the expected length. Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Reviewed-by: Tomasz Figa Link: https://lore.kernel.org/r/20260702082745.1014968-1-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih

platform/chrome: cros_ec_typec: Reject out-of-bounds PD cap count

2026-06-29T03:09:51+00:00

cros_typec_register_partner_pdos() copies the partner PDOs from the EC TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array. memcpy(caps_desc.pdo, resp->source_cap_pdos, sizeof(u32) * resp->source_cap_count); ... memcpy(caps_desc.pdo, resp->sink_cap_pdos, sizeof(u32) * resp->sink_cap_count); PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields from the EC. The only check is that they are not both zero. If either is larger than 7, the memcpy writes past the end of the array on the stack. A count of 255 overflows it by about 1 KB. The EC source arrays are only seven entries wide. A larger count reads past them too. The ChromeOS EC firmware caps these counts today, so a compliant setup does not hit this. The kernel should still validate these values rather than trust them. Validate the counts in cros_typec_register_partner_pdos() next to the memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS. The rest of cros_typec_handle_status() still runs so events are handled and cleared. Fixes: 348a2e8c93d3 ("platform/chrome: cros_ec_typec: Register partner PDOs") Suggested-by: Andrei Kuchynski Co-developed-by: Kaixuan Li Signed-off-by: Kaixuan Li Signed-off-by: Maoyi Xie Reviewed-by: Benson Leung Reviewed-by: Andrei Kuchynski Link: https://lore.kernel.org/r/20260625130056.3378097-1-maoyixie.tju@gmail.com Signed-off-by: Tzung-Bi Shih

platform/chrome: of_hw_prober: Use dumb trackpad prober for Spherion

2026-06-29T02:59:02+00:00

The trackpad power supply on Spherion is the system common 3.3V power rail. This is always on as long as the main processor is running. Switch to the dumb trackpad prober since it does not need to manage the power rail. Signed-off-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20260625060859.1020483-1-wenst@chromium.org Signed-off-by: Tzung-Bi Shih

platform/chrome: Drop unused assignment of platform_device_id driver data

2026-06-29T02:52:38+00:00

The drivers explicitly set the .driver_data member of struct platform_device_id to zero without relying on that value. Drop these unused assignments. While touching these arrays use a single space in the list terminator consistently. Signed-off-by: Uwe Kleine-König (The Capable Hub) Link: https://lore.kernel.org/r/5b72bac661bdf1c874bea4b91ce3c2eccc84bba1.1781690554.git.u.kleine-koenig@baylibre.com Signed-off-by: Tzung-Bi Shih

platform/chrome: sensorhub: Bound the EC-reported sensor number

2026-06-29T02:47:59+00:00

Each EC FIFO event carries an 8-bit sensor number (in->sensor_num). cros_ec_sensorhub_ring_handler() validates the FIFO event count, the per-read count and the ring bound, but not the sensor number, which cros_ec_sensor_ring_process_event() then uses unchecked to index sensorhub->batch_state[] - allocated with only sensorhub->sensor_num entries. A sensor number of sensor_num or larger is an out-of-bounds read and write of batch_state[]. Validate the sensor number in the ring handler, where each event is read from the EC, and drop a malformed event before it is used. Fixes: 145d59baff59 ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas Link: https://lore.kernel.org/r/20260618-b4-disp-adb3f790-v3-1-3a164ed63cbd@proton.me Signed-off-by: Tzung-Bi Shih

platform/chrome: Prevent build for big-endian systems

2026-06-02T03:14:10+00:00

Both ARM and ARM64 which are a dependency for CHROME_PLATFORMS have seldomly used big-endian variants. The ChromeOS EC framework and drivers are written under the assumption that they will be running on a little-endian systems. Code which would be broken on big-endian can be found trivially. Some examples: cros_ec.c: suspend_params.sleep_timeout_ms = ec_dev->suspend_timeout_ms cros_ec_debugfs.c: resp->time_since_ec_boot_ms cros_ec_wdt.c: arg.req.reboot_timeout_sec = wdd->timeout Prevent the build for big-endian systems. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20260531-cros-big-endian-v1-2-0cc90f39c636@weissschuh.net Signed-off-by: Tzung-Bi Shih

platform/chrome: Remove superfluous dependencies from CROS_EC

2026-06-02T03:14:10+00:00

CROS_EC depends on CHROME_PLATFORMS which already declares these dependencies. Remove the duplication. Signed-off-by: Thomas Weißschuh Link: https://lore.kernel.org/r/20260531-cros-big-endian-v1-1-0cc90f39c636@weissschuh.net Signed-off-by: Tzung-Bi Shih

platform/chrome: cros_ec_chardev: Introduce rwsem for protecting ec_dev

2026-05-28T04:27:03+00:00

Introduce a rwsem for protecting `ec_dev` to prevent Use-After-Free on the `ec_dev`. - Writers: In driver's probe() and remove(). - Readers: In file operations. Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20260525052654.4076429-5-tzungbi@kernel.org Signed-off-by: Tzung-Bi Shih