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: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops
Date: Fri, 21 Oct 2022 19:31:56 +0100 [thread overview]
Message-ID: <Y1LlnMdm8pGVXC6d@shell.armlinux.org.uk> (raw)
In-Reply-To: <trinity-e60759de-3f0f-4b1e-bc0f-b33c4f8ac201-1666374467573@3c-app-gmx-bap55>
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)" <linux@armlinux.org.uk>
> > An: "Frank Wunderlich" <frank-w@public-files.de>
> > 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!
next prev parent reply other threads:[~2022-10-21 18:32 UTC|newest]
Thread overview: 50+ 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 16:17 ` Russell King (Oracle)
2022-10-21 6:04 ` Frank Wunderlich
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:06 ` Russell King (Oracle)
2022-10-21 17:47 ` Aw: " Frank Wunderlich
2022-10-21 18:31 ` Russell King (Oracle) [this message]
2022-10-21 19:52 ` Aw: " Frank Wunderlich
2022-10-21 21:28 ` Russell King (Oracle)
2022-10-22 6:25 ` Frank Wunderlich
2022-10-22 9:11 ` Russell King (Oracle)
2022-10-22 10:52 ` Aw: " Frank Wunderlich
2022-10-22 17:05 ` Russell King (Oracle)
2022-10-22 17:53 ` Aw: " Frank Wunderlich
2022-10-22 19:18 ` Russell King (Oracle)
2022-10-23 7:26 ` Aw: " Frank Wunderlich
2022-10-23 9:43 ` Russell King (Oracle)
2022-10-23 15:05 ` Aw: " Frank Wunderlich
2022-10-23 15:46 ` Russell King (Oracle)
2022-10-23 16:41 ` Aw: " Frank Wunderlich
2022-10-23 17:52 ` Russell King (Oracle)
2022-10-23 19:03 ` Aw: " Frank Wunderlich
2022-10-23 19:21 ` Frank Wunderlich
2022-10-23 20:09 ` Russell King (Oracle)
2022-10-24 9:27 ` Russell King (Oracle)
2022-10-24 14:45 ` Aw: " Frank Wunderlich
2022-10-24 14:56 ` Russell King (Oracle)
2022-10-25 8:03 ` Frank Wunderlich
2023-01-16 13:08 ` Bjørn Mork
2023-01-16 13:47 ` Russell King (Oracle)
2023-01-16 14:45 ` Bjørn Mork
2023-01-16 14:59 ` Russell King (Oracle)
2023-01-16 15:21 ` Bjørn Mork
2023-01-16 15:32 ` Russell King (Oracle)
2023-01-16 16:33 ` Bjørn Mork
2023-01-16 16:43 ` Russell King (Oracle)
2023-01-16 16:48 ` Bjørn Mork
2023-01-16 16:45 ` Bjørn Mork
2023-01-16 17:47 ` Russell King (Oracle)
2023-01-16 17:59 ` Bjørn Mork
2023-01-16 18:04 ` Bjørn Mork
2023-01-16 18:14 ` Russell King (Oracle)
2023-01-16 18:30 ` Bjørn Mork
2023-01-16 18:50 ` Bjørn Mork
2023-01-16 19:15 ` Russell King (Oracle)
2023-01-16 18:54 ` Russell King (Oracle)
2023-01-16 18:59 ` Bjørn Mork
2023-01-16 18:06 ` Russell King (Oracle)
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=Y1LlnMdm8pGVXC6d@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).