On Tue, Sep 17, 2019 at 04:17:07PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Sep 17, 2019 at 02:39:43PM +0100, Russell King - ARM Linux admin wrote:
> > On Tue, Sep 17, 2019 at 04:32:53PM +0300, tinywrkb wrote:
> > > On Tue, Sep 17, 2019 at 02:54:34PM +0200, Andrew Lunn wrote:
> > > > On Tue, Sep 17, 2019 at 03:41:01PM +0300, tinywrkb wrote:
> > > > > On Sun, Sep 15, 2019 at 03:56:52PM +0200, Andrew Lunn wrote:
> > > > > > > Tinywrkb confirmed to me in private communication that revert of
> > > > > > > 5502b218e001 fixes Ethernet for him on effected system.
> > > > > > >
> > > > > > > He also referred me to an old Cubox-i spec that lists 10/100 Ethernet
> > > > > > > only for i.MX6 Solo/DualLite variants of Cubox-i. It turns out that
> > > > > > > there was a plan to use a different 10/100 PHY for Solo/DualLite
> > > > > > > SOMs. This plan never materialized. All SolidRun i.MX6 SOMs use the same
> > > > > > > AR8035 PHY that supports 1Gb.
> > > > > > >
> > > > > > > Commit 5502b218e001 might be triggering a hardware issue on the affected
> > > > > > > Cubox-i. I could not reproduce the issue here with Cubox-i and a Dual
> > > > > > > SOM variant running v5.3-rc8. I have no Solo/DualLite variant handy at
> > > > > > > the moment.
> > > > > >
> > > > > > Could somebody with an affected device show us the output of ethtool
> > > > > > with and without 5502b218e001. Does one show 1G has been negotiated,
> > > > > > and the other 100Mbps? If this is true, how does it get 100Mbps
> > > > > > without that patch? We are missing a piece of the puzzle.
> > > > > >
> > > > > > Andrew
> > > > >
> > > > > linux-test-5.1rc1-a2703de70942-without_bad_commit
> > > > >
> > > > > Settings for eth0:
> > > > > Supported ports: [ TP MII ]
> > > > > Supported link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > >
> > > > So this means the local device says it can do 1000Mbps.
> > > >
> > > >
> > > > > Supported pause frame use: Symmetric
> > > > > Supports auto-negotiation: Yes
> > > > > Supported FEC modes: Not reported
> > > > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > >
> > > > The link peer can also do 1000Mbps.
> > > >
> > > >
> > > > > Advertised pause frame use: Symmetric
> > > > > Advertised auto-negotiation: Yes
> > > > > Advertised FEC modes: Not reported
> > > > > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > > > Link partner advertised pause frame use: Symmetric
> > > > > Link partner advertised auto-negotiation: Yes
> > > > > Link partner advertised FEC modes: Not reported
> > > > > Speed: 100Mb/s
> > > >
> > > > Yet they have decided to do 100Mbps.
> > > >
> > > > We need to understand Why? The generic PHY driver would not do this on
> > > > its own. So i'm thinking something has poked a PHY register with some
> > > > value, and this patch is causing it to be over written.
> > > >
> > > > Please can you use mii-tool -v -v to dump the PHY registers in each
> > > > case.
> > > >
> > > > Thanks
> > > > Andrew
> > >
> > > Here's the output of # mii-tool -v -v eth0
> > >
> > > * linux-test-5.1rc1-a2703de70942-without_bad_commit
> > >
> > > Using SIOCGMIIPHY=0x8947
> > > eth0: negotiated 100baseTx-FD flow-control, link ok
> > > registers for MII PHY 0:
> > > 3100 796d 004d d072 15e1 c5e1 000f 0000
> > > 0000 0000 0800 0000 0000 0000 0000 a000
> > > 0000 0000 0000 f420 082c 0000 04e8 0000
> > > 3200 3000 0000 063d 0000 0000 0000 0000
> > > product info: vendor 00:13:74, model 7 rev 2
> > > basic mode: autonegotiation enabled
> > > basic status: autonegotiation complete, link ok
> > > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> >
> > This is *not* advertising 1000baseT modes (register 9).
> >
> > >
> > >
> > > * linux-test-5.1rc1-5502b218e001-with_bad_commit
> > >
> > > Using SIOCGMIIPHY=0x8947
> > > eth0: negotiated 100baseTx-FD flow-control, link ok
> > > registers for MII PHY 0:
> > > 3100 796d 004d d072 15e1 c5e1 000d 0000
> > > 0000 0000 0800 0000 0000 0000 0000 a000
> > > 0000 0000 0000 0000 082c 0000 04e8 0000
> > > 3200 3000 0000 063d 0000 0000 0000 0000
> > > product info: vendor 00:13:74, model 7 rev 2
> > > basic mode: autonegotiation enabled
> > > basic status: autonegotiation complete, link ok
> > > capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> > > advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> > > link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> >
> > Neither is this.
> >
> > However, the kernel and phylib _thinks_ that it is. My guess is
> > something has rewritten the PHY registers from userspace, rather
> > than using ethtool to change the advertisment. The MAC is still
> > trying to operate at 1000Mbps (since that is what phylib resolved)
> > yet the link might be actually operating at 100Mbps - but for that
> > to happen, we should've seen the link go down and up again.
> >
> > Odd.
>
> For reference, here I see:
>
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 1000baseT-FD flow-control, link ok
> registers for MII PHY 0:
> 3100 796d 004d d072 15e1 c1e1 000d 0000
> 0000 0200 3800 0000 0000 0000 0000 a000
> 0000 0000 0000 0000 082c 0000 04e8 0000
> 3200 3000 0000 060e 0000 0000 0000 0000
> product info: vendor 00:13:74, model 7 rev 2
> basic mode: autonegotiation enabled
> basic status: autonegotiation complete, link ok
> capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> advertising: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
> link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>
> Note that userspace writing to register 9 (1G settings) will update
> the physical PHY's advertisment for 1G speeds, but the kernel's idea
> will not be updated, so things will become de-sync'd, and the kernel
> _will_ incorrectly determine the speed.
>
> So, are you using mii-tool or mii-diag to change the negotiation
> settings, rather than using ethtool?
>
> This is likely the case, as prior to 5502b218e001, we used to read
> the advertisment registers afresh each time we evaluate the resulting
> link mode. After 5502b218e001, we use the advertisment mask cached
> in phydev->advertising, which, looking at phy_mii_ioctl(), will not
> be updated if register 9 is written.
Please try this patch - I haven't written a commit message for it yet,
it's just to prove the above point.
Thanks.
drivers/net/phy/phy.c | 5 +++++
include/linux/mii.h | 9 +++++++++
2 files changed, 14 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 7af390d8bbdb..068a08a50064 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -458,6 +458,11 @@ int phy_mii_ioctl(struct phy_device *phydev, struct ifreq *ifr, int cmd)
val);
change_autoneg = true;
break;
+ case MII_CTRL1000:
+ mii_ctrl1000_mod_linkmode_adv_t(phydev->advertising,
+ val);
+ change_autoneg = true;
+ break;
default:
/* do nothing */
break;
diff --git a/include/linux/mii.h b/include/linux/mii.h
index 5cd824c1c0ca..1249d32dbd63 100644
--- a/include/linux/mii.h
+++ b/include/linux/mii.h
@@ -455,6 +455,15 @@ static inline void mii_lpa_mod_linkmode_lpa_t(unsigned long *lp_advertising,
lp_advertising, lpa & LPA_LPACK);
}
+static inline void mii_ctrl1000_mod_linkmode_adv_t(unsigned long *advertising,
+ u32 ctrl1000)
+{
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT, advertising,
+ ctrl1000 & ADVERTISE_1000HALF);
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT, advertising,
+ ctrl1000 & ADVERTISE_1000FULL);
+}
+
/**
* linkmode_adv_to_lcl_adv_t
* @advertising:pointer to linkmode advertising
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
