[RFC PATCH 0/2] I3C MCTP net driver

[Jeremy Kerr]

Hi Iwona,

> Wouldn't creating "mctpi3cX" network interface for each I3C device rather than
> I3C bus be a better fit to model MCTP over I3C?

Great question! A few reasons for this structure:

 - it is a closer match to existing usage of network interfaces and
   remote endpoints (say, IP, CAN, etc): you have an interface for
   representing the local hardware and stack state, which may provide a
   path for any devices reachable through that hardware.

 - a simpler addressing structure: you only need one *local* MCTP
   address (EID) for the whole bus, rather that one per remote device.

 - the presence/absence of interfaces is not dependent on what's
   connected to the bus. If we used a netdev per remote device, users
   would not be able to set up the local stack until a remote endpoint
   is bound (ie, userspace would need to configure every interface on
   i3c hot join). With this model, that stack state can persist over
   whatever may be happening to remote devices (unplug, reset,
   re-addressing, etc).

 - if there is ever a proposal for broadcast messages in the i3c
   transport binding, we would have to re-write it in this structure
   anyway.

> Why are we following the mctp-i2c approach rather than mctp-serial?

mctp-serial follows the same model: the local device is always present,
the difference here being that no physical addressing is required.
Routes to remote endpoints are added depending on remote endpoint state,
but the local state is preserved regardless of what is (or is not) on
the other end of the link.

> This would also simplify the series, as we would no longer need "mctp-
> controller" property, and the driver would just follow the I3C class driver
> model without the need for notifiers.

It would simplify the series, but we would be punting a lot of those
complexities over to userspace.

Cheers,


Jeremy