RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Ondřej Jirman Date: Jul/22/2019, 15:39:55 (UTC+00:00) > On Mon, Jul 22, 2019 at 02:26:45PM +, Jose Abreu wrote: > > From: Andrew Lunn > > Date: Jul/22/2019, 15:19:43 (UTC+00:00) > > > > > On Mon, Jul 22, 2019 at 01:58:20PM +, Jose Abreu wrote: > > > > From: Andrew Lunn > > > > Date: Jul/22/2019, 14:40:23 (UTC+00:00) > > > > > > > > > Does this mean that all stmmac variants support 1G? There are none > > > > > which just support Fast Ethernet? > > > > > > > > This glue logic drivers sometimes reflect a custom IP that's Synopsys > > > > based but modified by customer, so I can't know before-hand what's the > > > > supported max speed. There are some old versions that don't support 1G > > > > but I expect that PHY driver limits this ... > > > > > > If a Fast PHY is used, then yes, it would be limited. But sometimes a > > > 1G PHY is used because they are cheaper than a Fast PHY. > > > > > > > > I'm also not sure the change fits the problem. Why did it not > > > > > negotiate 100FULL rather than 10Half? You are only moving the 1G > > > > > speeds around, so 100 speeds should of been advertised and selected. > > > > > > > > Hmm, now that I'm looking at it closer I agree with you. Maybe link > > > > partner or PHY doesn't support 100M ? > > > > > > In the working case, ethtool shows the link partner supports 10, 100, > > > and 1G. So something odd is going on here. > > > > > > You fix does seems reasonable, and it has been reported to fix the > > > issue, but it would be good to understand what is going on here. > > > > Agreed! > > > > Ondrej, can you please share dmesg log and ethtool output with the fixed > > patch ? > > See the attachment, or this link: So, I've removed all 1G link modes from stmmac and run it on an ARM based board. My link status resolves to 100M/Full using Generic PHY so maybe something is wrong with the PHY driver that Ondrej is using ("RTL8211E Gigabit Ethernet") ? --- Thanks, Jose Miguel Abreu
Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
On Mon, Jul 22, 2019 at 02:26:45PM +, Jose Abreu wrote: > From: Andrew Lunn > Date: Jul/22/2019, 15:19:43 (UTC+00:00) > > > On Mon, Jul 22, 2019 at 01:58:20PM +, Jose Abreu wrote: > > > From: Andrew Lunn > > > Date: Jul/22/2019, 14:40:23 (UTC+00:00) > > > > > > > Does this mean that all stmmac variants support 1G? There are none > > > > which just support Fast Ethernet? > > > > > > This glue logic drivers sometimes reflect a custom IP that's Synopsys > > > based but modified by customer, so I can't know before-hand what's the > > > supported max speed. There are some old versions that don't support 1G > > > but I expect that PHY driver limits this ... > > > > If a Fast PHY is used, then yes, it would be limited. But sometimes a > > 1G PHY is used because they are cheaper than a Fast PHY. > > > > > > I'm also not sure the change fits the problem. Why did it not > > > > negotiate 100FULL rather than 10Half? You are only moving the 1G > > > > speeds around, so 100 speeds should of been advertised and selected. > > > > > > Hmm, now that I'm looking at it closer I agree with you. Maybe link > > > partner or PHY doesn't support 100M ? > > > > In the working case, ethtool shows the link partner supports 10, 100, > > and 1G. So something odd is going on here. > > > > You fix does seems reasonable, and it has been reported to fix the > > issue, but it would be good to understand what is going on here. > > Agreed! > > Ondrej, can you please share dmesg log and ethtool output with the fixed > patch ? See the attachment, or this link: https://megous.com/dl/tmp/dmesg-5.3-working regards, Ondrej > --- > Thanks, > Jose Miguel Abreu [0.00] Machine model: OrangePi 3 [0.00] cma: Reserved 64 MiB at 0xbc00 [0.00] On node 0 totalpages: 524288 [0.00] DMA32 zone: 8192 pages used for memmap [0.00] DMA32 zone: 0 pages reserved [0.00] DMA32 zone: 524288 pages, LIFO batch:63 [0.00] psci: probing for conduit method from DT. [0.00] psci: PSCIv1.1 detected in firmware. [0.00] psci: Using standard PSCI v0.2 function IDs [0.00] psci: MIGRATE_INFO_TYPE not supported. [0.00] psci: SMC Calling Convention v1.1 [0.00] percpu: Embedded 22 pages/cpu s53208 r8192 d28712 u90112 [0.00] pcpu-alloc: s53208 r8192 d28712 u90112 alloc=22*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Detected VIPT I-cache on CPU0 [0.00] Speculative Store Bypass Disable mitigation not required [0.00] Built 1 zonelists, mobility grouping on. Total pages: 516096 [0.00] Kernel command line: console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p3 rootfstype=f2fs rw elevator=noop rootwait panic=3 quiet [0.00] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) [0.00] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 1962168K/2097152K available (13822K kernel code, 804K rwdata, 4028K rodata, 2048K init, 619K bss, 69448K reserved, 65536K cma-reserved) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [0.00] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 [0.00] GIC: Using split EOI/Deactivate mode [0.00] arch_timer: cp15 timer(s) running at 24.00MHz (phys). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns [0.04] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns [0.000205] Console: colour dummy device 80x25 [0.000214] printk: console [tty1] enabled [0.000244] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000) [0.000251] pid_max: default: 32768 minimum: 301 [0.000376] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) [0.000389] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) [0.000844] *** VALIDATE proc *** [0.001011] *** VALIDATE cgroup1 *** [0.001017] *** VALIDATE cgroup2 *** [0.001597] ASID allocator initialised with 32768 entries [0.001667] rcu: Hierarchical SRCU implementation. [0.002044] smp: Bringing up secondary CPUs ... [0.002673] Detected VIPT I-cache on CPU1 [0.002721] CPU1: Booted secondary processor 0x01 [0x410fd034] [0.003242] Detected VIPT I-cache on CPU2 [0.003270] CPU2: Booted secondary processor 0x02 [0x410fd034] [0.003764] Detected VIPT I-cache on CPU3 [0.003789] CPU3:
RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Andrew Lunn Date: Jul/22/2019, 15:19:43 (UTC+00:00) > On Mon, Jul 22, 2019 at 01:58:20PM +, Jose Abreu wrote: > > From: Andrew Lunn > > Date: Jul/22/2019, 14:40:23 (UTC+00:00) > > > > > Does this mean that all stmmac variants support 1G? There are none > > > which just support Fast Ethernet? > > > > This glue logic drivers sometimes reflect a custom IP that's Synopsys > > based but modified by customer, so I can't know before-hand what's the > > supported max speed. There are some old versions that don't support 1G > > but I expect that PHY driver limits this ... > > If a Fast PHY is used, then yes, it would be limited. But sometimes a > 1G PHY is used because they are cheaper than a Fast PHY. > > > > I'm also not sure the change fits the problem. Why did it not > > > negotiate 100FULL rather than 10Half? You are only moving the 1G > > > speeds around, so 100 speeds should of been advertised and selected. > > > > Hmm, now that I'm looking at it closer I agree with you. Maybe link > > partner or PHY doesn't support 100M ? > > In the working case, ethtool shows the link partner supports 10, 100, > and 1G. So something odd is going on here. > > You fix does seems reasonable, and it has been reported to fix the > issue, but it would be good to understand what is going on here. Agreed! Ondrej, can you please share dmesg log and ethtool output with the fixed patch ? --- Thanks, Jose Miguel Abreu
Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
On Mon, Jul 22, 2019 at 01:58:20PM +, Jose Abreu wrote: > From: Andrew Lunn > Date: Jul/22/2019, 14:40:23 (UTC+00:00) > > > Does this mean that all stmmac variants support 1G? There are none > > which just support Fast Ethernet? > > This glue logic drivers sometimes reflect a custom IP that's Synopsys > based but modified by customer, so I can't know before-hand what's the > supported max speed. There are some old versions that don't support 1G > but I expect that PHY driver limits this ... If a Fast PHY is used, then yes, it would be limited. But sometimes a 1G PHY is used because they are cheaper than a Fast PHY. > > I'm also not sure the change fits the problem. Why did it not > > negotiate 100FULL rather than 10Half? You are only moving the 1G > > speeds around, so 100 speeds should of been advertised and selected. > > Hmm, now that I'm looking at it closer I agree with you. Maybe link > partner or PHY doesn't support 100M ? In the working case, ethtool shows the link partner supports 10, 100, and 1G. So something odd is going on here. You fix does seems reasonable, and it has been reported to fix the issue, but it would be good to understand what is going on here. Andrew
RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Andrew Lunn Date: Jul/22/2019, 14:40:23 (UTC+00:00) > Does this mean that all stmmac variants support 1G? There are none > which just support Fast Ethernet? This glue logic drivers sometimes reflect a custom IP that's Synopsys based but modified by customer, so I can't know before-hand what's the supported max speed. There are some old versions that don't support 1G but I expect that PHY driver limits this ... > I'm also not sure the change fits the problem. Why did it not > negotiate 100FULL rather than 10Half? You are only moving the 1G > speeds around, so 100 speeds should of been advertised and selected. Hmm, now that I'm looking at it closer I agree with you. Maybe link partner or PHY doesn't support 100M ? It's working for Ondrej but I got curious now ... --- Thanks, Jose Miguel Abreu
Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
On Mon, Jul 22, 2019 at 01:28:51PM +, Jose Abreu wrote: > From: Ondřej Jirman > Date: Jul/22/2019, 13:42:40 (UTC+00:00) > > > Hello Jose, > > > > On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote: > > > [ Hope this diff looks better (generated with --minimal) ] > > > > > > This converts stmmac to use phylink. Besides the code redution this will > > > allow to gain more flexibility. > > > > I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared > > to > > 5.2 it fails to detect 1000Mbps link and the driver negotiates just a > > 10Mbps speed. > > > > After going through stmmac patches since 5.2, I think it may be realted to > > this > > series, but I'm not completely sure. You'll probably have a better > > understanding > > of the changes. Do you have an idea what might be wrong? Please, see some > > logs > > below. > > Probably due to: > 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports") > > Can you try attached patch ? Tried, and it works! dwmac-sun8i 502.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] dwmac-sun8i 502.ethernet eth0: phy: setting supported 00,,62ff advertising 00,,62ff dwmac-sun8i 502.ethernet eth0: No Safety Features support found dwmac-sun8i 502.ethernet eth0: No MAC Management Counters available dwmac-sun8i 502.ethernet eth0: PTP not supported by HW dwmac-sun8i 502.ethernet eth0: configuring for phy/rgmii link mode dwmac-sun8i 502.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,,62ff pause=10 link=0 an=1 dwmac-sun8i 502.ethernet eth0: phy link down rgmii/Unknown/Unknown dwmac-sun8i 502.ethernet eth0: phy link up rgmii/1Gbps/Full dwmac-sun8i 502.ethernet eth0: phylink_mac_config: mode=phy/rgmii/1Gbps/Full adv=00,, pause=0f link=1 an=0 dwmac-sun8i 502.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Tested-by: Ondrej Jirman thank you, Ondrej > > > > > thank you and regards, > > Ondrej > > > > On 5.3-rc1 I see: > > > > [6.116512] dwmac-sun8i 502.ethernet eth0: PHY [stmmac-0:01] driver > > [RTL8211E Gigabit Ethernet] > > [6.116522] dwmac-sun8i 502.ethernet eth0: phy: setting supported > > 00,,62cf advertising 00,,62cf > > [6.118714] dwmac-sun8i 502.ethernet eth0: No Safety Features > > support found > > [6.118725] dwmac-sun8i 502.ethernet eth0: No MAC Management > > Counters available > > [6.118730] dwmac-sun8i 502.ethernet eth0: PTP not supported by HW > > [6.118738] dwmac-sun8i 502.ethernet eth0: configuring for phy/rgmii > > link mode > > [6.118747] dwmac-sun8i 502.ethernet eth0: phylink_mac_config: > > mode=phy/rgmii/Unknown/Unknown adv=00,,62cf pause=10 link=0 an=1 > > [6.126099] dwmac-sun8i 502.ethernet eth0: phy link down > > rgmii/Unknown/Unknown > > [6.276325] random: crng init done > > [6.276338] random: 7 urandom warning(s) missed due to ratelimiting > > [7.543987] zram0: detected capacity change from 0 to 402653184 > > [7.667702] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 > > across:393212k SS > > > > ... delay due to other causes ... > > > > [ 28.640234] dwmac-sun8i 502.ethernet eth0: phy link up > > rgmii/10Mbps/Full > > [ 28.640295] dwmac-sun8i 502.ethernet eth0: phylink_mac_config: > > mode=phy/rgmii/10Mbps/Full adv=00,, pause=0f link=1 an=0 > > [ 28.640324] dwmac-sun8i 502.ethernet eth0: Link is Up - 10Mbps/Full > > - flow control rx/tx > > > > Settings for eth0: > > Supported ports: [ TP MII ] > > Supported link modes: 10baseT/Half 10baseT/Full > > 100baseT/Half 100baseT/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 > > Advertised pause frame use: Symmetric Receive-only > > Advertised auto-negotiation: Yes > > Advertised FEC modes: Not reported > > Link partner advertised link modes: 10baseT/Half 10baseT/Full > > Link partner advertised pause frame use: Symmetric Receive-only > > Link partner advertised auto-negotiation: Yes > > Link partner advertised FEC modes: Not reported > > Speed: 10Mb/s > > Duplex: Full > > Port: MII > > PHYAD: 1 > > Transceiver: internal > > Auto-negotiation: on > > Supports Wake-on: d > > Wake-on: d > > Current message level: 0x003f (63) > >drv probe link timer ifdown ifup > > Link detected: yes > > > > On 5.2 it looks like this: > > > > [1.153596] dwmac-sun8i 502.ethernet: PTP uses main clock > > [1.416221]
Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
On Mon, Jul 22, 2019 at 01:28:51PM +, Jose Abreu wrote: > From: Ondřej Jirman > Date: Jul/22/2019, 13:42:40 (UTC+00:00) > > > Hello Jose, > > > > On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote: > > > [ Hope this diff looks better (generated with --minimal) ] > > > > > > This converts stmmac to use phylink. Besides the code redution this will > > > allow to gain more flexibility. > > > > I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared > > to > > 5.2 it fails to detect 1000Mbps link and the driver negotiates just a > > 10Mbps speed. > > > > After going through stmmac patches since 5.2, I think it may be realted to > > this > > series, but I'm not completely sure. You'll probably have a better > > understanding > > of the changes. Do you have an idea what might be wrong? Please, see some > > logs > > below. > > Probably due to: > 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports") > > Can you try attached patch ? > Hi Jose Does this mean that all stmmac variants support 1G? There are none which just support Fast Ethernet? I'm also not sure the change fits the problem. Why did it not negotiate 100FULL rather than 10Half? You are only moving the 1G speeds around, so 100 speeds should of been advertised and selected. Thanks Andrew
RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Ondřej Jirman Date: Jul/22/2019, 13:42:40 (UTC+00:00) > Hello Jose, > > On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote: > > [ Hope this diff looks better (generated with --minimal) ] > > > > This converts stmmac to use phylink. Besides the code redution this will > > allow to gain more flexibility. > > I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to > 5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps > speed. > > After going through stmmac patches since 5.2, I think it may be realted to > this > series, but I'm not completely sure. You'll probably have a better > understanding > of the changes. Do you have an idea what might be wrong? Please, see some logs > below. Probably due to: 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports") Can you try attached patch ? > > thank you and regards, > Ondrej > > On 5.3-rc1 I see: > > [6.116512] dwmac-sun8i 502.ethernet eth0: PHY [stmmac-0:01] driver > [RTL8211E Gigabit Ethernet] > [6.116522] dwmac-sun8i 502.ethernet eth0: phy: setting supported > 00,,62cf advertising 00,,62cf > [6.118714] dwmac-sun8i 502.ethernet eth0: No Safety Features support > found > [6.118725] dwmac-sun8i 502.ethernet eth0: No MAC Management Counters > available > [6.118730] dwmac-sun8i 502.ethernet eth0: PTP not supported by HW > [6.118738] dwmac-sun8i 502.ethernet eth0: configuring for phy/rgmii > link mode > [6.118747] dwmac-sun8i 502.ethernet eth0: phylink_mac_config: > mode=phy/rgmii/Unknown/Unknown adv=00,,62cf pause=10 link=0 an=1 > [6.126099] dwmac-sun8i 502.ethernet eth0: phy link down > rgmii/Unknown/Unknown > [6.276325] random: crng init done > [6.276338] random: 7 urandom warning(s) missed due to ratelimiting > [7.543987] zram0: detected capacity change from 0 to 402653184 > [7.667702] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 > across:393212k SS > > ... delay due to other causes ... > > [ 28.640234] dwmac-sun8i 502.ethernet eth0: phy link up > rgmii/10Mbps/Full > [ 28.640295] dwmac-sun8i 502.ethernet eth0: phylink_mac_config: > mode=phy/rgmii/10Mbps/Full adv=00,, pause=0f link=1 an=0 > [ 28.640324] dwmac-sun8i 502.ethernet eth0: Link is Up - 10Mbps/Full - > flow control rx/tx > > Settings for eth0: > Supported ports: [ TP MII ] > Supported link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/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 > Advertised pause frame use: Symmetric Receive-only > Advertised auto-negotiation: Yes > Advertised FEC modes: Not reported > Link partner advertised link modes: 10baseT/Half 10baseT/Full > Link partner advertised pause frame use: Symmetric Receive-only > Link partner advertised auto-negotiation: Yes > Link partner advertised FEC modes: Not reported > Speed: 10Mb/s > Duplex: Full > Port: MII > PHYAD: 1 > Transceiver: internal > Auto-negotiation: on > Supports Wake-on: d > Wake-on: d > Current message level: 0x003f (63) > drv probe link timer ifdown ifup > Link detected: yes > > On 5.2 it looks like this: > > [1.153596] dwmac-sun8i 502.ethernet: PTP uses main clock > [1.416221] dwmac-sun8i 502.ethernet: PTP uses main clock > [1.522735] dwmac-sun8i 502.ethernet: Current syscon value is not the > default 58000 (expect 5) > [1.522750] dwmac-sun8i 502.ethernet: No HW DMA feature register > supported > [1.522753] dwmac-sun8i 502.ethernet: RX Checksum Offload Engine > supported > [1.522755] dwmac-sun8i 502.ethernet: COE Type 2 > [1.522758] dwmac-sun8i 502.ethernet: TX Checksum insertion supported > [1.522761] dwmac-sun8i 502.ethernet: Normal descriptors > [1.522763] dwmac-sun8i 502.ethernet: Chain mode enabled > [5.352833] dwmac-sun8i 502.ethernet eth0: No Safety Features support > found > [5.352842] dwmac-sun8i 502.ethernet eth0: No MAC Management Counters > available > [5.352846] dwmac-sun8i 502.ethernet eth0: PTP not supported by HW > [ 10.463072] dwmac-sun8i 502.ethernet eth0: Link is Up - 1Gbps/Full - > flow control off > > Settings for eth0: > Supported ports: [ TP MII ] > Supported link modes: 10baseT/Half 10baseT/Full > 100baseT/Half 100baseT/Full > 1000baseT/Half 1000baseT/Full > Supported pause frame use: Symmetric Receive-only > Supports
Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
Hello Jose, On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote: > [ Hope this diff looks better (generated with --minimal) ] > > This converts stmmac to use phylink. Besides the code redution this will > allow to gain more flexibility. I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to 5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed. After going through stmmac patches since 5.2, I think it may be realted to this series, but I'm not completely sure. You'll probably have a better understanding of the changes. Do you have an idea what might be wrong? Please, see some logs below. thank you and regards, Ondrej On 5.3-rc1 I see: [6.116512] dwmac-sun8i 502.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] [6.116522] dwmac-sun8i 502.ethernet eth0: phy: setting supported 00,,62cf advertising 00,,62cf [6.118714] dwmac-sun8i 502.ethernet eth0: No Safety Features support found [6.118725] dwmac-sun8i 502.ethernet eth0: No MAC Management Counters available [6.118730] dwmac-sun8i 502.ethernet eth0: PTP not supported by HW [6.118738] dwmac-sun8i 502.ethernet eth0: configuring for phy/rgmii link mode [6.118747] dwmac-sun8i 502.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,,62cf pause=10 link=0 an=1 [6.126099] dwmac-sun8i 502.ethernet eth0: phy link down rgmii/Unknown/Unknown [6.276325] random: crng init done [6.276338] random: 7 urandom warning(s) missed due to ratelimiting [7.543987] zram0: detected capacity change from 0 to 402653184 [7.667702] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 across:393212k SS ... delay due to other causes ... [ 28.640234] dwmac-sun8i 502.ethernet eth0: phy link up rgmii/10Mbps/Full [ 28.640295] dwmac-sun8i 502.ethernet eth0: phylink_mac_config: mode=phy/rgmii/10Mbps/Full adv=00,, pause=0f link=1 an=0 [ 28.640324] dwmac-sun8i 502.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/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 Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full Link partner advertised pause frame use: Symmetric Receive-only Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 10Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: d Wake-on: d Current message level: 0x003f (63) drv probe link timer ifdown ifup Link detected: yes On 5.2 it looks like this: [1.153596] dwmac-sun8i 502.ethernet: PTP uses main clock [1.416221] dwmac-sun8i 502.ethernet: PTP uses main clock [1.522735] dwmac-sun8i 502.ethernet: Current syscon value is not the default 58000 (expect 5) [1.522750] dwmac-sun8i 502.ethernet: No HW DMA feature register supported [1.522753] dwmac-sun8i 502.ethernet: RX Checksum Offload Engine supported [1.522755] dwmac-sun8i 502.ethernet: COE Type 2 [1.522758] dwmac-sun8i 502.ethernet: TX Checksum insertion supported [1.522761] dwmac-sun8i 502.ethernet: Normal descriptors [1.522763] dwmac-sun8i 502.ethernet: Chain mode enabled [5.352833] dwmac-sun8i 502.ethernet eth0: No Safety Features support found [5.352842] dwmac-sun8i 502.ethernet eth0: No MAC Management Counters available [5.352846] dwmac-sun8i 502.ethernet eth0: PTP not supported by HW [ 10.463072] dwmac-sun8i 502.ethernet eth0: Link is Up - 1Gbps/Full - flow control off Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/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/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not
RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Corentin Labbe > since this patch I hit > dwmac-sun8i 1c3.ethernet: ethernet@1c3 PHY address 29556736 is too > large > > any idea ? This is because phy_node is no longer pointing to the same place so sun8i_dwmac_set_syscon() fails. I'm seeing this pattern of using phy_node in other wrappers so I will try to submit a fix for them all. Thanks for reporting.
Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote: > [ Hope this diff looks better (generated with --minimal) ] > > This converts stmmac to use phylink. Besides the code redution this will > allow to gain more flexibility. > > Cc: Joao Pinto > Cc: David S. Miller > Cc: Giuseppe Cavallaro > Cc: Alexandre Torgue > Cc: Russell King > Cc: Andrew Lunn > Cc: Florian Fainelli > Cc: Heiner Kallweit > > Jose Abreu (3): > net: stmmac: Prepare to convert to phylink > net: stmmac: Start adding phylink support > net: stmmac: Convert to phylink and remove phylib logic > > drivers/net/ethernet/stmicro/stmmac/Kconfig | 3 +- > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +- > .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +--- > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 391 -- > .../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +- > 5 files changed, 190 insertions(+), 313 deletions(-) > > -- > 2.21.0 > Hello since this patch I hit dwmac-sun8i 1c3.ethernet: ethernet@1c3 PHY address 29556736 is too large any idea ?
Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Jose Abreu Date: Tue, 11 Jun 2019 17:18:44 +0200 > [ Hope this diff looks better (generated with --minimal) ] > > This converts stmmac to use phylink. Besides the code redution this will > allow to gain more flexibility. Series applied, thank you.