On Fri, Aug 29, 2025 at 11:28:55AM +0000, Dmitry Torokhov wrote:

On Thu, Aug 28, 2025 at 08:35:56AM +0000, Tzung-Bi Shih wrote:

quoted

A race is observed when cros_ec_lpc and cros-ec-keyb are all built as
modules.  cros_ec_lpc is cros-ec-keyb's parent.  However, they can be
probed at the same time.

Example:

+ -----------------------------------------------------------------+
| Some init process (e.g. udevd) | deferred_probe_work_func worker |
+ -----------------------------------------------------------------+
| Probe cros-ec-keyb.            |                                 |
| - Decide to defer[1].          |                                 |
|                                | A device bound to a driver[2].  |
| Probe cros_ec_lpc.             |                                 |
| - Init the struct[3].          |                                 |
|                                | Retry cros-ec-keyb from the     |
|                                | deferred list[4].               |
|                                | - Won't defer again as [3].     |
|                                | - Access uninitialized data in  |
|                                |   the struct.                   |
| - Register the device.         |                                 |
+ -----------------------------------------------------------------+

[1] https://elixir.bootlin.com/linux/v6.16/source/drivers/input/keyboard/cros_ec_keyb.c#L707
[2] https://elixir.bootlin.com/linux/v6.16/source/drivers/base/dd.c#L405
[3] https://elixir.bootlin.com/linux/v6.16/source/drivers/platform/chrome/cros_ec_lpc.c#L644
[4] https://elixir.bootlin.com/linux/v6.16/source/drivers/base/dd.c#L418

Note that the device link[5] can't help as in the observed environment,
the devices are already added via device_add()[6].

[5] https://www.kernel.org/doc/html/latest/driver-api/device_link.html#usage
[6] https://elixir.bootlin.com/linux/v6.16/source/drivers/acpi/acpi_platform.c#L177

The series fixes the issue by ensuring the struct is ready for accessing
before continuing to probe cros-ec-keyb.

Why is the keyboard platform device instantiated before the transport
(cros_ec_lpc) is done initializing? I think this is the root of the
issue...

I may misunderstand but it seems to me:

- The ACPI bus enumerated and instantiated the platform devices[6] first.

- The keyboard platform device was probed when `cros_ec_keyb_driver`
  registered.  It deferred as its parent's drvdata was NULL[1].

- The transport platform device was probed when `cros_ec_lpc_driver`
  registered.  It set the drvdata[3].

- The keyboard platform device was probed again from retrying the deferred
  list, by another thread `deferred_probe_work_func`.  The parent's drvdata
  wasn't NULL and cros_ec_register() for the transport device weren't
  finished.  The race happened.