From: "Bjørn Mork" <bjorn@mork.no>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: netdev@vger.kernel.org, Sean Wang <sean.wang@mediatek.com>,
linux-kernel@vger.kernel.org,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Alexander Couzens <lynxis@fe80.eu>,
John Crispin <john@phrozen.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
linux-mediatek@lists.infradead.org,
Frank Wunderlich <linux@fw-web.de>,
Paolo Abeni <pabeni@redhat.com>,
Mark Lee <Mark-MC.Lee@mediatek.com>,
linux-arm-kernel@lists.infradead.org,
Felix Fietkau <nbd@nbd.name>
Subject: Re: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops
Date: Mon, 16 Jan 2023 17:33:53 +0100 [thread overview]
Message-ID: <875yd630cu.fsf@miraculix.mork.no> (raw)
In-Reply-To: <Y8Vt9vfEa4w8HXHQ@shell.armlinux.org.uk> (Russell King's message of "Mon, 16 Jan 2023 15:32:06 +0000")
"Russell King (Oracle)" <linux@armlinux.org.uk> 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
WARNING: multiple messages have this Message-ID (diff)
From: "Bjørn Mork" <bjorn@mork.no>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Frank Wunderlich <frank-w@public-files.de>,
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: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops
Date: Mon, 16 Jan 2023 17:33:53 +0100 [thread overview]
Message-ID: <875yd630cu.fsf@miraculix.mork.no> (raw)
In-Reply-To: <Y8Vt9vfEa4w8HXHQ@shell.armlinux.org.uk> (Russell King's message of "Mon, 16 Jan 2023 15:32:06 +0000")
"Russell King (Oracle)" <linux@armlinux.org.uk> 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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: "Bjørn Mork" <bjorn@mork.no>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Frank Wunderlich <frank-w@public-files.de>,
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: [PATCH v2] net: mtk_sgmii: implement mtk_pcs_ops
Date: Mon, 16 Jan 2023 17:33:53 +0100 [thread overview]
Message-ID: <875yd630cu.fsf@miraculix.mork.no> (raw)
In-Reply-To: <Y8Vt9vfEa4w8HXHQ@shell.armlinux.org.uk> (Russell King's message of "Mon, 16 Jan 2023 15:32:06 +0000")
"Russell King (Oracle)" <linux@armlinux.org.uk> 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
next prev parent reply other threads:[~2023-01-16 16:37 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)
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 [this message]
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=875yd630cu.fsf@miraculix.mork.no \
--to=bjorn@mork.no \
--cc=Mark-MC.Lee@mediatek.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--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@armlinux.org.uk \
--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 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.