From: "Russell King (Oracle)" <linux@armlinux.org.uk> To: Frank Wunderlich <frank-w@public-files.de> Cc: Frank Wunderlich <linux@fw-web.de>, linux-mediatek@lists.infradead.org, Alexander Couzens <lynxis@fe80.eu>, Felix Fietkau <nbd@nbd.name>, John Crispin <john@phrozen.org>, Sean Wang <sean.wang@mediatek.com>, Mark Lee <Mark-MC.Lee@mediatek.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Matthias Brugger <matthias.bgg@gmail.com>, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: Re: Re: Re: Re: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops Date: Sat, 22 Oct 2022 20:18:27 +0100 [thread overview] Message-ID: <Y1RCA+l2OHkrFfhB@shell.armlinux.org.uk> (raw) In-Reply-To: <trinity-164dc5a6-98ce-464c-a43d-b00b91ca69e5-1666461195968@3c-app-gmx-bs49> Hi, On Sat, Oct 22, 2022 at 07:53:16PM +0200, Frank Wunderlich wrote: > > Gesendet: Samstag, 22. Oktober 2022 um 19:05 Uhr > > Von: "Russell King (Oracle)" <linux@armlinux.org.uk> > > 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)" <linux@armlinux.org.uk> > > > > this patch breaks connectivity at least on the sfp-port (eth1). > > > > 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? > > yes link is up on my switch, cannot enable autoneg for fibre-port, so port is fixed to 1000M/full flowcontrol enabled. > > > 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? > > 0xe0 is bits 5-7 are set (in lower byte from upper word)..which one is for duplex? > > so i should set state->duplex/pause based on this value (maybe compare with own caps)? > > found a documentation where 5=full,6=half, and bits 7+8 are for pause (symetric/asymetric) > > regmap_read(mpcs->regmap, SGMSYS_PCS_CONTROL_1+8, &val); > partner_advertising = (val & 0x00ff0000) >> 16; Not quite :) When we have the link partner's advertisement and the BMSR, we have a helper function in phylink to do all the gritty work: regmap_read(mpcs->regmap, SGMSYS_PCS_CONTROL_1, &bm); regmap_read(mpcs->regmap, SGMSYS_PCS_CONTROL_1 + 8, &adv); phylink_mii_c22_pcs_decode_state(state, bm >> 16, adv >> 16); will do all the work for you without having to care about whether you're operating at 2500base-X, 1000base-X or SGMII mode. > > 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? > > these is not clear to me...should i blindly set these and how to > verify what they do? Yes please - I don't think anyone knows what they do. > is network broken because of wrong duplex/pause setting? do not > fully understand your Patch. I suspect not having the duplex correct _could_ break stuff, but I also wonder whether the PCS is trying to decode the advertisements itself and coming out with the wrong settings. If it's interpreting a link partner advertisement of 0x00e0 using SGMII rules, then it will be looking at bits 11 and 10 for the speed, both of which are zero, which means 10Mbps - and 1000base-X doesn't operate at 10Mbps! So my hunch is that one of those two IF_MODE_BIT{0,5} _might_ change the way the PCS interprets the control word, but as we don't have any documentation to go on, only experimentation will answer this question. If these registers are MMIO, you could ensure that you have /dev/mem access enabled, and use devmem2 to poke at this register which would probably be quicker than doing a build-boot-test cycle with the kernel - this is how I do a lot of this kind of discovery when documentation is lacking. > But the timer-change can also break sgmii... SGMII mode should be writing the same value to the link timer, but looking at it now, I see I ended up with one too many zeros on the 16000000! It should be 1.6ms in nanoseconds, so 1600000. Please correct for future testing. Many thanks for your patience. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk> To: Frank Wunderlich <frank-w@public-files.de> Cc: Frank Wunderlich <linux@fw-web.de>, linux-mediatek@lists.infradead.org, Alexander Couzens <lynxis@fe80.eu>, Felix Fietkau <nbd@nbd.name>, John Crispin <john@phrozen.org>, Sean Wang <sean.wang@mediatek.com>, Mark Lee <Mark-MC.Lee@mediatek.com>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Matthias Brugger <matthias.bgg@gmail.com>, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: Re: Re: Re: Re: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops Date: Sat, 22 Oct 2022 20:18:27 +0100 [thread overview] Message-ID: <Y1RCA+l2OHkrFfhB@shell.armlinux.org.uk> (raw) In-Reply-To: <trinity-164dc5a6-98ce-464c-a43d-b00b91ca69e5-1666461195968@3c-app-gmx-bs49> Hi, On Sat, Oct 22, 2022 at 07:53:16PM +0200, Frank Wunderlich wrote: > > Gesendet: Samstag, 22. Oktober 2022 um 19:05 Uhr > > Von: "Russell King (Oracle)" <linux@armlinux.org.uk> > > 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)" <linux@armlinux.org.uk> > > > > this patch breaks connectivity at least on the sfp-port (eth1). > > > > 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? > > yes link is up on my switch, cannot enable autoneg for fibre-port, so port is fixed to 1000M/full flowcontrol enabled. > > > 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? > > 0xe0 is bits 5-7 are set (in lower byte from upper word)..which one is for duplex? > > so i should set state->duplex/pause based on this value (maybe compare with own caps)? > > found a documentation where 5=full,6=half, and bits 7+8 are for pause (symetric/asymetric) > > regmap_read(mpcs->regmap, SGMSYS_PCS_CONTROL_1+8, &val); > partner_advertising = (val & 0x00ff0000) >> 16; Not quite :) When we have the link partner's advertisement and the BMSR, we have a helper function in phylink to do all the gritty work: regmap_read(mpcs->regmap, SGMSYS_PCS_CONTROL_1, &bm); regmap_read(mpcs->regmap, SGMSYS_PCS_CONTROL_1 + 8, &adv); phylink_mii_c22_pcs_decode_state(state, bm >> 16, adv >> 16); will do all the work for you without having to care about whether you're operating at 2500base-X, 1000base-X or SGMII mode. > > 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? > > these is not clear to me...should i blindly set these and how to > verify what they do? Yes please - I don't think anyone knows what they do. > is network broken because of wrong duplex/pause setting? do not > fully understand your Patch. I suspect not having the duplex correct _could_ break stuff, but I also wonder whether the PCS is trying to decode the advertisements itself and coming out with the wrong settings. If it's interpreting a link partner advertisement of 0x00e0 using SGMII rules, then it will be looking at bits 11 and 10 for the speed, both of which are zero, which means 10Mbps - and 1000base-X doesn't operate at 10Mbps! So my hunch is that one of those two IF_MODE_BIT{0,5} _might_ change the way the PCS interprets the control word, but as we don't have any documentation to go on, only experimentation will answer this question. If these registers are MMIO, you could ensure that you have /dev/mem access enabled, and use devmem2 to poke at this register which would probably be quicker than doing a build-boot-test cycle with the kernel - this is how I do a lot of this kind of discovery when documentation is lacking. > But the timer-change can also break sgmii... SGMII mode should be writing the same value to the link timer, but looking at it now, I see I ended up with one too many zeros on the 16000000! It should be 1.6ms in nanoseconds, so 1600000. Please correct for future testing. Many thanks for your patience. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-10-22 19:18 UTC|newest] Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-10-20 14:44 [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops Frank Wunderlich 2022-10-20 14:44 ` Frank Wunderlich 2022-10-20 14:44 ` Frank Wunderlich 2022-10-20 16:17 ` Russell King (Oracle) 2022-10-20 16:17 ` Russell King (Oracle) 2022-10-20 16:17 ` Russell King (Oracle) 2022-10-21 6:04 ` Frank Wunderlich 2022-10-21 6:04 ` Frank Wunderlich 2022-10-21 7:24 ` Russell King (Oracle) 2022-10-21 7:24 ` Russell King (Oracle) [not found] ` <9E91B812-8687-463D-8B98-3C4BF26CBE08@fw-web.de> 2022-10-21 9:00 ` Russell King (Oracle) 2022-10-21 9:00 ` Russell King (Oracle) 2022-10-21 9:00 ` Russell King (Oracle) 2022-10-21 9:06 ` Russell King (Oracle) 2022-10-21 9:06 ` Russell King (Oracle) 2022-10-21 17:47 ` Aw: " Frank Wunderlich 2022-10-21 17:47 ` Frank Wunderlich 2022-10-21 18:31 ` Russell King (Oracle) 2022-10-21 18:31 ` Russell King (Oracle) 2022-10-21 19:52 ` Aw: " Frank Wunderlich 2022-10-21 19:52 ` Frank Wunderlich 2022-10-21 21:28 ` Russell King (Oracle) 2022-10-21 21:28 ` Russell King (Oracle) 2022-10-22 6:25 ` Frank Wunderlich 2022-10-22 6:25 ` Frank Wunderlich 2022-10-22 9:11 ` Russell King (Oracle) 2022-10-22 9:11 ` Russell King (Oracle) 2022-10-22 9:11 ` Russell King (Oracle) 2022-10-22 10:52 ` Aw: " Frank Wunderlich 2022-10-22 10:52 ` Frank Wunderlich 2022-10-22 17:05 ` Russell King (Oracle) 2022-10-22 17:05 ` Russell King (Oracle) 2022-10-22 17:53 ` Aw: " Frank Wunderlich 2022-10-22 17:53 ` Frank Wunderlich 2022-10-22 19:18 ` Russell King (Oracle) [this message] 2022-10-22 19:18 ` Russell King (Oracle) 2022-10-23 7:26 ` Aw: " Frank Wunderlich 2022-10-23 7:26 ` Frank Wunderlich 2022-10-23 9:43 ` Russell King (Oracle) 2022-10-23 9:43 ` Russell King (Oracle) 2022-10-23 15:05 ` Aw: " Frank Wunderlich 2022-10-23 15:05 ` Frank Wunderlich 2022-10-23 15:46 ` Russell King (Oracle) 2022-10-23 15:46 ` Russell King (Oracle) 2022-10-23 16:41 ` Aw: " Frank Wunderlich 2022-10-23 16:41 ` Frank Wunderlich 2022-10-23 17:52 ` Russell King (Oracle) 2022-10-23 17:52 ` Russell King (Oracle) 2022-10-23 19:03 ` Aw: " Frank Wunderlich 2022-10-23 19:03 ` Frank Wunderlich 2022-10-23 19:21 ` Frank Wunderlich 2022-10-23 19:21 ` Frank Wunderlich 2022-10-23 20:09 ` Russell King (Oracle) 2022-10-23 20:09 ` Russell King (Oracle) 2022-10-24 9:27 ` Russell King (Oracle) 2022-10-24 9:27 ` Russell King (Oracle) 2022-10-24 14:45 ` Aw: " Frank Wunderlich 2022-10-24 14:45 ` Frank Wunderlich 2022-10-24 14:56 ` Russell King (Oracle) 2022-10-24 14:56 ` Russell King (Oracle) 2022-10-25 8:03 ` Frank Wunderlich 2022-10-25 8:03 ` Frank Wunderlich 2023-01-16 13:08 ` Bjørn Mork 2023-01-16 13:08 ` Bjørn Mork 2023-01-16 13:47 ` Russell King (Oracle) 2023-01-16 13:47 ` Russell King (Oracle) 2023-01-16 13:47 ` Russell King (Oracle) 2023-01-16 14:45 ` Bjørn Mork 2023-01-16 14:45 ` Bjørn Mork 2023-01-16 14:45 ` Bjørn Mork 2023-01-16 14:59 ` Russell King (Oracle) 2023-01-16 14:59 ` Russell King (Oracle) 2023-01-16 14:59 ` Russell King (Oracle) 2023-01-16 15:21 ` Bjørn Mork 2023-01-16 15:21 ` Bjørn Mork 2023-01-16 15:21 ` Bjørn Mork 2023-01-16 15:32 ` Russell King (Oracle) 2023-01-16 15:32 ` Russell King (Oracle) 2023-01-16 15:32 ` Russell King (Oracle) 2023-01-16 16:33 ` Bjørn Mork 2023-01-16 16:33 ` Bjørn Mork 2023-01-16 16:33 ` Bjørn Mork 2023-01-16 16:43 ` Russell King (Oracle) 2023-01-16 16:43 ` Russell King (Oracle) 2023-01-16 16:43 ` Russell King (Oracle) 2023-01-16 16:48 ` Bjørn Mork 2023-01-16 16:48 ` Bjørn Mork 2023-01-16 16:48 ` Bjørn Mork 2023-01-16 16:45 ` Bjørn Mork 2023-01-16 16:45 ` Bjørn Mork 2023-01-16 16:45 ` Bjørn Mork 2023-01-16 17:47 ` Russell King (Oracle) 2023-01-16 17:47 ` Russell King (Oracle) 2023-01-16 17:47 ` Russell King (Oracle) 2023-01-16 17:59 ` Bjørn Mork 2023-01-16 17:59 ` Bjørn Mork 2023-01-16 17:59 ` Bjørn Mork 2023-01-16 18:04 ` Bjørn Mork 2023-01-16 18:04 ` Bjørn Mork 2023-01-16 18:04 ` Bjørn Mork 2023-01-16 18:14 ` Russell King (Oracle) 2023-01-16 18:14 ` Russell King (Oracle) 2023-01-16 18:14 ` Russell King (Oracle) 2023-01-16 18:30 ` Bjørn Mork 2023-01-16 18:30 ` Bjørn Mork 2023-01-16 18:30 ` Bjørn Mork 2023-01-16 18:50 ` Bjørn Mork 2023-01-16 18:50 ` Bjørn Mork 2023-01-16 18:50 ` Bjørn Mork 2023-01-16 19:15 ` Russell King (Oracle) 2023-01-16 19:15 ` Russell King (Oracle) 2023-01-16 19:15 ` Russell King (Oracle) 2023-01-16 18:54 ` Russell King (Oracle) 2023-01-16 18:54 ` Russell King (Oracle) 2023-01-16 18:54 ` Russell King (Oracle) 2023-01-16 18:59 ` Bjørn Mork 2023-01-16 18:59 ` Bjørn Mork 2023-01-16 18:59 ` Bjørn Mork 2023-01-16 18:06 ` Russell King (Oracle) 2023-01-16 18:06 ` Russell King (Oracle) 2023-01-16 18:06 ` Russell King (Oracle) 2022-10-20 19:10 ` Jakub Kicinski 2022-10-20 19:10 ` Jakub Kicinski 2022-10-20 19:10 ` Jakub Kicinski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Y1RCA+l2OHkrFfhB@shell.armlinux.org.uk \ --to=linux@armlinux.org.uk \ --cc=Mark-MC.Lee@mediatek.com \ --cc=davem@davemloft.net \ --cc=edumazet@google.com \ --cc=frank-w@public-files.de \ --cc=john@phrozen.org \ --cc=kuba@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=linux@fw-web.de \ --cc=lynxis@fe80.eu \ --cc=matthias.bgg@gmail.com \ --cc=nbd@nbd.name \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=sean.wang@mediatek.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.