Re: [PATCH net-next v10 6/9] net: phy: phy_port: Store information about a MII port's vacant state

[Maxime Chevallier]

On 5/15/26 15:12, Andrew Lunn wrote:

> My comment is really about, what do we mean by vacant/empty?

Ah yes got it :)

> Is it simply about there physically being a module in the cage, or is
> it also about being able to drive that module? If it is just about
> there being a module in the cage, then vacant/empty is good. If we
> also want to say that we have been able to read out the EEPROM and
> determined the module will work in combination with the PCS and MAC,
> then i would probably use a different name. "usable", "compatible"?

So the direction I have in mind in the first one. We have a device with
a port that's an SFP cage. It has its set of capabilities, in this case
they are a set of phy_interface_t that you can use in that cage. It's 
empty/vacane withouy any modue in it.

Now you insert a module, the SFP cages is still there, same 
capabilities, but there's a new physical front-facing MDI, with its set 
of capabilities (baseT, 100FX, you name it). Now the SFP cage isn't 
vacant anymore.

I'd say, if we can't read the eeprom, or if we insert an incompatible 
module (10G module on 1000BaseX port for example), the SFP cage stays
non-vacant. The port corresponding to the module itself may or may not 
be created (depending on the error, the more we can tell the user the 
better IMO).

> Either way, i think the code either needs simplifying, or made more
> complex.

So, I think the direction will be "let's make it simpler" :)

Maxime

> 	Andrew