Messages in this thread Patch in this message | | | From | Alvin Šipraga <> | Subject | Re: [PATCH net] net: dsa: realtek: rtl8365mb: fix GMII caps for ports with internal PHY | Date | Tue, 7 Jun 2022 14:17:44 +0000 |
| |
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@armlinux.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@armlinux.org.uk> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.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) { | |