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

> [2] https://github.com/vitor-soares-snps/i3c-tools

An idea: because this project only contains 'i3ctransfer' at the moment,
it probably makes sense to provide this tool with the Kernel, placed in
the 'tools' directory? We can seperate it again if it becomes too big or
we want its own community there. But for now, I think it could make
sense unless you want to maintain this repo as well?

Happy hacking!

> An idea: because this project only contains 'i3ctransfer' at the moment,
> it probably makes sense to provide this tool with the Kernel, placed in
> the 'tools' directory? We can seperate it again if it becomes too big or
> we want its own community there. But for now, I think it could make
> sense unless you want to maintain this repo as well?

I think this is pretty reasonable. I can incorporate i3c-tools in a
new revision of this changeset as well (Given all the input, a new
revision will surely be coming).

Thanks,
Sam

> - 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.

I haven't looked at the code (and won't have the time to do so), but if
the above paragraph had not been present, I would have nacked the series
right away. To say it positive: Kudos for working on these issues!