Re: [PATCH net] net: dsa: realtek: rtl8365mb: fix GMII caps for ports with internal PHY
From: Alvin Šipraga
Date: Tue Jun 07 2022 - 10:18:02 EST
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@xxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx>
Acked-by: Florian Fainelli <f.fainelli@xxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
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) {