netdev - Re: [PATCH net] net: phylink: check for SFP bus presence in phylink_expects

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 12 Apr 2023 10:06:27 +0200
From:   Maxime Chevallier <maxime.chevallier@...tlin.com>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     davem@...emloft.net,
        Sit Michael Wei Hong <michael.wei.hong.sit@...el.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        "linux-stm32 @ st-md-mailman . stormreply . com" 
        <linux-stm32@...md-mailman.stormreply.com>,
        "alexis . lothore @ bootlin . com" <alexis.lothore@...tlin.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        thomas.petazzoni@...tlin.com, Andrew Lunn <andrew@...n.ch>,
        Jakub Kicinski <kuba@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net] net: phylink: check for SFP bus presence in
 phylink_expects_phy

Hello Russell,

On Wed, 12 Apr 2023 08:51:21 +0100
"Russell King (Oracle)" <linux@...linux.org.uk> wrote:

> On Wed, Apr 12, 2023 at 09:48:50AM +0200, Maxime Chevallier wrote:
> > When an SFP bus is present, we don't expect a PHY to be attached
> > directly from the MAC driver, it will be handled by phylink at SFP
> > attach time.  
> 
> If we have a SFP, then phylink should be configured for in-band mode.
> Maybe fix the firmware description instead?
> 

The DT used on that platform has the following configuration :

[...]
&gmac1 {
  status = "okay";
  phy-mode = "sgmii";
  managed = "in-band-status";
  sfp = <&sfp>;
[...]
}

Here phylink_expects_phy() returns true because although we use
in-band management, the link mode is set to sgmii, and
phylink_expects_phy() checks if we are in in-band mode AND 802.3z.

As we have an SFP and the link mode will be changed according to the
module we plug-in, there should be no problem switching phy-mode to
"1000BaseX", so I'm perfectly fine with this solution.

However, is it semantically correct to use sgmii here ? If so, it may be
a bit counter-intuitive to have to set the mode to 1000BaseX just so
that the phylink_expects_phy() check passes ?

Thanks for the quick reply,

Maxime