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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220607141744.l2yhwnix6aoiwl54@bang-olufsen.dk>
Date:   Tue, 7 Jun 2022 14:17:44 +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:05:40PM +0100, Russell King (Oracle) wrote:
> On Tue, Jun 07, 2022 at 10:52:48AM -0300, Luiz Angelo Daros de Luca wrote:
> > > > > Luiz, Russel:
> > > > >
> > > > > Commit a5dba0f207e5 ought to have had a Fixes: tag I think, because it
> > > > > claims to have been fixing a regression in the net-next tree - is that
> > > > > right? I seem to have missed both referenced commits when they were
> > > > > posted and never hit this issue personally. I only found things now
> > > > > during some other refactoring and the test for GMII looked weird to me
> > > > > so I went and investigated.
> > > > >
> > > > > Could you please help me identify that Fixes: tag? Just for my own
> > > > > understanding of what caused this added requirement for GMII on ports
> > > > > with internal PHY.
> > > >
> > > > I have absolutely no idea. I don't think any "requirement" has ever been
> > > > added - phylib has always defaulted to GMII, so as the driver stood when
> > > > it was first submitted on Oct 18 2021, I don't see how it could have
> > > > worked, unless the DT it was being tested with specified a phy-mode of
> > > > "internal". As you were the one who submitted it, you would have a
> > > > better idea.
> > > >
> > > > The only suggestion I have is to bisect to find out exactly what caused
> > > > the GMII vs INTERNAL issue to crop up.
> > >
> > > Alright, thanks for the quick response. Maybe Luiz has a better idea, otherwise
> > > I will try bisecting if I find the time.
> > 
> > I don't know. I just got hit by the issue after a rebase (sorry, I
> > don't know exactly from which commit I was rebasing).
> > But I did test the net (!-next) and left a working commit note. You
> > can diff 3dd7d40b43..a5dba0f20.
> > If I'm to guess, I would blame:
> > 
> > 21bd64bd717de: net: dsa: consolidate phylink creation
> 
> Why do you suspect that commit? I fail to see any functional change in
> that commit that would cause the problem.

Agree, seems like the referenced commit makes no functional change.

But thanks for the range of commits Luiz, I found one that looks like the
culprit. It's small so I will reproduce the whole thing below. Will test later.

--------------------8<-------------------

commit a18e6521a7d95dae8c65b5b0ef6bbe624fbe808c
Author: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
Date:   Fri Nov 19 16:28:06 2021 +0000

    net: phylink: handle NA interface mode in phylink_fwnode_phy_connect()
    
    Commit 4904b6ea1f9db ("net: phy: phylink: Use PHY device interface if
    N/A") introduced handling for the phy interface mode where this is not
    known at phylink creation time. This was never added to the OF/fwnode
    paths, but is necessary when the phy is present in DT, but the phy-mode
    is not specified.
    
    Add this handling.
    
    Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
    Acked-by: Florian Fainelli <f.fainelli@...il.com>
    Signed-off-by: David S. Miller <davem@...emloft.net>

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 2d201a795775..3603c024109a 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -1325,7 +1325,8 @@ static int phylink_bringup_phy(struct phylink *pl, struct phy_device *phy,
        mutex_unlock(&phy->lock);
 
        phylink_dbg(pl,
-                   "phy: setting supported %*pb advertising %*pb\n",
+                   "phy: %s setting supported %*pb advertising %*pb\n",
+                   phy_modes(interface),
                    __ETHTOOL_LINK_MODE_MASK_NBITS, pl->supported,
                    __ETHTOOL_LINK_MODE_MASK_NBITS, phy->advertising);
 
@@ -1443,6 +1444,12 @@ int phylink_fwnode_phy_connect(struct phylink *pl,
        if (!phy_dev)
                return -ENODEV;
 
+       /* Use PHY device/driver interface */
+       if (pl->link_interface == PHY_INTERFACE_MODE_NA) {
+               pl->link_interface = phy_dev->interface;
+               pl->link_config.interface = pl->link_interface;
+       }
+
        ret = phy_attach_direct(pl->netdev, phy_dev, flags,
                                pl->link_interface);
        if (ret) {