[PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

This patch series introduces the i3cdev module, exposing unbound I3C
target devices to userspace via character device nodes (/dev/bus/i3c/*),
along with the i3ctransfer userspace utility in tools/i3c/.

Userspace access to I3C targets is needed for devices that do not have a
kernel driver bound to them, such as targets in ROM/bootloader recovery
mode (e.g., OCP Secure Firmware Recovery v1.1 and Caliptra Silicon Root of
Trust recovery flows), as well as hardware bring-up and diagnostics.

When a kernel driver later binds to an I3C device (for example via
dynamic module loading), i3cdev automatically detaches via the
BUS_NOTIFY_BIND_DRIVER notifier so kernel drivers always take
precedence.

Testing status:
This v5 series has been compile-tested across all modified I3C controller
drivers with W=1. Posting v5 now so collaborators and controller owners
can test the unified UAPI and actual_len updates on their respective
hardware and provide Tested-by tags while we complete final hardware
verification of the v5 updates on our platform.

Changes in v5:
- Updated Patch 2/5 ("i3c: master: add i3c_for_each_dev helper"):
  - Dropped mutex_lock(&i3c_core_lock) around bus_for_each_dev() to avoid
    lock inversion and deadlock with external callbacks (sashiko-bot).
- Added Patch 3/5 ("i3c: use actual_len for read transfers"):
  - Clarified @actual_len kerneldoc in <linux/i3c/device.h>
    (Adrian Hunter).
  - Incorporated Meagan Lloyd's controller updates (adi, dw, cdns,
    mipi-i3c-hci, renesas) so all I3C controller drivers populate
    xfer->actual_len on reads without mutating xfer->len
    (Adrian Hunter, Meagan Lloyd).
  - Updated mctp-i3c to read xfer.actual_len instead of xfer.len
    (Adrian Hunter).
- Updated Patch 4/5 ("i3c: add i3cdev module to expose i3c dev in /dev"):
  - Unified the UAPI around struct i3c_ioc_xfer and I3C_IOC_XFER(N) in
    <uapi/linux/i3c/i3cdev.h>, supporting both SDR and HDR modes via a
    mode field and union { __u8 rnw; __u8 cmd; } (Frank Li).
  - Added __u16 actual_len to struct i3c_ioc_xfer and updated
    i3cdev_do_xfer() to copy actual_len bytes to userspace and write
    actual_len back to userspace via put_user() on read transfers
    (Adrian Hunter, Frank Li).
  - Tracked active i3cdev instances in a private list (i3cdev_list)
    instead of using i3cdev_set_drvdata()/i3cdev_get_drvdata() so i3cdev
    never clobbers client drivers' dev->driver_data (Meagan Lloyd).
  - Validated direction field and verified that reserved padding pad[2] is
    zeroed (Greg KH).
  - Clamped read()/write() byte count to type_max(xfers.len) (u16) to
    prevent silent integer truncation and unbounded kernel allocations
    (sashiko-bot).
  - Used ida_alloc_max() capped to MINORMASK to prevent minor number
    overflow (sashiko-bot).
  - Added i3cdev_attach_lock mutex and idempotency check in
    i3cdev_attach()/i3cdev_detach() to serialize concurrent attach/detach
    calls (sashiko-bot).
  - Updated bus notifier to handle BUS_NOTIFY_DRIVER_NOT_BOUND and return
    NOTIFY_OK instead of raw errno values (sashiko-bot).
- Added Patch 5/5 ("tools: i3c: add i3ctransfer utility"):
  - Added tools/i3c/i3ctransfer.c (adapted from Vitor Soares's
    i3c-tools) updated for struct i3c_ioc_xfer, supporting SDR and HDR
    (-m, -c) modes and reporting actual_len bytes on reads
    (Wolfram Sang).
  - Note to Vitor Soares: Since your original i3ctransfer commit in
    i3c-tools did not include a Signed-off-by tag, could you please
    reply with your Signed-off-by / Acked-by for Patch 5/5?

Changes in v4:
- Dropped dev_open count tracking and used cdev_device_add/del with
  mutex locking to prevent use-after-free on detach
  (Greg KH, Wolfram Sang).
- Fixed 32/64-bit UAPI alignment and added compat_ptr_ioctl.
- Switched to dynamic minor allocation via IDA.

Sam Agazaryan (2):
  i3c: use actual_len for read transfers
  tools: i3c: add i3ctransfer utility

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                            |   2 +
 drivers/i3c/Kconfig                    |  11 +
 drivers/i3c/Makefile                   |   1 +
 drivers/i3c/i3cdev.c                   | 491 +++++++++++++++++++++++++
 drivers/i3c/internals.h                |   4 +
 drivers/i3c/master.c                   |   9 +-
 drivers/i3c/master/adi-i3c-master.c    |   5 +-
 drivers/i3c/master/dw-i3c-master.c     |   2 +-
 drivers/i3c/master/i3c-master-cdns.c   |   5 +-
 drivers/i3c/master/mipi-i3c-hci/core.c |   2 +-
 drivers/i3c/master/renesas-i3c.c       |   3 +
 drivers/net/mctp/mctp-i3c.c            |  10 +-
 include/linux/i3c/device.h             |   2 +-
 include/uapi/linux/i3c/i3cdev.h        |  57 +++
 tools/Makefile                         |  13 +-
 tools/i3c/Build                        |   1 +
 tools/i3c/Makefile                     |  58 +++
 tools/i3c/i3ctransfer.c                | 307 ++++++++++++++++
 18 files changed, 966 insertions(+), 17 deletions(-)
 create mode 100644 drivers/i3c/i3cdev.c
 create mode 100644 include/uapi/linux/i3c/i3cdev.h
 create mode 100644 tools/i3c/Build
 create mode 100644 tools/i3c/Makefile
 create mode 100644 tools/i3c/i3ctransfer.c

-- 
2.55.0.1082.g2b9226bbc0-goog



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

[PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

This patch series introduces the i3cdev module, exposing unbound I3C
target devices to userspace via character device nodes (/dev/bus/i3c/*),
along with the i3ctransfer userspace utility in tools/i3c/.

Userspace access to I3C targets is needed for devices that do not have a
kernel driver bound to them, such as targets in ROM/bootloader recovery
mode (e.g., OCP Secure Firmware Recovery v1.1 and Caliptra Silicon Root of
Trust recovery flows), as well as hardware bring-up and diagnostics.

When a kernel driver later binds to an I3C device (for example via
dynamic module loading), i3cdev automatically detaches via the
BUS_NOTIFY_BIND_DRIVER notifier so kernel drivers always take
precedence.

Testing status:
This v5 series has been compile-tested across all modified I3C controller
drivers with W=1. Posting v5 now so collaborators and controller owners
can test the unified UAPI and actual_len updates on their respective
hardware and provide Tested-by tags while we complete final hardware
verification of the v5 updates on our platform.

Changes in v5:
- Updated Patch 2/5 ("i3c: master: add i3c_for_each_dev helper"):
  - Dropped mutex_lock(&i3c_core_lock) around bus_for_each_dev() to avoid
    lock inversion and deadlock with external callbacks (sashiko-bot).
- Added Patch 3/5 ("i3c: use actual_len for read transfers"):
  - Clarified @actual_len kerneldoc in <linux/i3c/device.h>
    (Adrian Hunter).
  - Incorporated Meagan Lloyd's controller updates (adi, dw, cdns,
    mipi-i3c-hci, renesas) so all I3C controller drivers populate
    xfer->actual_len on reads without mutating xfer->len
    (Adrian Hunter, Meagan Lloyd).
  - Updated mctp-i3c to read xfer.actual_len instead of xfer.len
    (Adrian Hunter).
- Updated Patch 4/5 ("i3c: add i3cdev module to expose i3c dev in /dev"):
  - Unified the UAPI around struct i3c_ioc_xfer and I3C_IOC_XFER(N) in
    <uapi/linux/i3c/i3cdev.h>, supporting both SDR and HDR modes via a
    mode field and union { __u8 rnw; __u8 cmd; } (Frank Li).
  - Added __u16 actual_len to struct i3c_ioc_xfer and updated
    i3cdev_do_xfer() to copy actual_len bytes to userspace and write
    actual_len back to userspace via put_user() on read transfers
    (Adrian Hunter, Frank Li).
  - Tracked active i3cdev instances in a private list (i3cdev_list)
    instead of using i3cdev_set_drvdata()/i3cdev_get_drvdata() so i3cdev
    never clobbers client drivers' dev->driver_data (Meagan Lloyd).
  - Validated direction field and verified that reserved padding pad[2] is
    zeroed (Greg KH).
  - Clamped read()/write() byte count to type_max(xfers.len) (u16) to
    prevent silent integer truncation and unbounded kernel allocations
    (sashiko-bot).
  - Used ida_alloc_max() capped to MINORMASK to prevent minor number
    overflow (sashiko-bot).
  - Added i3cdev_attach_lock mutex and idempotency check in
    i3cdev_attach()/i3cdev_detach() to serialize concurrent attach/detach
    calls (sashiko-bot).
  - Updated bus notifier to handle BUS_NOTIFY_DRIVER_NOT_BOUND and return
    NOTIFY_OK instead of raw errno values (sashiko-bot).
- Added Patch 5/5 ("tools: i3c: add i3ctransfer utility"):
  - Added tools/i3c/i3ctransfer.c (adapted from Vitor Soares's
    i3c-tools) updated for struct i3c_ioc_xfer, supporting SDR and HDR
    (-m, -c) modes and reporting actual_len bytes on reads
    (Wolfram Sang).
  - Note to Vitor Soares: Since your original i3ctransfer commit in
    i3c-tools did not include a Signed-off-by tag, could you please
    reply with your Signed-off-by / Acked-by for Patch 5/5?

Changes in v4:
- Dropped dev_open count tracking and used cdev_device_add/del with
  mutex locking to prevent use-after-free on detach
  (Greg KH, Wolfram Sang).
- Fixed 32/64-bit UAPI alignment and added compat_ptr_ioctl.
- Switched to dynamic minor allocation via IDA.

Sam Agazaryan (2):
  i3c: use actual_len for read transfers
  tools: i3c: add i3ctransfer utility

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                            |   2 +
 drivers/i3c/Kconfig                    |  11 +
 drivers/i3c/Makefile                   |   1 +
 drivers/i3c/i3cdev.c                   | 491 +++++++++++++++++++++++++
 drivers/i3c/internals.h                |   4 +
 drivers/i3c/master.c                   |   9 +-
 drivers/i3c/master/adi-i3c-master.c    |   5 +-
 drivers/i3c/master/dw-i3c-master.c     |   2 +-
 drivers/i3c/master/i3c-master-cdns.c   |   5 +-
 drivers/i3c/master/mipi-i3c-hci/core.c |   2 +-
 drivers/i3c/master/renesas-i3c.c       |   3 +
 drivers/net/mctp/mctp-i3c.c            |  10 +-
 include/linux/i3c/device.h             |   2 +-
 include/uapi/linux/i3c/i3cdev.h        |  57 +++
 tools/Makefile                         |  13 +-
 tools/i3c/Build                        |   1 +
 tools/i3c/Makefile                     |  58 +++
 tools/i3c/i3ctransfer.c                | 307 ++++++++++++++++
 18 files changed, 966 insertions(+), 17 deletions(-)
 create mode 100644 drivers/i3c/i3cdev.c
 create mode 100644 include/uapi/linux/i3c/i3cdev.h
 create mode 100644 tools/i3c/Build
 create mode 100644 tools/i3c/Makefile
 create mode 100644 tools/i3c/i3ctransfer.c

-- 
2.55.0.1082.g2b9226bbc0-goog

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Mon, Sep 21, 2026 at 11:05:58PM +0000, Sam Agazaryan wrote:
> This patch series introduces the i3cdev module, exposing unbound I3C
> target devices to userspace via character device nodes (/dev/bus/i3c/*),
> along with the i3ctransfer userspace utility in tools/i3c/.
> 
> Userspace access to I3C targets is needed for devices that do not have a
> kernel driver bound to them, such as targets in ROM/bootloader recovery
> mode (e.g., OCP Secure Firmware Recovery v1.1 and Caliptra Silicon Root of
> Trust recovery flows), as well as hardware bring-up and diagnostics.
> 
> When a kernel driver later binds to an I3C device (for example via
> dynamic module loading), i3cdev automatically detaches via the
> BUS_NOTIFY_BIND_DRIVER notifier so kernel drivers always take
> precedence.
> 
> Testing status:
> This v5 series has been compile-tested across all modified I3C controller
> drivers with W=1. Posting v5 now so collaborators and controller owners
> can test the unified UAPI and actual_len updates on their respective
> hardware and provide Tested-by tags while we complete final hardware
> verification of the v5 updates on our platform.

I do not know how we end up here. The not-settled yet discussion is in
thread with aqt_dCazxTDR4cpk@ashevche-desk.local.

But I have a big concern about exposing i3c to user space in the way we have it
in i2c. Taking into account that i2c is an odd bus and might lead even to HW
*physical* breakage, I would thing 100 times before making the same mistake
in i3c. If you ever want to do this, this must not be user visible feature
(hidden under expert and debug and maybe even more guards for the starter).

Personally from my perspective this is no go, but I'm not a maintainer here.

P.S.
And you need to gather the opinion of Wolfram as well.

-- 
With Best Regards,
Andy Shevchenko



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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Mon, Sep 21, 2026 at 11:05:58PM +0000, Sam Agazaryan wrote:
> This patch series introduces the i3cdev module, exposing unbound I3C
> target devices to userspace via character device nodes (/dev/bus/i3c/*),
> along with the i3ctransfer userspace utility in tools/i3c/.
> 
> Userspace access to I3C targets is needed for devices that do not have a
> kernel driver bound to them, such as targets in ROM/bootloader recovery
> mode (e.g., OCP Secure Firmware Recovery v1.1 and Caliptra Silicon Root of
> Trust recovery flows), as well as hardware bring-up and diagnostics.
> 
> When a kernel driver later binds to an I3C device (for example via
> dynamic module loading), i3cdev automatically detaches via the
> BUS_NOTIFY_BIND_DRIVER notifier so kernel drivers always take
> precedence.
> 
> Testing status:
> This v5 series has been compile-tested across all modified I3C controller
> drivers with W=1. Posting v5 now so collaborators and controller owners
> can test the unified UAPI and actual_len updates on their respective
> hardware and provide Tested-by tags while we complete final hardware
> verification of the v5 updates on our platform.

I do not know how we end up here. The not-settled yet discussion is in
thread with aqt_dCazxTDR4cpk@ashevche-desk.local.

But I have a big concern about exposing i3c to user space in the way we have it
in i2c. Taking into account that i2c is an odd bus and might lead even to HW
*physical* breakage, I would thing 100 times before making the same mistake
in i3c. If you ever want to do this, this must not be user visible feature
(hidden under expert and debug and maybe even more guards for the starter).

Personally from my perspective this is no go, but I'm not a maintainer here.

P.S.
And you need to gather the opinion of Wolfram as well.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Wolfram Sang]

Hi Andy,

> And you need to gather the opinion of Wolfram as well.

Dunno if I can help here. When it comes to driver development, a dev
interface is surely useful but can stay in some debug corner. However,
cover letter says:

>> Userspace access to I3C targets is needed for devices that do not have a
>> kernel driver bound to them, such as targets in ROM/bootloader recovery
>> mode (e.g., OCP Secure Firmware Recovery v1.1 and Caliptra Silicon Root of
>> Trust recovery flows), as well as hardware bring-up and diagnostics.

I don't know anything about these recovery mechanisms and their needs. I
might have time to look into I3C things after all the conferences in
Prague, but no promises...

Happy hacking,

   Wolfram


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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Wolfram Sang]

Hi Andy,

> And you need to gather the opinion of Wolfram as well.

Dunno if I can help here. When it comes to driver development, a dev
interface is surely useful but can stay in some debug corner. However,
cover letter says:

>> Userspace access to I3C targets is needed for devices that do not have a
>> kernel driver bound to them, such as targets in ROM/bootloader recovery
>> mode (e.g., OCP Secure Firmware Recovery v1.1 and Caliptra Silicon Root of
>> Trust recovery flows), as well as hardware bring-up and diagnostics.

I don't know anything about these recovery mechanisms and their needs. I
might have time to look into I3C things after all the conferences in
Prague, but no promises...

Happy hacking,

   Wolfram

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

Hey Wolfram and Andy,


Andy:

> I do not know how we end up here. The not-settled yet discussion is in
> thread with aqt_dCazxTDR4cpk@ashevche-desk.local.

There has been some back and forth but I originally uploaded this
patch set using
notifiers for binding looking for comments on the revival of a
potential upstream
i3cdev driver - Meagan had been working on a similar effort with i3cdev
using a different approach for binding and as of right now the bus notifier
approach seems to be more favored, but not approved nor decided on yet.

> But I have a big concern about exposing i3c to user space in the way we have it
> in i2c. Taking into account that i2c is an odd bus and might lead even to HW
> *physical* breakage, I would thing 100 times before making the same mistake
> in i3c. If you ever want to do this, this must not be user visible feature
> (hidden under expert and debug and maybe even more guards for the starter).
>

Just to make sure we're on the same page here about this - is your concern that
we can arbitrarily address any device on the i3c bus at-will as is the case
with i2c-dev?

FWIW, i3cdev as it exists in this patchset does not have as much free reign
over the i3c bus as i2c-dev does over an i2c bus:

1. i3cdev attaches to discrete target devices rather than exposing the
bus as a whole.
This means if I have 5 devices on my electrical bus that are up and operational
and 4 of them have a proper i3c driver to bind to (E.G. mctp-i3c) then
i3cdev will
not touch those devices, only the 5th device without a bound driver and
that would be via the i3cdev instance created specifically for that
device. A matching
kernel driver being found for a device later means i3cdev
automatically detaches itself
and makes way for a compatible client driver to bind.

2. Master controllers are also not a binding option for the driver, so
no free access to
send out arbitrary CCCs, perform bus scans, do DAA work, etc.

CONFIG_I3CDEV defaults to n and only creates root-owned character
devices for unbound targets, though if i3c maintainers prefer adding
"depends on EXPERT" or expanding the Kconfig help text, I am happy to do
that in v6.

Wolfram:

> >> Userspace access to I3C targets is needed for devices that do not have a
> >> kernel driver bound to them, such as targets in ROM/bootloader recovery
> >> mode (e.g., OCP Secure Firmware Recovery v1.1 and Caliptra Silicon Root of
> >> Trust recovery flows), as well as hardware bring-up and diagnostics.
>
> I don't know anything about these recovery mechanisms and their needs. I
> might have time to look into I3C things after all the conferences in
> Prague, but no promises...

Targets such as Caliptra (Silicon Root of
Trust), SoCs, and accelerators implement the OCP Secure Firmware
Recovery specification over I3C. When a target's runtime firmware is
corrupted, unprovisioned, or fails secure boot, its ROM/bootloader
exposes an I3C target endpoint implementing the OCP Recovery register
interface (PROT_CAP, DEVICE_ID, DEVICE_STATUS, RECOVERY_CTRL,
INDIRECT_FIFO_DATA) over standard I3C private transfers.

Per Section 8.4 of the OCP Secure Firmware Recovery v1.1 spec [1],
because I3C does not have native SMBus-style block transfers, the
recovery protocol emulates them over I3C using framed Private Write
transfers and combined Private Write + Repeated START Private Read
transfers (with PEC) to poll status/reason registers, pull crash logs
from Component Memory Spaces (CMS), stream signed recovery images into
the FIFO, and trigger activation.

The spec defines this same command set across SMBus, USB EP0, and I3C so
that a userspace Recovery Agent on a BMC can drive the recovery,
diagnostic log extraction, and attestation workflow across transports
(using i2c-dev for SMBus, usbfs/libusb for USB EP0, and i3cdev for I3C),
alongside general hardware bring-up and vendor-specific provisioning.

[1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf/

Thanks,
Sam

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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

Hey Wolfram and Andy,


Andy:

> I do not know how we end up here. The not-settled yet discussion is in
> thread with aqt_dCazxTDR4cpk@ashevche-desk.local.

There has been some back and forth but I originally uploaded this
patch set using
notifiers for binding looking for comments on the revival of a
potential upstream
i3cdev driver - Meagan had been working on a similar effort with i3cdev
using a different approach for binding and as of right now the bus notifier
approach seems to be more favored, but not approved nor decided on yet.

> But I have a big concern about exposing i3c to user space in the way we have it
> in i2c. Taking into account that i2c is an odd bus and might lead even to HW
> *physical* breakage, I would thing 100 times before making the same mistake
> in i3c. If you ever want to do this, this must not be user visible feature
> (hidden under expert and debug and maybe even more guards for the starter).
>

Just to make sure we're on the same page here about this - is your concern that
we can arbitrarily address any device on the i3c bus at-will as is the case
with i2c-dev?

FWIW, i3cdev as it exists in this patchset does not have as much free reign
over the i3c bus as i2c-dev does over an i2c bus:

1. i3cdev attaches to discrete target devices rather than exposing the
bus as a whole.
This means if I have 5 devices on my electrical bus that are up and operational
and 4 of them have a proper i3c driver to bind to (E.G. mctp-i3c) then
i3cdev will
not touch those devices, only the 5th device without a bound driver and
that would be via the i3cdev instance created specifically for that
device. A matching
kernel driver being found for a device later means i3cdev
automatically detaches itself
and makes way for a compatible client driver to bind.

2. Master controllers are also not a binding option for the driver, so
no free access to
send out arbitrary CCCs, perform bus scans, do DAA work, etc.

CONFIG_I3CDEV defaults to n and only creates root-owned character
devices for unbound targets, though if i3c maintainers prefer adding
"depends on EXPERT" or expanding the Kconfig help text, I am happy to do
that in v6.

Wolfram:

> >> Userspace access to I3C targets is needed for devices that do not have a
> >> kernel driver bound to them, such as targets in ROM/bootloader recovery
> >> mode (e.g., OCP Secure Firmware Recovery v1.1 and Caliptra Silicon Root of
> >> Trust recovery flows), as well as hardware bring-up and diagnostics.
>
> I don't know anything about these recovery mechanisms and their needs. I
> might have time to look into I3C things after all the conferences in
> Prague, but no promises...

Targets such as Caliptra (Silicon Root of
Trust), SoCs, and accelerators implement the OCP Secure Firmware
Recovery specification over I3C. When a target's runtime firmware is
corrupted, unprovisioned, or fails secure boot, its ROM/bootloader
exposes an I3C target endpoint implementing the OCP Recovery register
interface (PROT_CAP, DEVICE_ID, DEVICE_STATUS, RECOVERY_CTRL,
INDIRECT_FIFO_DATA) over standard I3C private transfers.

Per Section 8.4 of the OCP Secure Firmware Recovery v1.1 spec [1],
because I3C does not have native SMBus-style block transfers, the
recovery protocol emulates them over I3C using framed Private Write
transfers and combined Private Write + Repeated START Private Read
transfers (with PEC) to poll status/reason registers, pull crash logs
from Component Memory Spaces (CMS), stream signed recovery images into
the FIFO, and trigger activation.

The spec defines this same command set across SMBus, USB EP0, and I3C so
that a userspace Recovery Agent on a BMC can drive the recovery,
diagnostic log extraction, and attestation workflow across transports
(using i2c-dev for SMBus, usbfs/libusb for USB EP0, and i3cdev for I3C),
alongside general hardware bring-up and vendor-specific provisioning.

[1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf/

Thanks,
Sam

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Fri, Oct 09, 2026 at 09:05:28PM -0700, Sam Agazaryan wrote:

> > I do not know how we end up here. The not-settled yet discussion is in
> > thread with aqt_dCazxTDR4cpk@ashevche-desk.local.
> 
> There has been some back and forth but I originally uploaded this
> patch set using
> notifiers for binding looking for comments on the revival of a
> potential upstream
> i3cdev driver - Meagan had been working on a similar effort with i3cdev
> using a different approach for binding and as of right now the bus notifier
> approach seems to be more favored, but not approved nor decided on yet.
> 
> > But I have a big concern about exposing i3c to user space in the way we have it
> > in i2c. Taking into account that i2c is an odd bus and might lead even to HW
> > *physical* breakage, I would thing 100 times before making the same mistake
> > in i3c. If you ever want to do this, this must not be user visible feature
> > (hidden under expert and debug and maybe even more guards for the starter).
> 
> Just to make sure we're on the same page here about this - is your concern that
> we can arbitrarily address any device on the i3c bus at-will as is the case
> with i2c-dev?

Yes and more as this bus (i3c) is still non-discoverable (am I mistaken?).

> FWIW, i3cdev as it exists in this patchset does not have as much free reign
> over the i3c bus as i2c-dev does over an i2c bus:
> 
> 1. i3cdev attaches to discrete target devices rather than exposing the
> bus as a whole.
> This means if I have 5 devices on my electrical bus that are up and operational
> and 4 of them have a proper i3c driver to bind to (E.G. mctp-i3c) then
> i3cdev will
> not touch those devices, only the 5th device without a bound driver and
> that would be via the i3cdev instance created specifically for that
> device. A matching
> kernel driver being found for a device later means i3cdev
> automatically detaches itself
> and makes way for a compatible client driver to bind.

This makes even less usefulness in my eyes. Immediate Q: if 4 already have the
proper driver in the kernel, what's wrong to make it for the fifth one?

What if the device needs more? Or if this is a multi-functional device that
may have driver for only one part?

What to do with the i2c devices connected to i3c bus in the compatible mode?

> 2. Master controllers are also not a binding option for the driver, so
> no free access to
> send out arbitrary CCCs, perform bus scans, do DAA work, etc.
> 
> CONFIG_I3CDEV defaults to n and only creates root-owned character
> devices for unbound targets, though if i3c maintainers prefer adding
> "depends on EXPERT" or expanding the Kconfig help text, I am happy to do
> that in v6.

I really want to announce that as debug feature. Maybe I missed some use cases
when it's the only way to handle the target devices, but for now I fail to see
that.

-- 
With Best Regards,
Andy Shevchenko



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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Fri, Oct 09, 2026 at 09:05:28PM -0700, Sam Agazaryan wrote:

> > I do not know how we end up here. The not-settled yet discussion is in
> > thread with aqt_dCazxTDR4cpk@ashevche-desk.local.
> 
> There has been some back and forth but I originally uploaded this
> patch set using
> notifiers for binding looking for comments on the revival of a
> potential upstream
> i3cdev driver - Meagan had been working on a similar effort with i3cdev
> using a different approach for binding and as of right now the bus notifier
> approach seems to be more favored, but not approved nor decided on yet.
> 
> > But I have a big concern about exposing i3c to user space in the way we have it
> > in i2c. Taking into account that i2c is an odd bus and might lead even to HW
> > *physical* breakage, I would thing 100 times before making the same mistake
> > in i3c. If you ever want to do this, this must not be user visible feature
> > (hidden under expert and debug and maybe even more guards for the starter).
> 
> Just to make sure we're on the same page here about this - is your concern that
> we can arbitrarily address any device on the i3c bus at-will as is the case
> with i2c-dev?

Yes and more as this bus (i3c) is still non-discoverable (am I mistaken?).

> FWIW, i3cdev as it exists in this patchset does not have as much free reign
> over the i3c bus as i2c-dev does over an i2c bus:
> 
> 1. i3cdev attaches to discrete target devices rather than exposing the
> bus as a whole.
> This means if I have 5 devices on my electrical bus that are up and operational
> and 4 of them have a proper i3c driver to bind to (E.G. mctp-i3c) then
> i3cdev will
> not touch those devices, only the 5th device without a bound driver and
> that would be via the i3cdev instance created specifically for that
> device. A matching
> kernel driver being found for a device later means i3cdev
> automatically detaches itself
> and makes way for a compatible client driver to bind.

This makes even less usefulness in my eyes. Immediate Q: if 4 already have the
proper driver in the kernel, what's wrong to make it for the fifth one?

What if the device needs more? Or if this is a multi-functional device that
may have driver for only one part?

What to do with the i2c devices connected to i3c bus in the compatible mode?

> 2. Master controllers are also not a binding option for the driver, so
> no free access to
> send out arbitrary CCCs, perform bus scans, do DAA work, etc.
> 
> CONFIG_I3CDEV defaults to n and only creates root-owned character
> devices for unbound targets, though if i3c maintainers prefer adding
> "depends on EXPERT" or expanding the Kconfig help text, I am happy to do
> that in v6.

I really want to announce that as debug feature. Maybe I missed some use cases
when it's the only way to handle the target devices, but for now I fail to see
that.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> Yes and more as this bus (i3c) is still non-discoverable (am I mistaken?).

I3C is a dynamically discoverable bus. During DAA each I3C target reports a
Provisioned ID (PID), Bus Characteristic Register (BCR), and Device
Characteristic
Register (DCR), and is assigned a dynamic address by the controller.

> This makes even less usefulness in my eyes. Immediate Q: if 4 already have the
> proper driver in the kernel, what's wrong to make it for the fifth one?

1. The original use case was hardware bring-up, silicon validation, and debug
(i3ctransfer): Just like spidev, engineers need a debug interface
to issue ad-hoc SDR/HDR transfers during bring-up or hardware validation before
a driver exists.

2. Userspace firmware recovery / update tools (OCP Secure Firmware
Recovery, Caliptra RoT):
The recovery protocol is purely a polled request/response transport
(no IBIs allowed per spec)
used by userspace update tooling (fwupd / BMC recovery daemons) to
parse signed firmware
manifests, stream recovery image chunks to INDIRECT_FIFO_DATA, and
poll RECOVERY_STATUS—similar
to how userspace firmware updaters operate over spidev, hidraw, or
USB/NVMe ioctls rather than
putting firmware image parsing and update policy inside the kernel. In
my response to
Wolfram above I discussed this some more.

> What if the device needs more? Or if this is a multi-functional device that
> may have driver for only one part?

If a device needs more than basic transfers (such as IBIs,
hot-join handling, or integration with a subsystem like hwmon/iio/mctp),
it should use a dedicated kernel driver.

For multi-function devices, if the functions are exposed as MIPI I3C
Targets (e.g. a device exposing both an mctp-i3c interface and
an OCP recovery interface), each virtual target is assigned its own
dynamic address and DCR during ENTDAA and is enumerated as a distinct
i3c_device instance on the bus. Conversely, if multiple functions share
a single I3C target address and register map, i3cdev intentionally does
not allow userspace to access a target while a kernel driver is bound
to it (avoiding the I2C_SLAVE_FORCE problem where userspace can race
with a bound driver), so that case should be handled by an in-kernel
MFD driver - but that is not the use case being targeted here with OCP
recovery.



> What to do with the i2c devices connected to i3c bus in the compatible mode?

I3C master controllers register an i2c adapter for i2c devices running on an
i3c mixed mode bus - they are identified as i2c_bus_type, not i3c.

Thanks,
Sam

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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> Yes and more as this bus (i3c) is still non-discoverable (am I mistaken?).

I3C is a dynamically discoverable bus. During DAA each I3C target reports a
Provisioned ID (PID), Bus Characteristic Register (BCR), and Device
Characteristic
Register (DCR), and is assigned a dynamic address by the controller.

> This makes even less usefulness in my eyes. Immediate Q: if 4 already have the
> proper driver in the kernel, what's wrong to make it for the fifth one?

1. The original use case was hardware bring-up, silicon validation, and debug
(i3ctransfer): Just like spidev, engineers need a debug interface
to issue ad-hoc SDR/HDR transfers during bring-up or hardware validation before
a driver exists.

2. Userspace firmware recovery / update tools (OCP Secure Firmware
Recovery, Caliptra RoT):
The recovery protocol is purely a polled request/response transport
(no IBIs allowed per spec)
used by userspace update tooling (fwupd / BMC recovery daemons) to
parse signed firmware
manifests, stream recovery image chunks to INDIRECT_FIFO_DATA, and
poll RECOVERY_STATUS—similar
to how userspace firmware updaters operate over spidev, hidraw, or
USB/NVMe ioctls rather than
putting firmware image parsing and update policy inside the kernel. In
my response to
Wolfram above I discussed this some more.

> What if the device needs more? Or if this is a multi-functional device that
> may have driver for only one part?

If a device needs more than basic transfers (such as IBIs,
hot-join handling, or integration with a subsystem like hwmon/iio/mctp),
it should use a dedicated kernel driver.

For multi-function devices, if the functions are exposed as MIPI I3C
Targets (e.g. a device exposing both an mctp-i3c interface and
an OCP recovery interface), each virtual target is assigned its own
dynamic address and DCR during ENTDAA and is enumerated as a distinct
i3c_device instance on the bus. Conversely, if multiple functions share
a single I3C target address and register map, i3cdev intentionally does
not allow userspace to access a target while a kernel driver is bound
to it (avoiding the I2C_SLAVE_FORCE problem where userspace can race
with a bound driver), so that case should be handled by an in-kernel
MFD driver - but that is not the use case being targeted here with OCP
recovery.



> What to do with the i2c devices connected to i3c bus in the compatible mode?

I3C master controllers register an i2c adapter for i2c devices running on an
i3c mixed mode bus - they are identified as i2c_bus_type, not i3c.

Thanks,
Sam

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Sun, Oct 18, 2026 at 01:28:44PM -0700, Sam Agazaryan wrote:
> > Yes and more as this bus (i3c) is still non-discoverable (am I mistaken?).
> 
> I3C is a dynamically discoverable bus. During DAA each I3C target reports a
> Provisioned ID (PID), Bus Characteristic Register (BCR), and Device
> Characteristic Register (DCR), and is assigned a dynamic address by the
> controller.

Did I miss this in the initial explanation? If not, please add it next time.

> > This makes even less usefulness in my eyes. Immediate Q: if 4 already have the
> > proper driver in the kernel, what's wrong to make it for the fifth one?
> 
> 1. The original use case was hardware bring-up, silicon validation, and debug
> (i3ctransfer): Just like spidev, engineers need a debug interface
> to issue ad-hoc SDR/HDR transfers during bring-up or hardware validation before
> a driver exists.

Totally debug feature to me. Once you expose something in /dev (imply IOCTL),
it will become an ABI. And I'm fully against this.

> 2. Userspace firmware recovery / update tools (OCP Secure Firmware
> Recovery, Caliptra RoT):
> The recovery protocol is purely a polled request/response transport
> (no IBIs allowed per spec) used by userspace update tooling (fwupd / BMC
> recovery daemons) to parse signed firmware manifests, stream recovery image
> chunks to INDIRECT_FIFO_DATA, and poll RECOVERY_STATUS—similar to how
> userspace firmware updaters operate over spidev, hidraw, or USB/NVMe ioctls
> rather than putting firmware image parsing and update policy inside the
> kernel. In my response to Wolfram above I discussed this some more.

Do we have such use cases IRL? Do we have tooling support (at least pending)
somewhere? Why does it require user space interaction in _this_ way (meaning
IOCTL and /dev node)?

> > What if the device needs more? Or if this is a multi-functional device that
> > may have driver for only one part?
> 
> If a device needs more than basic transfers (such as IBIs,
> hot-join handling, or integration with a subsystem like hwmon/iio/mctp),
> it should use a dedicated kernel driver.
> 
> For multi-function devices, if the functions are exposed as MIPI I3C
> Targets (e.g. a device exposing both an mctp-i3c interface and
> an OCP recovery interface), each virtual target is assigned its own
> dynamic address and DCR during ENTDAA and is enumerated as a distinct
> i3c_device instance on the bus. Conversely, if multiple functions share
> a single I3C target address and register map, i3cdev intentionally does
> not allow userspace to access a target while a kernel driver is bound
> to it (avoiding the I2C_SLAVE_FORCE problem where userspace can race
> with a bound driver), so that case should be handled by an in-kernel
> MFD driver - but that is not the use case being targeted here with OCP
> recovery.

So, imagine that someone submits a kernel driver for a simple device, while
another person already uses the driver for multi-functional device where the
former one is driving only part of it. Strictly speaking the kernel driver
submission becomes a user space regression. Which effectively means that whenever
you open i3cdev, no other kernel drivers may appear. Yes, I understand that
a poor victim of such an unlikely course of events may recompile the kernel,
disable driver, et cetera, but this still raises the same question, why do
we do that to the mere users?

> > What to do with the i2c devices connected to i3c bus in the compatible mode?
> 
> I3C master controllers register an i2c adapter for i2c devices running on an
> i3c mixed mode bus - they are identified as i2c_bus_type, not i3c.

P.S> Still not convinced, that this has to be an ABI. For debugfs and something
like this, no objections, but ABI.

-- 
With Best Regards,
Andy Shevchenko



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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Sun, Oct 18, 2026 at 01:28:44PM -0700, Sam Agazaryan wrote:
> > Yes and more as this bus (i3c) is still non-discoverable (am I mistaken?).
> 
> I3C is a dynamically discoverable bus. During DAA each I3C target reports a
> Provisioned ID (PID), Bus Characteristic Register (BCR), and Device
> Characteristic Register (DCR), and is assigned a dynamic address by the
> controller.

Did I miss this in the initial explanation? If not, please add it next time.

> > This makes even less usefulness in my eyes. Immediate Q: if 4 already have the
> > proper driver in the kernel, what's wrong to make it for the fifth one?
> 
> 1. The original use case was hardware bring-up, silicon validation, and debug
> (i3ctransfer): Just like spidev, engineers need a debug interface
> to issue ad-hoc SDR/HDR transfers during bring-up or hardware validation before
> a driver exists.

Totally debug feature to me. Once you expose something in /dev (imply IOCTL),
it will become an ABI. And I'm fully against this.

> 2. Userspace firmware recovery / update tools (OCP Secure Firmware
> Recovery, Caliptra RoT):
> The recovery protocol is purely a polled request/response transport
> (no IBIs allowed per spec) used by userspace update tooling (fwupd / BMC
> recovery daemons) to parse signed firmware manifests, stream recovery image
> chunks to INDIRECT_FIFO_DATA, and poll RECOVERY_STATUS—similar to how
> userspace firmware updaters operate over spidev, hidraw, or USB/NVMe ioctls
> rather than putting firmware image parsing and update policy inside the
> kernel. In my response to Wolfram above I discussed this some more.

Do we have such use cases IRL? Do we have tooling support (at least pending)
somewhere? Why does it require user space interaction in _this_ way (meaning
IOCTL and /dev node)?

> > What if the device needs more? Or if this is a multi-functional device that
> > may have driver for only one part?
> 
> If a device needs more than basic transfers (such as IBIs,
> hot-join handling, or integration with a subsystem like hwmon/iio/mctp),
> it should use a dedicated kernel driver.
> 
> For multi-function devices, if the functions are exposed as MIPI I3C
> Targets (e.g. a device exposing both an mctp-i3c interface and
> an OCP recovery interface), each virtual target is assigned its own
> dynamic address and DCR during ENTDAA and is enumerated as a distinct
> i3c_device instance on the bus. Conversely, if multiple functions share
> a single I3C target address and register map, i3cdev intentionally does
> not allow userspace to access a target while a kernel driver is bound
> to it (avoiding the I2C_SLAVE_FORCE problem where userspace can race
> with a bound driver), so that case should be handled by an in-kernel
> MFD driver - but that is not the use case being targeted here with OCP
> recovery.

So, imagine that someone submits a kernel driver for a simple device, while
another person already uses the driver for multi-functional device where the
former one is driving only part of it. Strictly speaking the kernel driver
submission becomes a user space regression. Which effectively means that whenever
you open i3cdev, no other kernel drivers may appear. Yes, I understand that
a poor victim of such an unlikely course of events may recompile the kernel,
disable driver, et cetera, but this still raises the same question, why do
we do that to the mere users?

> > What to do with the i2c devices connected to i3c bus in the compatible mode?
> 
> I3C master controllers register an i2c adapter for i2c devices running on an
> i3c mixed mode bus - they are identified as i2c_bus_type, not i3c.

P.S> Still not convinced, that this has to be an ABI. For debugfs and something
like this, no objections, but ABI.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Mon, Oct 19, 2026 at 12:45:11PM +0300, Andy Shevchenko wrote:
> On Sun, Oct 18, 2026 at 01:28:44PM -0700, Sam Agazaryan wrote:
> > > Yes and more as this bus (i3c) is still non-discoverable (am I mistaken?).
> > 
> > I3C is a dynamically discoverable bus. During DAA each I3C target reports a
> > Provisioned ID (PID), Bus Characteristic Register (BCR), and Device
> > Characteristic Register (DCR), and is assigned a dynamic address by the
> > controller.
> 
> Did I miss this in the initial explanation? If not, please add it next time.
> 
> > > This makes even less usefulness in my eyes. Immediate Q: if 4 already have the
> > > proper driver in the kernel, what's wrong to make it for the fifth one?
> > 
> > 1. The original use case was hardware bring-up, silicon validation, and debug
> > (i3ctransfer): Just like spidev, engineers need a debug interface
> > to issue ad-hoc SDR/HDR transfers during bring-up or hardware validation before
> > a driver exists.
> 
> Totally debug feature to me. Once you expose something in /dev (imply IOCTL),
> it will become an ABI. And I'm fully against this.
> 
> > 2. Userspace firmware recovery / update tools (OCP Secure Firmware
> > Recovery, Caliptra RoT):
> > The recovery protocol is purely a polled request/response transport
> > (no IBIs allowed per spec) used by userspace update tooling (fwupd / BMC
> > recovery daemons) to parse signed firmware manifests, stream recovery image
> > chunks to INDIRECT_FIFO_DATA, and poll RECOVERY_STATUS—similar to how
> > userspace firmware updaters operate over spidev, hidraw, or USB/NVMe ioctls
> > rather than putting firmware image parsing and update policy inside the
> > kernel. In my response to Wolfram above I discussed this some more.
> 
> Do we have such use cases IRL? Do we have tooling support (at least pending)
> somewhere? Why does it require user space interaction in _this_ way (meaning
> IOCTL and /dev node)?
> 
> > > What if the device needs more? Or if this is a multi-functional device that
> > > may have driver for only one part?
> > 
> > If a device needs more than basic transfers (such as IBIs,
> > hot-join handling, or integration with a subsystem like hwmon/iio/mctp),
> > it should use a dedicated kernel driver.
> > 
> > For multi-function devices, if the functions are exposed as MIPI I3C
> > Targets (e.g. a device exposing both an mctp-i3c interface and
> > an OCP recovery interface), each virtual target is assigned its own
> > dynamic address and DCR during ENTDAA and is enumerated as a distinct
> > i3c_device instance on the bus. Conversely, if multiple functions share
> > a single I3C target address and register map, i3cdev intentionally does
> > not allow userspace to access a target while a kernel driver is bound
> > to it (avoiding the I2C_SLAVE_FORCE problem where userspace can race
> > with a bound driver), so that case should be handled by an in-kernel
> > MFD driver - but that is not the use case being targeted here with OCP
> > recovery.
> 
> So, imagine that someone submits a kernel driver for a simple device, while
> another person already uses the driver for multi-functional device where the
> former one is driving only part of it. Strictly speaking the kernel driver
> submission becomes a user space regression. Which effectively means that whenever
> you open i3cdev, no other kernel drivers may appear. Yes, I understand that
> a poor victim of such an unlikely course of events may recompile the kernel,
> disable driver, et cetera, but this still raises the same question, why do
> we do that to the mere users?
> 
> > > What to do with the i2c devices connected to i3c bus in the compatible mode?
> > 
> > I3C master controllers register an i2c adapter for i2c devices running on an
> > i3c mixed mode bus - they are identified as i2c_bus_type, not i3c.

Forgot to ask, but do they interfere?

> P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> like this, no objections, but ABI.

-- 
With Best Regards,
Andy Shevchenko



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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Mon, Oct 19, 2026 at 12:45:11PM +0300, Andy Shevchenko wrote:
> On Sun, Oct 18, 2026 at 01:28:44PM -0700, Sam Agazaryan wrote:
> > > Yes and more as this bus (i3c) is still non-discoverable (am I mistaken?).
> > 
> > I3C is a dynamically discoverable bus. During DAA each I3C target reports a
> > Provisioned ID (PID), Bus Characteristic Register (BCR), and Device
> > Characteristic Register (DCR), and is assigned a dynamic address by the
> > controller.
> 
> Did I miss this in the initial explanation? If not, please add it next time.
> 
> > > This makes even less usefulness in my eyes. Immediate Q: if 4 already have the
> > > proper driver in the kernel, what's wrong to make it for the fifth one?
> > 
> > 1. The original use case was hardware bring-up, silicon validation, and debug
> > (i3ctransfer): Just like spidev, engineers need a debug interface
> > to issue ad-hoc SDR/HDR transfers during bring-up or hardware validation before
> > a driver exists.
> 
> Totally debug feature to me. Once you expose something in /dev (imply IOCTL),
> it will become an ABI. And I'm fully against this.
> 
> > 2. Userspace firmware recovery / update tools (OCP Secure Firmware
> > Recovery, Caliptra RoT):
> > The recovery protocol is purely a polled request/response transport
> > (no IBIs allowed per spec) used by userspace update tooling (fwupd / BMC
> > recovery daemons) to parse signed firmware manifests, stream recovery image
> > chunks to INDIRECT_FIFO_DATA, and poll RECOVERY_STATUS—similar to how
> > userspace firmware updaters operate over spidev, hidraw, or USB/NVMe ioctls
> > rather than putting firmware image parsing and update policy inside the
> > kernel. In my response to Wolfram above I discussed this some more.
> 
> Do we have such use cases IRL? Do we have tooling support (at least pending)
> somewhere? Why does it require user space interaction in _this_ way (meaning
> IOCTL and /dev node)?
> 
> > > What if the device needs more? Or if this is a multi-functional device that
> > > may have driver for only one part?
> > 
> > If a device needs more than basic transfers (such as IBIs,
> > hot-join handling, or integration with a subsystem like hwmon/iio/mctp),
> > it should use a dedicated kernel driver.
> > 
> > For multi-function devices, if the functions are exposed as MIPI I3C
> > Targets (e.g. a device exposing both an mctp-i3c interface and
> > an OCP recovery interface), each virtual target is assigned its own
> > dynamic address and DCR during ENTDAA and is enumerated as a distinct
> > i3c_device instance on the bus. Conversely, if multiple functions share
> > a single I3C target address and register map, i3cdev intentionally does
> > not allow userspace to access a target while a kernel driver is bound
> > to it (avoiding the I2C_SLAVE_FORCE problem where userspace can race
> > with a bound driver), so that case should be handled by an in-kernel
> > MFD driver - but that is not the use case being targeted here with OCP
> > recovery.
> 
> So, imagine that someone submits a kernel driver for a simple device, while
> another person already uses the driver for multi-functional device where the
> former one is driving only part of it. Strictly speaking the kernel driver
> submission becomes a user space regression. Which effectively means that whenever
> you open i3cdev, no other kernel drivers may appear. Yes, I understand that
> a poor victim of such an unlikely course of events may recompile the kernel,
> disable driver, et cetera, but this still raises the same question, why do
> we do that to the mere users?
> 
> > > What to do with the i2c devices connected to i3c bus in the compatible mode?
> > 
> > I3C master controllers register an i2c adapter for i2c devices running on an
> > i3c mixed mode bus - they are identified as i2c_bus_type, not i3c.

Forgot to ask, but do they interfere?

> P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> like this, no objections, but ABI.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> Did I miss this in the initial explanation? If not, please add it next time.

That is just how the existing I3C core enumerates targets during DAA,
not something added by this series. I will add a sentence to the
cover letter and Patch 4 commit message in v6 contrasting it with
i2c-dev to make that context clear.

> Do we have such use cases IRL? Do we have tooling support (at least pending)
> somewhere? Why does it require user space interaction in _this_ way (meaning
> IOCTL and /dev node)?

Yes, this is used in real systems today:

1. Tooling & production users:

- i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
years).

- OCP Secure Firmware Recovery (DCR 0xBD) [1] and Caliptra Root-of-Trust
recovery agents on OpenBMC/gBMC platforms (e.g., AST2700 / Caliptra
MCU recovery tooling and BMC recovery daemons). Because Vitor's
original i3cdev series was not merged in 2019, multiple silicon
vendors and OpenBMC trees have been carrying out-of-tree forks of i3cdev;
upstreaming consolidates those diverging implementations.

2. Why an ioctl is required over a read and write:

- In the OCP Secure Firmware Recovery v1.1 specification (Section
8.4, "Recovery I3C Interface Block Read via Private Write and
Private Read"), every recovery command read is a combined transaction
consisting of a Private Write with no STOP, followed by a Repeated START,
followed by a Private Read, and finally a STOP.

- Because write() and read() only submit a single transfer at a time
(nxfers = 1), the controller emits a STOP condition on the wire
at the end of write() and drops the bus lock. Submitting multiple
i3c_ioc_xfer descriptors in a single I3C_IOC_XFER(N) ioctl is
required so i3c_device_do_xfers() queues them together under one
bus lock acquisition and the controller emits a Repeated START
between messages (as well as passing HDR mode/cmd parameters).

[1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf

> So, imagine that someone submits a kernel driver for a simple device, while
> another person already uses the driver for multi-functional device where the
> former one is driving only part of it. Strictly speaking the kernel driver
> submission becomes a user space regression. Which effectively means that whenever
> you open i3cdev, no other kernel drivers may appear. Yes, I understand that
> a poor victim of such an unlikely course of events may recompile the kernel,
> disable driver, et cetera, but this still raises the same question, why do
> we do that to the mere users?

Note that a user does not need to recompile the kernel if a kernel
driver binds to a device they wish to access via i3cdev. Because i3cdev
handles BUS_NOTIFY_UNBOUND_DRIVER, unbinding the kernel driver at
runtime via sysfs:

echo <dev> > /sys/bus/i3c/devices/<dev>/driver/unbind

automatically triggers i3cdev_attach() and exposes /dev/bus/i3c/<dev>
without rebuilding the kernel. Also, I3C drivers match against a
target's MIPI-assigned DCR or 48-bit PID (Manufacturer ID + Part ID),
so a driver for a simple device will not accidentally match a different
chip's PID or a dedicated DCR like 0xBD.

> P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> like this, no objections, but ABI.

Production BMC recovery daemons cannot rely on debugfs, which is
optional and restricted or unmounted on production builds. A character
device in /dev/bus/i3c/* provides the stable ioctl those tools need and
integrates with udev so non-root daemons can be granted access to
specific target nodes (e.g. matching on DCR 0xBD), similar to spidev
and hidraw.


> Forgot to ask, but do they interfere?

Is this in reference to i2c devices on the i3c bus? No, I3C transfers
and legacy
I2C transfers on a mixed-mode bus do not interfere:

1. Both i3c_device_do_xfers() and i3c_master_i2c_adapter_xfer() acquire
i3c_bus_normaluse_lock(&master->bus), so I3C and I2C transactions on
the same bus are serialized by the I3C core.

2. Attached I2C client addresses are marked as I3C_ADDR_SLOT_I2C_DEV in
the bus address slot table, preventing DAA from assigning an I2C
device's address to an I3C target.

Thanks,
Sam

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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> Did I miss this in the initial explanation? If not, please add it next time.

That is just how the existing I3C core enumerates targets during DAA,
not something added by this series. I will add a sentence to the
cover letter and Patch 4 commit message in v6 contrasting it with
i2c-dev to make that context clear.

> Do we have such use cases IRL? Do we have tooling support (at least pending)
> somewhere? Why does it require user space interaction in _this_ way (meaning
> IOCTL and /dev node)?

Yes, this is used in real systems today:

1. Tooling & production users:

- i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
years).

- OCP Secure Firmware Recovery (DCR 0xBD) [1] and Caliptra Root-of-Trust
recovery agents on OpenBMC/gBMC platforms (e.g., AST2700 / Caliptra
MCU recovery tooling and BMC recovery daemons). Because Vitor's
original i3cdev series was not merged in 2019, multiple silicon
vendors and OpenBMC trees have been carrying out-of-tree forks of i3cdev;
upstreaming consolidates those diverging implementations.

2. Why an ioctl is required over a read and write:

- In the OCP Secure Firmware Recovery v1.1 specification (Section
8.4, "Recovery I3C Interface Block Read via Private Write and
Private Read"), every recovery command read is a combined transaction
consisting of a Private Write with no STOP, followed by a Repeated START,
followed by a Private Read, and finally a STOP.

- Because write() and read() only submit a single transfer at a time
(nxfers = 1), the controller emits a STOP condition on the wire
at the end of write() and drops the bus lock. Submitting multiple
i3c_ioc_xfer descriptors in a single I3C_IOC_XFER(N) ioctl is
required so i3c_device_do_xfers() queues them together under one
bus lock acquisition and the controller emits a Repeated START
between messages (as well as passing HDR mode/cmd parameters).

[1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf

> So, imagine that someone submits a kernel driver for a simple device, while
> another person already uses the driver for multi-functional device where the
> former one is driving only part of it. Strictly speaking the kernel driver
> submission becomes a user space regression. Which effectively means that whenever
> you open i3cdev, no other kernel drivers may appear. Yes, I understand that
> a poor victim of such an unlikely course of events may recompile the kernel,
> disable driver, et cetera, but this still raises the same question, why do
> we do that to the mere users?

Note that a user does not need to recompile the kernel if a kernel
driver binds to a device they wish to access via i3cdev. Because i3cdev
handles BUS_NOTIFY_UNBOUND_DRIVER, unbinding the kernel driver at
runtime via sysfs:

echo <dev> > /sys/bus/i3c/devices/<dev>/driver/unbind

automatically triggers i3cdev_attach() and exposes /dev/bus/i3c/<dev>
without rebuilding the kernel. Also, I3C drivers match against a
target's MIPI-assigned DCR or 48-bit PID (Manufacturer ID + Part ID),
so a driver for a simple device will not accidentally match a different
chip's PID or a dedicated DCR like 0xBD.

> P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> like this, no objections, but ABI.

Production BMC recovery daemons cannot rely on debugfs, which is
optional and restricted or unmounted on production builds. A character
device in /dev/bus/i3c/* provides the stable ioctl those tools need and
integrates with udev so non-root daemons can be granted access to
specific target nodes (e.g. matching on DCR 0xBD), similar to spidev
and hidraw.


> Forgot to ask, but do they interfere?

Is this in reference to i2c devices on the i3c bus? No, I3C transfers
and legacy
I2C transfers on a mixed-mode bus do not interfere:

1. Both i3c_device_do_xfers() and i3c_master_i2c_adapter_xfer() acquire
i3c_bus_normaluse_lock(&master->bus), so I3C and I2C transactions on
the same bus are serialized by the I3C core.

2. Attached I2C client addresses are marked as I3C_ADDR_SLOT_I2C_DEV in
the bus address slot table, preventing DAA from assigning an I2C
device's address to an I3C target.

Thanks,
Sam

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Alexandre Belloni]

On 20/10/2026 14:20:16-0700, Sam Agazaryan wrote:
> > Did I miss this in the initial explanation? If not, please add it next time.
> 
> That is just how the existing I3C core enumerates targets during DAA,
> not something added by this series. I will add a sentence to the
> cover letter and Patch 4 commit message in v6 contrasting it with
> i2c-dev to make that context clear.
> 
> > Do we have such use cases IRL? Do we have tooling support (at least pending)
> > somewhere? Why does it require user space interaction in _this_ way (meaning
> > IOCTL and /dev node)?
> 
> Yes, this is used in real systems today:
> 
> 1. Tooling & production users:
> 
> - i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
> AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
> years).
> 
> - OCP Secure Firmware Recovery (DCR 0xBD) [1] and Caliptra Root-of-Trust
> recovery agents on OpenBMC/gBMC platforms (e.g., AST2700 / Caliptra
> MCU recovery tooling and BMC recovery daemons). Because Vitor's
> original i3cdev series was not merged in 2019, multiple silicon
> vendors and OpenBMC trees have been carrying out-of-tree forks of i3cdev;
> upstreaming consolidates those diverging implementations.
> 
> 2. Why an ioctl is required over a read and write:
> 
> - In the OCP Secure Firmware Recovery v1.1 specification (Section
> 8.4, "Recovery I3C Interface Block Read via Private Write and
> Private Read"), every recovery command read is a combined transaction
> consisting of a Private Write with no STOP, followed by a Repeated START,
> followed by a Private Read, and finally a STOP.
> 
> - Because write() and read() only submit a single transfer at a time
> (nxfers = 1), the controller emits a STOP condition on the wire
> at the end of write() and drops the bus lock. Submitting multiple
> i3c_ioc_xfer descriptors in a single I3C_IOC_XFER(N) ioctl is
> required so i3c_device_do_xfers() queues them together under one
> bus lock acquisition and the controller emits a Repeated START
> between messages (as well as passing HDR mode/cmd parameters).
> 
> [1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf
> 
> > So, imagine that someone submits a kernel driver for a simple device, while
> > another person already uses the driver for multi-functional device where the
> > former one is driving only part of it. Strictly speaking the kernel driver
> > submission becomes a user space regression. Which effectively means that whenever
> > you open i3cdev, no other kernel drivers may appear. Yes, I understand that
> > a poor victim of such an unlikely course of events may recompile the kernel,
> > disable driver, et cetera, but this still raises the same question, why do
> > we do that to the mere users?
> 
> Note that a user does not need to recompile the kernel if a kernel
> driver binds to a device they wish to access via i3cdev. Because i3cdev
> handles BUS_NOTIFY_UNBOUND_DRIVER, unbinding the kernel driver at
> runtime via sysfs:
> 
> echo <dev> > /sys/bus/i3c/devices/<dev>/driver/unbind
> 
> automatically triggers i3cdev_attach() and exposes /dev/bus/i3c/<dev>
> without rebuilding the kernel. Also, I3C drivers match against a
> target's MIPI-assigned DCR or 48-bit PID (Manufacturer ID + Part ID),
> so a driver for a simple device will not accidentally match a different
> chip's PID or a dedicated DCR like 0xBD.
> 
> > P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> > like this, no objections, but ABI.
> 
> Production BMC recovery daemons cannot rely on debugfs, which is
> optional and restricted or unmounted on production builds. A character
> device in /dev/bus/i3c/* provides the stable ioctl those tools need and
> integrates with udev so non-root daemons can be granted access to
> specific target nodes (e.g. matching on DCR 0xBD), similar to spidev
> and hidraw.
> 
> 
> > Forgot to ask, but do they interfere?
> 
> Is this in reference to i2c devices on the i3c bus? No, I3C transfers
> and legacy
> I2C transfers on a mixed-mode bus do not interfere:
> 
> 1. Both i3c_device_do_xfers() and i3c_master_i2c_adapter_xfer() acquire
> i3c_bus_normaluse_lock(&master->bus), so I3C and I2C transactions on
> the same bus are serialized by the I3C core.
> 
> 2. Attached I2C client addresses are marked as I3C_ADDR_SLOT_I2C_DEV in
> the bus address slot table, preventing DAA from assigning an I2C
> device's address to an I3C target.

On my side, I believe i3cdev can be added to the kernel and that it is
way safer than i2cdev but I agree that the ABI has to be properly
designed, maybe we need to version it or have a way to probe for
supported features so we can update safely later on. It is failry simple
right now but I feel like we are going to see people with more needs
than initiating transfers.

Also, I think this should not bind to any devices by default and make
binding explicit.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Alexandre Belloni]

On 20/10/2026 14:20:16-0700, Sam Agazaryan wrote:
> > Did I miss this in the initial explanation? If not, please add it next time.
> 
> That is just how the existing I3C core enumerates targets during DAA,
> not something added by this series. I will add a sentence to the
> cover letter and Patch 4 commit message in v6 contrasting it with
> i2c-dev to make that context clear.
> 
> > Do we have such use cases IRL? Do we have tooling support (at least pending)
> > somewhere? Why does it require user space interaction in _this_ way (meaning
> > IOCTL and /dev node)?
> 
> Yes, this is used in real systems today:
> 
> 1. Tooling & production users:
> 
> - i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
> AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
> years).
> 
> - OCP Secure Firmware Recovery (DCR 0xBD) [1] and Caliptra Root-of-Trust
> recovery agents on OpenBMC/gBMC platforms (e.g., AST2700 / Caliptra
> MCU recovery tooling and BMC recovery daemons). Because Vitor's
> original i3cdev series was not merged in 2019, multiple silicon
> vendors and OpenBMC trees have been carrying out-of-tree forks of i3cdev;
> upstreaming consolidates those diverging implementations.
> 
> 2. Why an ioctl is required over a read and write:
> 
> - In the OCP Secure Firmware Recovery v1.1 specification (Section
> 8.4, "Recovery I3C Interface Block Read via Private Write and
> Private Read"), every recovery command read is a combined transaction
> consisting of a Private Write with no STOP, followed by a Repeated START,
> followed by a Private Read, and finally a STOP.
> 
> - Because write() and read() only submit a single transfer at a time
> (nxfers = 1), the controller emits a STOP condition on the wire
> at the end of write() and drops the bus lock. Submitting multiple
> i3c_ioc_xfer descriptors in a single I3C_IOC_XFER(N) ioctl is
> required so i3c_device_do_xfers() queues them together under one
> bus lock acquisition and the controller emits a Repeated START
> between messages (as well as passing HDR mode/cmd parameters).
> 
> [1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf
> 
> > So, imagine that someone submits a kernel driver for a simple device, while
> > another person already uses the driver for multi-functional device where the
> > former one is driving only part of it. Strictly speaking the kernel driver
> > submission becomes a user space regression. Which effectively means that whenever
> > you open i3cdev, no other kernel drivers may appear. Yes, I understand that
> > a poor victim of such an unlikely course of events may recompile the kernel,
> > disable driver, et cetera, but this still raises the same question, why do
> > we do that to the mere users?
> 
> Note that a user does not need to recompile the kernel if a kernel
> driver binds to a device they wish to access via i3cdev. Because i3cdev
> handles BUS_NOTIFY_UNBOUND_DRIVER, unbinding the kernel driver at
> runtime via sysfs:
> 
> echo <dev> > /sys/bus/i3c/devices/<dev>/driver/unbind
> 
> automatically triggers i3cdev_attach() and exposes /dev/bus/i3c/<dev>
> without rebuilding the kernel. Also, I3C drivers match against a
> target's MIPI-assigned DCR or 48-bit PID (Manufacturer ID + Part ID),
> so a driver for a simple device will not accidentally match a different
> chip's PID or a dedicated DCR like 0xBD.
> 
> > P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> > like this, no objections, but ABI.
> 
> Production BMC recovery daemons cannot rely on debugfs, which is
> optional and restricted or unmounted on production builds. A character
> device in /dev/bus/i3c/* provides the stable ioctl those tools need and
> integrates with udev so non-root daemons can be granted access to
> specific target nodes (e.g. matching on DCR 0xBD), similar to spidev
> and hidraw.
> 
> 
> > Forgot to ask, but do they interfere?
> 
> Is this in reference to i2c devices on the i3c bus? No, I3C transfers
> and legacy
> I2C transfers on a mixed-mode bus do not interfere:
> 
> 1. Both i3c_device_do_xfers() and i3c_master_i2c_adapter_xfer() acquire
> i3c_bus_normaluse_lock(&master->bus), so I3C and I2C transactions on
> the same bus are serialized by the I3C core.
> 
> 2. Attached I2C client addresses are marked as I3C_ADDR_SLOT_I2C_DEV in
> the bus address slot table, preventing DAA from assigning an I2C
> device's address to an I3C target.

On my side, I believe i3cdev can be added to the kernel and that it is
way safer than i2cdev but I agree that the ABI has to be properly
designed, maybe we need to version it or have a way to probe for
supported features so we can update safely later on. It is failry simple
right now but I feel like we are going to see people with more needs
than initiating transfers.

Also, I think this should not bind to any devices by default and make
binding explicit.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Tue, Oct 20, 2026 at 02:20:16PM -0700, Sam Agazaryan wrote:
> > Did I miss this in the initial explanation? If not, please add it next time.
> 
> That is just how the existing I3C core enumerates targets during DAA,
> not something added by this series. I will add a sentence to the
> cover letter and Patch 4 commit message in v6 contrasting it with
> i2c-dev to make that context clear.
> 
> > Do we have such use cases IRL? Do we have tooling support (at least pending)
> > somewhere? Why does it require user space interaction in _this_ way (meaning
> > IOCTL and /dev node)?
> 
> Yes, this is used in real systems today:
> 
> 1. Tooling & production users:
> 
> - i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
> AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
> years).

So, nothing in production, meaning we can design that in kernel differently.

> - OCP Secure Firmware Recovery (DCR 0xBD) [1] and Caliptra Root-of-Trust
> recovery agents on OpenBMC/gBMC platforms (e.g., AST2700 / Caliptra
> MCU recovery tooling and BMC recovery daemons). Because Vitor's
> original i3cdev series was not merged in 2019, multiple silicon
> vendors and OpenBMC trees have been carrying out-of-tree forks of i3cdev;
> upstreaming consolidates those diverging implementations.
> 
> 2. Why an ioctl is required over a read and write:
> 
> - In the OCP Secure Firmware Recovery v1.1 specification (Section
> 8.4, "Recovery I3C Interface Block Read via Private Write and
> Private Read"), every recovery command read is a combined transaction
> consisting of a Private Write with no STOP, followed by a Repeated START,
> followed by a Private Read, and finally a STOP.
> 
> - Because write() and read() only submit a single transfer at a time
> (nxfers = 1), the controller emits a STOP condition on the wire
> at the end of write() and drops the bus lock. Submitting multiple
> i3c_ioc_xfer descriptors in a single I3C_IOC_XFER(N) ioctl is
> required so i3c_device_do_xfers() queues them together under one
> bus lock acquisition and the controller emits a Repeated START
> between messages (as well as passing HDR mode/cmd parameters).

Thanks, probably I was unclear, my specific question was why this needs a user
space to issue those recovery flows. And why it needs to be IOCTL-based and not
some higher level one.

> [1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf
> 
> > So, imagine that someone submits a kernel driver for a simple device, while
> > another person already uses the driver for multi-functional device where the
> > former one is driving only part of it. Strictly speaking the kernel driver
> > submission becomes a user space regression. Which effectively means that whenever
> > you open i3cdev, no other kernel drivers may appear. Yes, I understand that
> > a poor victim of such an unlikely course of events may recompile the kernel,
> > disable driver, et cetera, but this still raises the same question, why do
> > we do that to the mere users?
> 
> Note that a user does not need to recompile the kernel if a kernel
> driver binds to a device they wish to access via i3cdev. Because i3cdev
> handles BUS_NOTIFY_UNBOUND_DRIVER, unbinding the kernel driver at
> runtime via sysfs:
> 
> echo <dev> > /sys/bus/i3c/devices/<dev>/driver/unbind
> 
> automatically triggers i3cdev_attach() and exposes /dev/bus/i3c/<dev>
> without rebuilding the kernel.

Oh, that's quite a dangerous "feature"! Can we avoid doing that? Otherwise it
means any missed guard against unbind for the system controller related chips
may lead to real HW damage. I'm totally against this feature to be in any way
of an ABI. If you want that, do it exclusively via debugfs with a big fat
warning that this may lead to HW damages.

> Also, I3C drivers match against a
> target's MIPI-assigned DCR or 48-bit PID (Manufacturer ID + Part ID),
> so a driver for a simple device will not accidentally match a different
> chip's PID or a dedicated DCR like 0xBD.

Yes, but we are talking about opening a Pandora's box in user space, aren't we?

> > P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> > like this, no objections, but ABI.
> 
> Production BMC recovery daemons cannot rely on debugfs, which is
> optional and restricted or unmounted on production builds. A character
> device in /dev/bus/i3c/* provides the stable ioctl those tools need and
> integrates with udev so non-root daemons can be granted access to
> specific target nodes (e.g. matching on DCR 0xBD), similar to spidev
> and hidraw.

But why recovery mechanism can't be kernel-driven? With some sysfs
(just as an example) knobs to say "I want to run now a recovery flow
on this bus", et cetera.

> > Forgot to ask, but do they interfere?
> 
> Is this in reference to i2c devices on the i3c bus? No, I3C transfers
> and legacy I2C transfers on a mixed-mode bus do not interfere:
> 
> 1. Both i3c_device_do_xfers() and i3c_master_i2c_adapter_xfer() acquire
> i3c_bus_normaluse_lock(&master->bus), so I3C and I2C transactions on
> the same bus are serialized by the I3C core.
> 
> 2. Attached I2C client addresses are marked as I3C_ADDR_SLOT_I2C_DEV in
> the bus address slot table, preventing DAA from assigning an I2C
> device's address to an I3C target.

Can i2c device require an i2c recovery flow on the bus? If so, how would
it be combined together with the i3c recovery flow(s)?

-- 
With Best Regards,
Andy Shevchenko



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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Tue, Oct 20, 2026 at 02:20:16PM -0700, Sam Agazaryan wrote:
> > Did I miss this in the initial explanation? If not, please add it next time.
> 
> That is just how the existing I3C core enumerates targets during DAA,
> not something added by this series. I will add a sentence to the
> cover letter and Patch 4 commit message in v6 contrasting it with
> i2c-dev to make that context clear.
> 
> > Do we have such use cases IRL? Do we have tooling support (at least pending)
> > somewhere? Why does it require user space interaction in _this_ way (meaning
> > IOCTL and /dev node)?
> 
> Yes, this is used in real systems today:
> 
> 1. Tooling & production users:
> 
> - i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
> AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
> years).

So, nothing in production, meaning we can design that in kernel differently.

> - OCP Secure Firmware Recovery (DCR 0xBD) [1] and Caliptra Root-of-Trust
> recovery agents on OpenBMC/gBMC platforms (e.g., AST2700 / Caliptra
> MCU recovery tooling and BMC recovery daemons). Because Vitor's
> original i3cdev series was not merged in 2019, multiple silicon
> vendors and OpenBMC trees have been carrying out-of-tree forks of i3cdev;
> upstreaming consolidates those diverging implementations.
> 
> 2. Why an ioctl is required over a read and write:
> 
> - In the OCP Secure Firmware Recovery v1.1 specification (Section
> 8.4, "Recovery I3C Interface Block Read via Private Write and
> Private Read"), every recovery command read is a combined transaction
> consisting of a Private Write with no STOP, followed by a Repeated START,
> followed by a Private Read, and finally a STOP.
> 
> - Because write() and read() only submit a single transfer at a time
> (nxfers = 1), the controller emits a STOP condition on the wire
> at the end of write() and drops the bus lock. Submitting multiple
> i3c_ioc_xfer descriptors in a single I3C_IOC_XFER(N) ioctl is
> required so i3c_device_do_xfers() queues them together under one
> bus lock acquisition and the controller emits a Repeated START
> between messages (as well as passing HDR mode/cmd parameters).

Thanks, probably I was unclear, my specific question was why this needs a user
space to issue those recovery flows. And why it needs to be IOCTL-based and not
some higher level one.

> [1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf
> 
> > So, imagine that someone submits a kernel driver for a simple device, while
> > another person already uses the driver for multi-functional device where the
> > former one is driving only part of it. Strictly speaking the kernel driver
> > submission becomes a user space regression. Which effectively means that whenever
> > you open i3cdev, no other kernel drivers may appear. Yes, I understand that
> > a poor victim of such an unlikely course of events may recompile the kernel,
> > disable driver, et cetera, but this still raises the same question, why do
> > we do that to the mere users?
> 
> Note that a user does not need to recompile the kernel if a kernel
> driver binds to a device they wish to access via i3cdev. Because i3cdev
> handles BUS_NOTIFY_UNBOUND_DRIVER, unbinding the kernel driver at
> runtime via sysfs:
> 
> echo <dev> > /sys/bus/i3c/devices/<dev>/driver/unbind
> 
> automatically triggers i3cdev_attach() and exposes /dev/bus/i3c/<dev>
> without rebuilding the kernel.

Oh, that's quite a dangerous "feature"! Can we avoid doing that? Otherwise it
means any missed guard against unbind for the system controller related chips
may lead to real HW damage. I'm totally against this feature to be in any way
of an ABI. If you want that, do it exclusively via debugfs with a big fat
warning that this may lead to HW damages.

> Also, I3C drivers match against a
> target's MIPI-assigned DCR or 48-bit PID (Manufacturer ID + Part ID),
> so a driver for a simple device will not accidentally match a different
> chip's PID or a dedicated DCR like 0xBD.

Yes, but we are talking about opening a Pandora's box in user space, aren't we?

> > P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> > like this, no objections, but ABI.
> 
> Production BMC recovery daemons cannot rely on debugfs, which is
> optional and restricted or unmounted on production builds. A character
> device in /dev/bus/i3c/* provides the stable ioctl those tools need and
> integrates with udev so non-root daemons can be granted access to
> specific target nodes (e.g. matching on DCR 0xBD), similar to spidev
> and hidraw.

But why recovery mechanism can't be kernel-driven? With some sysfs
(just as an example) knobs to say "I want to run now a recovery flow
on this bus", et cetera.

> > Forgot to ask, but do they interfere?
> 
> Is this in reference to i2c devices on the i3c bus? No, I3C transfers
> and legacy I2C transfers on a mixed-mode bus do not interfere:
> 
> 1. Both i3c_device_do_xfers() and i3c_master_i2c_adapter_xfer() acquire
> i3c_bus_normaluse_lock(&master->bus), so I3C and I2C transactions on
> the same bus are serialized by the I3C core.
> 
> 2. Attached I2C client addresses are marked as I3C_ADDR_SLOT_I2C_DEV in
> the bus address slot table, preventing DAA from assigning an I2C
> device's address to an I3C target.

Can i2c device require an i2c recovery flow on the bus? If so, how would
it be combined together with the i3c recovery flow(s)?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Wed, Oct 21, 2026 at 11:57:56AM +0200, Alexandre Belloni wrote:
> On 20/10/2026 14:20:16-0700, Sam Agazaryan wrote:
> > > Did I miss this in the initial explanation? If not, please add it next time.
> > 
> > That is just how the existing I3C core enumerates targets during DAA,
> > not something added by this series. I will add a sentence to the
> > cover letter and Patch 4 commit message in v6 contrasting it with
> > i2c-dev to make that context clear.
> > 
> > > Do we have such use cases IRL? Do we have tooling support (at least pending)
> > > somewhere? Why does it require user space interaction in _this_ way (meaning
> > > IOCTL and /dev node)?
> > 
> > Yes, this is used in real systems today:
> > 
> > 1. Tooling & production users:
> > 
> > - i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
> > AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
> > years).
> > 
> > - OCP Secure Firmware Recovery (DCR 0xBD) [1] and Caliptra Root-of-Trust
> > recovery agents on OpenBMC/gBMC platforms (e.g., AST2700 / Caliptra
> > MCU recovery tooling and BMC recovery daemons). Because Vitor's
> > original i3cdev series was not merged in 2019, multiple silicon
> > vendors and OpenBMC trees have been carrying out-of-tree forks of i3cdev;
> > upstreaming consolidates those diverging implementations.
> > 
> > 2. Why an ioctl is required over a read and write:
> > 
> > - In the OCP Secure Firmware Recovery v1.1 specification (Section
> > 8.4, "Recovery I3C Interface Block Read via Private Write and
> > Private Read"), every recovery command read is a combined transaction
> > consisting of a Private Write with no STOP, followed by a Repeated START,
> > followed by a Private Read, and finally a STOP.
> > 
> > - Because write() and read() only submit a single transfer at a time
> > (nxfers = 1), the controller emits a STOP condition on the wire
> > at the end of write() and drops the bus lock. Submitting multiple
> > i3c_ioc_xfer descriptors in a single I3C_IOC_XFER(N) ioctl is
> > required so i3c_device_do_xfers() queues them together under one
> > bus lock acquisition and the controller emits a Repeated START
> > between messages (as well as passing HDR mode/cmd parameters).
> > 
> > [1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf
> > 
> > > So, imagine that someone submits a kernel driver for a simple device, while
> > > another person already uses the driver for multi-functional device where the
> > > former one is driving only part of it. Strictly speaking the kernel driver
> > > submission becomes a user space regression. Which effectively means that whenever
> > > you open i3cdev, no other kernel drivers may appear. Yes, I understand that
> > > a poor victim of such an unlikely course of events may recompile the kernel,
> > > disable driver, et cetera, but this still raises the same question, why do
> > > we do that to the mere users?
> > 
> > Note that a user does not need to recompile the kernel if a kernel
> > driver binds to a device they wish to access via i3cdev. Because i3cdev
> > handles BUS_NOTIFY_UNBOUND_DRIVER, unbinding the kernel driver at
> > runtime via sysfs:
> > 
> > echo <dev> > /sys/bus/i3c/devices/<dev>/driver/unbind
> > 
> > automatically triggers i3cdev_attach() and exposes /dev/bus/i3c/<dev>
> > without rebuilding the kernel. Also, I3C drivers match against a
> > target's MIPI-assigned DCR or 48-bit PID (Manufacturer ID + Part ID),
> > so a driver for a simple device will not accidentally match a different
> > chip's PID or a dedicated DCR like 0xBD.
> > 
> > > P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> > > like this, no objections, but ABI.
> > 
> > Production BMC recovery daemons cannot rely on debugfs, which is
> > optional and restricted or unmounted on production builds. A character
> > device in /dev/bus/i3c/* provides the stable ioctl those tools need and
> > integrates with udev so non-root daemons can be granted access to
> > specific target nodes (e.g. matching on DCR 0xBD), similar to spidev
> > and hidraw.
> > 
> > 
> > > Forgot to ask, but do they interfere?
> > 
> > Is this in reference to i2c devices on the i3c bus? No, I3C transfers
> > and legacy
> > I2C transfers on a mixed-mode bus do not interfere:
> > 
> > 1. Both i3c_device_do_xfers() and i3c_master_i2c_adapter_xfer() acquire
> > i3c_bus_normaluse_lock(&master->bus), so I3C and I2C transactions on
> > the same bus are serialized by the I3C core.
> > 
> > 2. Attached I2C client addresses are marked as I3C_ADDR_SLOT_I2C_DEV in
> > the bus address slot table, preventing DAA from assigning an I2C
> > device's address to an I3C target.
> 
> On my side, I believe i3cdev can be added to the kernel and that it is
> way safer than i2cdev but I agree that the ABI has to be properly
> designed, maybe we need to version it or have a way to probe for
> supported features so we can update safely later on. It is failry simple
> right now but I feel like we are going to see people with more needs
> than initiating transfers.

Yeah, I really think that i2cdev was a pure mistake (as to be an ABI).
I don't want to repeat it now, when we learnt about that case a lot.
If we ever going to have i3cdev (which justification I also put in doubts)
it needs to be very strict of what can be done and how.

> Also, I think this should not bind to any devices by default and make
> binding explicit.

Yes, this is quite dangerous "feature".

-- 
With Best Regards,
Andy Shevchenko



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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Wed, Oct 21, 2026 at 11:57:56AM +0200, Alexandre Belloni wrote:
> On 20/10/2026 14:20:16-0700, Sam Agazaryan wrote:
> > > Did I miss this in the initial explanation? If not, please add it next time.
> > 
> > That is just how the existing I3C core enumerates targets during DAA,
> > not something added by this series. I will add a sentence to the
> > cover letter and Patch 4 commit message in v6 contrasting it with
> > i2c-dev to make that context clear.
> > 
> > > Do we have such use cases IRL? Do we have tooling support (at least pending)
> > > somewhere? Why does it require user space interaction in _this_ way (meaning
> > > IOCTL and /dev node)?
> > 
> > Yes, this is used in real systems today:
> > 
> > 1. Tooling & production users:
> > 
> > - i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
> > AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
> > years).
> > 
> > - OCP Secure Firmware Recovery (DCR 0xBD) [1] and Caliptra Root-of-Trust
> > recovery agents on OpenBMC/gBMC platforms (e.g., AST2700 / Caliptra
> > MCU recovery tooling and BMC recovery daemons). Because Vitor's
> > original i3cdev series was not merged in 2019, multiple silicon
> > vendors and OpenBMC trees have been carrying out-of-tree forks of i3cdev;
> > upstreaming consolidates those diverging implementations.
> > 
> > 2. Why an ioctl is required over a read and write:
> > 
> > - In the OCP Secure Firmware Recovery v1.1 specification (Section
> > 8.4, "Recovery I3C Interface Block Read via Private Write and
> > Private Read"), every recovery command read is a combined transaction
> > consisting of a Private Write with no STOP, followed by a Repeated START,
> > followed by a Private Read, and finally a STOP.
> > 
> > - Because write() and read() only submit a single transfer at a time
> > (nxfers = 1), the controller emits a STOP condition on the wire
> > at the end of write() and drops the bus lock. Submitting multiple
> > i3c_ioc_xfer descriptors in a single I3C_IOC_XFER(N) ioctl is
> > required so i3c_device_do_xfers() queues them together under one
> > bus lock acquisition and the controller emits a Repeated START
> > between messages (as well as passing HDR mode/cmd parameters).
> > 
> > [1] https://www.opencompute.org/documents/ocp-recovery-document-1p1-final-pdf
> > 
> > > So, imagine that someone submits a kernel driver for a simple device, while
> > > another person already uses the driver for multi-functional device where the
> > > former one is driving only part of it. Strictly speaking the kernel driver
> > > submission becomes a user space regression. Which effectively means that whenever
> > > you open i3cdev, no other kernel drivers may appear. Yes, I understand that
> > > a poor victim of such an unlikely course of events may recompile the kernel,
> > > disable driver, et cetera, but this still raises the same question, why do
> > > we do that to the mere users?
> > 
> > Note that a user does not need to recompile the kernel if a kernel
> > driver binds to a device they wish to access via i3cdev. Because i3cdev
> > handles BUS_NOTIFY_UNBOUND_DRIVER, unbinding the kernel driver at
> > runtime via sysfs:
> > 
> > echo <dev> > /sys/bus/i3c/devices/<dev>/driver/unbind
> > 
> > automatically triggers i3cdev_attach() and exposes /dev/bus/i3c/<dev>
> > without rebuilding the kernel. Also, I3C drivers match against a
> > target's MIPI-assigned DCR or 48-bit PID (Manufacturer ID + Part ID),
> > so a driver for a simple device will not accidentally match a different
> > chip's PID or a dedicated DCR like 0xBD.
> > 
> > > P.S> Still not convinced, that this has to be an ABI. For debugfs and something
> > > like this, no objections, but ABI.
> > 
> > Production BMC recovery daemons cannot rely on debugfs, which is
> > optional and restricted or unmounted on production builds. A character
> > device in /dev/bus/i3c/* provides the stable ioctl those tools need and
> > integrates with udev so non-root daemons can be granted access to
> > specific target nodes (e.g. matching on DCR 0xBD), similar to spidev
> > and hidraw.
> > 
> > 
> > > Forgot to ask, but do they interfere?
> > 
> > Is this in reference to i2c devices on the i3c bus? No, I3C transfers
> > and legacy
> > I2C transfers on a mixed-mode bus do not interfere:
> > 
> > 1. Both i3c_device_do_xfers() and i3c_master_i2c_adapter_xfer() acquire
> > i3c_bus_normaluse_lock(&master->bus), so I3C and I2C transactions on
> > the same bus are serialized by the I3C core.
> > 
> > 2. Attached I2C client addresses are marked as I3C_ADDR_SLOT_I2C_DEV in
> > the bus address slot table, preventing DAA from assigning an I2C
> > device's address to an I3C target.
> 
> On my side, I believe i3cdev can be added to the kernel and that it is
> way safer than i2cdev but I agree that the ABI has to be properly
> designed, maybe we need to version it or have a way to probe for
> supported features so we can update safely later on. It is failry simple
> right now but I feel like we are going to see people with more needs
> than initiating transfers.

Yeah, I really think that i2cdev was a pure mistake (as to be an ABI).
I don't want to repeat it now, when we learnt about that case a lot.
If we ever going to have i3cdev (which justification I also put in doubts)
it needs to be very strict of what can be done and how.

> Also, I think this should not bind to any devices by default and make
> binding explicit.

Yes, this is quite dangerous "feature".

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> > 1. Tooling & production users:
> >
> > - i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
> > AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
> > years).
>
> So, nothing in production, meaning we can design that in kernel differently.

In hindsight I should have ordered that list differently, the second bullet
right below that is the production use case: production BMC firmware update
and recovery daemons running in OpenBMC server fleets (managing Caliptra
Root-of-Trust and SoC recovery targets over I3C), as well as production
server accelerator management daemons.

> But why recovery mechanism can't be kernel-driven? With some sysfs
> (just as an example) knobs to say "I want to run now a recovery flow
> on this bus", et cetera.

To make sure we're talking about the same thing: "OCP Secure Firmware
Recovery" is not electrical bus recovery (like recovering an i2c or
i3c bus itself by bit-banging to unstick a hung bus). It is device
firmware recovery and provisioning (similar in concept to USB DFU) to
recover and boot a target device that sits on the bus.

This lives in userspace because it is part of the BMC's Redfish/RoT
firmware management stack (handling network image streaming, signing/key
management, and chassis-level recovery policies), rather than a single
"recover this bus" hardware toggle. And it uses I3C_IOC_XFER because
each protocol register read/write requires combined Write + Repeated
START + Read transfers (or HDR transfers) to that specific target node.

> Oh, that's quite a dangerous "feature"! Can we avoid doing that? Otherwise it
> means any missed guard against unbind for the system controller related chips
> may lead to real HW damage. I'm totally against this feature to be in any way
> of an ABI. If you want that, do it exclusively via debugfs with a big fat
> warning that this may lead to HW damages.

Agreed -- as Alexandre also suggested in his reply, it sounds like
automatic binding isn't favored here due to risk of hardware damage.

> Can i2c device require an i2c recovery flow on the bus? If so, how would
> it be combined together with the i3c recovery flow(s)?

If you mean electrical bus recovery, i3cdev doesn't perform
bus-level electrical recovery. It only submits normal target-addressed
transfers via i3c_device_do_xfers().

If you mean OCP device firmware recovery on a mixed bus:

An I2C recovery target on a mixed bus uses standard SMBus Block
Read/Write transactions through the controller's i2c_adapter (not
i3cdev) while an I3C recovery target uses I3C Private Write/Read
transfers via i3cdev. On a mixed bus, the Linux I3C core already
configures the bus mode/SCL rate according to the I2C targets' LVR
spike-filter capabilities and serializes both paths via
i3c_bus_normaluse_lock(&master->bus).


Thanks,
Sam

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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> > 1. Tooling & production users:
> >
> > - i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
> > AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
> > years).
>
> So, nothing in production, meaning we can design that in kernel differently.

In hindsight I should have ordered that list differently, the second bullet
right below that is the production use case: production BMC firmware update
and recovery daemons running in OpenBMC server fleets (managing Caliptra
Root-of-Trust and SoC recovery targets over I3C), as well as production
server accelerator management daemons.

> But why recovery mechanism can't be kernel-driven? With some sysfs
> (just as an example) knobs to say "I want to run now a recovery flow
> on this bus", et cetera.

To make sure we're talking about the same thing: "OCP Secure Firmware
Recovery" is not electrical bus recovery (like recovering an i2c or
i3c bus itself by bit-banging to unstick a hung bus). It is device
firmware recovery and provisioning (similar in concept to USB DFU) to
recover and boot a target device that sits on the bus.

This lives in userspace because it is part of the BMC's Redfish/RoT
firmware management stack (handling network image streaming, signing/key
management, and chassis-level recovery policies), rather than a single
"recover this bus" hardware toggle. And it uses I3C_IOC_XFER because
each protocol register read/write requires combined Write + Repeated
START + Read transfers (or HDR transfers) to that specific target node.

> Oh, that's quite a dangerous "feature"! Can we avoid doing that? Otherwise it
> means any missed guard against unbind for the system controller related chips
> may lead to real HW damage. I'm totally against this feature to be in any way
> of an ABI. If you want that, do it exclusively via debugfs with a big fat
> warning that this may lead to HW damages.

Agreed -- as Alexandre also suggested in his reply, it sounds like
automatic binding isn't favored here due to risk of hardware damage.

> Can i2c device require an i2c recovery flow on the bus? If so, how would
> it be combined together with the i3c recovery flow(s)?

If you mean electrical bus recovery, i3cdev doesn't perform
bus-level electrical recovery. It only submits normal target-addressed
transfers via i3c_device_do_xfers().

If you mean OCP device firmware recovery on a mixed bus:

An I2C recovery target on a mixed bus uses standard SMBus Block
Read/Write transactions through the controller's i2c_adapter (not
i3cdev) while an I3C recovery target uses I3C Private Write/Read
transfers via i3cdev. On a mixed bus, the Linux I3C core already
configures the bus mode/SCL rate according to the I2C targets' LVR
spike-filter capabilities and serializes both paths via
i3c_bus_normaluse_lock(&master->bus).


Thanks,
Sam

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> On my side, I believe i3cdev can be added to the kernel and that it is
> way safer than i2cdev but I agree that the ABI has to be properly
> designed, maybe we need to version it or have a way to probe for
> supported features so we can update safely later on. It is failry simple
> right now but I feel like we are going to see people with more needs
> than initiating transfers.

For feature probing and ABI extension, what do you think of:

1. Adding an extensible I3C_IOC_GET_CAPS ioctl:

   struct i3c_ioc_caps {
       __u32 size; /* sizeof(struct i3c_ioc_caps) */
       __u32 pad;  /* must be 0 */
       __u64 caps; /* Bitmask of supported I3C_CAP_* features */
   };

   Today caps can report the transfer modes supported by the controller
   and target (I3C_CAP_SDR, I3C_CAP_HDR_DDR, I3C_CAP_HDR_TSP,
   I3C_CAP_HDR_TSL), and new bits in caps (or new fields appended to
   the end of the struct) can advertise future capabilities beyond basic
   transfers.

2. In struct i3c_ioc_xfer, we already have __u8 pad[2] at the end which
   is strictly checked to be 0 (-EINVAL if non-zero), reserving 16 bits
   for future per-transfer flags without changing the struct size.

> Also, I think this should not bind to any devices by default and make
> binding explicit.

This seems to be the consensus so far. I can convert i3cdev from a bus
notifier into a standard struct i3c_driver so it does not auto-attach
to all unbound targets on boot or on unbind while dropping patches 1
and 2.

Since Greg KH noted earlier [1] that driver_override / manual sysfs
bind is only for debugging and will taint the kernel in the near
future, what do you think of:

Matching explicit opt-in entries in i3cdev's i3c_device_id table (starting
with 0xBD for OCP Secure Firmware Recovery), and optionally
exposing a new_id sysfs attribute on the i3cdev driver for dynamically
adding target IDs at runtime? That also keeps everything self-contained
in i3cdev without needing cross-subsystem changes to hwmon/iio drivers.


[1] https://lore.kernel.org/linux-i3c/2026091834-bats-palpitate-5614@gregkh/


Thanks,
Sam

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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> On my side, I believe i3cdev can be added to the kernel and that it is
> way safer than i2cdev but I agree that the ABI has to be properly
> designed, maybe we need to version it or have a way to probe for
> supported features so we can update safely later on. It is failry simple
> right now but I feel like we are going to see people with more needs
> than initiating transfers.

For feature probing and ABI extension, what do you think of:

1. Adding an extensible I3C_IOC_GET_CAPS ioctl:

   struct i3c_ioc_caps {
       __u32 size; /* sizeof(struct i3c_ioc_caps) */
       __u32 pad;  /* must be 0 */
       __u64 caps; /* Bitmask of supported I3C_CAP_* features */
   };

   Today caps can report the transfer modes supported by the controller
   and target (I3C_CAP_SDR, I3C_CAP_HDR_DDR, I3C_CAP_HDR_TSP,
   I3C_CAP_HDR_TSL), and new bits in caps (or new fields appended to
   the end of the struct) can advertise future capabilities beyond basic
   transfers.

2. In struct i3c_ioc_xfer, we already have __u8 pad[2] at the end which
   is strictly checked to be 0 (-EINVAL if non-zero), reserving 16 bits
   for future per-transfer flags without changing the struct size.

> Also, I think this should not bind to any devices by default and make
> binding explicit.

This seems to be the consensus so far. I can convert i3cdev from a bus
notifier into a standard struct i3c_driver so it does not auto-attach
to all unbound targets on boot or on unbind while dropping patches 1
and 2.

Since Greg KH noted earlier [1] that driver_override / manual sysfs
bind is only for debugging and will taint the kernel in the near
future, what do you think of:

Matching explicit opt-in entries in i3cdev's i3c_device_id table (starting
with 0xBD for OCP Secure Firmware Recovery), and optionally
exposing a new_id sysfs attribute on the i3cdev driver for dynamically
adding target IDs at runtime? That also keeps everything self-contained
in i3cdev without needing cross-subsystem changes to hwmon/iio drivers.


[1] https://lore.kernel.org/linux-i3c/2026091834-bats-palpitate-5614@gregkh/


Thanks,
Sam

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Thu, Oct 22, 2026 at 01:23:10PM -0700, Sam Agazaryan wrote:
> > > 1. Tooling & production users:
> > >
> > > - i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
> > > AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
> > > years).
> >
> > So, nothing in production, meaning we can design that in kernel differently.
> 
> In hindsight I should have ordered that list differently, the second bullet
> right below that is the production use case: production BMC firmware update
> and recovery daemons running in OpenBMC server fleets (managing Caliptra
> Root-of-Trust and SoC recovery targets over I3C), as well as production
> server accelerator management daemons.

Okay, but they are not (obviously) use the upstream solutions for that.

> > But why recovery mechanism can't be kernel-driven? With some sysfs
> > (just as an example) knobs to say "I want to run now a recovery flow
> > on this bus", et cetera.
> 
> To make sure we're talking about the same thing: "OCP Secure Firmware
> Recovery" is not electrical bus recovery (like recovering an i2c or
> i3c bus itself by bit-banging to unstick a hung bus). It is device
> firmware recovery and provisioning (similar in concept to USB DFU) to
> recover and boot a target device that sits on the bus.

A-ha, so this is a device programming protocol on the top of the i3c bus.

> This lives in userspace because it is part of the BMC's Redfish/RoT
> firmware management stack (handling network image streaming, signing/key
> management, and chassis-level recovery policies), rather than a single
> "recover this bus" hardware toggle. And it uses I3C_IOC_XFER because
> each protocol register read/write requires combined Write + Repeated
> START + Read transfers (or HDR transfers) to that specific target node.

But it's still unclear to me why this can't be moved to the kernel space?
There is no user space that communicates with upstream kernel in the way
you described, they should have used a custom (out-of-tree) solutions, right?

> > Oh, that's quite a dangerous "feature"! Can we avoid doing that? Otherwise it
> > means any missed guard against unbind for the system controller related chips
> > may lead to real HW damage. I'm totally against this feature to be in any way
> > of an ABI. If you want that, do it exclusively via debugfs with a big fat
> > warning that this may lead to HW damages.
> 
> Agreed -- as Alexandre also suggested in his reply, it sounds like
> automatic binding isn't favored here due to risk of hardware damage.
> 
> > Can i2c device require an i2c recovery flow on the bus? If so, how would
> > it be combined together with the i3c recovery flow(s)?
> 
> If you mean electrical bus recovery, i3cdev doesn't perform
> bus-level electrical recovery. It only submits normal target-addressed
> transfers via i3c_device_do_xfers().

But how it will do if the i2c device blocks the i3c bus in mixed mode?
I mean, how will it affect the i3c transfers on the wire?

> If you mean OCP device firmware recovery on a mixed bus:
> 
> An I2C recovery target on a mixed bus uses standard SMBus Block
> Read/Write transactions through the controller's i2c_adapter (not
> i3cdev) while an I3C recovery target uses I3C Private Write/Read
> transfers via i3cdev. On a mixed bus, the Linux I3C core already
> configures the bus mode/SCL rate according to the I2C targets' LVR
> spike-filter capabilities and serializes both paths via
> i3c_bus_normaluse_lock(&master->bus).

Good to know, thanks!

-- 
With Best Regards,
Andy Shevchenko



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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Thu, Oct 22, 2026 at 01:23:10PM -0700, Sam Agazaryan wrote:
> > > 1. Tooling & production users:
> > >
> > > - i3ctransfer (Patch 5/5 of this series, and carried out-of-tree in
> > > AspeedTech-BMC/i3c-tools and vendor OpenBMC BSPs for several
> > > years).
> >
> > So, nothing in production, meaning we can design that in kernel differently.
> 
> In hindsight I should have ordered that list differently, the second bullet
> right below that is the production use case: production BMC firmware update
> and recovery daemons running in OpenBMC server fleets (managing Caliptra
> Root-of-Trust and SoC recovery targets over I3C), as well as production
> server accelerator management daemons.

Okay, but they are not (obviously) use the upstream solutions for that.

> > But why recovery mechanism can't be kernel-driven? With some sysfs
> > (just as an example) knobs to say "I want to run now a recovery flow
> > on this bus", et cetera.
> 
> To make sure we're talking about the same thing: "OCP Secure Firmware
> Recovery" is not electrical bus recovery (like recovering an i2c or
> i3c bus itself by bit-banging to unstick a hung bus). It is device
> firmware recovery and provisioning (similar in concept to USB DFU) to
> recover and boot a target device that sits on the bus.

A-ha, so this is a device programming protocol on the top of the i3c bus.

> This lives in userspace because it is part of the BMC's Redfish/RoT
> firmware management stack (handling network image streaming, signing/key
> management, and chassis-level recovery policies), rather than a single
> "recover this bus" hardware toggle. And it uses I3C_IOC_XFER because
> each protocol register read/write requires combined Write + Repeated
> START + Read transfers (or HDR transfers) to that specific target node.

But it's still unclear to me why this can't be moved to the kernel space?
There is no user space that communicates with upstream kernel in the way
you described, they should have used a custom (out-of-tree) solutions, right?

> > Oh, that's quite a dangerous "feature"! Can we avoid doing that? Otherwise it
> > means any missed guard against unbind for the system controller related chips
> > may lead to real HW damage. I'm totally against this feature to be in any way
> > of an ABI. If you want that, do it exclusively via debugfs with a big fat
> > warning that this may lead to HW damages.
> 
> Agreed -- as Alexandre also suggested in his reply, it sounds like
> automatic binding isn't favored here due to risk of hardware damage.
> 
> > Can i2c device require an i2c recovery flow on the bus? If so, how would
> > it be combined together with the i3c recovery flow(s)?
> 
> If you mean electrical bus recovery, i3cdev doesn't perform
> bus-level electrical recovery. It only submits normal target-addressed
> transfers via i3c_device_do_xfers().

But how it will do if the i2c device blocks the i3c bus in mixed mode?
I mean, how will it affect the i3c transfers on the wire?

> If you mean OCP device firmware recovery on a mixed bus:
> 
> An I2C recovery target on a mixed bus uses standard SMBus Block
> Read/Write transactions through the controller's i2c_adapter (not
> i3cdev) while an I3C recovery target uses I3C Private Write/Read
> transfers via i3cdev. On a mixed bus, the Linux I3C core already
> configures the bus mode/SCL rate according to the I2C targets' LVR
> spike-filter capabilities and serializes both paths via
> i3c_bus_normaluse_lock(&master->bus).

Good to know, thanks!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> > [...] production BMC firmware update
> > and recovery daemons running in OpenBMC server fleets (managing Caliptra
> > Root-of-Trust and SoC recovery targets over I3C), as well as production
> > server accelerator management daemons.
>
> Okay, but they are not (obviously) use the upstream solutions for that.

Right, they run on vendor kernels carrying out-of-tree i3cdev patches
based on an earlier version of this series, so there is no upstream ABI
to stay compatible with. This series already departs from that ABI
and v6 will change it further based on the review in this thread.

> But it's still unclear to me why this can't be moved to the kernel space?
> There is no user space that communicates with upstream kernel in the way
> you described, they should have used a custom (out-of-tree) solutions, right?

It could be, and the closest in kernel fit would be an OCP recovery
i3c_driver exposing fw_upload. But pushing an image is only one part of
the spec, and an in kernel driver would have to cover all of it, not
just the subset one recovery agent happens to use:

- status and identity: PROT_CAP, DEVICE_ID, DEVICE_STATUS (with
  recovery reason codes), RECOVERY_STATUS and HW_STATUS
- reset and boot control: DEVICE_RESET with forced recovery and
  flashless boot, and multi-stage activation through RECOVERY_CTRL
- memory spaces: code, critical logging and vendor-defined CMS
  regions, through either the indirect window or the FIFO interface
- the VENDOR command and vendor-specific status, which differ per
  SoC vendor

Which of these an agent uses, when to trigger recovery, and which image
goes with each stage all vary by platform, and the BMC's userspace
already makes those decisions.

An in-kernel driver would need new sysfs ABI for this, and that ABI
would have to grow as the spec evolves: v1.1 alone added multi-stage
activation, flashless boot and the indirect FIFO interface. With a
target-scoped transfer interface, none of that needs kernel changes.
fw_upload and lib/pldmfw fit well where a kernel driver already owns
the device; here the only consumer is the BMC's management stack.

The kernel already splits things this way on I3C for MCTP: mctp-i3c
binds by DCR and provides the transport, while PLDM firmware update
runs in userspace. i3cdev could be made to bind the same way, by the
OCP recovery DCR, instead of binding to every unbound target. Outside
I3C it is the same pattern: nvme-cli does NVMe firmware download/commit
through the passthrough ioctls, and fwupd updates devices over hidraw,
usbfs and drm_dp_aux_dev.

So the kernel side stays a small mechanism consisting of target-scoped
transfers to explicitly bound devices, and the recovery policy stays
in userspace, where it can follow new spec revisions without new kernel
ABI.

> > If you mean electrical bus recovery, i3cdev doesn't perform
> > bus-level electrical recovery. It only submits normal target-addressed
> > transfers via i3c_device_do_xfers().
>
> But how it will do if the i2c device blocks the i3c bus in mixed mode?
> I mean, how will it affect the i3c transfers on the wire?

Electrically speaking, SDA and SCL are shared, so an I2C target that
holds SDA low blocks every transfer on that bus, I3C and I2C alike,
regardless of which driver issued it. The controller reports the failure
as a NACK, arbitration loss or timeout, depending on the controller.
i3c_device_do_xfers() returns the error, and i3cdev passes it back to
userspace from the ioctl.

So i3cdev behaves the same as any in kernel I3C driver on that bus
since it uses the same transfer path. Getting a stuck bus released is
up to the controller driver rather than i3cdev. For what it's worth,
section 8.4.1 of the OCP recovery spec recommends a pure I3C bus for
critical recovery paths, and for mixed buses requires validating that
I2C targets have spike filters and considering isolating or
disabling the ones that can't. I2C devices on a mixed bus are also not
allowed to stretch the clock.

> > On a mixed bus, the Linux I3C core already
> > configures the bus mode/SCL rate according to the I2C targets' LVR
> > spike-filter capabilities and serializes both paths via
> > i3c_bus_normaluse_lock(&master->bus).
>
> Good to know, thanks!

One correction to my previous statements: i3c_bus_normaluse_lock() is
a shared lock that only excludes maintenance operations such as DAA.
The I2C and I3C transfers themselves are serialized by the master
driver's own locking, which is what keeps them from being interleaved
on the wire.


Thanks,
Sam

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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> > [...] production BMC firmware update
> > and recovery daemons running in OpenBMC server fleets (managing Caliptra
> > Root-of-Trust and SoC recovery targets over I3C), as well as production
> > server accelerator management daemons.
>
> Okay, but they are not (obviously) use the upstream solutions for that.

Right, they run on vendor kernels carrying out-of-tree i3cdev patches
based on an earlier version of this series, so there is no upstream ABI
to stay compatible with. This series already departs from that ABI
and v6 will change it further based on the review in this thread.

> But it's still unclear to me why this can't be moved to the kernel space?
> There is no user space that communicates with upstream kernel in the way
> you described, they should have used a custom (out-of-tree) solutions, right?

It could be, and the closest in kernel fit would be an OCP recovery
i3c_driver exposing fw_upload. But pushing an image is only one part of
the spec, and an in kernel driver would have to cover all of it, not
just the subset one recovery agent happens to use:

- status and identity: PROT_CAP, DEVICE_ID, DEVICE_STATUS (with
  recovery reason codes), RECOVERY_STATUS and HW_STATUS
- reset and boot control: DEVICE_RESET with forced recovery and
  flashless boot, and multi-stage activation through RECOVERY_CTRL
- memory spaces: code, critical logging and vendor-defined CMS
  regions, through either the indirect window or the FIFO interface
- the VENDOR command and vendor-specific status, which differ per
  SoC vendor

Which of these an agent uses, when to trigger recovery, and which image
goes with each stage all vary by platform, and the BMC's userspace
already makes those decisions.

An in-kernel driver would need new sysfs ABI for this, and that ABI
would have to grow as the spec evolves: v1.1 alone added multi-stage
activation, flashless boot and the indirect FIFO interface. With a
target-scoped transfer interface, none of that needs kernel changes.
fw_upload and lib/pldmfw fit well where a kernel driver already owns
the device; here the only consumer is the BMC's management stack.

The kernel already splits things this way on I3C for MCTP: mctp-i3c
binds by DCR and provides the transport, while PLDM firmware update
runs in userspace. i3cdev could be made to bind the same way, by the
OCP recovery DCR, instead of binding to every unbound target. Outside
I3C it is the same pattern: nvme-cli does NVMe firmware download/commit
through the passthrough ioctls, and fwupd updates devices over hidraw,
usbfs and drm_dp_aux_dev.

So the kernel side stays a small mechanism consisting of target-scoped
transfers to explicitly bound devices, and the recovery policy stays
in userspace, where it can follow new spec revisions without new kernel
ABI.

> > If you mean electrical bus recovery, i3cdev doesn't perform
> > bus-level electrical recovery. It only submits normal target-addressed
> > transfers via i3c_device_do_xfers().
>
> But how it will do if the i2c device blocks the i3c bus in mixed mode?
> I mean, how will it affect the i3c transfers on the wire?

Electrically speaking, SDA and SCL are shared, so an I2C target that
holds SDA low blocks every transfer on that bus, I3C and I2C alike,
regardless of which driver issued it. The controller reports the failure
as a NACK, arbitration loss or timeout, depending on the controller.
i3c_device_do_xfers() returns the error, and i3cdev passes it back to
userspace from the ioctl.

So i3cdev behaves the same as any in kernel I3C driver on that bus
since it uses the same transfer path. Getting a stuck bus released is
up to the controller driver rather than i3cdev. For what it's worth,
section 8.4.1 of the OCP recovery spec recommends a pure I3C bus for
critical recovery paths, and for mixed buses requires validating that
I2C targets have spike filters and considering isolating or
disabling the ones that can't. I2C devices on a mixed bus are also not
allowed to stretch the clock.

> > On a mixed bus, the Linux I3C core already
> > configures the bus mode/SCL rate according to the I2C targets' LVR
> > spike-filter capabilities and serializes both paths via
> > i3c_bus_normaluse_lock(&master->bus).
>
> Good to know, thanks!

One correction to my previous statements: i3c_bus_normaluse_lock() is
a shared lock that only excludes maintenance operations such as DAA.
The I2C and I3C transfers themselves are serialized by the master
driver's own locking, which is what keeps them from being interleaved
on the wire.


Thanks,
Sam

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Sun, Nov 08, 2026 at 10:11:52PM -0800, Sam Agazaryan wrote:

[...]

> > > production BMC firmware update and recovery daemons running in OpenBMC
> > > server fleets (managing Caliptra Root-of-Trust and SoC recovery targets
> > > over I3C), as well as production server accelerator management daemons.
> >
> > Okay, but they are not (obviously) use the upstream solutions for that.
> 
> Right, they run on vendor kernels carrying out-of-tree i3cdev patches
> based on an earlier version of this series, so there is no upstream ABI
> to stay compatible with. This series already departs from that ABI
> and v6 will change it further based on the review in this thread.
> 
> > But it's still unclear to me why this can't be moved to the kernel space?
> > There is no user space that communicates with upstream kernel in the way
> > you described, they should have used a custom (out-of-tree) solutions, right?
> 
> It could be, and the closest in kernel fit would be an OCP recovery
> i3c_driver exposing fw_upload. But pushing an image is only one part of
> the spec, and an in kernel driver would have to cover all of it, not
> just the subset one recovery agent happens to use:
> 
> - status and identity: PROT_CAP, DEVICE_ID, DEVICE_STATUS (with
>   recovery reason codes), RECOVERY_STATUS and HW_STATUS
> - reset and boot control: DEVICE_RESET with forced recovery and
>   flashless boot, and multi-stage activation through RECOVERY_CTRL
> - memory spaces: code, critical logging and vendor-defined CMS
>   regions, through either the indirect window or the FIFO interface
> - the VENDOR command and vendor-specific status, which differ per
>   SoC vendor

Good. We can see that being implemented step-by-step.

> Which of these an agent uses, when to trigger recovery, and which image
> goes with each stage all vary by platform, and the BMC's userspace
> already makes those decisions.

Based on the absence of any interface in the kernel before, there is no chance
to regress anything. It might be just a good will to try hard to support
existing out-of-tree solutions.

> An in-kernel driver would need new sysfs ABI for this, and that ABI
> would have to grow as the spec evolves: v1.1 alone added multi-stage
> activation, flashless boot and the indirect FIFO interface. With a
> target-scoped transfer interface, none of that needs kernel changes.
> fw_upload and lib/pldmfw fit well where a kernel driver already owns
> the device; here the only consumer is the BMC's management stack.

Yes, and I see no issues with that. Opening the whole i3cdev just for the same
reason sounds like an overkill. Especially if we do *not* expect any more users.

> The kernel already splits things this way on I3C for MCTP: mctp-i3c
> binds by DCR and provides the transport, while PLDM firmware update
> runs in userspace. i3cdev could be made to bind the same way, by the
> OCP recovery DCR, instead of binding to every unbound target. Outside
> I3C it is the same pattern: nvme-cli does NVMe firmware download/commit
> through the passthrough ioctls, and fwupd updates devices over hidraw,
> usbfs and drm_dp_aux_dev.
> 
> So the kernel side stays a small mechanism consisting of target-scoped
> transfers to explicitly bound devices, and the recovery policy stays
> in userspace, where it can follow new spec revisions without new kernel
> ABI.

If there are success stories, those examples might help to justify your
approach. It makes sense to mention that in the cover letter with the
summary on their designs (and split).

> > > If you mean electrical bus recovery, i3cdev doesn't perform
> > > bus-level electrical recovery. It only submits normal target-addressed
> > > transfers via i3c_device_do_xfers().
> >
> > But how it will do if the i2c device blocks the i3c bus in mixed mode?
> > I mean, how will it affect the i3c transfers on the wire?
> 
> Electrically speaking, SDA and SCL are shared, so an I2C target that
> holds SDA low blocks every transfer on that bus, I3C and I2C alike,
> regardless of which driver issued it. The controller reports the failure
> as a NACK, arbitration loss or timeout, depending on the controller.
> i3c_device_do_xfers() returns the error, and i3cdev passes it back to
> userspace from the ioctl.
> 
> So i3cdev behaves the same as any in kernel I3C driver on that bus
> since it uses the same transfer path. Getting a stuck bus released is
> up to the controller driver rather than i3cdev. For what it's worth,
> section 8.4.1 of the OCP recovery spec recommends a pure I3C bus for
> critical recovery paths, and for mixed buses requires validating that
> I2C targets have spike filters and considering isolating or
> disabling the ones that can't. I2C devices on a mixed bus are also not
> allowed to stretch the clock.

-- 
With Best Regards,
Andy Shevchenko



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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Andy Shevchenko]

On Sun, Nov 08, 2026 at 10:11:52PM -0800, Sam Agazaryan wrote:

[...]

> > > production BMC firmware update and recovery daemons running in OpenBMC
> > > server fleets (managing Caliptra Root-of-Trust and SoC recovery targets
> > > over I3C), as well as production server accelerator management daemons.
> >
> > Okay, but they are not (obviously) use the upstream solutions for that.
> 
> Right, they run on vendor kernels carrying out-of-tree i3cdev patches
> based on an earlier version of this series, so there is no upstream ABI
> to stay compatible with. This series already departs from that ABI
> and v6 will change it further based on the review in this thread.
> 
> > But it's still unclear to me why this can't be moved to the kernel space?
> > There is no user space that communicates with upstream kernel in the way
> > you described, they should have used a custom (out-of-tree) solutions, right?
> 
> It could be, and the closest in kernel fit would be an OCP recovery
> i3c_driver exposing fw_upload. But pushing an image is only one part of
> the spec, and an in kernel driver would have to cover all of it, not
> just the subset one recovery agent happens to use:
> 
> - status and identity: PROT_CAP, DEVICE_ID, DEVICE_STATUS (with
>   recovery reason codes), RECOVERY_STATUS and HW_STATUS
> - reset and boot control: DEVICE_RESET with forced recovery and
>   flashless boot, and multi-stage activation through RECOVERY_CTRL
> - memory spaces: code, critical logging and vendor-defined CMS
>   regions, through either the indirect window or the FIFO interface
> - the VENDOR command and vendor-specific status, which differ per
>   SoC vendor

Good. We can see that being implemented step-by-step.

> Which of these an agent uses, when to trigger recovery, and which image
> goes with each stage all vary by platform, and the BMC's userspace
> already makes those decisions.

Based on the absence of any interface in the kernel before, there is no chance
to regress anything. It might be just a good will to try hard to support
existing out-of-tree solutions.

> An in-kernel driver would need new sysfs ABI for this, and that ABI
> would have to grow as the spec evolves: v1.1 alone added multi-stage
> activation, flashless boot and the indirect FIFO interface. With a
> target-scoped transfer interface, none of that needs kernel changes.
> fw_upload and lib/pldmfw fit well where a kernel driver already owns
> the device; here the only consumer is the BMC's management stack.

Yes, and I see no issues with that. Opening the whole i3cdev just for the same
reason sounds like an overkill. Especially if we do *not* expect any more users.

> The kernel already splits things this way on I3C for MCTP: mctp-i3c
> binds by DCR and provides the transport, while PLDM firmware update
> runs in userspace. i3cdev could be made to bind the same way, by the
> OCP recovery DCR, instead of binding to every unbound target. Outside
> I3C it is the same pattern: nvme-cli does NVMe firmware download/commit
> through the passthrough ioctls, and fwupd updates devices over hidraw,
> usbfs and drm_dp_aux_dev.
> 
> So the kernel side stays a small mechanism consisting of target-scoped
> transfers to explicitly bound devices, and the recovery policy stays
> in userspace, where it can follow new spec revisions without new kernel
> ABI.

If there are success stories, those examples might help to justify your
approach. It makes sense to mention that in the cover letter with the
summary on their designs (and split).

> > > If you mean electrical bus recovery, i3cdev doesn't perform
> > > bus-level electrical recovery. It only submits normal target-addressed
> > > transfers via i3c_device_do_xfers().
> >
> > But how it will do if the i2c device blocks the i3c bus in mixed mode?
> > I mean, how will it affect the i3c transfers on the wire?
> 
> Electrically speaking, SDA and SCL are shared, so an I2C target that
> holds SDA low blocks every transfer on that bus, I3C and I2C alike,
> regardless of which driver issued it. The controller reports the failure
> as a NACK, arbitration loss or timeout, depending on the controller.
> i3c_device_do_xfers() returns the error, and i3cdev passes it back to
> userspace from the ioctl.
> 
> So i3cdev behaves the same as any in kernel I3C driver on that bus
> since it uses the same transfer path. Getting a stuck bus released is
> up to the controller driver rather than i3cdev. For what it's worth,
> section 8.4.1 of the OCP recovery spec recommends a pure I3C bus for
> critical recovery paths, and for mixed buses requires validating that
> I2C targets have spike filters and considering isolating or
> disabling the ones that can't. I2C devices on a mixed bus are also not
> allowed to stretch the clock.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> > An in-kernel driver would need new sysfs ABI for this, and that ABI
> > would have to grow as the spec evolves: v1.1 alone added multi-stage
> > activation, flashless boot and the indirect FIFO interface. With a
> > target-scoped transfer interface, none of that needs kernel changes.
> > fw_upload and lib/pldmfw fit well where a kernel driver already owns
> > the device; here the only consumer is the BMC's management stack.
>
> Yes, and I see no issues with that. Opening the whole i3cdev just for the same
> reason sounds like an overkill. Especially if we do *not* expect any more users.

OCP recovery isn't the only user. In her thread, Meagan described a
separate one [1]: accelerator cards that plug into different server
SKUs, where the I3C hubs and devices on the bus can differ per SKU, so
the hub setup has to be discovered and programmed from userspace at
runtime instead of being fixed in devicetree. She posted her own i3cdev
series and can speak to the details better than I can.

Also, with the explicit binding planned for v6, i3cdev would not open
the whole bus. It would only bind device classes listed in its ID
table, starting with the OCP recovery DCR, and any other class would
have to be added there deliberately, with its own justification.

> If there are success stories, those examples might help to justify your
> approach. It makes sense to mention that in the cover letter with the
> summary on their designs (and split).

Will do. I'll summarize in the v6 cover letter.

[1] https://lore.kernel.org/linux-i3c/20260924-86692413bdae0e78a12c1425@linux.microsoft.com/

Thanks,
Sam

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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Sam Agazaryan]

> > An in-kernel driver would need new sysfs ABI for this, and that ABI
> > would have to grow as the spec evolves: v1.1 alone added multi-stage
> > activation, flashless boot and the indirect FIFO interface. With a
> > target-scoped transfer interface, none of that needs kernel changes.
> > fw_upload and lib/pldmfw fit well where a kernel driver already owns
> > the device; here the only consumer is the BMC's management stack.
>
> Yes, and I see no issues with that. Opening the whole i3cdev just for the same
> reason sounds like an overkill. Especially if we do *not* expect any more users.

OCP recovery isn't the only user. In her thread, Meagan described a
separate one [1]: accelerator cards that plug into different server
SKUs, where the I3C hubs and devices on the bus can differ per SKU, so
the hub setup has to be discovered and programmed from userspace at
runtime instead of being fixed in devicetree. She posted her own i3cdev
series and can speak to the details better than I can.

Also, with the explicit binding planned for v6, i3cdev would not open
the whole bus. It would only bind device classes listed in its ID
table, starting with the OCP recovery DCR, and any other class would
have to be added there deliberately, with its own justification.

> If there are success stories, those examples might help to justify your
> approach. It makes sense to mention that in the cover letter with the
> summary on their designs (and split).

Will do. I'll summarize in the v6 cover letter.

[1] https://lore.kernel.org/linux-i3c/20260924-86692413bdae0e78a12c1425@linux.microsoft.com/

Thanks,
Sam

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Alexandre Belloni]

On 22/10/2026 17:17:20-0700, Sam Agazaryan wrote:
> > On my side, I believe i3cdev can be added to the kernel and that it is
> > way safer than i2cdev but I agree that the ABI has to be properly
> > designed, maybe we need to version it or have a way to probe for
> > supported features so we can update safely later on. It is failry simple
> > right now but I feel like we are going to see people with more needs
> > than initiating transfers.
> 
> For feature probing and ABI extension, what do you think of:
> 
> 1. Adding an extensible I3C_IOC_GET_CAPS ioctl:
> 
>    struct i3c_ioc_caps {
>        __u32 size; /* sizeof(struct i3c_ioc_caps) */
>        __u32 pad;  /* must be 0 */
>        __u64 caps; /* Bitmask of supported I3C_CAP_* features */
>    };
> 
>    Today caps can report the transfer modes supported by the controller
>    and target (I3C_CAP_SDR, I3C_CAP_HDR_DDR, I3C_CAP_HDR_TSP,
>    I3C_CAP_HDR_TSL), and new bits in caps (or new fields appended to
>    the end of the struct) can advertise future capabilities beyond basic
>    transfers.

This works but my point was also that we need to expose the i3cdev
capabilities so userspace can discover what is available. I guess we can
assume .read and .write are going to always be available and so this is
fine for now.

> 
> 2. In struct i3c_ioc_xfer, we already have __u8 pad[2] at the end which
>    is strictly checked to be 0 (-EINVAL if non-zero), reserving 16 bits
>    for future per-transfer flags without changing the struct size.
> 
> > Also, I think this should not bind to any devices by default and make
> > binding explicit.
> 
> This seems to be the consensus so far. I can convert i3cdev from a bus
> notifier into a standard struct i3c_driver so it does not auto-attach
> to all unbound targets on boot or on unbind while dropping patches 1
> and 2.
> 
> Since Greg KH noted earlier [1] that driver_override / manual sysfs
> bind is only for debugging and will taint the kernel in the near
> future, what do you think of:
> 
> Matching explicit opt-in entries in i3cdev's i3c_device_id table (starting
> with 0xBD for OCP Secure Firmware Recovery), and optionally
> exposing a new_id sysfs attribute on the i3cdev driver for dynamically
> adding target IDs at runtime? That also keeps everything self-contained
> in i3cdev without needing cross-subsystem changes to hwmon/iio drivers.
> 

We can add new_id later if necessary.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Alexandre Belloni]

On 22/10/2026 17:17:20-0700, Sam Agazaryan wrote:
> > On my side, I believe i3cdev can be added to the kernel and that it is
> > way safer than i2cdev but I agree that the ABI has to be properly
> > designed, maybe we need to version it or have a way to probe for
> > supported features so we can update safely later on. It is failry simple
> > right now but I feel like we are going to see people with more needs
> > than initiating transfers.
> 
> For feature probing and ABI extension, what do you think of:
> 
> 1. Adding an extensible I3C_IOC_GET_CAPS ioctl:
> 
>    struct i3c_ioc_caps {
>        __u32 size; /* sizeof(struct i3c_ioc_caps) */
>        __u32 pad;  /* must be 0 */
>        __u64 caps; /* Bitmask of supported I3C_CAP_* features */
>    };
> 
>    Today caps can report the transfer modes supported by the controller
>    and target (I3C_CAP_SDR, I3C_CAP_HDR_DDR, I3C_CAP_HDR_TSP,
>    I3C_CAP_HDR_TSL), and new bits in caps (or new fields appended to
>    the end of the struct) can advertise future capabilities beyond basic
>    transfers.

This works but my point was also that we need to expose the i3cdev
capabilities so userspace can discover what is available. I guess we can
assume .read and .write are going to always be available and so this is
fine for now.

> 
> 2. In struct i3c_ioc_xfer, we already have __u8 pad[2] at the end which
>    is strictly checked to be 0 (-EINVAL if non-zero), reserving 16 bits
>    for future per-transfer flags without changing the struct size.
> 
> > Also, I think this should not bind to any devices by default and make
> > binding explicit.
> 
> This seems to be the consensus so far. I can convert i3cdev from a bus
> notifier into a standard struct i3c_driver so it does not auto-attach
> to all unbound targets on boot or on unbind while dropping patches 1
> and 2.
> 
> Since Greg KH noted earlier [1] that driver_override / manual sysfs
> bind is only for debugging and will taint the kernel in the near
> future, what do you think of:
> 
> Matching explicit opt-in entries in i3cdev's i3c_device_id table (starting
> with 0xBD for OCP Secure Firmware Recovery), and optionally
> exposing a new_id sysfs attribute on the i3cdev driver for dynamically
> adding target IDs at runtime? That also keeps everything self-contained
> in i3cdev without needing cross-subsystem changes to hwmon/iio drivers.
> 

We can add new_id later if necessary.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH v5 0/5] i3c: add i3cdev module to expose i3c dev in /dev

[Pathak, Asutosh]

Hi Sam,

Alexandre pointed me at this series. I'm working on a driver for the USB-I3C
device class (USB class 0x3C) - a USB device that acts as an I3C controller,
with a host-side tool (OpenIPC) that drives the bus from userspace. The master
part registers normally, so its targets would show up as i3cdev nodes and we'd
rather use I3C_IOC_XFER than carry our own ioctls. So +1 on the direction.

A few things we need that the current UAPI doesn't cover yet - wanted to raise
them now rather than after it lands:

1. IBIs to userspace. Our main use case is reacting to target interrupts, but
   i3cdev is transfer-only today. We'd need a way to get IBIs (and ideally
   hot-join) delivered to the fd - poll()/read() of an event, or similar.
   This is the big one for us.

2. Larger transfers. len/actual_len are u16 and I3C_IOC_XFER caps the count.
   Our bulk flows go past 64K, so we'd want either a larger width or a
   documented way to split without dropping the bus lock mid-sequence.

3. Explicit opt-in over auto-attach. For bring-up/validation we don't want a
   node appearing just because a driver got unbound - Meagan's driver_override
   approach fits us better, and it also answers Andy's HW-damage concern.

4. CCCs from userspace. The union { rnw; cmd; } looks like it's meant for this -
   just confirming direct/broadcast CCCs are in scope, since our tooling needs
   them.

Happy to help with (1) if you want - it's the piece we care about most and I
suspect the recovery/BMC folks could use it too. Not trying to expand the scope
of v5, just flagging so the ABI leaves room.

Thanks,
Asutosh

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