[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 at 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