Hi,

Tue, Jan 27, 2026 at 08:32:24AM +0800, Jeremy Kerr wrote:

Hi Heikki,

quoted

Since we use kernel mode device drivers, we need the kernel device
instances (struct device) that bind to them. If you want to deal with
user mode drivers then you can always do that with the i2c-dev
interface, but then you will not be using the kernel drivers such as
the mctp-i2c.c in this case.

Sure you could - the userspace ARP implementation would be responsible
for binding an existing kernel driver to the newly-allocated dynamic i2c
address - say, through the new_device interface. The choice of driver
would typically depend on the enumerated UDID.

Uh, no. You should only use interfaces like new_device with the
devices that really can't be detected in kernel, which isn't the case
here. There is nothing preventing the kernel from detecting the ARP
devices.

So that really can not be the solution that we'll use with these
devices, but regardless of that, relying on user space in general with
the ARP protocol has considerable challenges that I don't see that
could be solved easily:

- You still need to deliver the UDID to the kernel because of things
  like the PEC flag, and the drivers will also need information from
  it.
- With the static (not hotplugged) devices you need to assign the
  correct ACPI node (or what ever fwnode) to the ARP-device.
- When the device is hotplugged, you would need new ABI, like I think
  you already noticed, but this really does not make any sense. We
  simply don't need it, because the kernel can process this
  information on its own very simply.

On top of those there were concerns, like what if an ARP-device is
needed relatively early on during the system bootup, but I don't
actually know how big issues things like that are.

But in any case, I don't think you would ever be able to make the ARP
work from user space except with the simples cases (possibly not
reliable even with those because of things like the PEC flag) which is
not enough.

So why would you want involve the user space at all since it would
just add complexity and limitations without any benefits? The SMBus
ARP is a standard, and _simple_, method of enumerating devices, so why
in earth would you not just let the kernel always take care of it?

quoted

But just to be clear, this is not only
about MCTP. The ARP-capable i2c-clients can be anything.

Yes, I'm not just talking about MCTP here either.

quoted

So even if you still want to scan the ARP-devices in user space
separately, the kernel must enumerate those devices independently in
any case.

I should also point out that to my surprise the i2c-dev interface
(I2C_CHARDEV) isn't always enabled, even when I2C seems to be
otherwise fully supported in the kernel. We simply can't assume that
it's always available.

I don't think requiring a specific functionality to be enabled would be
a showstopper for any particular implementation. We need CONFIG_I2C
already, why is CONFIG_I2C_CHARDEV any different?

Oh, if I just had the power, I would place this requirement on
everyone and everything. Unfortunately I don't have that power :(

I think this would mean that either we take care of the ARP
enumeration in kernel, like honestly it really has to be done
(regardless of this requirement), or we have to continue maintaining
(and adding :-( ) the code in the drivers and board files that create
the i2c-clients for these devices.

Br,

-- 
heikki