Re: [PATCH 3/3] i3c: add i3cdev character device module for user-space access

[Meagan Lloyd <meaganlloyd@linux.microsoft.com>]

On Thu, Sep 17, 2026 at 08:49:40AM +0300, Andy Shevchenko wrote:
> On Wed, Sep 16, 2026 at 03:57:10PM -0700, Meagan Lloyd wrote:
> > On Sat, Sep 12, 2026 at 04:34:01PM +0300, Andy Shevchenko wrote:
> > > On Fri, Sep 11, 2026 at 02:09:35PM -0700, Meagan Lloyd wrote:
> > > > The i3cdev driver is a character device driver that allows user-space
> > > > to control and interact with I3C devices.
> > > 
> > > > Currently, it has the ability to perform Single Data Rate (SDR)
> > > > transfers - basic reads/writes.
> > > > 
> > > > With the addition of sysfs driver_override, there is now a
> > > > straightforward and direct way to match the i3cdev driver to any i3c
> > > > device without stepping on the toes of more specialized drivers that are
> > > > loaded automatically.
> > > 
> > > Is it safe? Why on the earth do we need this? The commit message has not enough
> > > information.
> > 
> > I can't see a reason that it'd be unsafe. To give additional confidence,
> > it's already in-use in many bus_types:
> 
> This argument has nothing to do with i³c. Each bus is different on a physical
> layer, electrical protocols and programming flow. Each of them has own
> constraints.
> 

(resending as my previous reply hit a snag and is probably marked as
spam for most people)

My take is that if you're using the i3cdev module, it's up to the
programmer to review schematics/datasheets to know how to program
the hardware devices and bus (in the case of hubs) correctly.

Note, this thread's driver_override approach was not favored by the i3c
subsystem reviewers, so please continue any further discussion in the
prevailing approach's thread:
https://lore.kernel.org/linux-i3c/20260921230603.2518652-1-samagazaryan@google.com/T/#mb42d9b2785f8508d39eaf782b3d29189226b8029

> > To answer why we need it:
> > If we want to write i3cdev as a standard device driver, it can't
> > actually match anything by default. This is because, some devices on the
> > system may need specific drivers and i3cdev is generic and should
> > technically match every device.
> 
> Yes, but I have seen no reason why we should expose i³c bus to the user
> space. With i²c we already know very well that it was (and still is)
> a bad idea. Why i³c is better (especially taking into account i²c
> compatible mode and more complex programming flow)?
> 

cc'ing Andi Shyti from I2C subsystem for context.

Andi, we're considering an I3C character device driver interface.
If you have any feedback from your experience with I2C, can you
please share it in:
https://lore.kernel.org/linux-i3c/20260921230603.2518652-1-samagazaryan@google.com/T/#mb42d9b2785f8508d39eaf782b3d29189226b8029

> > Since the driver_override is default NULL and is set via sysfs, this
> > allows any specific drivers on boot to be loaded up and would allow
> > explicit control on what device i3cdev gets bound to.
> > 
> > This was my rational. I will refine the commit message with more details.
> 
> Put a real life example why the exposing i³c devices into user space is
> absolutely necessary.
> 

I'm supporting a kernel running on accelerator cards that plug into
various server SKUs where hubs/devices along the bus are not physically
on the card & may differ across SKUs. So, I'm looking to program hubs
flexibly and dynamically from userspace to setup bus hardware paths.

The hub drivers being posted to i3c subsystem require hard-coding in the
devicetree to setup the ports physically according to intended
bus/hardware design. As mentioned, these cards will not know what SKU it
will be plugged into, so the devicetree hard-coding cannot reasonably be
determined ahead of time. Theoretically, you may be able to add some
bootloader support to go query SKU information from other server
components and then populate the devicetree for the kernel, but that
will require heavy lifting and plumbing between other server firmware
components and the bootloader.

Further replies and discussion can be routed here:
https://lore.kernel.org/linux-i3c/20260921230603.2518652-1-samagazaryan@google.com/T/#mb42d9b2785f8508d39eaf782b3d29189226b8029

Thank you,
Meagan

> > > > This is accomplished by the i3cdev driver not having any entries in
> > > > the i3c_device_id table. After boot, simply set the driver_override
> > > > to "i3cdev" and bind the device manually via the sysfs bind knob.
> > > > This can also be automated with udev rules as well.
> > > > 
> > > > The character device interface will be exposed at: /dev/bus/i3c/<bus
> > > > id>-<Provisional ID>
> 
> ...
> 
> > > > +	for (int i = 0; i < metadata->nxfers; i++) {
> > > 
> > > Why is 'i' signed?
> 
> > Mostly for readability and to make sure the line length on loop headers
> > is kept below 80 chars. As a precaution, to make sure that 'i' can
> > represent any metadata->nxfers value without overflow during loops, I
> > check that metadata->nxfers is less than/equal to INT_MAX in
> > get_metadata().
> 
> No need to add useless checks.
> 
> ...
> 
> > > > +/** + * print_i3c_err() - Prints the I3C error encountered during
> > > > the prior + * call to the core's transfer function.  + * @i3cdev:
> > > > i3cdev_data object + * @metadata: Kernel's copy of i3cdev_xfers
> > > > (ioctl I3CDEV_XFER input) + * @i3c_xfers: i3c_xfer array that was
> > > > sent to the I3C core
> > > 
> > > > + * Returns: void
> > > 
> > > Huh?! Where is this coming from?
> > 
> > In i3cdev_ioctl_do_xfers, if i3c_device_do_xfers failed, I wanted to
> > print out the first I3C controller error encountered. The controller
> > drivers can set this in the i3c_xfer.err field. Hence this function.
> > 
> > It's to aid debugging and provide useful error information.
> > I can certainly refine the wording on the print_i3c_err documentation
> > header to make this more clear.
> 
> My point is about kernel-doc. Why do we need the return section for void?
> Where it comes from?
> 
> > > > + */
> 
> ...
> 
> > > Please, rely less on AI and more on the common sense and
> > > proof-reading.
> 
> > I think I gave you the wrong impression. The new contributions in this
> > series were written and developed by me. I used AI for quality assurance
> > and cross-referencing. Since I incorporated some AI-flagged suggestions,
> > I tried to acknowledge that with the Assisted-by tag.
> 
> I see, then there is a room to improve the code. But the main question is
> why do we even need this whole interface to begin with?
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
> 
> 
> -- 
> linux-i3c mailing list
> linux-i3c@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-i3c