public inbox for chrome-platform@lists.linux.dev
 help / color / mirror / Atom feed
From: Tzung-Bi Shih <tzungbi@kernel.org>
To: bleung@chromium.org, brendan.higgins@linux.dev, davidgow@google.com
Cc: tzungbi@kernel.org, rmoar@google.com, rostedt@goodmis.org,
	mhiramat@kernel.org, naveen@kernel.org,
	anil.s.keshavamurthy@intel.com, davem@davemloft.net,
	chrome-platform@lists.linux.dev, linux-kselftest@vger.kernel.org,
	kunit-dev@googlegroups.com, linux-trace-kernel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [RFC PATCH 0/7] platform/chrome: Add Kunit tests for protocol device drivers
Date: Tue, 20 May 2025 08:24:27 +0000	[thread overview]
Message-ID: <20250520082435.2255639-1-tzungbi@kernel.org> (raw)

The protocol device drivers under drivers/platform/chrome/ are responsible
to communicate to the ChromeOS EC (Embedded Controller).  They need to pack
the data in a pre-defined format and check if the EC responds accordingly.

The series adds some fundamental unit tests for the protocol.  It calls the
.cmd_xfer() and .pkt_xfer() callbacks (which are the most crucial parts for
the protocol), mocks the rest of the system, and checks if the interactions
are all correct.

The series isn't ready for landing.  It's more like a PoC for the
binary-level function redirection and its use cases.

The 1st patch adds ftrace stub which is originally from [1][2].  There is no
follow-up discussion about the ftrace stub.  As a result, the patch is still
on the mailing list.

The 2nd patch adds Kunit tests for cros_ec_i2c.  It relies on the ftrace stub
for redirecting cros_ec_{un,}register().

The 3rd patch uses static stub instead (if ftrace stub isn't really an option).
However, I'm not a big fan to change the production code (i.e. adding the
prologue in cros_ec_{un,}register()) for testing.

The 4th patch adds Kunit tests for cros_ec_spi.  It relies on the ftrace stub
for redirecting cros_ec_{un,}register() again.

The 5th patch calls .probe() directly instead of forcing the driver probe
needs to be synchronous.  In comparison with the 4th patch, I don't think
this is simpler.  I'd prefer to the way in the 4th patch.

After talked to Masami about the work, he suggested to use Kprobes for
function redirection.  The 6th patch adds kprobes stub.

The 7th patch uses kprobes stub instead for cros_ec_spi.

Questions:
- Are we going to support ftrace stub so that tests can use it?

- If ftrace stub isn't on the plate (e.g. due to too many dependencies), how
  about the kprobes stub?  Is it something we could pursue?

- (minor) I'm unsure if people would prefer 'kprobes stub' vs. 'kprobe stub'.

[1]: https://kunit.dev/mocking.html#binary-level-ftrace-et-al
[2]: https://lore.kernel.org/linux-kselftest/20220318021314.3225240-3-davidgow@google.com/

Daniel Latypov (1):
  kunit: expose ftrace-based API for stubbing out functions during tests

Tzung-Bi Shih (6):
  platform/chrome: kunit: cros_ec_i2c: Add tests with ftrace stub
  platform/chrome: kunit: cros_ec_i2c: Use static stub instead
  platform/chrome: kunit: cros_ec_spi: Add tests with ftrace stub
  platform/chrome: kunit: cros_ec_spi: Call .probe() directly
  kunit: Expose 'kprobes stub' API to redirect functions
  platform/chrome: kunit: cros_ec_spi: Use kprobes stub instead

 drivers/platform/chrome/Kconfig            |  17 +
 drivers/platform/chrome/Makefile           |   2 +
 drivers/platform/chrome/cros_ec.c          |   6 +
 drivers/platform/chrome/cros_ec_i2c_test.c | 479 +++++++++++++++++++++
 drivers/platform/chrome/cros_ec_spi_test.c | 355 +++++++++++++++
 include/kunit/ftrace_stub.h                |  84 ++++
 include/kunit/kprobes_stub.h               |  19 +
 kernel/trace/ftrace.c                      |   3 +
 lib/kunit/Kconfig                          |  18 +
 lib/kunit/Makefile                         |   8 +
 lib/kunit/ftrace_stub.c                    | 139 ++++++
 lib/kunit/kprobes_stub.c                   | 113 +++++
 lib/kunit/kunit-example-test.c             |  27 +-
 lib/kunit/stubs_example.kunitconfig        |  11 +
 14 files changed, 1280 insertions(+), 1 deletion(-)
 create mode 100644 drivers/platform/chrome/cros_ec_i2c_test.c
 create mode 100644 drivers/platform/chrome/cros_ec_spi_test.c
 create mode 100644 include/kunit/ftrace_stub.h
 create mode 100644 include/kunit/kprobes_stub.h
 create mode 100644 lib/kunit/ftrace_stub.c
 create mode 100644 lib/kunit/kprobes_stub.c
 create mode 100644 lib/kunit/stubs_example.kunitconfig

-- 
2.49.0.1101.gccaa498523-goog


             reply	other threads:[~2025-05-20  8:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-20  8:24 Tzung-Bi Shih [this message]
2025-05-20  8:24 ` [RFC PATCH 1/7] kunit: expose ftrace-based API for stubbing out functions during tests Tzung-Bi Shih
2025-05-20  8:24 ` [RFC PATCH 2/7] platform/chrome: kunit: cros_ec_i2c: Add tests with ftrace stub Tzung-Bi Shih
2025-05-20  8:24 ` [RFC PATCH 3/7] platform/chrome: kunit: cros_ec_i2c: Use static stub instead Tzung-Bi Shih
2025-05-20  8:24 ` [RFC PATCH 4/7] platform/chrome: kunit: cros_ec_spi: Add tests with ftrace stub Tzung-Bi Shih
2025-05-20  8:24 ` [RFC PATCH 5/7] platform/chrome: kunit: cros_ec_spi: Call .probe() directly Tzung-Bi Shih
2025-05-20  8:24 ` [RFC PATCH 6/7] kunit: Expose 'kprobes stub' API to redirect functions Tzung-Bi Shih
2025-05-20  8:24 ` [RFC PATCH 7/7] platform/chrome: kunit: cros_ec_spi: Use kprobes stub instead Tzung-Bi Shih
2025-05-20 16:04 ` [RFC PATCH 0/7] platform/chrome: Add Kunit tests for protocol device drivers Daniel Latypov
2025-06-30  6:32   ` Tzung-Bi Shih
2025-07-01  5:22     ` Daniel Latypov
2025-07-01 12:20       ` 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=20250520082435.2255639-1-tzungbi@kernel.org \
    --to=tzungbi@kernel.org \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=bleung@chromium.org \
    --cc=brendan.higgins@linux.dev \
    --cc=chrome-platform@lists.linux.dev \
    --cc=davem@davemloft.net \
    --cc=davidgow@google.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=naveen@kernel.org \
    --cc=rmoar@google.com \
    --cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox