On Mon, Aug 21, 2023 at 02:46:53PM -0400, Sean Anderson wrote: > After further review, it seems the reason 28g can get away without this > is because there's a one-to-one mapping between protocol controllers and > lanes. Unfortunately, that regularity is not present for 10g. > > --Sean There are some things I saw in your phy-fsl-lynx-10g.c driver and device tree bindings that I don't understand (the concept of lane groups), and I'm not sure if they're related with what you're saying here, so if you could elaborate a bit more (ideally with an example) on the one-to-one mapping and the specific problems it causes, it would be great. I may be off with my understanding of the regularity you are talking about, but the LX2160 (and Lynx 28G block) also has multi-lane protocols like 40G, 100G, assuming that's what you are talking about. I haven't started yet working on those for the mtip_backplane driver, but I'm not currently seeing a problem with the architecture where a phy_device represents a single lane that's part of a multi-lane port, and not an entire group. In my imagination, there are 2 cases: - all 4 lanes are managed by the single dpaa2-mac consumer (which has 4 phandles, and iterates over them with a "for" loop) - each of the 4 lanes is managed by the respective backplane AN/LT core, and thus, there's one phandle to each lane I sketched some dt-bindings for the second case here, so I guess it must be the first scenario that's somehow problematic? https://patchwork.kernel.org/project/netdevbpf/patch/20230817150644.3605105-9-vladimir.oltean@xxxxxxx/
