Message-ID: <aXjDENOsmWe5_VqS@kuha>
Date: Tue, 27 Jan 2026 15:52:16 +0200
From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To: Jeremy Kerr <jk@...econstruct.com.au>
Cc: Wolfram Sang <wsa+renesas@...g-engineering.com>,
	Matt Johnston <matt@...econstruct.com.au>,
	linux-i2c@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/4] i2c: SMBus ARP support

Hi,

Tue, Jan 27, 2026 at 08:32:24AM +0800, Jeremy Kerr wrote:
> Hi Heikki,
> 
> > 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?

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

Powered by blists - more mailing lists