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

From: Andy Shevchenko

Date: Sat Sep 12 2026 - 09:39:40 EST


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.

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

...

> + struct i3c_xfer xfer = {
> + .rnw = I3C_WRITE

In such cases always leave a trailing comma. It will reduce possible churn in
the future.

> + };

...

> + return !ret ? len : ret;

My gosh, wouldn't Elvis just work naturally?

return ret ?: len;

...

> + for (int i = 0; i < metadata->nxfers; i++) {

Why is 'i' signed?

> + ret = copy_struct_from_user(k_uxfer,
> + sizeof(*k_uxfers),
> + uxfer,
> + metadata->xfer_size);
> + if (ret)
> + goto out_free_k_uxfers;
> +
> + /* Enforce that padding must be zero */
> + if (memchr_inv(k_uxfer->pad, 0, sizeof(k_uxfer->pad))) {
> + ret = -EINVAL;
> + goto out_free_k_uxfers;
> + }
> +
> + uxfer += metadata->xfer_size; /* u8 pointer so use xfer_size */
> + k_uxfer++; /* struct i3cdev_xfer pointer */
> + }

...

> + if (!ret)
> + total_bytes += i3c_xfers[i].len;
> + else
> + return ret;

Yeah, you really need to reconsider patterns you use in the code. Here 'else'
is redundant. Homework to understand how (#easy).

...

> +/**
> + * 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?

> + */

...

Please, rely less on AI and more on the common sense and proof-reading.

--
With Best Regards,
Andy Shevchenko