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

[Andrew Lunn <andrew@lunn.ch>]

On Fri, May 15, 2026 at 09:22:29AM +0200, Maxime Chevallier wrote:
> Hi Andrew,
> 
> On 5/14/26 15:58, Andrew Lunn wrote:
> > > We have information about what MII they can handle, however we don't
> > > store anything about whether they are currently connected to an SFP
> > > module or not. As phy_port aims at listing the front-facing ports, let's
> > > store an "vacant" bit to know whether or not a MII port is currently
> > > vacant (i.e. there's no module in the SFP cage), or not (i.e.
> > > there's an SFP module).
> > 
> > vacant == False actually means a bit more than there is a module in
> > the cage. It also means that, so far, we have not had any errors
> > trying to use the module. If there is an error, we might have a module
> > physically in the cage, but vacant == True.
> 
> This is a good point. Even with an error, we should have vacant = false.
> 
> TBH I'm unsure how to name this, vacant may not be the best word there, but
> I'm struggling to find a better term.
> 
> maybe "empty" ?

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

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"?

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

	Andrew