From: Alexander Couzens <[email protected]>
Implement mtk_pcs_ops for the SGMII pcs to read the current state
of the hardware.
Signed-off-by: Alexander Couzens <[email protected]>
Signed-off-by: Frank Wunderlich <[email protected]>
Fixes: 14a44ab0330d ("net: mtk_eth_soc: partially convert to phylink_pcs")
---
v2:
- reorder members in phylink_pcs_ops
- drop pause setting
without this Patch i get this trace in 6.1-rc1 when enabling the left
sfp (eth1) on bpi-r3 (crash happens in phylink core because a NULL-pointer,
so fixes-Tag is a guess):
[ 108.302810] Unable to handle kernel execute from non-executable memory at virtual address 0000000000000000
[ 108.312462] Mem abort info:
[ 108.315263] ESR = 0x0000000086000005
[ 108.319003] EC = 0x21: IABT (current EL), IL = 32 bits
[ 108.324335] SET = 0, FnV = 0
[ 108.327378] EA = 0, S1PTW = 0
[ 108.330505] FSC = 0x05: level 1 translation fault
[ 108.335375] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000419be000
[ 108.341798] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pu
d=0000000000000000
[ 108.350489] Internal error: Oops: 0000000086000005 [#1] SMP
[ 108.356047] Modules linked in: cdc_mbim cdc_ncm cdc_wdm cdc_ether qcserial us
a_wwan usbnet usbser
a Mmeisis
ge from syslogd@bpi-r3 at Aug 7 15:26:54 ...
kernel:[ 108.350489] Internal error: Oops: 0000000086000005 [#1] SMP
[ 108.376743] CPU: 3 PID: 8 Comm: kworker/u8:0 Not tainted 6.0.0-bpi-r3 #1
[ 108.383461] Hardware name: Bananapi BPI-R3 (sdmmc) (DT)
[ 108.388671] Workqueue: events_power_efficient phylink_resolve
[ 108.394411] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 108.401355] pc : 0x0
[ 108.403531] lr : phylink_mac_pcs_get_state+0x7c/0x100
[ 108.408572] sp : ffffffc00963bd00
[ 108.411873] x29: ffffffc00963bd00 x28: 0000000000000000 x27: 0000000000000000
[ 108.418994] x26: ffffff80000ed074 x25: ffffff800001c105 x24: 0000000000000000
[ 108.426116] x23: ffffff80022f8cd8 x22: ffffff80022f8d30 x21: ffffff80022f8c00
[ 108.433236] x20: 0000000000000000 x19: ffffff8000126040 x18: 0000000000000000
[ 108.440357] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 108.447478] x14: ffffffffffffffff x13: 0000000000000030 x12: 0101010101010101
[ 108.454598] x11: 7f7f7f7f7f7f7f7f x10: fefefefefefefeff x9 : ffffff80000ed07c
[ 108.461720] x8 : fefefefefefefeff x7 : 0000000000000017 x6 : ffffff80000ed074
[ 108.468840] x5 : 0000000000000000 x4 : 0000020000006440 x3 : 00000000fffffffa
[ 108.475960] x2 : 0000000000000000 x1 : ffffffc00963bd80 x0 : ffffff80014c3ab0
[ 108.483082] Call trace:
[ 108.485516] 0x0
[ 108.487344] phylink_resolve+0x248/0x520
[ 108.491256] process_one_work+0x204/0x478
[ 108.495256] worker_thread+0x148/0x4c0
[ 108.498993] kthread+0xdc/0xe8
[ 108.502037] ret_from_fork+0x10/0x20
[ 108.505608] Code: bad PC value
[ 108.508652] ---[ end trace 0000000000000000 ]---
[ 108.513255] Kernel panic - not syncing: Oops: Fatal exception
[ 108.518984] SMP: stopping secondary CPUs
[ 108.522894] Kernel Offset: disabled
[ 108.526369] CPU features: 0x00000,00800084,0000420b
[ 108.531232] Memory Limit: none
[ 108.534274] Rebooting in 1 seconds..
---
drivers/net/ethernet/mediatek/mtk_sgmii.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/ethernet/mediatek/mtk_sgmii.c b/drivers/net/ethernet/mediatek/mtk_sgmii.c
index 736839c84130..8b7465057e57 100644
--- a/drivers/net/ethernet/mediatek/mtk_sgmii.c
+++ b/drivers/net/ethernet/mediatek/mtk_sgmii.c
@@ -122,7 +122,21 @@ static void mtk_pcs_link_up(struct phylink_pcs *pcs, unsigned int mode,
regmap_write(mpcs->regmap, SGMSYS_SGMII_MODE, val);
}
+static void mtk_pcs_get_state(struct phylink_pcs *pcs, struct phylink_link_state *state)
+{
+ struct mtk_pcs *mpcs = pcs_to_mtk_pcs(pcs);
+ unsigned int val;
+
+ regmap_read(mpcs->regmap, mpcs->ana_rgc3, &val);
+ state->speed = val & RG_PHY_SPEED_3_125G ? SPEED_2500 : SPEED_1000;
+
+ regmap_read(mpcs->regmap, SGMSYS_PCS_CONTROL_1, &val);
+ state->an_complete = !!(val & SGMII_AN_COMPLETE);
+ state->link = !!(val & SGMII_LINK_STATYS);
+}
+
static const struct phylink_pcs_ops mtk_pcs_ops = {
+ .pcs_get_state = mtk_pcs_get_state,
.pcs_config = mtk_pcs_config,
.pcs_an_restart = mtk_pcs_restart_an,
.pcs_link_up = mtk_pcs_link_up,
--
2.34.1
On Thu, Oct 20, 2022 at 04:44:31PM +0200, Frank Wunderlich wrote:
> diff --git a/drivers/net/ethernet/mediatek/mtk_sgmii.c b/drivers/net/ethernet/mediatek/mtk_sgmii.c
> index 736839c84130..8b7465057e57 100644
> --- a/drivers/net/ethernet/mediatek/mtk_sgmii.c
> +++ b/drivers/net/ethernet/mediatek/mtk_sgmii.c
> @@ -122,7 +122,21 @@ static void mtk_pcs_link_up(struct phylink_pcs *pcs, unsigned int mode,
> regmap_write(mpcs->regmap, SGMSYS_SGMII_MODE, val);
> }
>
> +static void mtk_pcs_get_state(struct phylink_pcs *pcs, struct phylink_link_state *state)
> +{
> + struct mtk_pcs *mpcs = pcs_to_mtk_pcs(pcs);
> + unsigned int val;
> +
> + regmap_read(mpcs->regmap, mpcs->ana_rgc3, &val);
> + state->speed = val & RG_PHY_SPEED_3_125G ? SPEED_2500 : SPEED_1000;
> +
Sorry, looking back at my initial comment on the first revision of this
patch, I see my second point was confused. It should have read:
"2) There should also be a setting for state->duplex."
IOW, "duplex" instead of "pause".
Also, is there no way to read the link partner advertisement?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Thu, 20 Oct 2022 16:44:31 +0200 Frank Wunderlich wrote:
> Signed-off-by: Alexander Couzens <[email protected]>
> Signed-off-by: Frank Wunderlich <[email protected]>
>
> Fixes: 14a44ab0330d ("net: mtk_eth_soc: partially convert to phylink_pcs")
nit, the correct formatting of tags would be:
From: Alexander Couzens <[email protected]>
Implement mtk_pcs_ops for the SGMII pcs to read the current state
of the hardware.
Fixes: 14a44ab0330d ("net: mtk_eth_soc: partially convert to phylink_pcs")
Signed-off-by: Alexander Couzens <[email protected]>
Signed-off-by: Frank Wunderlich <[email protected]>
---
Am 20. Oktober 2022 18:17:41 MESZ schrieb "Russell King (Oracle)" <[email protected]>:
>On Thu, Oct 20, 2022 at 04:44:31PM +0200, Frank Wunderlich wrote:
>> diff --git a/drivers/net/ethernet/mediatek/mtk_sgmii.c b/drivers/net/ethernet/mediatek/mtk_sgmii.c
>> index 736839c84130..8b7465057e57 100644
>> --- a/drivers/net/ethernet/mediatek/mtk_sgmii.c
>> +++ b/drivers/net/ethernet/mediatek/mtk_sgmii.c
>> @@ -122,7 +122,21 @@ static void mtk_pcs_link_up(struct phylink_pcs *pcs, unsigned int mode,
>> regmap_write(mpcs->regmap, SGMSYS_SGMII_MODE, val);
>> }
>>
>> +static void mtk_pcs_get_state(struct phylink_pcs *pcs, struct phylink_link_state *state)
>> +{
>> + struct mtk_pcs *mpcs = pcs_to_mtk_pcs(pcs);
>> + unsigned int val;
>> +
>> + regmap_read(mpcs->regmap, mpcs->ana_rgc3, &val);
>> + state->speed = val & RG_PHY_SPEED_3_125G ? SPEED_2500 : SPEED_1000;
>> +
>
>Sorry, looking back at my initial comment on the first revision of this
>patch, I see my second point was confused. It should have read:
>
>"2) There should also be a setting for state->duplex."
>
>IOW, "duplex" instead of "pause".
>
>Also, is there no way to read the link partner advertisement?
Hi,
On my board (bpi-r3) we have no autoneg on the gmacs. We have a switch (mt7531) with fixed-link on the first and a sfp-cage on the other. Second mac gets speed-setting (1000base-X or 2500base-X) from sfp eeprom, but no advertisement from the "other end". Imho it is always full duplex.
I have no register documentation to check if there is any way to read out pause/duplex setting. Maybe MTK can answer this or extend function later.
regards Frank
On Fri, Oct 21, 2022 at 08:04:51AM +0200, Frank Wunderlich wrote:
> On my board (bpi-r3) we have no autoneg on the gmacs. We have a switch (mt7531) with fixed-link on the first and a sfp-cage on the other. Second mac gets speed-setting (1000base-X or 2500base-X) from sfp eeprom, but no advertisement from the "other end". Imho it is always full duplex.
If it's a fixed link, then this function you're adding won't be called.
It's only called for in-band mode which is exclusive with fixed-link
mode.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Fri, Oct 21, 2022 at 08:04:51AM +0200, Frank Wunderlich wrote:
> I have no register documentation to check if there is any way to read out pause/duplex setting. Maybe MTK can answer this or extend function later.
I suspect we can probably guess.
Looking at SGMSYS_PCS_CONTROL_1, this is actually the standard BMCR in
the low 16 bits, and BMSR in the upper 16 bits, so:
At address 4, I'd expect the PHYSID.
At address 8, I'd expect the advertisement register in the low 16 bits
and the link partner advertisement in the upper 16 bits.
Can you try an experiment, and in mtk_sgmii_init() try accessing the
regmap at address 0, 4, and 8 and print their contents please?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Fri, Oct 21, 2022 at 10:41:22AM +0200, Frank Wunderlich wrote:
> Am 21. Oktober 2022 09:24:02 MESZ schrieb "Russell King (Oracle)" <[email protected]>:
> >On Fri, Oct 21, 2022 at 08:04:51AM +0200, Frank Wunderlich wrote:
> >> On my board (bpi-r3) we have no autoneg on the gmacs. We have a switch (mt7531) with fixed-link on the first and a sfp-cage on the other. Second mac gets speed-setting (1000base-X or 2500base-X) from sfp eeprom, but no advertisement from the "other end". Imho it is always full duplex.
> >
> >If it's a fixed link, then this function you're adding won't be called.
> >It's only called for in-band mode which is exclusive with fixed-link
> >mode.
> >
> >--
> >RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> >FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
>
> Right, i get this trace for the second mac which is without fixed-link because of in-band-managed for sfp (read speed settings from sfp eeprom).
So, you need to set state->duplex to DUPLEX_FULL if this is what the
hardware is actually doing.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
> Gesendet: Freitag, 21. Oktober 2022 um 11:06 Uhr
> Von: "Russell King (Oracle)" <[email protected]>
> An: "Frank Wunderlich" <[email protected]>
> On Fri, Oct 21, 2022 at 08:04:51AM +0200, Frank Wunderlich wrote:
> > I have no register documentation to check if there is any way to read out pause/duplex setting. Maybe MTK can answer this or extend function later.
>
> I suspect we can probably guess.
>
> Looking at SGMSYS_PCS_CONTROL_1, this is actually the standard BMCR in
> the low 16 bits, and BMSR in the upper 16 bits, so:
>
> At address 4, I'd expect the PHYSID.
> At address 8, I'd expect the advertisement register in the low 16 bits
> and the link partner advertisement in the upper 16 bits.
>
> Can you try an experiment, and in mtk_sgmii_init() try accessing the
> regmap at address 0, 4, and 8 and print their contents please?
is this what you want to see?
int mtk_sgmii_init(struct mtk_sgmii *ss, struct device_node *r, u32 ana_rgc3)
{
struct device_node *np;
+ unsigned int val;
int i;
for (i = 0; i < MTK_MAX_DEVS; i++) {
@@ -158,6 +159,12 @@ int mtk_sgmii_init(struct mtk_sgmii *ss, struct device_node *r, u32 ana_rgc3)
if (IS_ERR(ss->pcs[i].regmap))
return PTR_ERR(ss->pcs[i].regmap);
+ regmap_read(ss->pcs[i].regmap, SGMSYS_PCS_CONTROL_1, &val);
+ printk(KERN_ALERT "dev: %d offset:0 0x%x",i,val);
+ regmap_read(ss->pcs[i].regmap, SGMSYS_PCS_CONTROL_1+4, &val);
+ printk(KERN_ALERT "dev: %d offset:4 0x%x",i,val);
+ regmap_read(ss->pcs[i].regmap, SGMSYS_PCS_CONTROL_1+8, &val);
+ printk(KERN_ALERT "dev: %d offset:8 0x%x",i,val);
ss->pcs[i].pcs.ops = &mtk_pcs_ops;
}
[ 1.083359] dev: 0 offset:0 0x840140
[ 1.083376] dev: 0 offset:4 0x4d544950
[ 1.086955] dev: 0 offset:8 0x1
[ 1.090697] dev: 1 offset:0 0x81140
[ 1.093866] dev: 1 offset:4 0x4d544950
[ 1.097342] dev: 1 offset:8 0x1
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
>
regards Frank
On Fri, Oct 21, 2022 at 07:47:47PM +0200, Frank Wunderlich wrote:
> > Gesendet: Freitag, 21. Oktober 2022 um 11:06 Uhr
> > Von: "Russell King (Oracle)" <[email protected]>
> > An: "Frank Wunderlich" <[email protected]>
> > On Fri, Oct 21, 2022 at 08:04:51AM +0200, Frank Wunderlich wrote:
> > > I have no register documentation to check if there is any way to read out pause/duplex setting. Maybe MTK can answer this or extend function later.
> >
> > I suspect we can probably guess.
> >
> > Looking at SGMSYS_PCS_CONTROL_1, this is actually the standard BMCR in
> > the low 16 bits, and BMSR in the upper 16 bits, so:
> >
> > At address 4, I'd expect the PHYSID.
> > At address 8, I'd expect the advertisement register in the low 16 bits
> > and the link partner advertisement in the upper 16 bits.
> >
> > Can you try an experiment, and in mtk_sgmii_init() try accessing the
> > regmap at address 0, 4, and 8 and print their contents please?
>
> is this what you want to see?
>
> int mtk_sgmii_init(struct mtk_sgmii *ss, struct device_node *r, u32 ana_rgc3)
> {
> struct device_node *np;
> + unsigned int val;
> int i;
>
> for (i = 0; i < MTK_MAX_DEVS; i++) {
> @@ -158,6 +159,12 @@ int mtk_sgmii_init(struct mtk_sgmii *ss, struct device_node *r, u32 ana_rgc3)
> if (IS_ERR(ss->pcs[i].regmap))
> return PTR_ERR(ss->pcs[i].regmap);
>
> + regmap_read(ss->pcs[i].regmap, SGMSYS_PCS_CONTROL_1, &val);
> + printk(KERN_ALERT "dev: %d offset:0 0x%x",i,val);
> + regmap_read(ss->pcs[i].regmap, SGMSYS_PCS_CONTROL_1+4, &val);
> + printk(KERN_ALERT "dev: %d offset:4 0x%x",i,val);
> + regmap_read(ss->pcs[i].regmap, SGMSYS_PCS_CONTROL_1+8, &val);
> + printk(KERN_ALERT "dev: %d offset:8 0x%x",i,val);
> ss->pcs[i].pcs.ops = &mtk_pcs_ops;
> }
>
>
> [ 1.083359] dev: 0 offset:0 0x840140
> [ 1.083376] dev: 0 offset:4 0x4d544950
> [ 1.086955] dev: 0 offset:8 0x1
> [ 1.090697] dev: 1 offset:0 0x81140
> [ 1.093866] dev: 1 offset:4 0x4d544950
> [ 1.097342] dev: 1 offset:8 0x1
Thanks. Decoding these...
dev 0:
BMCR: fixed, full duplex, 1000Mbps, !autoneg
BMSR: link up
Phy ID: 0x4d54 0x4950
Advertise: 0x0001 (which would correspond with the MAC side of SGMII)
Link partner: 0x0000 (no advertisement received, but we're not using
negotiation.)
dev 1:
BMCR: autoneg (full duplex, 1000Mbps - both would be ignored)
BMSR: able to do autoneg, no link
Phy ID: 0x4d54 0x4950
Advertise: 0x0001 (same as above)
Link partner: 0x0000 (no advertisement received due to no link)
Okay, what would now be interesting is to see how dev 1 behaves when
it has link with a 1000base-X link partner that is advertising
properly. If this changes to 0x01e0 or similar (in the high 16-bits
of offset 8) then we definitely know that this is an IEEE PHY register
set laid out in memory, and we can program the advertisement and read
the link partner's abilities.
At that point, we should try programming the low 16-bits of offset 8
to see whether that advertisement makes it to the far end of the link.
It would be well worth trying to work this out, because it will then
vastly improve the knowledge of this hardware, and improve the
driver no end.
Is this something you could investigate please?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
> Gesendet: Freitag, 21. Oktober 2022 um 20:31 Uhr
> Von: "Russell King (Oracle)" <[email protected]>
> On Fri, Oct 21, 2022 at 07:47:47PM +0200, Frank Wunderlich wrote:
> > > Gesendet: Freitag, 21. Oktober 2022 um 11:06 Uhr
> > > Von: "Russell King (Oracle)" <[email protected]>
> > > Looking at SGMSYS_PCS_CONTROL_1, this is actually the standard BMCR in
> > > the low 16 bits, and BMSR in the upper 16 bits, so:
> > >
> > > At address 4, I'd expect the PHYSID.
> > > At address 8, I'd expect the advertisement register in the low 16 bits
> > > and the link partner advertisement in the upper 16 bits.
> > >
> > > Can you try an experiment, and in mtk_sgmii_init() try accessing the
> > > regmap at address 0, 4, and 8 and print their contents please?
> >
> > is this what you want to see?
> > [ 1.083359] dev: 0 offset:0 0x840140
> > [ 1.083376] dev: 0 offset:4 0x4d544950
> > [ 1.086955] dev: 0 offset:8 0x1
> > [ 1.090697] dev: 1 offset:0 0x81140
> > [ 1.093866] dev: 1 offset:4 0x4d544950
> > [ 1.097342] dev: 1 offset:8 0x1
>
> Thanks. Decoding these...
>
> dev 0:
> BMCR: fixed, full duplex, 1000Mbps, !autoneg
> BMSR: link up
> Phy ID: 0x4d54 0x4950
> Advertise: 0x0001 (which would correspond with the MAC side of SGMII)
> Link partner: 0x0000 (no advertisement received, but we're not using
> negotiation.)
>
> dev 1:
> BMCR: autoneg (full duplex, 1000Mbps - both would be ignored)
> BMSR: able to do autoneg, no link
> Phy ID: 0x4d54 0x4950
> Advertise: 0x0001 (same as above)
> Link partner: 0x0000 (no advertisement received due to no link)
>
> Okay, what would now be interesting is to see how dev 1 behaves when
> it has link with a 1000base-X link partner that is advertising
> properly. If this changes to 0x01e0 or similar (in the high 16-bits
> of offset 8) then we definitely know that this is an IEEE PHY register
> set laid out in memory, and we can program the advertisement and read
> the link partner's abilities.
added register-read on the the new get_state function too
on bootup it is now a bit different
[ 1.086283] dev: 0 offset:0 0x40140 #was previously 0x840140
[ 1.086301] dev: 0 offset:4 0x4d544950
[ 1.089795] dev: 0 offset:8 0x1
[ 1.093584] dev: 1 offset:0 0x81140
[ 1.096716] dev: 1 offset:4 0x4d544950
[ 1.100191] dev: 1 offset:8 0x1
root@bpi-r3:~# ip link set eth1 up
[ 172.037519] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/1000base-x link mode
root@bpi-r3:~#
[ 172.102949] offset:0 0x40140 #still same value
[ 172.102964] offset:4 0x4d544950
[ 172.105842] offset:8 0x1
[ 172.108992] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 1Gbps/Unknown - flow control off
[ 172.120058] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
so no change on link up
maybe ethtool-output is interesting
root@bpi-r3:~# ethtool -m eth1
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x07 (LC)
Transceiver codes : 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00
Transceiver type : Ethernet: 1000BASE-SX
Encoding : 0x01 (8B/10B)
BR, Nominal : 1300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 550m
Length (62.5um) : 270m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 850nm
Vendor name : OEM
Vendor OUI : 00:90:65
Vendor PN : GLC-SX-MMD _
Vendor rev : _e
Option values : 0x00 0x1a
Option : RX_LOS implemented
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : CSCGE1M14134
Date code : 220120
Optical diagnostics support : Yes
Laser bias current : 3.634 mA
Laser output power : 0.3181 mW / -4.97 dBm
Receiver signal average optical power : 0.3444 mW / -4.63 dBm
Module temperature : 35.32 degrees C / 95.58 degrees F
Module voltage : 3.3101 V
Alarm/warning flags implemented : Yes
Laser bias current high alarm : Off
Laser bias current low alarm : Off
Laser bias current high warning : Off
Laser bias current low warning : Off
Laser output power high alarm : Off
Laser output power low alarm : Off
Laser output power high warning : Off
Laser output power low warning : Off
Module temperature high alarm : Off
Module temperature low alarm : Off
Module temperature high warning : Off
Module temperature low warning : Off
Module voltage high alarm : Off
Module voltage low alarm : Off
Module voltage high warning : Off
Module voltage low warning : Off
Laser rx power high alarm : Off
Laser rx power low alarm : Off
Laser rx power high warning : Off
Laser rx power low warning : Off
Laser bias current high alarm threshold : 100.000 mA
Laser bias current low alarm threshold : 0.000 mA
Laser bias current high warning threshold : 90.000 mA
Laser bias current low warning threshold : 0.100 mA
Laser output power high alarm threshold : 1.2589 mW / 1.00 dBm
Laser output power low alarm threshold : 0.0501 mW / -13.00 dBm
Laser output power high warning threshold : 0.7943 mW / -1.00 dBm
Laser output power low warning threshold : 0.0631 mW / -12.00 dBm
Module temperature high alarm threshold : 90.00 degrees C / 194.00 degrees F
Module temperature low alarm threshold : -45.00 degrees C / -49.00 degrees F
Module temperature high warning threshold : 85.00 degrees C / 185.00 degrees F
Module temperature low warning threshold : -40.00 degrees C / -40.00 degrees F
Module voltage high alarm threshold : 3.8000 V
Module voltage low alarm threshold : 2.7000 V
Module voltage high warning threshold : 3.7000 V
Module voltage low warning threshold : 2.8000 V
Laser rx power high alarm threshold : 0.7943 mW / -1.00 dBm
Laser rx power low alarm threshold : 0.0079 mW / -21.02 dBm
Laser rx power high warning threshold : 0.5012 mW / -3.00 dBm
Laser rx power low warning threshold : 0.0126 mW / -19.00 dBm
root@bpi-r3:~# ethtool eth1
[ 295.755349] offset:0 0x40140
[ 295.755368] offset:4 0x4d544950
Settings for eth[ 295.758247] offset:8 0x1
1:
Supported p[ 295.761551] offset:0 0x40140
[ 295.765446] offset:4 0x4d544950
Supported link modes: 1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Unknown! (255)
Auto-negotiation: on
Port: FIBRE
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
> At that point, we should try programming the low 16-bits of offset 8
> to see whether that advertisement makes it to the far end of the link.
have only my switch on the other side where i imho cannot read out these advertising. and programming to which values at which point (in the get-state callback to be done on link-up)?
> It would be well worth trying to work this out, because it will then
> vastly improve the knowledge of this hardware, and improve the
> driver no end.
>
> Is this something you could investigate please?
regards Frank
On Fri, Oct 21, 2022 at 09:52:36PM +0200, Frank Wunderlich wrote:
> > Gesendet: Freitag, 21. Oktober 2022 um 20:31 Uhr
> > Von: "Russell King (Oracle)" <[email protected]>
>
> > On Fri, Oct 21, 2022 at 07:47:47PM +0200, Frank Wunderlich wrote:
> > > > Gesendet: Freitag, 21. Oktober 2022 um 11:06 Uhr
> > > > Von: "Russell King (Oracle)" <[email protected]>
>
> > > > Looking at SGMSYS_PCS_CONTROL_1, this is actually the standard BMCR in
> > > > the low 16 bits, and BMSR in the upper 16 bits, so:
> > > >
> > > > At address 4, I'd expect the PHYSID.
> > > > At address 8, I'd expect the advertisement register in the low 16 bits
> > > > and the link partner advertisement in the upper 16 bits.
> > > >
> > > > Can you try an experiment, and in mtk_sgmii_init() try accessing the
> > > > regmap at address 0, 4, and 8 and print their contents please?
> > >
> > > is this what you want to see?
>
> > > [ 1.083359] dev: 0 offset:0 0x840140
> > > [ 1.083376] dev: 0 offset:4 0x4d544950
> > > [ 1.086955] dev: 0 offset:8 0x1
> > > [ 1.090697] dev: 1 offset:0 0x81140
> > > [ 1.093866] dev: 1 offset:4 0x4d544950
> > > [ 1.097342] dev: 1 offset:8 0x1
> >
> > Thanks. Decoding these...
> >
> > dev 0:
> > BMCR: fixed, full duplex, 1000Mbps, !autoneg
> > BMSR: link up
> > Phy ID: 0x4d54 0x4950
> > Advertise: 0x0001 (which would correspond with the MAC side of SGMII)
> > Link partner: 0x0000 (no advertisement received, but we're not using
> > negotiation.)
> >
> > dev 1:
> > BMCR: autoneg (full duplex, 1000Mbps - both would be ignored)
> > BMSR: able to do autoneg, no link
> > Phy ID: 0x4d54 0x4950
> > Advertise: 0x0001 (same as above)
> > Link partner: 0x0000 (no advertisement received due to no link)
> >
> > Okay, what would now be interesting is to see how dev 1 behaves when
> > it has link with a 1000base-X link partner that is advertising
> > properly. If this changes to 0x01e0 or similar (in the high 16-bits
> > of offset 8) then we definitely know that this is an IEEE PHY register
> > set laid out in memory, and we can program the advertisement and read
> > the link partner's abilities.
>
> added register-read on the the new get_state function too
>
> on bootup it is now a bit different
>
> [ 1.086283] dev: 0 offset:0 0x40140 #was previously 0x840140
> [ 1.086301] dev: 0 offset:4 0x4d544950
> [ 1.089795] dev: 0 offset:8 0x1
> [ 1.093584] dev: 1 offset:0 0x81140
> [ 1.096716] dev: 1 offset:4 0x4d544950
> [ 1.100191] dev: 1 offset:8 0x1
>
> root@bpi-r3:~# ip link set eth1 up
> [ 172.037519] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/1000base-x link mode
> root@bpi-r3:~#
> [ 172.102949] offset:0 0x40140 #still same value
If this is "dev: 1" the value has changed - the ANENABLE bit has been
turned off, which means it's not going to bother receiving or sending
the 16-bit control word. Bit 12 needs to stay set for it to perform
the exchange.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Am 21. Oktober 2022 23:28:09 MESZ schrieb "Russell King (Oracle)" <[email protected]>:
>On Fri, Oct 21, 2022 at 09:52:36PM +0200, Frank Wunderlich wrote:
>> > Gesendet: Freitag, 21. Oktober 2022 um 20:31 Uhr
>> > Von: "Russell King (Oracle)" <[email protected]>
>>
>> > On Fri, Oct 21, 2022 at 07:47:47PM +0200, Frank Wunderlich wrote:
>> > > > Gesendet: Freitag, 21. Oktober 2022 um 11:06 Uhr
>> > > > Von: "Russell King (Oracle)" <[email protected]>
>>
>> > > > Looking at SGMSYS_PCS_CONTROL_1, this is actually the standard BMCR in
>> > > > the low 16 bits, and BMSR in the upper 16 bits, so:
>> > > >
>> > > > At address 4, I'd expect the PHYSID.
>> > > > At address 8, I'd expect the advertisement register in the low 16 bits
>> > > > and the link partner advertisement in the upper 16 bits.
>> > > >
>> > > > Can you try an experiment, and in mtk_sgmii_init() try accessing the
>> > > > regmap at address 0, 4, and 8 and print their contents please?
>> > >
>> > > is this what you want to see?
>>
>> > > [ 1.083359] dev: 0 offset:0 0x840140
>> > > [ 1.083376] dev: 0 offset:4 0x4d544950
>> > > [ 1.086955] dev: 0 offset:8 0x1
>> > > [ 1.090697] dev: 1 offset:0 0x81140
>> > > [ 1.093866] dev: 1 offset:4 0x4d544950
>> > > [ 1.097342] dev: 1 offset:8 0x1
>> >
>> > Thanks. Decoding these...
>> >
>> > dev 0:
>> > BMCR: fixed, full duplex, 1000Mbps, !autoneg
>> > BMSR: link up
>> > Phy ID: 0x4d54 0x4950
>> > Advertise: 0x0001 (which would correspond with the MAC side of SGMII)
>> > Link partner: 0x0000 (no advertisement received, but we're not using
>> > negotiation.)
>> >
>> > dev 1:
>> > BMCR: autoneg (full duplex, 1000Mbps - both would be ignored)
>> > BMSR: able to do autoneg, no link
>> > Phy ID: 0x4d54 0x4950
>> > Advertise: 0x0001 (same as above)
>> > Link partner: 0x0000 (no advertisement received due to no link)
>> >
>> > Okay, what would now be interesting is to see how dev 1 behaves when
>> > it has link with a 1000base-X link partner that is advertising
>> > properly. If this changes to 0x01e0 or similar (in the high 16-bits
>> > of offset 8) then we definitely know that this is an IEEE PHY register
>> > set laid out in memory, and we can program the advertisement and read
>> > the link partner's abilities.
>>
>> added register-read on the the new get_state function too
>>
>> on bootup it is now a bit different
>>
>> [ 1.086283] dev: 0 offset:0 0x40140 #was previously 0x840140
>> [ 1.086301] dev: 0 offset:4 0x4d544950
>> [ 1.089795] dev: 0 offset:8 0x1
>> [ 1.093584] dev: 1 offset:0 0x81140
>> [ 1.096716] dev: 1 offset:4 0x4d544950
>> [ 1.100191] dev: 1 offset:8 0x1
>>
>> root@bpi-r3:~# ip link set eth1 up
>> [ 172.037519] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/1000base-x link mode
>> root@bpi-r3:~#
>> [ 172.102949] offset:0 0x40140 #still same value
>
>If this is "dev: 1" the value has changed - the ANENABLE bit has been
>turned off, which means it's not going to bother receiving or sending
>the 16-bit control word. Bit 12 needs to stay set for it to perform
>the exchange.
Your right,was confused that dev 0 (fixed link to switch chip) had different value.
offset:0 0x81140 => 0x40140
So i should change offset 8 (currently 0x1) to at least 0x1 | BIT(12)? I can try to set this in the get_state callback,but i'm unsure i can read out it on my switch (basic mode changes yes,but not the value directly)...if mode is not autoneg i will see no change there.
regards Frank
On Sat, Oct 22, 2022 at 08:25:26AM +0200, Frank Wunderlich wrote:
> Am 21. Oktober 2022 23:28:09 MESZ schrieb "Russell King (Oracle)" <[email protected]>:
> >On Fri, Oct 21, 2022 at 09:52:36PM +0200, Frank Wunderlich wrote:
> >> > Gesendet: Freitag, 21. Oktober 2022 um 20:31 Uhr
> >> > Von: "Russell King (Oracle)" <[email protected]>
> >>
> >> > On Fri, Oct 21, 2022 at 07:47:47PM +0200, Frank Wunderlich wrote:
> >> > > > Gesendet: Freitag, 21. Oktober 2022 um 11:06 Uhr
> >> > > > Von: "Russell King (Oracle)" <[email protected]>
> >>
> >> > > > Looking at SGMSYS_PCS_CONTROL_1, this is actually the standard BMCR in
> >> > > > the low 16 bits, and BMSR in the upper 16 bits, so:
> >> > > >
> >> > > > At address 4, I'd expect the PHYSID.
> >> > > > At address 8, I'd expect the advertisement register in the low 16 bits
> >> > > > and the link partner advertisement in the upper 16 bits.
> >> > > >
> >> > > > Can you try an experiment, and in mtk_sgmii_init() try accessing the
> >> > > > regmap at address 0, 4, and 8 and print their contents please?
> >> > >
> >> > > is this what you want to see?
> >>
> >> > > [ 1.083359] dev: 0 offset:0 0x840140
> >> > > [ 1.083376] dev: 0 offset:4 0x4d544950
> >> > > [ 1.086955] dev: 0 offset:8 0x1
> >> > > [ 1.090697] dev: 1 offset:0 0x81140
> >> > > [ 1.093866] dev: 1 offset:4 0x4d544950
> >> > > [ 1.097342] dev: 1 offset:8 0x1
> >> >
> >> > Thanks. Decoding these...
> >> >
> >> > dev 0:
> >> > BMCR: fixed, full duplex, 1000Mbps, !autoneg
> >> > BMSR: link up
> >> > Phy ID: 0x4d54 0x4950
> >> > Advertise: 0x0001 (which would correspond with the MAC side of SGMII)
> >> > Link partner: 0x0000 (no advertisement received, but we're not using
> >> > negotiation.)
> >> >
> >> > dev 1:
> >> > BMCR: autoneg (full duplex, 1000Mbps - both would be ignored)
> >> > BMSR: able to do autoneg, no link
> >> > Phy ID: 0x4d54 0x4950
> >> > Advertise: 0x0001 (same as above)
> >> > Link partner: 0x0000 (no advertisement received due to no link)
> >> >
> >> > Okay, what would now be interesting is to see how dev 1 behaves when
> >> > it has link with a 1000base-X link partner that is advertising
> >> > properly. If this changes to 0x01e0 or similar (in the high 16-bits
> >> > of offset 8) then we definitely know that this is an IEEE PHY register
> >> > set laid out in memory, and we can program the advertisement and read
> >> > the link partner's abilities.
> >>
> >> added register-read on the the new get_state function too
> >>
> >> on bootup it is now a bit different
> >>
> >> [ 1.086283] dev: 0 offset:0 0x40140 #was previously 0x840140
> >> [ 1.086301] dev: 0 offset:4 0x4d544950
> >> [ 1.089795] dev: 0 offset:8 0x1
> >> [ 1.093584] dev: 1 offset:0 0x81140
> >> [ 1.096716] dev: 1 offset:4 0x4d544950
> >> [ 1.100191] dev: 1 offset:8 0x1
> >>
> >> root@bpi-r3:~# ip link set eth1 up
> >> [ 172.037519] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/1000base-x link mode
> >> root@bpi-r3:~#
> >> [ 172.102949] offset:0 0x40140 #still same value
> >
> >If this is "dev: 1" the value has changed - the ANENABLE bit has been
> >turned off, which means it's not going to bother receiving or sending
> >the 16-bit control word. Bit 12 needs to stay set for it to perform
> >the exchange.
>
> Your right,was confused that dev 0 (fixed link to switch chip) had different value.
>
> offset:0 0x81140 => 0x40140
>
> So i should change offset 8 (currently 0x1) to at least 0x1 | BIT(12)? I can try to set this in the get_state callback,but i'm unsure i can read out it on my switch (basic mode changes yes,but not the value directly)...if mode is not autoneg i will see no change there.
Hi Frank,
Please try this untested patch, which should setup the PCS to perform
autonegotiation when using in-band mode for 1000base-X, write the
correct to offset 8, and set the link timer correctly.
Thanks.
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index b52f3b0177ef..1a3eb3ecf7e3 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -479,7 +479,7 @@
/* Register to programmable link timer, the unit in 2 * 8ns */
#define SGMSYS_PCS_LINK_TIMER 0x18
-#define SGMII_LINK_TIMER_DEFAULT (0x186a0 & GENMASK(19, 0))
+#define SGMII_LINK_TIMER_MASK GENMASK(19, 0)
/* Register to control remote fault */
#define SGMSYS_SGMII_MODE 0x20
diff --git a/drivers/net/ethernet/mediatek/mtk_sgmii.c b/drivers/net/ethernet/mediatek/mtk_sgmii.c
index 736839c84130..973275c8e29e 100644
--- a/drivers/net/ethernet/mediatek/mtk_sgmii.c
+++ b/drivers/net/ethernet/mediatek/mtk_sgmii.c
@@ -20,19 +20,35 @@ static struct mtk_pcs *pcs_to_mtk_pcs(struct phylink_pcs *pcs)
}
/* For SGMII interface mode */
-static int mtk_pcs_setup_mode_an(struct mtk_pcs *mpcs)
+static int mtk_pcs_setup_mode_an(struct mtk_pcs *mpcs,
+ phy_interface_t interface,
+ const unsigned long *advertising)
{
unsigned int val;
+ int advertise;
+
+ advertise = phylink_mii_c22_pcs_encode_advertisement(interface,
+ advertising);
+ if (advertise < 0)
+ advertise = 0;
+
+ if (interface == PHY_INTERFACE_MODE_SGMII)
+ val = 16000000 / 2 / 8;
+ else
+ val = 10000000 / 2 / 8;
/* Setup the link timer and QPHY power up inside SGMIISYS */
- regmap_write(mpcs->regmap, SGMSYS_PCS_LINK_TIMER,
- SGMII_LINK_TIMER_DEFAULT);
+ regmap_write(mpcs->regmap, SGMSYS_PCS_LINK_TIMER, val);
regmap_read(mpcs->regmap, SGMSYS_SGMII_MODE, &val);
val |= SGMII_REMOTE_FAULT_DIS;
regmap_write(mpcs->regmap, SGMSYS_SGMII_MODE, val);
+ regmap_update_bits(mpcs->regmap, SGMSYS_PCS_CONTROL_1 + 8, 0xffff,
+ advertise);
+
regmap_read(mpcs->regmap, SGMSYS_PCS_CONTROL_1, &val);
+ val |= SGMII_AN_ENABLE;
val |= SGMII_AN_RESTART;
regmap_write(mpcs->regmap, SGMSYS_PCS_CONTROL_1, val);
@@ -52,12 +68,6 @@ static int mtk_pcs_setup_mode_force(struct mtk_pcs *mpcs,
{
unsigned int val;
- regmap_read(mpcs->regmap, mpcs->ana_rgc3, &val);
- val &= ~RG_PHY_SPEED_MASK;
- if (interface == PHY_INTERFACE_MODE_2500BASEX)
- val |= RG_PHY_SPEED_3_125G;
- regmap_write(mpcs->regmap, mpcs->ana_rgc3, val);
-
/* Disable SGMII AN */
regmap_read(mpcs->regmap, SGMSYS_PCS_CONTROL_1, &val);
val &= ~SGMII_AN_ENABLE;
@@ -83,13 +93,20 @@ static int mtk_pcs_config(struct phylink_pcs *pcs, unsigned int mode,
bool permit_pause_to_mac)
{
struct mtk_pcs *mpcs = pcs_to_mtk_pcs(pcs);
+ unsigned int val;
int err = 0;
+ regmap_read(mpcs->regmap, mpcs->ana_rgc3, &val);
+ val &= ~RG_PHY_SPEED_MASK;
+ if (interface == PHY_INTERFACE_MODE_2500BASEX)
+ val |= RG_PHY_SPEED_3_125G;
+ regmap_write(mpcs->regmap, mpcs->ana_rgc3, val);
+
/* Setup SGMIISYS with the determined property */
- if (interface != PHY_INTERFACE_MODE_SGMII)
+ if (phylink_autoneg_inband(mode))
+ err = mtk_pcs_setup_mode_an(mpcs, interface, advertising);
+ else if (interface != PHY_INTERFACE_MODE_SGMII)
err = mtk_pcs_setup_mode_force(mpcs, interface);
- else if (phylink_autoneg_inband(mode))
- err = mtk_pcs_setup_mode_an(mpcs);
return err;
}
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
> Gesendet: Samstag, 22. Oktober 2022 um 11:11 Uhr
> Von: "Russell King (Oracle)" <[email protected]>
> Please try this untested patch, which should setup the PCS to perform
> autonegotiation when using in-band mode for 1000base-X, write the
> correct to offset 8, and set the link timer correctly.
hi,
this patch breaks connectivity at least on the sfp-port (eth1).
root@bpi-r3:~# ip link set eth1 up
[ 65.457521] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/1000base-x link mode
root@bpi-r3:~# [ 65.522936] offset:0 0x2c1140
[ 65.522950] offset:4 0x4d544950
[ 65.525914] offset:8 0x40e041a0
[ 65.529064] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 1Gbps/Unknown - flow control off
[ 65.540733] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
root@bpi-r3:~# ip a a 192.168.0.19/24 dev eth1
root@bpi-r3:~# ip r a default via 192.168.0.10
root@bpi-r3:~# iperf3 -c 192.168.0.21 #ping does not work too
iperf3: error - unable to send control message: Bad file descriptor
root@bpi-r3:~# ethtool eth1
[ 177.346183] offset:0 0x2c1140
[ 177.346202] offset:4 0x4d544950
Settings for eth[ 177.349168] offset:8 0x40e041a0
1:
Supported p[ 177.352477] offset:0 0x2c1140
[ 177.356952] offset:4 0x4d544950
Supported link modes: 1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Unknown! (255)
Auto-negotiation: on
Port: FIBRE
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
root@bpi-r3:~#
from sgmii_init
[ 1.091796] dev: 1 offset:0 0x81140
[ 1.094977] dev: 1 offset:4 0x4d544950
[ 1.098456] dev: 1 offset:8 0x1
...
pcs_get_state
[ 65.522936] offset:0 0x2c1140
[ 65.522950] offset:4 0x4d544950
[ 65.525914] offset:8 0x40e041a0
[ 177.346183] offset:0 0x2c1140
[ 177.346202] offset:4 0x4d544950
[ 177.349168] offset:8 0x40e041a0
[ 177.352477] offset:0 0x2c1140
[ 177.356952] offset:4 0x4d544950
regards Frank
On Sat, Oct 22, 2022 at 12:52:00PM +0200, Frank Wunderlich wrote:
> > Gesendet: Samstag, 22. Oktober 2022 um 11:11 Uhr
> > Von: "Russell King (Oracle)" <[email protected]>
>
> > Please try this untested patch, which should setup the PCS to perform
> > autonegotiation when using in-band mode for 1000base-X, write the
> > correct to offset 8, and set the link timer correctly.
>
> hi,
>
> this patch breaks connectivity at least on the sfp-port (eth1).
>
> root@bpi-r3:~# ip link set eth1 up
> [ 65.457521] mtk_soc_eth 15100000.ethernet eth1: configuring for inband/1000base-x link mode
> root@bpi-r3:~# [ 65.522936] offset:0 0x2c1140
> [ 65.522950] offset:4 0x4d544950
> [ 65.525914] offset:8 0x40e041a0
> [ 65.529064] mtk_soc_eth 15100000.ethernet eth1: Link is Up - 1Gbps/Unknown - flow control off
> [ 65.540733] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
>
> root@bpi-r3:~# ip a a 192.168.0.19/24 dev eth1
> root@bpi-r3:~# ip r a default via 192.168.0.10
> root@bpi-r3:~# iperf3 -c 192.168.0.21 #ping does not work too
> iperf3: error - unable to send control message: Bad file descriptor
> root@bpi-r3:~# ethtool eth1
> [ 177.346183] offset:0 0x2c1140
> [ 177.346202] offset:4 0x4d544950
> Settings for eth[ 177.349168] offset:8 0x40e041a0
> 1:
> Supported p[ 177.352477] offset:0 0x2c1140
> [ 177.356952] offset:4 0x4d544950
>
> Supported link modes: 1000baseX/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 1000baseX/Full
> Advertised pause frame use: Symmetric Receive-only
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Speed: 1000Mb/s
> Duplex: Unknown! (255)
> Auto-negotiation: on
> Port: FIBRE
> PHYAD: 0
> Transceiver: internal
> Current message level: 0x000000ff (255)
> drv probe link timer ifdown ifup rx_err tx_err
> Link detected: yes
> root@bpi-r3:~#
>
> from sgmii_init
> [ 1.091796] dev: 1 offset:0 0x81140
> [ 1.094977] dev: 1 offset:4 0x4d544950
> [ 1.098456] dev: 1 offset:8 0x1
> ...
> pcs_get_state
> [ 65.522936] offset:0 0x2c1140
> [ 65.522950] offset:4 0x4d544950
> [ 65.525914] offset:8 0x40e041a0
> [ 177.346183] offset:0 0x2c1140
> [ 177.346202] offset:4 0x4d544950
> [ 177.349168] offset:8 0x40e041a0
> [ 177.352477] offset:0 0x2c1140
> [ 177.356952] offset:4 0x4d544950
Hi,
Thanks. Well, the results suggest that the register at offset 8 is
indeed the advertisement and link-partner advertisement register. So
we have a bit of progress and a little more understanding of this
hardware.
Do you know if your link partner also thinks the link is up?
What I notice is:
mtk_soc_eth 15100000.ethernet eth1: Link is Up - 1Gbps/Unknown - flow control off
The duplex is "unknown" which means you're not filling in the
state->duplex field in your pcs_get_state() function. Given the
link parter adverisement is 0x00e0, this means the link partner
supports PAUSE, 1000base-X/Half and 1000base-X/Full. The resolution
is therefore full duplex, so can we hack that in to your
pcs_get_state() so we're getting that right for this testing please?
Now, I'm wondering what SGMII_IF_MODE_BIT0 and SGMII_IF_MODE_BIT5 do
in the SGMSYS_SGMII_MODE register. Does one of these bits set the
format for the 16-bit control word that's used to convey the
advertisements. I think the next step would be to play around with
these and see what effect setting or clearing these bits has -
please can you give that a go?
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Mon, Jan 16, 2023 at 04:21:30PM +0100, Bj?rn Mork wrote:
> [ 54.539438] mtk_soc_eth 15100000.ethernet wan: Link is Down
> [ 56.619937] mtk_sgmii_select_pcs: id=1
> [ 56.623690] mtk_pcs_config: interface=4
> [ 56.627511] offset:0 0x140
> [ 56.627513] offset:4 0x4d544950
> [ 56.630215] offset:8 0x20
> [ 56.633340] forcing AN
> [ 56.638292] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1000, use_an=1
> [ 56.649226] mtk_pcs_link_up: interface=4
> [ 56.653135] offset:0 0x81140
> [ 56.653137] offset:4 0x4d544950
> [ 56.656001] offset:8 0x1
> [ 56.659137] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
Thanks - there seems to be something weird with the bmcr value printed
above in the mtk_pcs_config line.
You have bmcr=0x1000, but the code sets two bits - SGMII_AN_RESTART and
SGMII_AN_ENABLE which are bits 9 and 12, so bmcr should be 0x1200, not
0x1000. Any ideas why?
Can you also hint at what the bits in the PHY register you quote mean
please?
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
"Russell King (Oracle)" <[email protected]> writes:
> On Mon, Jan 16, 2023 at 04:21:30PM +0100, Bjørn Mork wrote:
>> [ 54.539438] mtk_soc_eth 15100000.ethernet wan: Link is Down
>> [ 56.619937] mtk_sgmii_select_pcs: id=1
>> [ 56.623690] mtk_pcs_config: interface=4
>> [ 56.627511] offset:0 0x140
>> [ 56.627513] offset:4 0x4d544950
>> [ 56.630215] offset:8 0x20
>> [ 56.633340] forcing AN
>> [ 56.638292] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1000, use_an=1
>> [ 56.649226] mtk_pcs_link_up: interface=4
>> [ 56.653135] offset:0 0x81140
>> [ 56.653137] offset:4 0x4d544950
>> [ 56.656001] offset:8 0x1
>> [ 56.659137] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
>
> Thanks - there seems to be something weird with the bmcr value printed
> above in the mtk_pcs_config line.
>
> You have bmcr=0x1000, but the code sets two bits - SGMII_AN_RESTART and
> SGMII_AN_ENABLE which are bits 9 and 12, so bmcr should be 0x1200, not
> 0x1000. Any ideas why?
No, not really
> Can you also hint at what the bits in the PHY register you quote mean
> please?
This could very well be a red herring. It's the only difference I've
been able to spot, but I have no idea what it means.
This is an attempt at reformatting the pdf tables for email. Hope it's
readable:
VSPEC1_SGMII_STAT Reset Value
Chip Level SGMII status register (Register 30.9) 0008 H
15 14..8 7 6 5 4 3 2 1 .. 0
MACSEC_* Res RES Res ANOK RF ANAB LS DR
ro ro ro rolh ro roll ro
Field Bits Type Description
MACSEC_CAP 15 RO MACSEC Capability in the product
0 B DISABLED Product is not MACSEC capable
1 B ENABLED Product is MACSEC capable
RES 7 RO Reserved
Ignore when read.
ANOK 5 RO Auto-Negotiation Completed
Indicates whether the auto-negotiation process is completed or not.
0 B RUNNING Auto-negotiation process is in progress or not started
1 B COMPLETED Auto-negotiation process is completed
RF 4 ROLH Remote Fault
Indicates the detection of a remote fault event.
0 B INACTIVE No remote fault condition detected
1 B ACTIVE Remote fault condition detected
ANAB 3 RO Auto-Negotiation Ability
Specifies the auto-negotiation ability.
0 B DISABLED PHY is not able to perform auto-negotiation
1 B ENABLED PHY is able to perform auto-negotiation
LS 2 ROLL Link Status
Indicates the link status of the SGMII
0 B INACTIVE The link is down. No communication with link partner possible.
1 B ACTIVE The link is up. Data communication with link partner is possible.
DR 1:0 RO SGMII Data Rate
This field indicates the operating data rate of SGMII when link is up
00 B DR_10 SGMII link rate is 10 Mbit/s
01 B DR_100 SGMII link rate is 100 Mbit/s
10 B DR_1G SGMII link rate is 1000 Mbit/s
11 B DR_2G5 SGMII link rate is 2500 Mbit/s
Bjørn
Bjørn Mork <[email protected]> writes:
>> You have bmcr=0x1000, but the code sets two bits - SGMII_AN_RESTART and
>> SGMII_AN_ENABLE which are bits 9 and 12, so bmcr should be 0x1200, not
>> 0x1000. Any ideas why?
>
> No, not really
Doh! Looked over it again, and this was my fault of course. Had an
"bmcr = SGMII_AN_ENABLE;"
line overwriting the original value from a previous attempt without
changing the if condition.. Thanks for spotting that.
But this still doesn't work any better:
[ 43.019395] mtk_soc_eth 15100000.ethernet wan: Link is Down
[ 45.099898] mtk_sgmii_select_pcs: id=1
[ 45.103653] mtk_pcs_config: interface=4
[ 45.107473] offset:0 0x140
[ 45.107476] offset:4 0x4d544950
[ 45.110181] offset:8 0x20
[ 45.113305] forcing AN
[ 45.118256] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
[ 45.129191] mtk_pcs_link_up: interface=4
[ 45.133100] offset:0 0x81140
[ 45.133102] offset:4 0x4d544950
[ 45.135967] offset:8 0x1
[ 45.139104] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
Bjørn
On Mon, Jan 16, 2023 at 05:33:53PM +0100, Bj?rn Mork wrote:
> "Russell King (Oracle)" <[email protected]> writes:
>
> > On Mon, Jan 16, 2023 at 04:21:30PM +0100, Bj?rn Mork wrote:
> >> [ 54.539438] mtk_soc_eth 15100000.ethernet wan: Link is Down
> >> [ 56.619937] mtk_sgmii_select_pcs: id=1
> >> [ 56.623690] mtk_pcs_config: interface=4
> >> [ 56.627511] offset:0 0x140
> >> [ 56.627513] offset:4 0x4d544950
> >> [ 56.630215] offset:8 0x20
> >> [ 56.633340] forcing AN
> >> [ 56.638292] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1000, use_an=1
> >> [ 56.649226] mtk_pcs_link_up: interface=4
> >> [ 56.653135] offset:0 0x81140
> >> [ 56.653137] offset:4 0x4d544950
> >> [ 56.656001] offset:8 0x1
> >> [ 56.659137] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
> >
> > Thanks - there seems to be something weird with the bmcr value printed
> > above in the mtk_pcs_config line.
> >
> > You have bmcr=0x1000, but the code sets two bits - SGMII_AN_RESTART and
> > SGMII_AN_ENABLE which are bits 9 and 12, so bmcr should be 0x1200, not
> > 0x1000. Any ideas why?
>
> No, not really
>
> > Can you also hint at what the bits in the PHY register you quote mean
> > please?
>
> This could very well be a red herring. It's the only difference I've
> been able to spot, but I have no idea what it means.
>
> This is an attempt at reformatting the pdf tables for email. Hope it's
> readable:
I found the document for the PHY at:
https://assets.maxlinear.com/web/documents/617792_gpy212b1vc_gpy212c0vc_ds_rev1.3.pdf
It seems as I suspected, the PHY has not completed SGMII AN. Please
can you read register 8 when operating at 1G speeds as well
(VSPEC1_SGMII_CTRL)? Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
"Russell King (Oracle)" <[email protected]> writes:
> I found the document for the PHY at:
>
> https://assets.maxlinear.com/web/documents/617792_gpy212b1vc_gpy212c0vc_ds_rev1.3.pdf
>
> It seems as I suspected, the PHY has not completed SGMII AN. Please
> can you read register 8 when operating at 1G speeds as well
> (VSPEC1_SGMII_CTRL)? Thanks.
Both phys at 1G:
root@OpenWrt:/# mdio mdio-bus 5:30 raw 8
0x34da
root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
0x34da
Bjørn
"Russell King (Oracle)" <[email protected]> writes:
> On Mon, Jan 16, 2023 at 05:45:12PM +0100, Bjørn Mork wrote:
>> Bjørn Mork <[email protected]> writes:
>>
>> >> You have bmcr=0x1000, but the code sets two bits - SGMII_AN_RESTART and
>> >> SGMII_AN_ENABLE which are bits 9 and 12, so bmcr should be 0x1200, not
>> >> 0x1000. Any ideas why?
>> >
>> > No, not really
>>
>> Doh! Looked over it again, and this was my fault of course. Had an
>>
>> "bmcr = SGMII_AN_ENABLE;"
>>
>> line overwriting the original value from a previous attempt without
>> changing the if condition.. Thanks for spotting that.
>>
>> But this still doesn't work any better:
>>
>> [ 43.019395] mtk_soc_eth 15100000.ethernet wan: Link is Down
>> [ 45.099898] mtk_sgmii_select_pcs: id=1
>> [ 45.103653] mtk_pcs_config: interface=4
>> [ 45.107473] offset:0 0x140
>> [ 45.107476] offset:4 0x4d544950
>> [ 45.110181] offset:8 0x20
>> [ 45.113305] forcing AN
>> [ 45.118256] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
>> [ 45.129191] mtk_pcs_link_up: interface=4
>> [ 45.133100] offset:0 0x81140
>> [ 45.133102] offset:4 0x4d544950
>> [ 45.135967] offset:8 0x1
>> [ 45.139104] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
>
> In your _dump_pcs_ctrl() function, please can you dump the
> SGMSYS_SGMII_MODE register as well (offset 0x20), in case this gives
> more clue as to what's going on.
[ 49.339410] mtk_soc_eth 15100000.ethernet wan: Link is Down
[ 52.459913] mtk_sgmii_select_pcs: id=1
[ 52.463673] mtk_pcs_config: interface=4
[ 52.467494] offset:0 0x140
[ 52.467496] offset:4 0x4d544950
[ 52.470199] offset:8 0x20
[ 52.473325] offset:20 0x10000
[ 52.475929] forcing AN
[ 52.481232] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
[ 52.492166] mtk_pcs_link_up: interface=4
[ 52.496072] offset:0 0x81140
[ 52.496074] offset:4 0x4d544950
[ 52.498938] offset:8 0x1
[ 52.502067] offset:20 0x10000
[ 52.504599] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
[ 65.979410] mtk_soc_eth 15100000.ethernet wan: Link is Down
[ 70.139856] mtk_sgmii_select_pcs: id=1
[ 70.143616] mtk_pcs_config: interface=22
[ 70.147523] offset:0 0x81140
[ 70.147525] offset:4 0x4d544950
[ 70.150402] offset:8 0x1
[ 70.153526] offset:20 0x10000
[ 70.156049] mtk_pcs_config: rgc3=0x4, advertise=0x20 (changed), link_timer=10000000, sgm_mode=0x0, bmcr=0x0, use_an=0
[ 70.169672] mtk_pcs_link_up: interface=22
[ 70.173664] offset:0 0x40140
[ 70.173666] offset:4 0x4d544950
[ 70.176530] offset:8 0x20
[ 70.179659] offset:20 0x10000
[ 70.182279] mtk_soc_eth 15100000.ethernet wan: Link is Up - 2.5Gbps/Full - flow control rx/tx
Bjørn
On Mon, Jan 16, 2023 at 06:59:19PM +0100, Bj?rn Mork wrote:
> "Russell King (Oracle)" <[email protected]> writes:
>
> > On Mon, Jan 16, 2023 at 05:45:12PM +0100, Bj?rn Mork wrote:
> >> Bj?rn Mork <[email protected]> writes:
> >>
> >> >> You have bmcr=0x1000, but the code sets two bits - SGMII_AN_RESTART and
> >> >> SGMII_AN_ENABLE which are bits 9 and 12, so bmcr should be 0x1200, not
> >> >> 0x1000. Any ideas why?
> >> >
> >> > No, not really
> >>
> >> Doh! Looked over it again, and this was my fault of course. Had an
> >>
> >> "bmcr = SGMII_AN_ENABLE;"
> >>
> >> line overwriting the original value from a previous attempt without
> >> changing the if condition.. Thanks for spotting that.
> >>
> >> But this still doesn't work any better:
> >>
> >> [ 43.019395] mtk_soc_eth 15100000.ethernet wan: Link is Down
> >> [ 45.099898] mtk_sgmii_select_pcs: id=1
> >> [ 45.103653] mtk_pcs_config: interface=4
> >> [ 45.107473] offset:0 0x140
> >> [ 45.107476] offset:4 0x4d544950
> >> [ 45.110181] offset:8 0x20
> >> [ 45.113305] forcing AN
> >> [ 45.118256] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
> >> [ 45.129191] mtk_pcs_link_up: interface=4
> >> [ 45.133100] offset:0 0x81140
> >> [ 45.133102] offset:4 0x4d544950
> >> [ 45.135967] offset:8 0x1
> >> [ 45.139104] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
> >
> > In your _dump_pcs_ctrl() function, please can you dump the
> > SGMSYS_SGMII_MODE register as well (offset 0x20), in case this gives
> > more clue as to what's going on.
>
>
> [ 49.339410] mtk_soc_eth 15100000.ethernet wan: Link is Down
> [ 52.459913] mtk_sgmii_select_pcs: id=1
> [ 52.463673] mtk_pcs_config: interface=4
> [ 52.467494] offset:0 0x140
> [ 52.467496] offset:4 0x4d544950
> [ 52.470199] offset:8 0x20
> [ 52.473325] offset:20 0x10000
> [ 52.475929] forcing AN
> [ 52.481232] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
> [ 52.492166] mtk_pcs_link_up: interface=4
> [ 52.496072] offset:0 0x81140
> [ 52.496074] offset:4 0x4d544950
> [ 52.498938] offset:8 0x1
> [ 52.502067] offset:20 0x10000
> [ 52.504599] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
> [ 65.979410] mtk_soc_eth 15100000.ethernet wan: Link is Down
> [ 70.139856] mtk_sgmii_select_pcs: id=1
> [ 70.143616] mtk_pcs_config: interface=22
> [ 70.147523] offset:0 0x81140
> [ 70.147525] offset:4 0x4d544950
> [ 70.150402] offset:8 0x1
> [ 70.153526] offset:20 0x10000
> [ 70.156049] mtk_pcs_config: rgc3=0x4, advertise=0x20 (changed), link_timer=10000000, sgm_mode=0x0, bmcr=0x0, use_an=0
> [ 70.169672] mtk_pcs_link_up: interface=22
> [ 70.173664] offset:0 0x40140
> [ 70.173666] offset:4 0x4d544950
> [ 70.176530] offset:8 0x20
> [ 70.179659] offset:20 0x10000
> [ 70.182279] mtk_soc_eth 15100000.ethernet wan: Link is Up - 2.5Gbps/Full - flow control rx/tx
Umm. What's at offset:20 seems to be unprogrammable - it always reads
back with only bit 16 set! This probably explains why it's not working,
as it looks like it can't be programmed to operate in SGMII mode!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Bjørn Mork <[email protected]> writes:
> [ 52.473325] offset:20 0x10000
Should have warned about my inability to write the simplest code without
adding more bugs than characters. 20 != 0x20
I hope this makes more sense:
[ 44.139420] mtk_soc_eth 15100000.ethernet wan: Link is Down
[ 47.259922] mtk_sgmii_select_pcs: id=1
[ 47.263683] mtk_pcs_config: interface=4
[ 47.267503] offset:0 0x140
[ 47.267505] offset:4 0x4d544950
[ 47.270210] offset:8 0x20
[ 47.273335] offset:0x20 0x31120018
[ 47.275939] forcing AN
[ 47.281676] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
[ 47.292610] mtk_pcs_link_up: interface=4
[ 47.296516] offset:0 0x81140
[ 47.296518] offset:4 0x4d544950
[ 47.299387] offset:8 0x1
[ 47.302512] offset:0x20 0x3112011b
[ 47.305043] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
[ 56.619420] mtk_soc_eth 15100000.ethernet wan: Link is Down
[ 60.779865] mtk_sgmii_select_pcs: id=1
[ 60.783623] mtk_pcs_config: interface=22
[ 60.787531] offset:0 0x81140
[ 60.787533] offset:4 0x4d544950
[ 60.790409] offset:8 0x1
[ 60.793535] offset:0x20 0x3112011b
[ 60.796057] mtk_pcs_config: rgc3=0x4, advertise=0x20 (changed), link_timer=10000000, sgm_mode=0x0, bmcr=0x0, use_an=0
[ 60.810117] mtk_pcs_link_up: interface=22
[ 60.814110] offset:0 0x40140
[ 60.814112] offset:4 0x4d544950
[ 60.816976] offset:8 0x20
[ 60.820105] offset:0x20 0x31120018
[ 60.822723] mtk_soc_eth 15100000.ethernet wan: Link is Up - 2.5Gbps/Full - flow control rx/tx
Bjørn
On Mon, Jan 16, 2023 at 07:04:53PM +0100, Bj?rn Mork wrote:
> Bj?rn Mork <[email protected]> writes:
>
> > [ 52.473325] offset:20 0x10000
>
> Should have warned about my inability to write the simplest code without
> adding more bugs than characters. 20 != 0x20
Ah, that kind of explains the lack of change in the values at offset 20!
> [ 44.139420] mtk_soc_eth 15100000.ethernet wan: Link is Down
> [ 47.259922] mtk_sgmii_select_pcs: id=1
> [ 47.263683] mtk_pcs_config: interface=4
> [ 47.267503] offset:0 0x140
> [ 47.267505] offset:4 0x4d544950
> [ 47.270210] offset:8 0x20
> [ 47.273335] offset:0x20 0x31120018
> [ 47.275939] forcing AN
> [ 47.281676] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
> [ 47.292610] mtk_pcs_link_up: interface=4
> [ 47.296516] offset:0 0x81140
> [ 47.296518] offset:4 0x4d544950
> [ 47.299387] offset:8 0x1
> [ 47.302512] offset:0x20 0x3112011b
> [ 47.305043] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
> [ 56.619420] mtk_soc_eth 15100000.ethernet wan: Link is Down
> [ 60.779865] mtk_sgmii_select_pcs: id=1
> [ 60.783623] mtk_pcs_config: interface=22
> [ 60.787531] offset:0 0x81140
> [ 60.787533] offset:4 0x4d544950
> [ 60.790409] offset:8 0x1
> [ 60.793535] offset:0x20 0x3112011b
> [ 60.796057] mtk_pcs_config: rgc3=0x4, advertise=0x20 (changed), link_timer=10000000, sgm_mode=0x0, bmcr=0x0, use_an=0
> [ 60.810117] mtk_pcs_link_up: interface=22
> [ 60.814110] offset:0 0x40140
> [ 60.814112] offset:4 0x4d544950
> [ 60.816976] offset:8 0x20
> [ 60.820105] offset:0x20 0x31120018
> [ 60.822723] mtk_soc_eth 15100000.ethernet wan: Link is Up - 2.5Gbps/Full - flow control rx/tx
That all looks fine. However, I'm running out of ideas. What we
seem to have is:
PHY:
VSPEC1_SGMII_CTRL = 0x34da
VSPEC1_SGMII_STAT = 0x000e
The PHY is programmed to exchange SGMII with the host PCS, and it
says that it hasn't completed that exchange (bit 5 of STAT).
The Mediatek PCS says:
BMCR = 0x1140 AN enabled
BMSR = 0x0008 AN capable
ADVERTISE = 0x0001 SGMII response (bit 14 is clear, hardware is
supposed to manage that bit)
LPA = 0x0000 SGMII received control word (nothing)
SGMII_MODE = 0x011b SGMII mode, duplex AN, 1000M, Full duplex,
Remote fault disable
which all looks like it should work - but it isn't.
One last thing I can think of trying at the moment would be writing
the VSPEC1_SGMII_CTRL with 0x36da, setting bit 9 which allegedly
restarts the SGMII exchange. There's some comments in the PHY driver
that this may be needed - maybe it's necessary once the MAC's PCS
has been switched to SGMII mode.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Mon, Jan 16, 2023 at 07:30:27PM +0100, Bj?rn Mork wrote:
> "Russell King (Oracle)" <[email protected]> writes:
>
> > That all looks fine. However, I'm running out of ideas.
>
> Thanks a lot for the effort in any case. It's comforting that even the
> top experts can't figure out this one :-)
>
>
> > What we seem to have is:
> >
> > PHY:
> > VSPEC1_SGMII_CTRL = 0x34da
> > VSPEC1_SGMII_STAT = 0x000e
> >
> > The PHY is programmed to exchange SGMII with the host PCS, and it
> > says that it hasn't completed that exchange (bit 5 of STAT).
> >
> > The Mediatek PCS says:
> > BMCR = 0x1140 AN enabled
> > BMSR = 0x0008 AN capable
> > ADVERTISE = 0x0001 SGMII response (bit 14 is clear, hardware is
> > supposed to manage that bit)
> > LPA = 0x0000 SGMII received control word (nothing)
> > SGMII_MODE = 0x011b SGMII mode, duplex AN, 1000M, Full duplex,
> > Remote fault disable
> >
> > which all looks like it should work - but it isn't.
> >
> > One last thing I can think of trying at the moment would be writing
> > the VSPEC1_SGMII_CTRL with 0x36da, setting bit 9 which allegedly
> > restarts the SGMII exchange. There's some comments in the PHY driver
> > that this may be needed - maybe it's necessary once the MAC's PCS
> > has been switched to SGMII mode.
>
>
> Tried that now. Didn't change anything. And still no packets.
>
> root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
> 0x34da
> root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
> 0x000e
> root@OpenWrt:/# mdio mdio-bus 6:30 raw 8 0x36da
> root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
> 0x34da
> root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
> 0x000e
If bit 9 is indeed the restart-an bit, it will be self-clearing, so
I wouldn't expect a read back of it to change to 0x36da.
I guess next thing to try is clearing and setting the AN enable bit,
bit 12, so please try this:
mdio mdio-bus 6:30 raw 8 0x24da
mdio mdio-bus 6:30 raw 8 0x36da
mdio mdio-bus 6:30 raw 9
If that doesn't work, then let's try something a bit harder:
mdio mdio-bus 6:30 raw 8 0xb4da
mdio mdio-bus 6:30 raw 9
Please let me know the results from those.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Mon, Jan 16, 2023 at 05:45:12PM +0100, Bj?rn Mork wrote:
> Bj?rn Mork <[email protected]> writes:
>
> >> You have bmcr=0x1000, but the code sets two bits - SGMII_AN_RESTART and
> >> SGMII_AN_ENABLE which are bits 9 and 12, so bmcr should be 0x1200, not
> >> 0x1000. Any ideas why?
> >
> > No, not really
>
> Doh! Looked over it again, and this was my fault of course. Had an
>
> "bmcr = SGMII_AN_ENABLE;"
>
> line overwriting the original value from a previous attempt without
> changing the if condition.. Thanks for spotting that.
>
> But this still doesn't work any better:
>
> [ 43.019395] mtk_soc_eth 15100000.ethernet wan: Link is Down
> [ 45.099898] mtk_sgmii_select_pcs: id=1
> [ 45.103653] mtk_pcs_config: interface=4
> [ 45.107473] offset:0 0x140
> [ 45.107476] offset:4 0x4d544950
> [ 45.110181] offset:8 0x20
> [ 45.113305] forcing AN
> [ 45.118256] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
> [ 45.129191] mtk_pcs_link_up: interface=4
> [ 45.133100] offset:0 0x81140
> [ 45.133102] offset:4 0x4d544950
> [ 45.135967] offset:8 0x1
> [ 45.139104] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
In your _dump_pcs_ctrl() function, please can you dump the
SGMSYS_SGMII_MODE register as well (offset 0x20), in case this gives
more clue as to what's going on.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
Bjørn Mork <[email protected]> writes:
> "Russell King (Oracle)" <[email protected]> writes:
>
>> That all looks fine. However, I'm running out of ideas.
>
> Thanks a lot for the effort in any case. It's comforting that even the
> top experts can't figure out this one :-)
>
>
>> What we seem to have is:
>>
>> PHY:
>> VSPEC1_SGMII_CTRL = 0x34da
>> VSPEC1_SGMII_STAT = 0x000e
>>
>> The PHY is programmed to exchange SGMII with the host PCS, and it
>> says that it hasn't completed that exchange (bit 5 of STAT).
>>
>> The Mediatek PCS says:
>> BMCR = 0x1140 AN enabled
>> BMSR = 0x0008 AN capable
>> ADVERTISE = 0x0001 SGMII response (bit 14 is clear, hardware is
>> supposed to manage that bit)
>> LPA = 0x0000 SGMII received control word (nothing)
>> SGMII_MODE = 0x011b SGMII mode, duplex AN, 1000M, Full duplex,
>> Remote fault disable
>>
>> which all looks like it should work - but it isn't.
>>
>> One last thing I can think of trying at the moment would be writing
>> the VSPEC1_SGMII_CTRL with 0x36da, setting bit 9 which allegedly
>> restarts the SGMII exchange. There's some comments in the PHY driver
>> that this may be needed - maybe it's necessary once the MAC's PCS
>> has been switched to SGMII mode.
>
>
> Tried that now. Didn't change anything. And still no packets.
>
> root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
> 0x34da
> root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
> 0x000e
> root@OpenWrt:/# mdio mdio-bus 6:30 raw 8 0x36da
> root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
> 0x34da
> root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
> 0x000e
And just as we were about to give up I got another datapoint.
Changed phy-mode and managed mode as follows in the device tree as a
last desperate attempt:
mac@1 {
compatible = "mediatek,eth-mac";
reg = <1>;
label = "wan";
// phy-mode = "2500base-x";
phy-mode = "sgmii";
managed = "in-band-status";
phy-handle = <&phy6>;
};
Made things fail with 2.5G, as expected I guess. But this actually works
with 1G!
Except for an unexpected packet drop. But at least there are packets
coming through at 1G now. This is the remote end of the link:
ns-enp3s0# ethtool -s enp3s0 autoneg off speed 1000 duplex full
ns-enp3s0# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.544 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.283 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.261 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.295 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=0.273 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=0.290 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=0.266 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=0.269 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=0.270 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=0.261 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=0.261 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=0.266 ms
^C
--- 192.168.0.1 ping statistics ---
13 packets transmitted, 12 received, 7.69231% packet loss, time 12282ms
rtt min/avg/max/mdev = 0.261/0.294/0.544/0.075 ms
ns-enp3s0# ethtool enp3s0
Settings for enp3s0:
Supported ports: [ TP ]
Supported link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
2500baseT/Full
5000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: off
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
MDI-X: Unknown
Supports Wake-on: pg
Wake-on: g
Current message level: 0x00000005 (5)
drv link
Link detected: yes
.
The MT7986 end looks like this:
root@OpenWrt:/# [ 55.659413] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
[ 55.664380] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
[ 58.779924] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
[ 58.784884] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
[ 58.789841] mtk_sgmii_select_pcs: id=1
[ 58.793581] mtk_pcs_config: interface=4
[ 58.797399] offset:0 0x81140
[ 58.797401] offset:4 0x4d544950
[ 58.800273] offset:8 0x1a0
[ 58.803397] offset:0x20 0x31120118
[ 58.806089] forcing AN
[ 58.811826] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
[ 58.822759] mtk_pcs_restart_an
[ 58.825800] mtk_pcs_get_state: bm=0x81140, adv=0xda014001
[ 58.831184] mtk_pcs_get_state: bm=0x2c1140, adv=0xda014001
[ 58.836649] mtk_pcs_link_up: interface=4
[ 58.840559] offset:0 0xac1140
[ 58.840561] offset:4 0x4d544950
[ 58.843512] offset:8 0xda014001
[ 58.846636] offset:0x20 0x3112011b
[ 58.849780] mtk_soc_eth 15100000.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx
[ 58.861521] IPv6: ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
root@OpenWrt:/# ethtool wan
Settings for wan:
Supported ports: [ ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: master
Port: Twisted Pair
PHYAD: 6
Transceiver: external
MDI-X: on (auto)
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
0x34da
root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
0x002e
And naturally 100M works too:
root@OpenWrt:/# [ 528.859412] mtk_pcs_get_state: bm=0x2c1140, adv=0x5a014001
[ 528.864908] mtk_soc_eth 15100000.ethernet wan: Link is Down
[ 528.870513] mtk_pcs_get_state: bm=0x2c1140, adv=0x5a014001
[ 528.875983] mtk_pcs_get_state: bm=0x2c1140, adv=0x5a014001
[ 530.939756] mtk_pcs_get_state: bm=0x2c1140, adv=0xd6014001
[ 530.945238] mtk_pcs_link_up: interface=4
[ 530.949143] offset:0 0x2c1140
[ 530.949145] offset:4 0x4d544950
[ 530.952107] offset:8 0xd6014001
[ 530.955232] offset:0x20 0x3112011b
[ 530.958368] mtk_soc_eth 15100000.ethernet wan: Link is Up - 100Mbps/Full - flow control rx/tx
root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
0x34da
root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
0x002d
Now, if we only could figure out what the difference is between this and
what we configure when the mode is changed from 2500base-x to sgmii.
Bjørn
"Russell King (Oracle)" <[email protected]> writes:
> On Mon, Jan 16, 2023 at 07:30:27PM +0100, Bjørn Mork wrote:
>> "Russell King (Oracle)" <[email protected]> writes:
>>
>> > That all looks fine. However, I'm running out of ideas.
>>
>> Thanks a lot for the effort in any case. It's comforting that even the
>> top experts can't figure out this one :-)
>>
>>
>> > What we seem to have is:
>> >
>> > PHY:
>> > VSPEC1_SGMII_CTRL = 0x34da
>> > VSPEC1_SGMII_STAT = 0x000e
>> >
>> > The PHY is programmed to exchange SGMII with the host PCS, and it
>> > says that it hasn't completed that exchange (bit 5 of STAT).
>> >
>> > The Mediatek PCS says:
>> > BMCR = 0x1140 AN enabled
>> > BMSR = 0x0008 AN capable
>> > ADVERTISE = 0x0001 SGMII response (bit 14 is clear, hardware is
>> > supposed to manage that bit)
>> > LPA = 0x0000 SGMII received control word (nothing)
>> > SGMII_MODE = 0x011b SGMII mode, duplex AN, 1000M, Full duplex,
>> > Remote fault disable
>> >
>> > which all looks like it should work - but it isn't.
>> >
>> > One last thing I can think of trying at the moment would be writing
>> > the VSPEC1_SGMII_CTRL with 0x36da, setting bit 9 which allegedly
>> > restarts the SGMII exchange. There's some comments in the PHY driver
>> > that this may be needed - maybe it's necessary once the MAC's PCS
>> > has been switched to SGMII mode.
>>
>>
>> Tried that now. Didn't change anything. And still no packets.
>>
>> root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
>> 0x34da
>> root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
>> 0x000e
>> root@OpenWrt:/# mdio mdio-bus 6:30 raw 8 0x36da
>> root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
>> 0x34da
>> root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
>> 0x000e
>
> If bit 9 is indeed the restart-an bit, it will be self-clearing, so
> I wouldn't expect a read back of it to change to 0x36da.
>
> I guess next thing to try is clearing and setting the AN enable bit,
> bit 12, so please try this:
>
> mdio mdio-bus 6:30 raw 8 0x24da
> mdio mdio-bus 6:30 raw 8 0x36da
> mdio mdio-bus 6:30 raw 9
>
> If that doesn't work, then let's try something a bit harder:
>
> mdio mdio-bus 6:30 raw 8 0xb4da
> mdio mdio-bus 6:30 raw 9
>
> Please let me know the results from those.
OK, back to the original dts with phy-mode = "2500base-x", with peer set
to 1G. Still no success:
root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
0x34da
root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
0x000e
root@OpenWrt:/# mdio mdio-bus 6:30 raw 8 0x24da
root@OpenWrt:/# mdio mdio-bus 6:30 raw 8 0x36da
root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
0x000e
root@OpenWrt:/# mdio mdio-bus 6:30 raw 8 0xb4da
root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
0x000e
Bjørn
"Russell King (Oracle)" <[email protected]> writes:
> That all looks fine. However, I'm running out of ideas.
Thanks a lot for the effort in any case. It's comforting that even the
top experts can't figure out this one :-)
> What we seem to have is:
>
> PHY:
> VSPEC1_SGMII_CTRL = 0x34da
> VSPEC1_SGMII_STAT = 0x000e
>
> The PHY is programmed to exchange SGMII with the host PCS, and it
> says that it hasn't completed that exchange (bit 5 of STAT).
>
> The Mediatek PCS says:
> BMCR = 0x1140 AN enabled
> BMSR = 0x0008 AN capable
> ADVERTISE = 0x0001 SGMII response (bit 14 is clear, hardware is
> supposed to manage that bit)
> LPA = 0x0000 SGMII received control word (nothing)
> SGMII_MODE = 0x011b SGMII mode, duplex AN, 1000M, Full duplex,
> Remote fault disable
>
> which all looks like it should work - but it isn't.
>
> One last thing I can think of trying at the moment would be writing
> the VSPEC1_SGMII_CTRL with 0x36da, setting bit 9 which allegedly
> restarts the SGMII exchange. There's some comments in the PHY driver
> that this may be needed - maybe it's necessary once the MAC's PCS
> has been switched to SGMII mode.
Tried that now. Didn't change anything. And still no packets.
root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
0x34da
root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
0x000e
root@OpenWrt:/# mdio mdio-bus 6:30 raw 8 0x36da
root@OpenWrt:/# mdio mdio-bus 6:30 raw 8
0x34da
root@OpenWrt:/# mdio mdio-bus 6:30 raw 9
0x000e
Bjørn
On Mon, Jan 16, 2023 at 07:50:52PM +0100, Bj?rn Mork wrote:
> Made things fail with 2.5G, as expected I guess. But this actually works
> with 1G!
>
> Except for an unexpected packet drop. But at least there are packets
> coming through at 1G now. This is the remote end of the link:
>
> ns-enp3s0# ethtool -s enp3s0 autoneg off speed 1000 duplex full
> ns-enp3s0# ping 192.168.0.1
> PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
> 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.544 ms
> 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.283 ms
> 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.261 ms
> 64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.295 ms
> 64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=0.273 ms
> 64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=0.290 ms
> 64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=0.266 ms
> 64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=0.269 ms
> 64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=0.270 ms
> 64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=0.261 ms
> 64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=0.261 ms
> 64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=0.266 ms
> ^C
> --- 192.168.0.1 ping statistics ---
> 13 packets transmitted, 12 received, 7.69231% packet loss, time 12282ms
> rtt min/avg/max/mdev = 0.261/0.294/0.544/0.075 ms
> ns-enp3s0# ethtool enp3s0
> Settings for enp3s0:
> Supported ports: [ TP ]
> Supported link modes: 100baseT/Full
> 1000baseT/Full
> 10000baseT/Full
> 2500baseT/Full
> 5000baseT/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 1000baseT/Full
> Advertised pause frame use: Symmetric
> Advertised auto-negotiation: No
> Advertised FEC modes: Not reported
> Speed: 1000Mb/s
> Duplex: Full
> Auto-negotiation: off
> Port: Twisted Pair
> PHYAD: 0
> Transceiver: internal
> MDI-X: Unknown
> Supports Wake-on: pg
> Wake-on: g
> Current message level: 0x00000005 (5)
> drv link
> Link detected: yes
> .
>
> The MT7986 end looks like this:
>
> root@OpenWrt:/# [ 55.659413] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
> [ 55.664380] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
> [ 58.779924] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
> [ 58.784884] mtk_pcs_get_state: bm=0x81140, adv=0x1a0
> [ 58.789841] mtk_sgmii_select_pcs: id=1
> [ 58.793581] mtk_pcs_config: interface=4
> [ 58.797399] offset:0 0x81140
> [ 58.797401] offset:4 0x4d544950
> [ 58.800273] offset:8 0x1a0
> [ 58.803397] offset:0x20 0x31120118
This looks like it's configured for 1000base-X at this point.
> [ 58.806089] forcing AN
> [ 58.811826] mtk_pcs_config: rgc3=0x0, advertise=0x1 (changed), link_timer=1600000, sgm_mode=0x103, bmcr=0x1200, use_an=1
> [ 58.822759] mtk_pcs_restart_an
> [ 58.825800] mtk_pcs_get_state: bm=0x81140, adv=0xda014001
> [ 58.831184] mtk_pcs_get_state: bm=0x2c1140, adv=0xda014001
> [ 58.836649] mtk_pcs_link_up: interface=4
> [ 58.840559] offset:0 0xac1140
> [ 58.840561] offset:4 0x4d544950
> [ 58.843512] offset:8 0xda014001
> [ 58.846636] offset:0x20 0x3112011b
and here we've reconfigured it for SGMII mode - and we can see the
Mediatek PCS has set the ACK bit (bit 14) in its advertisement
register as one would expect.
> Now, if we only could figure out what the difference is between this and
> what we configure when the mode is changed from 2500base-x to sgmii.
Maybe there is something missing which we need to do on the Mediatek
side to properly switch between 2500base-X and SGMII.
It has a feel of a problem changing the underlying link speed between
3.125 and 1.25Gbps, which is done by the ANA_RGC3 register.
Hmm, maybe the PCS needs to be powered down to change the speed, in
other words, SGMII_PHYA_PWD needs to be set before the write to the
ANA_RGC3 register?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!