Since the SMBus Address Resolution Protocol (ARP) is now
supported with all I2C host adapters, every ARP-capable MCTP
device will get automatically enumerated. Those devices just
need to be bind to this driver.

The SMBus ARP-capable MCTP devices are identified by
checking the interface (MCTP SMBus/I2C Transport Binding
Specification section 6.5). The interface must match the ASF
protocol, so all devices that use the ASF protocol as their
interface will be probed by this driver.

Link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0237_1.2.0.pdf
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
 drivers/net/mctp/mctp-i2c.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/net/mctp/mctp-i2c.c b/drivers/net/mctp/mctp-i2c.c
index 8043b57bdf25..47d7f6b5212e 100644
--- a/drivers/net/mctp/mctp-i2c.c
+++ b/drivers/net/mctp/mctp-i2c.c
@@ -21,6 +21,7 @@
 #include <linux/netdevice.h>
 #include <linux/i2c.h>
 #include <linux/i2c-mux.h>
+#include <linux/i2c-smbus.h>
 #include <linux/if_arp.h>
 #include <net/mctp.h>
 #include <net/mctpdevice.h>
@@ -1105,6 +1106,12 @@ static const struct i2c_device_id mctp_i2c_id[] = {
 };
 MODULE_DEVICE_TABLE(i2c, mctp_i2c_id);
 
+static const struct smbus_device_id mctp_smbus_id[] = {
+	{ SMBUS_INTERFACE_ASF },
+	{}
+};
+MODULE_DEVICE_TABLE(smbus, mctp_smbus_id);
+
 static const struct of_device_id mctp_i2c_of_match[] = {
 	{ .compatible = "mctp-i2c-controller" },
 	{},
@@ -1119,6 +1126,7 @@ static struct i2c_driver mctp_i2c_driver = {
 	.probe = mctp_i2c_probe,
 	.remove = mctp_i2c_remove,
 	.id_table = mctp_i2c_id,
+	.smbus_id_table = mctp_smbus_id,
 };
 
 static __init int mctp_i2c_mod_init(void)
-- 
2.50.1

On 1/21/26 10:23 AM, Heikki Krogerus wrote:
> Since the SMBus Address Resolution Protocol (ARP) is now
> supported with all I2C host adapters, every ARP-capable MCTP
> device will get automatically enumerated. Those devices just
> need to be bind to this driver.
> 
> The SMBus ARP-capable MCTP devices are identified by
> checking the interface (MCTP SMBus/I2C Transport Binding
> Specification section 6.5). The interface must match the ASF
> protocol, so all devices that use the ASF protocol as their
> interface will be probed by this driver.
> 
> Link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0237_1.2.0.pdf
> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>

This patch depends on 1/4 but it looks like it could be a follow-up to
the main series. If so, I think it would be better to re-submit it after
the relevant code landed in net-next to avoid cross sub-tree problems.

Otherwise I think it should go via I2C tree - and we will solve
conflicts as needed later on.

Thanks,

Paolo

On Thu, 22 Jan 2026 15:36:05 +0100 Paolo Abeni wrote:
> On 1/21/26 10:23 AM, Heikki Krogerus wrote:
> > Since the SMBus Address Resolution Protocol (ARP) is now
> > supported with all I2C host adapters, every ARP-capable MCTP
> > device will get automatically enumerated. Those devices just
> > need to be bind to this driver.
> > 
> > The SMBus ARP-capable MCTP devices are identified by
> > checking the interface (MCTP SMBus/I2C Transport Binding
> > Specification section 6.5). The interface must match the ASF
> > protocol, so all devices that use the ASF protocol as their
> > interface will be probed by this driver.
> > 
> > Link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0237_1.2.0.pdf
> > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>  
> 
> This patch depends on 1/4 but it looks like it could be a follow-up to
> the main series. If so, I think it would be better to re-submit it after
> the relevant code landed in net-next to avoid cross sub-tree problems.
> 
> Otherwise I think it should go via I2C tree - and we will solve
> conflicts as needed later on.

+1 I don't wanna speak for Jeremy and Matt but with their Ack, and
assuming there's no dependency in net-next I think i2c tree may
be the easiest path? There isn't much code in the series under
drivers/net.

Hi Heikki and Jakub,

> +1 I don't wanna speak for Jeremy and Matt but with their Ack, and
> assuming there's no dependency in net-next I think i2c tree may
> be the easiest path?

Yes, given this is more i2c- than net-related, I would be fine for the
changes to go via the i2c tree there. Staging the core via i2c and then
(subsequently) this one via net would also work, but seems to be
overkill for a minor change to the net driver.

I have some overall comments on the i2c side though, I'll follow up with
those separately.

Cheers,


Jeremy

Fri, Jan 23, 2026 at 11:18:42AM +1100, Jeremy Kerr kirjoitti:
> Hi Heikki and Jakub,
> 
> > +1 I don't wanna speak for Jeremy and Matt but with their Ack, and
> > assuming there's no dependency in net-next I think i2c tree may
> > be the easiest path?
> 
> Yes, given this is more i2c- than net-related, I would be fine for the
> changes to go via the i2c tree there. Staging the core via i2c and then
> (subsequently) this one via net would also work, but seems to be
> overkill for a minor change to the net driver.

OK. I'll drop this one from v3 and send it separately later as a
follow-up, once we have the i2c side ready.

> I have some overall comments on the i2c side though, I'll follow up with
> those separately.

thanks,

-- 
heikki

On Fri, 23 Jan 2026 10:46:38 +0200 Heikki Krogerus wrote:
> > > +1 I don't wanna speak for Jeremy and Matt but with their Ack, and
> > > assuming there's no dependency in net-next I think i2c tree may
> > > be the easiest path?  
> > 
> > Yes, given this is more i2c- than net-related, I would be fine for the
> > changes to go via the i2c tree there. Staging the core via i2c and then
> > (subsequently) this one via net would also work, but seems to be
> > overkill for a minor change to the net driver.  
> 
> OK. I'll drop this one from v3 and send it separately later as a
> follow-up, once we have the i2c side ready.

FWIW my reading of Jeremy's reply was that we're okay with these
patches going via i2c, so:

Acked-by: Jakub Kicinski <kuba@kernel.org>

and no need to drop this from the series.