Re: [RFC net-next 0/4] ethtool: CMIS module diagnostic loopback support

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

Hello Andrew, BJörn,

On 25/02/2026 14:14, Andrew Lunn wrote:
>>> Suddenly does something else.
>>
>> Indeed!
>>
>>> Is this an ABI break? How do we make this reliable so implementing
>>> more loopbacks at different levels does not change how you use
>>> --set-loopback?
>>
>> Isn't this somewhat similar to what we have with ifindex/phy_index,
>> but potentially unstable when modules are swapped/changed?
> 
> If you hot plug hardware, a new PHY pops into existence, i don't think
> it is too unreasonable for the hot plugable parts to change ids. I
> would however expect the fixed parts to keep there IDs.

That's indeed the phy index behaviour.

> 
> But here we are talking about software, a kernel upgrade/downgrade
> causing the IDs to change.
>  
>> Instead of ids, use string name and/or topology indices (e.g.
>> phy_index)? All three -- owner, phy_index, name tuple?

The overall approach after all these discussions sounds fine to me, I do
think that the index of the component that does the loopback needs to be
there somewhere, when relevant.

Either through a name string, or a combo of an enum indicating the
component type (MAC/PHY/Module/etc.) + its index. I think it's safe to
assume that indices will fit in u32 ?

something like :

# MAC PCS loopback
ethtool --set-loopback eth0 loc mac name pcs

# PHY id 2 PMA loopback (I'm making things up here)
ethtool --set-loopback eth0 loc phy id 2 name pma

That way we can extend that fairly easily for, say, combo-port devices
where we could select which of the port we want to loopback :)

Maxime