All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Agazaryan <samagazaryan@google.com>
To: linux-i3c@lists.infradead.org
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Frank Li <Frank.Li@nxp.com>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	 Vitor Soares <vitor.soares@toradex.com>,
	 Oleksandr Shulzhenko
	<oleksandr.shulzhenko.viktorovych@intel.com>,
	linux-kernel@vger.kernel.org,
	 Sam Agazaryan <samagazaryan@google.com>
Subject: [PATCH v4 0/3] i3c: Introduce i3c device userspace interface
Date: Sun,  6 Sep 2026 20:27:44 +0000	[thread overview]
Message-ID: <20260906202747.4041389-1-samagazaryan@google.com> (raw)

This series revives the I3C userspace character device interface (i3cdev),
originally proposed by Vitor Soares in 2019/2020 [1][2].

1. Motivation & Production Use Case:
Previously, one of the reservations against introducing an i3cdev module
was the lack of a standardized production userspace use case beyond
controller development and bringup.

We now have a standardized industry use case: the OCP Secure Firmware
Recovery Specification (v1.1) and Open-Source Silicon Root of Trust
(Caliptra) recovery flows over I3C. When an I3C target device (SoC, ASIC,
or SRoT) is held in ROM or bootloader recovery mode, no functional
in-kernel driver is bound to the target. A userspace recovery daemon on
the BMC must perform private SDR transfers to interact with Recovery
Control & Status Registers (CSRs) and stream recovery firmware images.

Exposing an interface modeled after i2c-dev/spidev allows userspace
recovery tools to operate directly on unbound I3C devices without
requiring rigid or proprietary in-kernel recovery drivers.

2. Changes since v3 (Feb 2020):
- Rebased onto upstream i3c/next and adapted to the unified i3c_xfer API
  (replacing deprecated i3c_priv_xfer / i3c_device_do_priv_xfers with
  i3c_xfer / i3c_device_do_xfers(..., I3C_SDR)).
- Addressed UAPI structure feedback from Greg KH and Arnd Bergmann:
  * Used explicit __u64 for user data buffer addresses.
  * Added fixed-width explicit padding to ensure consistent 32-bit /
    64-bit ABI alignment.
- Wired up .compat_ioctl = compat_ptr_ioctl in file_operations.
- Fixed device lifecycle and concurrency:
  * Switched to cdev_device_add() and cdev_device_del() with an embedded
    struct device and a release callback, preventing use-after-free and
    races on driver unbind/detach (incorporating fix from Oleksandr
    Shulzhenko).
  * Cleared i3cdev->i3c under xfer_lock on detach so concurrent/subsequent
    file operations safely return -ENODEV.
- Fixed read transfer buffer allocation:
  * Replaced unconditional memdup_user() with kzalloc() for read
    transfers (rnw == true), avoiding copying uninitialized userspace
    memory into the kernel buffer.
- Fixed mutex leak in i3cdev_read() and i3cdev_write() error paths.
- Switched to static const struct class with class_register().
- Switched minor number allocation to the IDA allocator.
- Added include/uapi/linux/i3c/ to MAINTAINERS under I3C SUBSYSTEM.

[1] https://lore.kernel.org/all/cover.1575977795.git.vitor.soares@synopsys.com/
[2] https://github.com/vitor-soares-snps/i3c-tools

Vitor Soares (3):
  i3c: master: export i3c_masterdev_type
  i3c: master: add i3c_for_each_dev helper
  i3c: add i3cdev module to expose i3c dev in /dev

 MAINTAINERS                     |   1 +
 drivers/i3c/Kconfig             |  11 +
 drivers/i3c/Makefile            |   1 +
 drivers/i3c/i3cdev.c            | 445 ++++++++++++++++++++++++++++++++
 drivers/i3c/internals.h         |   4 +
 drivers/i3c/master.c            |  15 +-
 include/uapi/linux/i3c/i3cdev.h |  37 +++
 7 files changed, 513 insertions(+), 1 deletion(-)
 create mode 100644 drivers/i3c/i3cdev.c
 create mode 100644 include/uapi/linux/i3c/i3cdev.h

-- 
2.55.0.979.g7e5102b832-goog


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

             reply	other threads:[~2026-09-06 20:29 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-06 20:27 Sam Agazaryan [this message]
2026-09-06 20:27 ` [PATCH v4 1/3] i3c: master: export i3c_masterdev_type Sam Agazaryan
2026-09-06 20:27 ` [PATCH v4 2/3] i3c: master: add i3c_for_each_dev helper Sam Agazaryan
2026-09-06 20:40   ` sashiko-bot
2026-09-06 20:27 ` [PATCH v4 3/3] i3c: add i3cdev module to expose i3c dev in /dev Sam Agazaryan
2026-09-06 20:41   ` sashiko-bot
2026-09-07 14:40   ` Greg Kroah-Hartman
2026-09-09  6:13     ` Sam Agazaryan
2026-09-09 21:51   ` Frank Li
2026-09-11  3:44     ` Sam Agazaryan
2026-09-11 15:10       ` Frank Li
2026-09-11 23:57         ` Sam Agazaryan
2026-09-11 19:03       ` Adrian Hunter
2026-09-14 23:46         ` Sam Agazaryan
2026-09-15  9:49           ` Adrian Hunter
2026-09-15 21:26             ` Sam Agazaryan
2026-09-11 22:05   ` Meagan Lloyd
2026-09-12  0:12     ` Sam Agazaryan
2026-09-17 22:27       ` Meagan Lloyd
2026-09-18 18:59         ` Meagan Lloyd
2026-09-18 20:21           ` Greg Kroah-Hartman
2026-09-18 22:47           ` Sam Agazaryan
2026-09-08 11:48 ` [PATCH v4 0/3] i3c: Introduce i3c device userspace interface Wolfram Sang
2026-09-12 11:12 ` Wolfram Sang
2026-09-14 20:58   ` Sam Agazaryan

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=20260906202747.4041389-1-samagazaryan@google.com \
    --to=samagazaryan@google.com \
    --cc=Frank.Li@nxp.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleksandr.shulzhenko.viktorovych@intel.com \
    --cc=vitor.soares@toradex.com \
    /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.