[PATCH] platform/chrome: cros_usbpd_notify: Don't use a non-EC parent's drvdata

[PATCH] platform/chrome: cros_usbpd_notify: Don't use a non-EC parent's drvdata

[Sergey Tiraspolsky]

cros_usbpd_notify_probe_acpi() takes the parent's driver data as the
struct cros_ec_device to talk to. Only the Chrome EC (GOOG0004) stores
one there. On older devices without the updated device hierarchy,
GOOG0003 is a child of the ACPI EC (PNP0C09) instead, as on the 2017
Pixelbook (Eve), and the driver relied on the parent's driver data
being NULL to fall back to sending a 0 event.

Since commit db65a06d10b3 ("ACPI: EC: Convert the driver to a platform
one"), the ACPI EC's platform device stores its struct acpi_ec as driver
data, so on those devices the probe treats a struct acpi_ec as a struct
cros_ec_device. The "Couldn't get Chrome EC device pointer" warning is
no longer printed, and every USB PD notification, e.g. on resume or
charger plug, oopses:

  BUG: unable to handle page fault for address: ffffffff96103220
  Oops: Oops: 0002 [#1] SMP PTI
  Workqueue: kacpi_notify acpi_os_execute_deferred
  RIP: 0010:native_queued_spin_lock_slowpath+0x29d/0x330
  Call Trace:
   _raw_spin_lock_irqsave+0x59/0x80
   cros_ec_cmd_xfer+0x2a/0xf0 [cros_ec_proto]
   cros_ec_cmd_xfer_status+0x1a/0x90 [cros_ec_proto]
   cros_ec_cmd+0xb7/0x140 [cros_ec_proto]
   cros_usbpd_get_event_and_notify+0x42/0xc0 [cros_usbpd_notify]
   acpi_ev_notify_dispatch+0x4e/0x70

When it happens during resume, the machine stays on a black screen.

Only use the parent's driver data when the parent is GOOG0004, as the
probe already does when deciding whether to defer, and continue without
an EC device pointer otherwise.

The root cause was found from the oops logs, and this change and its
changelog were written, with the help of an AI coding assistant. I
reviewed both and tested the fix on the affected hardware.

Fixes: db65a06d10b3 ("ACPI: EC: Convert the driver to a platform one")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Sergey Tiraspolsky <stiraspo@gmail.com>
---

Notes:
    Tested on a 2017 Google Pixelbook (Eve), where GOOG0003 is a child of
    PNP0C09, on 7.2.5 (Arch-based distro kernel; none of its patches touch
    drivers/platform/chrome or drivers/acpi/ec.c), building this change as
    an out-of-tree module:
    
     - without the patch: four oopses with the trace above in the logs, one
       3 seconds after resume, and lid-close suspends that never resumed
     - with the patch: the probe prints "Couldn't get Chrome EC device
       pointer." again; a charger unplug/replug produced 9 USB PD
       notifications, all taking the "EC device inaccessible; sending 0
       event status" path; suspend with a charger unplug/replug while asleep
       resumed normally; no oopses
    
    Not tested: a device where GOOG0003 is a child of GOOG0004 (that path
    only moves into the if branch here, its logic is unchanged).

 drivers/platform/chrome/cros_usbpd_notify.c | 37 +++++++++++----------
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/platform/chrome/cros_usbpd_notify.c b/drivers/platform/chrome/cros_usbpd_notify.c
index 6f5eea4938..5657b93a6c 100644
--- a/drivers/platform/chrome/cros_usbpd_notify.c
+++ b/drivers/platform/chrome/cros_usbpd_notify.c
@@ -110,24 +110,25 @@ static int cros_usbpd_notify_probe_acpi(struct platform_device *pdev)
 	if (!pdnotify)
 		return -ENOMEM;
 
-	/* Get the EC device pointer needed to talk to the EC. */
-	ec_dev = dev_get_drvdata(dev->parent);
-	if (!ec_dev) {
-		/*
-		 * We continue even for older devices which don't have the
-		 * correct device hierarchy, namely, GOOG0003 is a child
-		 * of GOOG0004. If GOOG0003 is a child of GOOG0004 and we
-		 * can't get a pointer to the Chrome EC device, defer the
-		 * probe function.
-		 */
-		parent_fwnode = fwnode_get_parent(dev->fwnode);
-		if (parent_fwnode) {
-			parent_adev = to_acpi_device_node(parent_fwnode);
-			if (parent_adev &&
-			    acpi_dev_hid_match(parent_adev, CREC_DRV_NAME)) {
-				return -EPROBE_DEFER;
-			}
-		}
+	/*
+	 * Get the EC device pointer needed to talk to the EC. Only the Chrome
+	 * EC (GOOG0004) stores a struct cros_ec_device as its driver data, so
+	 * only use the parent's driver data when GOOG0003 is a child of
+	 * GOOG0004, and defer the probe until that driver has bound.
+	 *
+	 * We continue without the pointer for older devices which don't have
+	 * the correct device hierarchy. There GOOG0003 is a child of another
+	 * device, such as the ACPI EC (PNP0C09), whose driver data is not a
+	 * struct cros_ec_device.
+	 */
+	parent_fwnode = fwnode_get_parent(dev->fwnode);
+	parent_adev = to_acpi_device_node(parent_fwnode);
+	if (parent_adev && acpi_dev_hid_match(parent_adev, CREC_DRV_NAME)) {
+		ec_dev = dev_get_drvdata(dev->parent);
+		if (!ec_dev)
+			return -EPROBE_DEFER;
+	} else {
+		ec_dev = NULL;
 		dev_warn(dev, "Couldn't get Chrome EC device pointer.\n");
 	}
 
-- 
2.55.0

Re: [PATCH] platform/chrome: cros_usbpd_notify: Don't use a non-EC parent's drvdata

[Tzung-Bi Shih]

On Sat, Oct 03, 2026 at 01:46:23PM -0700, Sergey Tiraspolsky wrote:
> Notes:
>     Tested on a 2017 Google Pixelbook (Eve), where GOOG0003 is a child of
>     PNP0C09, on 7.2.5 (Arch-based distro kernel; none of its patches touch
>     drivers/platform/chrome or drivers/acpi/ec.c), building this change as
>     an out-of-tree module:
>     
>      - without the patch: four oopses with the trace above in the logs, one
>        3 seconds after resume, and lid-close suspends that never resumed
>      - with the patch: the probe prints "Couldn't get Chrome EC device
>        pointer." again; a charger unplug/replug produced 9 USB PD
>        notifications, all taking the "EC device inaccessible; sending 0
>        event status" path; suspend with a charger unplug/replug while asleep
>        resumed normally; no oopses
>     
>     Not tested: a device where GOOG0003 is a child of GOOG0004 (that path
>     only moves into the if branch here, its logic is unchanged).

Hi Sergey,

Thanks for looking into this.

Coincidentally, James Fairweather ran into the same issue on a Nami
Chromebook and submitted a patch shortly after yours [1].

The patch [1] addresses the same crash, but also fixes an existing firmware
node reference leak by calling fwnode_handle_put() on the handle returned by
fwnode_get_parent().

Because of the additional leak fix, I plan to proceed with James's patch.
To ensure your earlier report and testing on Eve are properly credited, I'll
add your "Reported-by" tag when applying the patch.

If you have a chance to test James's patch on your Pixelbook (Eve) and reply
with a Tested-by tag to [1], that would be greatly appreciated.

[1] https://lore.kernel.org/all/20261003222855.23707-1-james.a.fairweather@gmail.com/