All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Benson Leung <bleung@chromium.org>
Cc: tzungbi@kernel.org, linux-input@vger.kernel.org,
	chrome-platform@lists.linux.dev
Subject: [PATCH 0/5] platform/chrome: Fix a race when probing drivers
Date: Thu, 28 Aug 2025 08:35:56 +0000	[thread overview]
Message-ID: <20250828083601.856083-1-tzungbi@kernel.org> (raw)

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.

The 1st - 3rd patches are preparatory steps to allow the per-device lock
can be used even if the struct cros_ec_device is unregistered.

The 4th patch introduces a new flag `registered` and use the lock for
protecting the flag.

The 5th patch defers probe if the struct cros_ec_device is not ready yet.

Tzung-Bi Shih (5):
  platform/chrome: Centralize cros_ec_device allocation
  platform/chrome: Centralize common cros_ec_device initialization
  platform/chrome: cros_ec: Separate initialization from
    cros_ec_register()
  platform/chrome: cros_ec: Add a flag to track registration state
  Input: cros_ec_keyb - Defer probe until parent EC device is registered

 drivers/input/keyboard/cros_ec_keyb.c       |  6 ++
 drivers/platform/chrome/cros_ec.c           | 85 ++++++++++++++-------
 drivers/platform/chrome/cros_ec.h           |  3 +
 drivers/platform/chrome/cros_ec_i2c.c       |  9 +--
 drivers/platform/chrome/cros_ec_ishtp.c     |  6 +-
 drivers/platform/chrome/cros_ec_lpc.c       |  6 +-
 drivers/platform/chrome/cros_ec_proto.c     | 15 ++++
 drivers/platform/chrome/cros_ec_rpmsg.c     |  6 +-
 drivers/platform/chrome/cros_ec_spi.c       |  7 +-
 drivers/platform/chrome/cros_ec_uart.c      |  6 +-
 include/linux/platform_data/cros_ec_proto.h | 18 ++++-
 11 files changed, 103 insertions(+), 64 deletions(-)

-- 
2.51.0.268.g9569e192d0-goog


             reply	other threads:[~2025-08-28  8:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-28  8:35 Tzung-Bi Shih [this message]
2025-08-28  8:35 ` [PATCH 1/5] platform/chrome: Centralize cros_ec_device allocation Tzung-Bi Shih
2025-08-28  8:35 ` [PATCH 2/5] platform/chrome: Centralize common cros_ec_device initialization Tzung-Bi Shih
2025-08-28  8:35 ` [PATCH 3/5] platform/chrome: cros_ec: Separate initialization from cros_ec_register() Tzung-Bi Shih
2025-08-28  8:36 ` [PATCH 4/5] platform/chrome: cros_ec: Add a flag to track registration state Tzung-Bi Shih
2025-08-28  8:36 ` [PATCH 5/5] Input: cros_ec_keyb - Defer probe until parent EC device is registered Tzung-Bi Shih
2025-09-14  1:06   ` Dmitry Torokhov
2025-08-29 11:28 ` [PATCH 0/5] platform/chrome: Fix a race when probing drivers Dmitry Torokhov
2025-08-29 12:50   ` Tzung-Bi Shih
2025-09-02 13:18     ` Tzung-Bi Shih
2025-09-04 14:06       ` Dmitry Torokhov
2025-09-05  8:38         ` Tzung-Bi Shih
2025-09-14  1:08           ` Dmitry Torokhov
2025-09-14  3:26             ` Tzung-Bi Shih
2025-09-14  3:47 ` Tzung-Bi Shih

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250828083601.856083-1-tzungbi@kernel.org \
    --to=tzungbi@kernel.org \
    --cc=bleung@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.