Re: [PATCH net-next v20 01/13] phylink: Add phylink_mac_interrupt

[Andrew Lunn <andrew@lunn.ch>]

On Fri, Nov 06, 2026 at 04:32:30PM +0100, Birger Koblitz wrote:
> Thanks Maxime for reviewing!
> 
> On 06/11/2026 11:11 am, Maxime Chevallier wrote:
> 
> > > +/**
> > > + * phylink_mac_interrupt() - wrapper for phy_mac_interrupt()
> > > + * @pl: a pointer to a &struct phylink returned from phylink_create()
> > > + *
> > > + * Passes a link-change interrupt received by the MAC to phylib.
> > > + * This function may be called in interrupt context, and therefore cannot take
> > > + * a mutex. However, it is safe to assume that the reference to phy does not
> > > + * disappear during the call, as only an SFP module may be unplugged to make a
> > > + * PHY disappear. SFP modules however do not support interrupts.
> > 
> > I don't see the relevance of PHY SFP supporting interrupts or not here,
> > this just re-triggers the PHY state machine. Looks like a comment to
> > make sashiko happy.
> Indeed, this is for sashiko. Unfortunately it followed up with: "The
> function comment notes that SFP modules do not support interrupts. However,
> when an SFP module is physically unplugged, the electrical link drops. Could
> this link drop trigger the MAC interrupt being handled here?", which is
> equally irrelevant, I believe.

It does appear the LLM does not understand what an SFP is and how it
operates.

We should just accept the LLM is wrong, and don't add too many
comments to try to correct it.

The danger is, this code gets merged, and LLM kiddies come along,
there LLM thinks it is broken, they try to fix it and submit
patches. But lets see if that actually happens.

	Andrew