[RFC PATCH 0/2] I3C MCTP net driver

Jeremy Kerr jk at codeconstruct.com.au
Sun May 14 19:29:22 PDT 2023


Hi Iwona,

> > However: I would think it would be much simpler to just put the two
> > devices on the same i3c bus on the same MCTP network, and assign
> > distinct EIDs. Whether those devices could communicate can be defined by
> > bridging policy.
> 
> The only reason why I believe it would be possible for someone to come up with
> such network layout would be the limited amount of EIDs available in MCTP 1.x,
> in which case putting everything in the same MCTP network won't be an option.

Yep, that's the reason why we implemented networks in the initial core
code - it's likely that we'll hit the EID limits at some point.

> I'm bringing this up, since I originally considered device-driver model that
> goes with network controller per I3C device.
> I think this is the only case in which it can be more complicated to model.
> I just want to avoid a situation where we paint ourselves into a corner, and the
> VLAN-like approach sounds good to me (if we ever end up needing it).

OK, neat - I think we have a plan should we need to represent the i3c
"logical bus" in future then.

> > The former is definitely simpler, and was what I had originally
> > intended, but may not cover all use-cases. I'd be interested in your
> > thoughts there.
> 
> Currently, I don't see any use cases where a "forwarding" boolean flag wouldn't
> be enough, but we can go back to this in the future when we add bridging
> support.

Sounds good then, thanks for the input!

Cheers,


Jeremy



More information about the linux-i3c mailing list