netdev - Re: [PATCH net] net: dsa: realtek: rtl8365mb: fix GMII caps for ports with internal PHY

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]

Message-ID: <20220607161531.x5yfgkoyk55yieq4@bang-olufsen.dk>
Date:   Tue, 7 Jun 2022 16:15:33 +0000
From:   Alvin Šipraga <ALSI@...g-olufsen.dk>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
CC:     Luiz Angelo Daros de Luca <luizluca@...il.com>,
        Alvin Šipraga <alvin@...s.dk>,
        Linus Walleij <linus.walleij@...aro.org>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net] net: dsa: realtek: rtl8365mb: fix GMII caps for ports
 with internal PHY

On Tue, Jun 07, 2022 at 03:45:32PM +0100, Russell King (Oracle) wrote:
> 
> This one I agree could well be the culpret, but it means that the
> original premise that PHY_INTERFACE_MODE_INTERNAL was being used is
> incorrect - it's actually been relying on using PHY_INTERFACE_MODE_NA.
> 
> It instead means that PHY_INTERFACE_MODE_NA was being used, which
> really isn't good, because PHY_INTERFACE_MODE_NA internally inside
> phylink has always had a special meaning - that being with the
> validate step which has been used to get _all_ possible modes from
> the MAC. This was never intended to be used for anything except
> phylink's internal use to retrieve that information from the MAC
> driver to make decisions about what mode(s) a SFP should use.

Right, and there is even a "do not touch" warning in the enum definition of
PHY_INTERFACE_MODE_NA ;-)

Thanks for the explanation.

> 
> So yes, this is most likely the culpret, and if proven, please use
> it for the Fixes: tag for any fixes to drivers that incorrectly
> relied upon that behaviour.

If I take net and revert the aforementioned commit, then I am able to connect a
PHY and indeed the mode is _NA, as evidenced by log lines like this:

[   10.702205] realtek-smi ethernet-switch swp0: configuring for phy/ link mode

So a18e6521a7d9 is indeed the reason it broke for Luiz to begin with.

So, in summary:

- initial driver version

  rtl8365mb with no phy-mode specified on the port would connect with _NA
  because it supported it erroneously; at this point in time, when no phy-mode
  is specified in the DT, _NA gets used, which is also technically wrong

- a18e6521a7d9 ("net: phylink: handle NA interface mode in phylink_fwnode_phy_connect()")

  rtl8365mb now doesn't work without phy-mode specified because you fixed the
  _NA behaviour and now _GMII is used (which is right), but rtl8365mb doesn't
  support _GMII
  
    
- a5dba0f207e5 ("net: dsa: rtl8365mb: add GMII as user port mode")

  rtl8365mb now supports _GMII so everything works again
  
- 6ff6064605e9 ("net: dsa: realtek: convert to phylink_generic_validate()")

  rtl8365mb breaks again because _GMII is no longer supported due to some
  refactoring

I will re-send the patch this evening with an updated description.

Kind regards,
Alvin