riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor.Dooley]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

Hey,
I seem to have come across a regression in the default riscv defconfig
between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
machine") which causes the ethernet phy to not come up on my Icicle kit:
[ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
[ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)

I did try to bisect normally, but unfortunately it was not trivial for
me to do, because the following two commits from Linus' tree that
arrived after riscv-for-linus-5.18-mw0 are required actually bring up
the icicle kit & its ethernet:
37f7860602b5 net: macb: Align the dma and coherent dma masks
635e5e73370e clk: microchip: Add driver for Microchip PolarFire SoC

I went down a rabbit hole of checking the net side of things & found
that the failing check is in the call to phylink_validate in
phylink_bringup_phy. Some digging points to v5.18-rc1's
drivers/net/phy/phylink.c:L457 as the culprit, with the
phylink_is_empty_linkmode check failing.

At riscv-for-linus-5.18-mw0, cherry-picking those two commits brings it
up fine:
[ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
[ 2.828915] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
[11.045411] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[11.053247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

At riscv-for-linus-5.18-mw1 (1464d00b27b2) with those two commits
applied, I get the same validation failure as with v5.18-rc1.

I did some manual reversions of everything in
drivers/net/ethernet/cadence/ & drivers/net/phy/phylink.c that was
added since 5.17 to no avail.
Turns out the problem was exposed by riscv-for-linus-5.18-mw1 and
reverting c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver
for QEMU virt machine") avoided the problem for me.

Is this some sort of lack of support for CONFIG_PM=y in my clock driver,
that's leading to the PHY getting stuck in reset?
Or an interaction between CONFIG_PM=y & the macb/generic phy drivers?

I am kinda lost at this point & would appreciate any help investigating
further. I have attached the full log in case that helps.
Thanks,
Conor.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: failure.log --]
[-- Type: text/x-log; name="failure.log", Size: 10541 bytes --]

[    0.000000] Linux version 5.18.0-rc1 (conor@wendy) (riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP Tue Apr 5 13:17:47 IST 2022
[    0.000000] OF: fdt: Ignoring memory block 0x80000000 - 0xae000000
[    0.000000] OF: fdt: Ignoring memory range 0x1000000000 - 0x1000200000
[    0.000000] Machine model: Microchip PolarFire-SoC Icicle Kit
[    0.000000] efi: UEFI not found.
[    0.000000] Zone ranges:
[    0.000000]   DMA32    empty
[    0.000000]   Normal   [mem 0x0000001000200000-0x000000103fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000001000200000-0x000000103fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000001000200000-0x000000103fffffff]
[    0.000000] SBI specification v0.3 detected
[    0.000000] SBI implementation ID=0x1 Version=0x9
[    0.000000] SBI TIME extension detected
[    0.000000] SBI IPI extension detected
[    0.000000] SBI RFENCE extension detected
[    0.000000] SBI HSM extension detected
[    0.000000] CPU with hartid=0 is not available
[    0.000000] CPU with hartid=0 is not available
[    0.000000] riscv: base ISA extensions acdfim
[    0.000000] riscv: ELF capabilities acdfim
[    0.000000] percpu: Embedded 18 pages/cpu s34040 r8192 d31496 u73728
[    0.000000] pcpu-alloc: s34040 r8192 d31496 u73728 alloc=18*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 258055
[    0.000000] Kernel command line:
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: Cannot allocate buffer
[    0.000000] Virtual kernel memory layout:
[    0.000000]       fixmap : 0xffffffc6fee00000 - 0xffffffc6ff000000   (2048 kB)
[    0.000000]       pci io : 0xffffffc6ff000000 - 0xffffffc700000000   (  16 MB)
[    0.000000]      vmemmap : 0xffffffc700000000 - 0xffffffc800000000   (4096 MB)
[    0.000000]      vmalloc : 0xffffffc800000000 - 0xffffffd800000000   (65536 MB)
[    0.000000]       lowmem : 0xffffffd800000000 - 0xffffffd83fe00000   (1022 MB)
[    0.000000]       kernel : 0xffffffff80000000 - 0xffffffffffffffff   (2047 MB)
[    0.000000] Memory: 945200K/1046528K available (6531K kernel code, 4865K rwdata, 2048K rodata, 2165K init, 335K bss, 101328K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[    0.000000] rcu:     RCU debug extended QS entry/exit.
[    0.000000]  Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] CPU with hartid=0 is not available
[    0.000000] riscv-intc: unable to find hart id for /cpus/cpu@0/interrupt-controller
[    0.000000] riscv-intc: 64 local interrupts mapped
[    0.000000] plic: interrupt-controller@c000000: mapped 186 interrupts with 4 handlers for 9 contexts.
[    0.000000] random: get_random_bytes called from start_kernel+0x4c6/0x722 with crng_init=0
[    0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [4]
[    0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
[    0.000003] sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns
[    0.000370] Console: colour dummy device 80x25
[    0.001523] printk: console [tty0] enabled
[    0.001638] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=4000)
[    0.001707] pid_max: default: 32768 minimum: 301
[    0.002184] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.002317] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.006182] cblist_init_generic: Setting adjustable number of callback queues.
[    0.006257] cblist_init_generic: Setting shift to 2 and lim to 1.
[    0.006534] ASID allocator disabled (0 bits)
[    0.006844] rcu: Hierarchical SRCU implementation.
[    0.007418] EFI services will not be available.
[    0.008649] smp: Bringing up secondary CPUs ...
[    0.013205] smp: Brought up 1 node, 4 CPUs
[    0.014757] devtmpfs: initialized
[    0.019842] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.019934] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[    0.021531] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.022604] cpuidle: using governor menu
[    0.051726] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.052869] iommu: Default domain type: Translated
[    0.052916] iommu: DMA domain TLB invalidation policy: strict mode
[    0.053578] SCSI subsystem initialized
[    0.054006] libata version 3.00 loaded.
[    0.054362] usbcore: registered new interface driver usbfs
[    0.054476] usbcore: registered new interface driver hub
[    0.054573] usbcore: registered new device driver usb
[    0.056408] vgaarb: loaded
[    0.056687] clocksource: Switched to clocksource riscv_clocksource
[    0.073620] NET: Registered PF_INET protocol family
[    0.074488] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    0.077667] tcp_listen_portaddr_hash hash table entries: 512 (order: 2, 20480 bytes, linear)
[    0.077871] TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    0.078375] TCP bind hash table entries: 8192 (order: 6, 262144 bytes, linear)
[    0.080026] TCP: Hash tables configured (established 8192 bind 8192)
[    0.080938] UDP hash table entries: 512 (order: 3, 49152 bytes, linear)
[    0.081316] UDP-Lite hash table entries: 512 (order: 3, 49152 bytes, linear)
[    0.082048] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.083242] RPC: Registered named UNIX socket transport module.
[    0.083294] RPC: Registered udp transport module.
[    0.083326] RPC: Registered tcp transport module.
[    0.083355] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.083393] PCI: CLS 0 bytes, default 64
[    0.085448] workingset: timestamp_bits=62 max_order=18 bucket_order=0
[    0.085783] Unpacking initramfs...
[    0.101723] NFS: Registering the id_resolver key type
[    0.101842] Key type id_resolver registered
[    0.101879] Key type id_legacy registered
[    0.102096] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.102141] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[    0.102590] 9p: Installing v9fs 9p2000 file system support
[    0.103388] NET: Registered PF_ALG protocol family
[    0.103551] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    0.103604] io scheduler mq-deadline registered
[    0.103636] io scheduler kyber registered
[    0.104615] start plist test
[    0.111151] end plist test
[    0.216476] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.219973] 20100000.serial: ttyS1 at MMIO 0x20100000 (irq = 6, base_baud = 9375000) is a 16550A
[    0.865075] printk: console [ttyS1] enabled
[    0.871611] 20102000.serial: ttyS2 at MMIO 0x20102000 (irq = 7, base_baud = 9375000) is a 16550A
[    0.882714] 20104000.serial: ttyS3 at MMIO 0x20104000 (irq = 8, base_baud = 9375000) is a 16550A
[    0.893844] 20106000.serial: ttyS0 at MMIO 0x20106000 (irq = 10, base_baud = 9375000) is a 16550A
[    0.922280] loop: module loaded
[    1.478437] Freeing initrd memory: 66648K
[    1.517593] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    1.527842] e1000e: Intel(R) PRO/1000 Network Driver
[    1.532863] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    1.539029] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.545625] ehci-pci: EHCI PCI platform driver
[    1.550184] ehci-platform: EHCI generic platform driver
[    1.555662] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.561935] ohci-pci: OHCI PCI platform driver
[    1.566495] ohci-platform: OHCI generic platform driver
[    1.572791] usbcore: registered new interface driver uas
[    1.578279] usbcore: registered new interface driver usb-storage
[    1.584706] mousedev: PS/2 mouse device common for all mice
[    1.591420] sdhci: Secure Digital Host Controller Interface driver
[    1.597671] sdhci: Copyright(c) Pierre Ossman
[    1.602150] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.608466] usbcore: registered new interface driver usbhid
[    1.614146] usbhid: USB HID core driver
[    1.619393] NET: Registered PF_INET6 protocol family
[    1.626952] Segment Routing with IPv6
[    1.630778] In-situ OAM (IOAM) with IPv6
[    1.634918] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    1.640458] mmc0: SDHCI controller on 20008000.mmc [20008000.mmc] using ADMA 64-bit
[    1.642047] NET: Registered PF_PACKET protocol family
[    1.654158] 9pnet: Installing 9P2000 support
[    1.658634] Key type dns_resolver registered
[    1.664475] debug_vm_pgtable: [debug_vm_pgtable         ]: Validating architecture page table helpers
[    1.683396] Legacy PMU implementation is available
[    1.701275] Freeing unused kernel image (initmem) memory: 2164K
[    1.712785] Run /init as init process
[    1.716509]   with arguments:
[    1.716518]     /init
[    1.716527]   with environment:
[    1.716536]     HOME=/
[    1.716545]     TERM=linux
[    1.721514] sdhci-cdns 20008000.mmc: no tuning point found
[    1.727137] mmc0: tuning execution failed: -5
[    1.793666] mmc0: new high speed SDHC card at address aaaa
[    1.801760] mmcblk0: mmc0:aaaa SC16G 14.8 GiB
[    1.822190]  mmcblk0: p1 p2 p3
[    3.008272] random: dd: uninitialized urandom read (32 bytes read)
[    3.179071] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
[    3.193695] macb 20112000.ethernet eth0: Could not attach PHY (-22)   

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor.Dooley]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

Hey,
I seem to have come across a regression in the default riscv defconfig
between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
machine") which causes the ethernet phy to not come up on my Icicle kit:
[ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
[ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)

I did try to bisect normally, but unfortunately it was not trivial for
me to do, because the following two commits from Linus' tree that
arrived after riscv-for-linus-5.18-mw0 are required actually bring up
the icicle kit & its ethernet:
37f7860602b5 net: macb: Align the dma and coherent dma masks
635e5e73370e clk: microchip: Add driver for Microchip PolarFire SoC

I went down a rabbit hole of checking the net side of things & found
that the failing check is in the call to phylink_validate in
phylink_bringup_phy. Some digging points to v5.18-rc1's
drivers/net/phy/phylink.c:L457 as the culprit, with the
phylink_is_empty_linkmode check failing.

At riscv-for-linus-5.18-mw0, cherry-picking those two commits brings it
up fine:
[ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
[ 2.828915] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
[11.045411] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[11.053247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

At riscv-for-linus-5.18-mw1 (1464d00b27b2) with those two commits
applied, I get the same validation failure as with v5.18-rc1.

I did some manual reversions of everything in
drivers/net/ethernet/cadence/ & drivers/net/phy/phylink.c that was
added since 5.17 to no avail.
Turns out the problem was exposed by riscv-for-linus-5.18-mw1 and
reverting c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver
for QEMU virt machine") avoided the problem for me.

Is this some sort of lack of support for CONFIG_PM=y in my clock driver,
that's leading to the PHY getting stuck in reset?
Or an interaction between CONFIG_PM=y & the macb/generic phy drivers?

I am kinda lost at this point & would appreciate any help investigating
further. I have attached the full log in case that helps.
Thanks,
Conor.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: failure.log --]
[-- Type: text/x-log; name="failure.log", Size: 10541 bytes --]

[    0.000000] Linux version 5.18.0-rc1 (conor@wendy) (riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP Tue Apr 5 13:17:47 IST 2022
[    0.000000] OF: fdt: Ignoring memory block 0x80000000 - 0xae000000
[    0.000000] OF: fdt: Ignoring memory range 0x1000000000 - 0x1000200000
[    0.000000] Machine model: Microchip PolarFire-SoC Icicle Kit
[    0.000000] efi: UEFI not found.
[    0.000000] Zone ranges:
[    0.000000]   DMA32    empty
[    0.000000]   Normal   [mem 0x0000001000200000-0x000000103fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000001000200000-0x000000103fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000001000200000-0x000000103fffffff]
[    0.000000] SBI specification v0.3 detected
[    0.000000] SBI implementation ID=0x1 Version=0x9
[    0.000000] SBI TIME extension detected
[    0.000000] SBI IPI extension detected
[    0.000000] SBI RFENCE extension detected
[    0.000000] SBI HSM extension detected
[    0.000000] CPU with hartid=0 is not available
[    0.000000] CPU with hartid=0 is not available
[    0.000000] riscv: base ISA extensions acdfim
[    0.000000] riscv: ELF capabilities acdfim
[    0.000000] percpu: Embedded 18 pages/cpu s34040 r8192 d31496 u73728
[    0.000000] pcpu-alloc: s34040 r8192 d31496 u73728 alloc=18*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 258055
[    0.000000] Kernel command line:
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: Cannot allocate buffer
[    0.000000] Virtual kernel memory layout:
[    0.000000]       fixmap : 0xffffffc6fee00000 - 0xffffffc6ff000000   (2048 kB)
[    0.000000]       pci io : 0xffffffc6ff000000 - 0xffffffc700000000   (  16 MB)
[    0.000000]      vmemmap : 0xffffffc700000000 - 0xffffffc800000000   (4096 MB)
[    0.000000]      vmalloc : 0xffffffc800000000 - 0xffffffd800000000   (65536 MB)
[    0.000000]       lowmem : 0xffffffd800000000 - 0xffffffd83fe00000   (1022 MB)
[    0.000000]       kernel : 0xffffffff80000000 - 0xffffffffffffffff   (2047 MB)
[    0.000000] Memory: 945200K/1046528K available (6531K kernel code, 4865K rwdata, 2048K rodata, 2165K init, 335K bss, 101328K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[    0.000000] rcu:     RCU debug extended QS entry/exit.
[    0.000000]  Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] CPU with hartid=0 is not available
[    0.000000] riscv-intc: unable to find hart id for /cpus/cpu@0/interrupt-controller
[    0.000000] riscv-intc: 64 local interrupts mapped
[    0.000000] plic: interrupt-controller@c000000: mapped 186 interrupts with 4 handlers for 9 contexts.
[    0.000000] random: get_random_bytes called from start_kernel+0x4c6/0x722 with crng_init=0
[    0.000000] riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [4]
[    0.000000] clocksource: riscv_clocksource: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
[    0.000003] sched_clock: 64 bits at 1000kHz, resolution 1000ns, wraps every 2199023255500ns
[    0.000370] Console: colour dummy device 80x25
[    0.001523] printk: console [tty0] enabled
[    0.001638] Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=4000)
[    0.001707] pid_max: default: 32768 minimum: 301
[    0.002184] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.002317] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.006182] cblist_init_generic: Setting adjustable number of callback queues.
[    0.006257] cblist_init_generic: Setting shift to 2 and lim to 1.
[    0.006534] ASID allocator disabled (0 bits)
[    0.006844] rcu: Hierarchical SRCU implementation.
[    0.007418] EFI services will not be available.
[    0.008649] smp: Bringing up secondary CPUs ...
[    0.013205] smp: Brought up 1 node, 4 CPUs
[    0.014757] devtmpfs: initialized
[    0.019842] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.019934] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[    0.021531] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.022604] cpuidle: using governor menu
[    0.051726] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.052869] iommu: Default domain type: Translated
[    0.052916] iommu: DMA domain TLB invalidation policy: strict mode
[    0.053578] SCSI subsystem initialized
[    0.054006] libata version 3.00 loaded.
[    0.054362] usbcore: registered new interface driver usbfs
[    0.054476] usbcore: registered new interface driver hub
[    0.054573] usbcore: registered new device driver usb
[    0.056408] vgaarb: loaded
[    0.056687] clocksource: Switched to clocksource riscv_clocksource
[    0.073620] NET: Registered PF_INET protocol family
[    0.074488] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    0.077667] tcp_listen_portaddr_hash hash table entries: 512 (order: 2, 20480 bytes, linear)
[    0.077871] TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    0.078375] TCP bind hash table entries: 8192 (order: 6, 262144 bytes, linear)
[    0.080026] TCP: Hash tables configured (established 8192 bind 8192)
[    0.080938] UDP hash table entries: 512 (order: 3, 49152 bytes, linear)
[    0.081316] UDP-Lite hash table entries: 512 (order: 3, 49152 bytes, linear)
[    0.082048] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.083242] RPC: Registered named UNIX socket transport module.
[    0.083294] RPC: Registered udp transport module.
[    0.083326] RPC: Registered tcp transport module.
[    0.083355] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.083393] PCI: CLS 0 bytes, default 64
[    0.085448] workingset: timestamp_bits=62 max_order=18 bucket_order=0
[    0.085783] Unpacking initramfs...
[    0.101723] NFS: Registering the id_resolver key type
[    0.101842] Key type id_resolver registered
[    0.101879] Key type id_legacy registered
[    0.102096] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.102141] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[    0.102590] 9p: Installing v9fs 9p2000 file system support
[    0.103388] NET: Registered PF_ALG protocol family
[    0.103551] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    0.103604] io scheduler mq-deadline registered
[    0.103636] io scheduler kyber registered
[    0.104615] start plist test
[    0.111151] end plist test
[    0.216476] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.219973] 20100000.serial: ttyS1 at MMIO 0x20100000 (irq = 6, base_baud = 9375000) is a 16550A
[    0.865075] printk: console [ttyS1] enabled
[    0.871611] 20102000.serial: ttyS2 at MMIO 0x20102000 (irq = 7, base_baud = 9375000) is a 16550A
[    0.882714] 20104000.serial: ttyS3 at MMIO 0x20104000 (irq = 8, base_baud = 9375000) is a 16550A
[    0.893844] 20106000.serial: ttyS0 at MMIO 0x20106000 (irq = 10, base_baud = 9375000) is a 16550A
[    0.922280] loop: module loaded
[    1.478437] Freeing initrd memory: 66648K
[    1.517593] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    1.527842] e1000e: Intel(R) PRO/1000 Network Driver
[    1.532863] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    1.539029] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.545625] ehci-pci: EHCI PCI platform driver
[    1.550184] ehci-platform: EHCI generic platform driver
[    1.555662] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.561935] ohci-pci: OHCI PCI platform driver
[    1.566495] ohci-platform: OHCI generic platform driver
[    1.572791] usbcore: registered new interface driver uas
[    1.578279] usbcore: registered new interface driver usb-storage
[    1.584706] mousedev: PS/2 mouse device common for all mice
[    1.591420] sdhci: Secure Digital Host Controller Interface driver
[    1.597671] sdhci: Copyright(c) Pierre Ossman
[    1.602150] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.608466] usbcore: registered new interface driver usbhid
[    1.614146] usbhid: USB HID core driver
[    1.619393] NET: Registered PF_INET6 protocol family
[    1.626952] Segment Routing with IPv6
[    1.630778] In-situ OAM (IOAM) with IPv6
[    1.634918] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    1.640458] mmc0: SDHCI controller on 20008000.mmc [20008000.mmc] using ADMA 64-bit
[    1.642047] NET: Registered PF_PACKET protocol family
[    1.654158] 9pnet: Installing 9P2000 support
[    1.658634] Key type dns_resolver registered
[    1.664475] debug_vm_pgtable: [debug_vm_pgtable         ]: Validating architecture page table helpers
[    1.683396] Legacy PMU implementation is available
[    1.701275] Freeing unused kernel image (initmem) memory: 2164K
[    1.712785] Run /init as init process
[    1.716509]   with arguments:
[    1.716518]     /init
[    1.716527]   with environment:
[    1.716536]     HOME=/
[    1.716545]     TERM=linux
[    1.721514] sdhci-cdns 20008000.mmc: no tuning point found
[    1.727137] mmc0: tuning execution failed: -5
[    1.793666] mmc0: new high speed SDHC card at address aaaa
[    1.801760] mmcblk0: mmc0:aaaa SC16G 14.8 GiB
[    1.822190]  mmcblk0: p1 p2 p3
[    3.008272] random: dd: uninitialized urandom read (32 bytes read)
[    3.179071] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
[    3.193695] macb 20112000.ethernet eth0: Could not attach PHY (-22)   

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Andrew Lunn]

On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)

Hi Conor

In general, it is better to use the specific PHY driver for the PHY
then rely on the generic PHY driver. I think the Icicle Kit has a
VSC8662? So i would suggest you enable the Vitesse PHYs.

  Andrew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Andrew Lunn]

On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)

Hi Conor

In general, it is better to use the specific PHY driver for the PHY
then rely on the generic PHY driver. I think the Icicle Kit has a
VSC8662? So i would suggest you enable the Vitesse PHYs.

  Andrew

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor.Dooley]

On 05/04/2022 13:25, Andrew Lunn wrote:
> On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
>> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
> 
> Hi Conor
> 
> In general, it is better to use the specific PHY driver for the PHY
> then rely on the generic PHY driver. I think the Icicle Kit has a
> VSC8662? So i would suggest you enable the Vitesse PHYs.

Hi Andrew, thanks for the quick reply.
It does indeed have a Vitesse VSC8662, but the link never seems to
come up for me [1] so I have been using Generic PHY. I'll try look
at why that is. Either way would like to know what's gone wrong in
the Generic PHY case since that's what's available in the riscv
defconfig.

Thanks,
Conor.

[1]:
[    1.521768] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    3.206274] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    3.216641] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
(and then nothing)

> 
>    Andrew
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor.Dooley]

On 05/04/2022 13:25, Andrew Lunn wrote:
> On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
>> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
> 
> Hi Conor
> 
> In general, it is better to use the specific PHY driver for the PHY
> then rely on the generic PHY driver. I think the Icicle Kit has a
> VSC8662? So i would suggest you enable the Vitesse PHYs.

Hi Andrew, thanks for the quick reply.
It does indeed have a Vitesse VSC8662, but the link never seems to
come up for me [1] so I have been using Generic PHY. I'll try look
at why that is. Either way would like to know what's gone wrong in
the Generic PHY case since that's what's available in the riscv
defconfig.

Thanks,
Conor.

[1]:
[    1.521768] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    3.206274] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    3.216641] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
(and then nothing)

> 
>    Andrew
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor.Dooley]

On 05/04/2022 14:17, Conor Dooley wrote:
> 
> 
> On 05/04/2022 13:25, Andrew Lunn wrote:
>> On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
>>> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
>>
>> Hi Conor
>>
>> In general, it is better to use the specific PHY driver for the PHY
>> then rely on the generic PHY driver. I think the Icicle Kit has a
>> VSC8662? So i would suggest you enable the Vitesse PHYs.
> 
> Hi Andrew, thanks for the quick reply.
> It does indeed have a Vitesse VSC8662, but the link never seems to
> come up for me [1] so I have been using Generic PHY. I'll try look
> at why that is. Either way would like to know what's gone wrong in
> the Generic PHY case since that's what's available in the riscv
> defconfig.

I think I put this badly - without the reversion of the CONFIG_PM
addition, the link doesn't come up for the Vitesse driver but there
is no validation failure:

[    1.521768] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    3.206274] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    3.216641] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
(and then nothing)

If I revert the CONFIG_PM addition:

[    1.508882] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    2.879617] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    2.890010] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
[    6.981823] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[    6.989657] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

> 
> Thanks,
> Conor.
> 
> [1]:

> 
>>
>>    Andrew
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor.Dooley]

On 05/04/2022 14:17, Conor Dooley wrote:
> 
> 
> On 05/04/2022 13:25, Andrew Lunn wrote:
>> On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
>>> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
>>
>> Hi Conor
>>
>> In general, it is better to use the specific PHY driver for the PHY
>> then rely on the generic PHY driver. I think the Icicle Kit has a
>> VSC8662? So i would suggest you enable the Vitesse PHYs.
> 
> Hi Andrew, thanks for the quick reply.
> It does indeed have a Vitesse VSC8662, but the link never seems to
> come up for me [1] so I have been using Generic PHY. I'll try look
> at why that is. Either way would like to know what's gone wrong in
> the Generic PHY case since that's what's available in the riscv
> defconfig.

I think I put this badly - without the reversion of the CONFIG_PM
addition, the link doesn't come up for the Vitesse driver but there
is no validation failure:

[    1.521768] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    3.206274] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    3.216641] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
(and then nothing)

If I revert the CONFIG_PM addition:

[    1.508882] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    2.879617] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    2.890010] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
[    6.981823] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[    6.989657] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

> 
> Thanks,
> Conor.
> 
> [1]:

> 
>>
>>    Andrew
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Andrew Lunn]

On Tue, Apr 05, 2022 at 02:18:17PM +0000, Conor.Dooley@microchip.com wrote:
> 
> 
> On 05/04/2022 13:25, Andrew Lunn wrote:
> > On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
> >> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
> > 
> > Hi Conor
> > 
> > In general, it is better to use the specific PHY driver for the PHY
> > then rely on the generic PHY driver. I think the Icicle Kit has a
> > VSC8662? So i would suggest you enable the Vitesse PHYs.
> 
> Hi Andrew, thanks for the quick reply.
> It does indeed have a Vitesse VSC8662, but the link never seems to
> come up for me [1] so I have been using Generic PHY. I'll try look
> at why that is. Either way would like to know what's gone wrong in
> the Generic PHY case since that's what's available in the riscv
> defconfig.

Hi Conor

Generic PHY is purely best effort fall back for when there is nothing
better. It might work, it might not, depending on the PHY. If it is a
simple PHY which only implements the registers defined in 802.3 clause
22, and not much more, it has a good chance of working. Otherwise, you
really should be using the specific driver.

Don't worry too much about the defconfig, nobody actually uses
it. Distros have their own which turn on most things. So a real system
probably does have the correct PHY driver.

	 Andrew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Andrew Lunn]

On Tue, Apr 05, 2022 at 02:18:17PM +0000, Conor.Dooley@microchip.com wrote:
> 
> 
> On 05/04/2022 13:25, Andrew Lunn wrote:
> > On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
> >> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
> > 
> > Hi Conor
> > 
> > In general, it is better to use the specific PHY driver for the PHY
> > then rely on the generic PHY driver. I think the Icicle Kit has a
> > VSC8662? So i would suggest you enable the Vitesse PHYs.
> 
> Hi Andrew, thanks for the quick reply.
> It does indeed have a Vitesse VSC8662, but the link never seems to
> come up for me [1] so I have been using Generic PHY. I'll try look
> at why that is. Either way would like to know what's gone wrong in
> the Generic PHY case since that's what's available in the riscv
> defconfig.

Hi Conor

Generic PHY is purely best effort fall back for when there is nothing
better. It might work, it might not, depending on the PHY. If it is a
simple PHY which only implements the registers defined in 802.3 clause
22, and not much more, it has a good chance of working. Otherwise, you
really should be using the specific driver.

Don't worry too much about the defconfig, nobody actually uses
it. Distros have their own which turn on most things. So a real system
probably does have the correct PHY driver.

	 Andrew

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Andrew Lunn]

> Is this some sort of lack of support for CONFIG_PM=y in my clock driver,
> that's leading to the PHY getting stuck in reset?
> Or an interaction between CONFIG_PM=y & the macb/generic phy drivers?

What clock is driving the PHY? Sometimes the SoC outputs a clock to
the PHY, and the PHY will not work without it. Sometimes it is the
other way around, the PHY outputs a clock to SoC, so this might not be
your issue.

Maybe PM is turning the clock off because nothing is using it?

      Andrew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Andrew Lunn]

> Is this some sort of lack of support for CONFIG_PM=y in my clock driver,
> that's leading to the PHY getting stuck in reset?
> Or an interaction between CONFIG_PM=y & the macb/generic phy drivers?

What clock is driving the PHY? Sometimes the SoC outputs a clock to
the PHY, and the PHY will not work without it. Sometimes it is the
other way around, the PHY outputs a clock to SoC, so this might not be
your issue.

Maybe PM is turning the clock off because nothing is using it?

      Andrew

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Andrew Lunn]

> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
> [ 2.828915] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
> [11.045411] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> [11.053247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

You have a multi-part link. You need that the PHY reports the line
side is up. Put some printk in genphy_update_link() and look at
phydev->link. You also need that the SGMII link between the PHY and
the SoC is up. That is a bit harder to see, but try adding #define
DEBUG at the top of phylink.c and phy.c so you get additional debug
prints for the state machines.

       Andrew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Andrew Lunn]

> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
> [ 2.828915] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
> [11.045411] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> [11.053247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

You have a multi-part link. You need that the PHY reports the line
side is up. Put some printk in genphy_update_link() and look at
phydev->link. You also need that the SGMII link between the PHY and
the SoC is up. That is a bit harder to see, but try adding #define
DEBUG at the top of phylink.c and phy.c so you get additional debug
prints for the state machines.

       Andrew

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Russell King (Oracle)]

On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
> Hey,
> I seem to have come across a regression in the default riscv defconfig
> between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
> c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
> machine") which causes the ethernet phy to not come up on my Icicle kit:
> [ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
> [ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)

I don't think that would be related to the idle driver. This looks like
the PHY hasn't filled in the supported mask at probe time - do you have
the driver for the PHY built-in or the PHY driver module loaded?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Russell King (Oracle)]

On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
> Hey,
> I seem to have come across a regression in the default riscv defconfig
> between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
> c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
> machine") which causes the ethernet phy to not come up on my Icicle kit:
> [ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
> [ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)

I don't think that would be related to the idle driver. This looks like
the PHY hasn't filled in the supported mask at probe time - do you have
the driver for the PHY built-in or the PHY driver module loaded?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor Dooley]

On 05/04/2022 16:04, Andrew Lunn wrote:
>> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
>> [ 2.828915] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
>> [11.045411] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>> [11.053247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> 
> You have a multi-part link. You need that the PHY reports the line
> side is up. Put some printk in genphy_update_link() and look at
> phydev->link. You also need that the SGMII link between the PHY and
> the SoC is up. That is a bit harder to see, but try adding #define
> DEBUG at the top of phylink.c and phy.c so you get additional debug
> prints for the state machines.

Sure, will give it a go tomorrow.

> 
>         Andrew
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor Dooley]

On 05/04/2022 16:04, Andrew Lunn wrote:
>> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
>> [ 2.828915] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
>> [11.045411] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>> [11.053247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> 
> You have a multi-part link. You need that the PHY reports the line
> side is up. Put some printk in genphy_update_link() and look at
> phydev->link. You also need that the SGMII link between the PHY and
> the SoC is up. That is a bit harder to see, but try adding #define
> DEBUG at the top of phylink.c and phy.c so you get additional debug
> prints for the state machines.

Sure, will give it a go tomorrow.

> 
>         Andrew
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Palmer Dabbelt]

On Tue, 05 Apr 2022 08:53:06 PDT (-0700), linux@armlinux.org.uk wrote:
> On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
>> Hey,
>> I seem to have come across a regression in the default riscv defconfig
>> between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
>> c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
>> machine") which causes the ethernet phy to not come up on my Icicle kit:
>> [ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
>> [ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)
>
> I don't think that would be related to the idle driver. This looks like
> the PHY hasn't filled in the supported mask at probe time - do you have
> the driver for the PHY built-in or the PHY driver module loaded?

IIRC we had a bunch of issues with the PHY on the HiFive Unleashed, 
there was a quirky reset sequence that it wouldn't even probe 
correctly without.  We have a 

    &eth0 {
            status = "okay";
            phy-mode = "gmii";
            phy-handle = <&phy0>;
            phy0: ethernet-phy@0 {
                    compatible = "ethernet-phy-id0007.0771";
                    reg = <0>;
            };
    };

in the Unleashed DT, but I can't find anything similar in the Icicle DT

    &mac1 {
            status = "okay";
            phy-mode = "sgmii";
            phy-handle = <&phy1>;
            phy1: ethernet-phy@9 {
                    reg = <9>;
                    ti,fifo-depth = <0x1>;
            };
            phy0: ethernet-phy@8 {
                    reg = <8>;
                    ti,fifo-depth = <0x1>;
            };
    };

I seem to remember picking that specific phy because it was similar to 
the one that was POR for the Icicle at the time we decided, maybe you 
have a similar phy with a similar quirk and need a similar workaround?

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Palmer Dabbelt]

On Tue, 05 Apr 2022 08:53:06 PDT (-0700), linux@armlinux.org.uk wrote:
> On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
>> Hey,
>> I seem to have come across a regression in the default riscv defconfig
>> between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
>> c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
>> machine") which causes the ethernet phy to not come up on my Icicle kit:
>> [ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
>> [ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)
>
> I don't think that would be related to the idle driver. This looks like
> the PHY hasn't filled in the supported mask at probe time - do you have
> the driver for the PHY built-in or the PHY driver module loaded?

IIRC we had a bunch of issues with the PHY on the HiFive Unleashed, 
there was a quirky reset sequence that it wouldn't even probe 
correctly without.  We have a 

    &eth0 {
            status = "okay";
            phy-mode = "gmii";
            phy-handle = <&phy0>;
            phy0: ethernet-phy@0 {
                    compatible = "ethernet-phy-id0007.0771";
                    reg = <0>;
            };
    };

in the Unleashed DT, but I can't find anything similar in the Icicle DT

    &mac1 {
            status = "okay";
            phy-mode = "sgmii";
            phy-handle = <&phy1>;
            phy1: ethernet-phy@9 {
                    reg = <9>;
                    ti,fifo-depth = <0x1>;
            };
            phy0: ethernet-phy@8 {
                    reg = <8>;
                    ti,fifo-depth = <0x1>;
            };
    };

I seem to remember picking that specific phy because it was similar to 
the one that was POR for the Icicle at the time we decided, maybe you 
have a similar phy with a similar quirk and need a similar workaround?

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor Dooley]

On 05/04/2022 16:53, Russell King (Oracle) wrote:
> On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
>> Hey,
>> I seem to have come across a regression in the default riscv defconfig
>> between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
>> c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
>> machine") which causes the ethernet phy to not come up on my Icicle kit:
>> [ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
>> [ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)
> 
> I don't think that would be related to the idle driver. This looks like
> the PHY hasn't filled in the supported mask at probe time - do you have
> the driver for the PHY built-in or the PHY driver module loaded?

Hey Russel,
The idle stuff enabled CONFIG_PM=y though in the default riscv
defconfig, so it is not confined to just QEMU.

I am not sure what the symbol for the generic phy & I am not at work
to properly check, so I hope this is the relevant part of the config:

CONFIG_PHYLINK=y
CONFIG_PHYLIB=y
CONFIG_SWPHY=y
CONFIG_FIXED_PHY=y

If it isn't, you should be able to generate the config I used to cause
the error with:
make ARCH=RISCV defconfig

If you look at my response to Andrew [1] you'll see that my problems
are not isolated to just the Generic PHY driver as a builtin Vitesse
driver has issues too (although validation appears to have passed).

Thanks,
Conor.

[1] 
https://lore.kernel.org/linux-riscv/60fd1eb7-a2ce-9084-c567-721e975e7e86@microchip.com/

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor Dooley]

On 05/04/2022 16:53, Russell King (Oracle) wrote:
> On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
>> Hey,
>> I seem to have come across a regression in the default riscv defconfig
>> between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
>> c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
>> machine") which causes the ethernet phy to not come up on my Icicle kit:
>> [ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
>> [ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)
> 
> I don't think that would be related to the idle driver. This looks like
> the PHY hasn't filled in the supported mask at probe time - do you have
> the driver for the PHY built-in or the PHY driver module loaded?

Hey Russel,
The idle stuff enabled CONFIG_PM=y though in the default riscv
defconfig, so it is not confined to just QEMU.

I am not sure what the symbol for the generic phy & I am not at work
to properly check, so I hope this is the relevant part of the config:

CONFIG_PHYLINK=y
CONFIG_PHYLIB=y
CONFIG_SWPHY=y
CONFIG_FIXED_PHY=y

If it isn't, you should be able to generate the config I used to cause
the error with:
make ARCH=RISCV defconfig

If you look at my response to Andrew [1] you'll see that my problems
are not isolated to just the Generic PHY driver as a builtin Vitesse
driver has issues too (although validation appears to have passed).

Thanks,
Conor.

[1] 
https://lore.kernel.org/linux-riscv/60fd1eb7-a2ce-9084-c567-721e975e7e86@microchip.com/

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor Dooley]

On 05/04/2022 17:56, Palmer Dabbelt wrote:
> On Tue, 05 Apr 2022 08:53:06 PDT (-0700), linux@armlinux.org.uk wrote:
>> On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com 
>> wrote:
>>> Hey,
>>> I seem to have come across a regression in the default riscv defconfig
>>> between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
>>> c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
>>> machine") which causes the ethernet phy to not come up on my Icicle kit:
>>> [ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with 
>>> support 0000000,00000000,00006280 and advertisement 
>>> 0000000,00000000,00004280 failed: -EINVAL
>>> [ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)
>>
>> I don't think that would be related to the idle driver. This looks like
>> the PHY hasn't filled in the supported mask at probe time - do you have
>> the driver for the PHY built-in or the PHY driver module loaded?
> 
> IIRC we had a bunch of issues with the PHY on the HiFive Unleashed, 
> there was a quirky reset sequence that it wouldn't even probe correctly 
> without.  We have a
>     &eth0 {
>             status = "okay";
>             phy-mode = "gmii";
>             phy-handle = <&phy0>;
>             phy0: ethernet-phy@0 {
>                     compatible = "ethernet-phy-id0007.0771";
>                     reg = <0>;
>             };
>     };
> 
> in the Unleashed DT, but I can't find anything similar in the Icicle DT
> 
>     &mac1 {
>             status = "okay";
>             phy-mode = "sgmii";
>             phy-handle = <&phy1>;
>             phy1: ethernet-phy@9 {
>                     reg = <9>;
>                     ti,fifo-depth = <0x1>;
>             };
>             phy0: ethernet-phy@8 {
>                     reg = <8>;
>                     ti,fifo-depth = <0x1>;
>             };
>     };
> 
> I seem to remember picking that specific phy because it was similar to 
> the one that was POR for the Icicle at the time we decided, maybe you 
> have a similar phy with a similar quirk and need a similar workaround?

I tried using the one for the VSC8662 (0007.0660) since that's whats on,
the board but that didn't help.
Without the revert:

[    1.521768] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c 
at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    3.206274] macb 20112000.ethernet eth0: PHY 
[20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    3.216641] macb 20112000.ethernet eth0: configuring for phy/sgmii 
link mode
(and then nothing)

If I revert the CONFIG_PM addition:

[    1.508882] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c 
at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    2.879617] macb 20112000.ethernet eth0: PHY 
[20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    2.890010] macb 20112000.ethernet eth0: configuring for phy/sgmii 
link mode
[    6.981823] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - 
flow control off
[    6.989657] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

I will try again tomorrow with "ethernet-phy-id0007.0771" to see if
anything changes, since that would use the Microsemi driver rather
than the Vitesse driver that VSC8662/0007.0660 uses.

Thanks,
Conor.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor Dooley]

On 05/04/2022 17:56, Palmer Dabbelt wrote:
> On Tue, 05 Apr 2022 08:53:06 PDT (-0700), linux@armlinux.org.uk wrote:
>> On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com 
>> wrote:
>>> Hey,
>>> I seem to have come across a regression in the default riscv defconfig
>>> between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
>>> c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
>>> machine") which causes the ethernet phy to not come up on my Icicle kit:
>>> [ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with 
>>> support 0000000,00000000,00006280 and advertisement 
>>> 0000000,00000000,00004280 failed: -EINVAL
>>> [ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)
>>
>> I don't think that would be related to the idle driver. This looks like
>> the PHY hasn't filled in the supported mask at probe time - do you have
>> the driver for the PHY built-in or the PHY driver module loaded?
> 
> IIRC we had a bunch of issues with the PHY on the HiFive Unleashed, 
> there was a quirky reset sequence that it wouldn't even probe correctly 
> without.  We have a
>     &eth0 {
>             status = "okay";
>             phy-mode = "gmii";
>             phy-handle = <&phy0>;
>             phy0: ethernet-phy@0 {
>                     compatible = "ethernet-phy-id0007.0771";
>                     reg = <0>;
>             };
>     };
> 
> in the Unleashed DT, but I can't find anything similar in the Icicle DT
> 
>     &mac1 {
>             status = "okay";
>             phy-mode = "sgmii";
>             phy-handle = <&phy1>;
>             phy1: ethernet-phy@9 {
>                     reg = <9>;
>                     ti,fifo-depth = <0x1>;
>             };
>             phy0: ethernet-phy@8 {
>                     reg = <8>;
>                     ti,fifo-depth = <0x1>;
>             };
>     };
> 
> I seem to remember picking that specific phy because it was similar to 
> the one that was POR for the Icicle at the time we decided, maybe you 
> have a similar phy with a similar quirk and need a similar workaround?

I tried using the one for the VSC8662 (0007.0660) since that's whats on,
the board but that didn't help.
Without the revert:

[    1.521768] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c 
at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    3.206274] macb 20112000.ethernet eth0: PHY 
[20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    3.216641] macb 20112000.ethernet eth0: configuring for phy/sgmii 
link mode
(and then nothing)

If I revert the CONFIG_PM addition:

[    1.508882] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c 
at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    2.879617] macb 20112000.ethernet eth0: PHY 
[20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    2.890010] macb 20112000.ethernet eth0: configuring for phy/sgmii 
link mode
[    6.981823] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - 
flow control off
[    6.989657] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

I will try again tomorrow with "ethernet-phy-id0007.0771" to see if
anything changes, since that would use the Microsemi driver rather
than the Vitesse driver that VSC8662/0007.0660 uses.

Thanks,
Conor.

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Andrew Lunn]

> I tried using the one for the VSC8662 (0007.0660) since that's whats on,
> the board but that didn't help.
> Without the revert:
> 
> [    1.521768] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at
> 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
> [    3.206274] macb 20112000.ethernet eth0: PHY
> [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
> [    3.216641] macb 20112000.ethernet eth0: configuring for phy/sgmii link
> mode
> (and then nothing)
> 
> If I revert the CONFIG_PM addition:
> 
> [    1.508882] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at
> 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
> [    2.879617] macb 20112000.ethernet eth0: PHY
> [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
> [    2.890010] macb 20112000.ethernet eth0: configuring for phy/sgmii link
> mode
> [    6.981823] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow
> control off
> [    6.989657] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> 
> I will try again tomorrow with "ethernet-phy-id0007.0771" to see if
> anything changes, since that would use the Microsemi driver rather
> than the Vitesse driver that VSC8662/0007.0660 uses.

The numbers here should be the same as what you find in registers 2
and 3 of the PHY. They identify the manufacture, version and revision
of the PHY. With a normal probe, these two registers are read, and the
PHY driver found which says it supports the particular ID. The only
time you need to actually list the IDs in DT is when you cannot find
the PHY using the normal probe, generally because its regulator/reset
is turned off, and only the PHY driver knows how to fix that.
Chicken/Egg.

You don't have this issue, you always seem to be able to find the PHY,
so you don't need these properties.

Also, using the Microsemi driver for a Vitesse hardware is like using
the intel i210 Ethernet driver for an amd xgbe Ethernet hardware....

    Andrew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Andrew Lunn]

> I tried using the one for the VSC8662 (0007.0660) since that's whats on,
> the board but that didn't help.
> Without the revert:
> 
> [    1.521768] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at
> 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
> [    3.206274] macb 20112000.ethernet eth0: PHY
> [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
> [    3.216641] macb 20112000.ethernet eth0: configuring for phy/sgmii link
> mode
> (and then nothing)
> 
> If I revert the CONFIG_PM addition:
> 
> [    1.508882] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at
> 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
> [    2.879617] macb 20112000.ethernet eth0: PHY
> [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
> [    2.890010] macb 20112000.ethernet eth0: configuring for phy/sgmii link
> mode
> [    6.981823] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow
> control off
> [    6.989657] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> 
> I will try again tomorrow with "ethernet-phy-id0007.0771" to see if
> anything changes, since that would use the Microsemi driver rather
> than the Vitesse driver that VSC8662/0007.0660 uses.

The numbers here should be the same as what you find in registers 2
and 3 of the PHY. They identify the manufacture, version and revision
of the PHY. With a normal probe, these two registers are read, and the
PHY driver found which says it supports the particular ID. The only
time you need to actually list the IDs in DT is when you cannot find
the PHY using the normal probe, generally because its regulator/reset
is turned off, and only the PHY driver knows how to fix that.
Chicken/Egg.

You don't have this issue, you always seem to be able to find the PHY,
so you don't need these properties.

Also, using the Microsemi driver for a Vitesse hardware is like using
the intel i210 Ethernet driver for an amd xgbe Ethernet hardware....

    Andrew

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor Dooley]

On 05/04/2022 19:06, Andrew Lunn wrote:
>> I tried using the one for the VSC8662 (0007.0660) since that's whats on,
>> the board but that didn't help.
>> Without the revert:
>>
>> [    1.521768] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at
>> 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
>> [    3.206274] macb 20112000.ethernet eth0: PHY
>> [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
>> [    3.216641] macb 20112000.ethernet eth0: configuring for phy/sgmii link
>> mode
>> (and then nothing)
>>
>> If I revert the CONFIG_PM addition:
>>
>> [    1.508882] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at
>> 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
>> [    2.879617] macb 20112000.ethernet eth0: PHY
>> [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
>> [    2.890010] macb 20112000.ethernet eth0: configuring for phy/sgmii link
>> mode
>> [    6.981823] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow
>> control off
>> [    6.989657] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>
>> I will try again tomorrow with "ethernet-phy-id0007.0771" to see if
>> anything changes, since that would use the Microsemi driver rather
>> than the Vitesse driver that VSC8662/0007.0660 uses.
> 
> The numbers here should be the same as what you find in registers 2
> and 3 of the PHY. They identify the manufacture, version and revision
> of the PHY. With a normal probe, these two registers are read, and the
> PHY driver found which says it supports the particular ID. The only
> time you need to actually list the IDs in DT is when you cannot find
> the PHY using the normal probe, generally because its regulator/reset
> is turned off, and only the PHY driver knows how to fix that.
> Chicken/Egg.
> 
> You don't have this issue, you always seem to be able to find the PHY,
> so you don't need these properties.

Good to know.

> Also, using the Microsemi driver for a Vitesse hardware is like using
> the intel i210 Ethernet driver for an amd xgbe Ethernet hardware....

Ehh, not sure that this is the best comparison. Microsemi bought Vitesse
in 2015, and the PHYs supported by the Microsemi driver are all VSC*
products. I was going to try it in the off chance that the reset was
handled differently, but point taken!

> 
>      Andrew

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor Dooley]

On 05/04/2022 19:06, Andrew Lunn wrote:
>> I tried using the one for the VSC8662 (0007.0660) since that's whats on,
>> the board but that didn't help.
>> Without the revert:
>>
>> [    1.521768] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at
>> 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
>> [    3.206274] macb 20112000.ethernet eth0: PHY
>> [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
>> [    3.216641] macb 20112000.ethernet eth0: configuring for phy/sgmii link
>> mode
>> (and then nothing)
>>
>> If I revert the CONFIG_PM addition:
>>
>> [    1.508882] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at
>> 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
>> [    2.879617] macb 20112000.ethernet eth0: PHY
>> [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
>> [    2.890010] macb 20112000.ethernet eth0: configuring for phy/sgmii link
>> mode
>> [    6.981823] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow
>> control off
>> [    6.989657] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>
>> I will try again tomorrow with "ethernet-phy-id0007.0771" to see if
>> anything changes, since that would use the Microsemi driver rather
>> than the Vitesse driver that VSC8662/0007.0660 uses.
> 
> The numbers here should be the same as what you find in registers 2
> and 3 of the PHY. They identify the manufacture, version and revision
> of the PHY. With a normal probe, these two registers are read, and the
> PHY driver found which says it supports the particular ID. The only
> time you need to actually list the IDs in DT is when you cannot find
> the PHY using the normal probe, generally because its regulator/reset
> is turned off, and only the PHY driver knows how to fix that.
> Chicken/Egg.
> 
> You don't have this issue, you always seem to be able to find the PHY,
> so you don't need these properties.

Good to know.

> Also, using the Microsemi driver for a Vitesse hardware is like using
> the intel i210 Ethernet driver for an amd xgbe Ethernet hardware....

Ehh, not sure that this is the best comparison. Microsemi bought Vitesse
in 2015, and the PHYs supported by the Microsemi driver are all VSC*
products. I was going to try it in the off chance that the reset was
handled differently, but point taken!

> 
>      Andrew

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Russell King (Oracle)]

On Tue, Apr 05, 2022 at 05:58:50PM +0100, Conor Dooley wrote:
> On 05/04/2022 16:53, Russell King (Oracle) wrote:
> > On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
> > > Hey,
> > > I seem to have come across a regression in the default riscv defconfig
> > > between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
> > > c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
> > > machine") which causes the ethernet phy to not come up on my Icicle kit:
> > > [ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
> > > [ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)
> > 
> > I don't think that would be related to the idle driver. This looks like
> > the PHY hasn't filled in the supported mask at probe time - do you have
> > the driver for the PHY built-in or the PHY driver module loaded?
> 
> Hey Russel,
> The idle stuff enabled CONFIG_PM=y though in the default riscv
> defconfig, so it is not confined to just QEMU.
> 
> I am not sure what the symbol for the generic phy & I am not at work
> to properly check, so I hope this is the relevant part of the config:
> 
> CONFIG_PHYLINK=y
> CONFIG_PHYLIB=y
> CONFIG_SWPHY=y
> CONFIG_FIXED_PHY=y

The generic PHY is part of phylib, and will be used whenever phylib
wants to drive a PHY but no specific PHY driver is found at the point
the PHY device is attached in software to a network device.

For reference, that is a very important point to understand:

1) if the PHY driver is a module sitting on the root filesystem, but
the network driver attaches the PHY during boot before the root
filesystem is mounted, then the generic PHY driver will be used.

2) if the PHY driver is a module sitting on the root filesystem, and
the network driver attaches the PHY when the interface is brought up,
that is fine as long as the root filesystem is not network based.

> If you look at my response to Andrew [1] you'll see that my problems
> are not isolated to just the Generic PHY driver as a builtin Vitesse
> driver has issues too (although validation appears to have passed).

I've been catching up with email from the last three and a bit weeks,
so I haven't been reading all the threads before replying... there
will be some duplication between what Andrew and myself have said.

The right thing is certainly to use the Vitesse driver, and get to
the bottom of why the link won't come up when that driver is used.
I think from what I've been reading that it feels like a timing
issue - when cpu idle is enabled, then something affects the PHY
meaning that link never comes up.

The way this works with phylink in SGMII and in-band mode is that we
expect to read the link up/down, speed and duplex parameters from the
MAC/PCS end of the link, and the pause and link parameters from the
PHY. phylink will only report link up in this mode when the PHY and
the MAC/PCS both report that the link is up.

phylink should already contain sufficient debugging to work that out -
it prints at debug level whenever phylib reports a change to the link
parameters, and it also reports when the MAC/PCS triggers a change in
link state. That should be just about enough to work out which end of
the link is failing.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Russell King (Oracle)]

On Tue, Apr 05, 2022 at 05:58:50PM +0100, Conor Dooley wrote:
> On 05/04/2022 16:53, Russell King (Oracle) wrote:
> > On Tue, Apr 05, 2022 at 01:05:12PM +0000, Conor.Dooley@microchip.com wrote:
> > > Hey,
> > > I seem to have come across a regression in the default riscv defconfig
> > > between riscv-for-linus-5.18-mw0 (bbde015227e8) & v5.18-rc1, exposed by
> > > c5179ef1ca0c ("RISC-V: Enable RISC-V SBI CPU Idle driver for QEMU virt
> > > machine") which causes the ethernet phy to not come up on my Icicle kit:
> > > [ 3.179864] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
> > > [ 3.194490] macb 20112000.ethernet eth0: Could not attach PHY (-22)
> > 
> > I don't think that would be related to the idle driver. This looks like
> > the PHY hasn't filled in the supported mask at probe time - do you have
> > the driver for the PHY built-in or the PHY driver module loaded?
> 
> Hey Russel,
> The idle stuff enabled CONFIG_PM=y though in the default riscv
> defconfig, so it is not confined to just QEMU.
> 
> I am not sure what the symbol for the generic phy & I am not at work
> to properly check, so I hope this is the relevant part of the config:
> 
> CONFIG_PHYLINK=y
> CONFIG_PHYLIB=y
> CONFIG_SWPHY=y
> CONFIG_FIXED_PHY=y

The generic PHY is part of phylib, and will be used whenever phylib
wants to drive a PHY but no specific PHY driver is found at the point
the PHY device is attached in software to a network device.

For reference, that is a very important point to understand:

1) if the PHY driver is a module sitting on the root filesystem, but
the network driver attaches the PHY during boot before the root
filesystem is mounted, then the generic PHY driver will be used.

2) if the PHY driver is a module sitting on the root filesystem, and
the network driver attaches the PHY when the interface is brought up,
that is fine as long as the root filesystem is not network based.

> If you look at my response to Andrew [1] you'll see that my problems
> are not isolated to just the Generic PHY driver as a builtin Vitesse
> driver has issues too (although validation appears to have passed).

I've been catching up with email from the last three and a bit weeks,
so I haven't been reading all the threads before replying... there
will be some duplication between what Andrew and myself have said.

The right thing is certainly to use the Vitesse driver, and get to
the bottom of why the link won't come up when that driver is used.
I think from what I've been reading that it feels like a timing
issue - when cpu idle is enabled, then something affects the PHY
meaning that link never comes up.

The way this works with phylink in SGMII and in-band mode is that we
expect to read the link up/down, speed and duplex parameters from the
MAC/PCS end of the link, and the pause and link parameters from the
PHY. phylink will only report link up in this mode when the PHY and
the MAC/PCS both report that the link is up.

phylink should already contain sufficient debugging to work that out -
it prints at debug level whenever phylib reports a change to the link
parameters, and it also reports when the MAC/PCS triggers a change in
link state. That should be just about enough to work out which end of
the link is failing.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor.Dooley]

On 05/04/2022 15:04, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
>> [ 2.828915] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
>> [11.045411] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>> [11.053247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> 
> You have a multi-part link. You need that the PHY reports the line
> side is up. Put some printk in genphy_update_link() and look at
> phydev->link. You also need that the SGMII link between the PHY and
> the SoC is up. That is a bit harder to see, but try adding #define
> DEBUG at the top of phylink.c and phy.c so you get additional debug
> prints for the state machines.

Tracked the state of phydev->link in genphy_update_link, never saw a
value other than 0.

Using the debug prints in phylink.c I got the following:
[    3.230364] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    3.240682] macb 20112000.ethernet eth0: phy: sgmii setting supported 0000000,00000000,000042ff advertising 0000000,00000000,000042ff
[    3.252783] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
[    3.259892] macb 20112000.ethernet eth0: major config sgmii
[    3.265526] macb 20112000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/Unknown/Unknown adv=0000000,00000000,00000000 pause=00 link=0 an=0
[    3.279249] macb 20112000.ethernet eth0: phy link down sgmii/Unknown/Unknown/off

I couldn't see any prints out of phy.c

Thanks,
Conor.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor.Dooley]

On 05/04/2022 15:04, Andrew Lunn wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
>> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
>> [ 2.828915] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
>> [11.045411] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>> [11.053247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> 
> You have a multi-part link. You need that the PHY reports the line
> side is up. Put some printk in genphy_update_link() and look at
> phydev->link. You also need that the SGMII link between the PHY and
> the SoC is up. That is a bit harder to see, but try adding #define
> DEBUG at the top of phylink.c and phy.c so you get additional debug
> prints for the state machines.

Tracked the state of phydev->link in genphy_update_link, never saw a
value other than 0.

Using the debug prints in phylink.c I got the following:
[    3.230364] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
[    3.240682] macb 20112000.ethernet eth0: phy: sgmii setting supported 0000000,00000000,000042ff advertising 0000000,00000000,000042ff
[    3.252783] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
[    3.259892] macb 20112000.ethernet eth0: major config sgmii
[    3.265526] macb 20112000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/Unknown/Unknown adv=0000000,00000000,00000000 pause=00 link=0 an=0
[    3.279249] macb 20112000.ethernet eth0: phy link down sgmii/Unknown/Unknown/off

I couldn't see any prints out of phy.c

Thanks,
Conor.

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor.Dooley]

On 06/04/2022 08:36, Conor Dooley wrote:
> On 05/04/2022 15:04, Andrew Lunn wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>>> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
>>> [ 2.828915] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
>>> [11.045411] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>>> [11.053247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>
>> You have a multi-part link. You need that the PHY reports the line
>> side is up. Put some printk in genphy_update_link() and look at
>> phydev->link. You also need that the SGMII link between the PHY and
>> the SoC is up. That is a bit harder to see, but try adding #define
>> DEBUG at the top of phylink.c and phy.c so you get additional debug
>> prints for the state machines.
> 
> Tracked the state of phydev->link in genphy_update_link, never saw a
> value other than 0.
> 
> Using the debug prints in phylink.c I got the following:
> [    3.230364] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
> [    3.240682] macb 20112000.ethernet eth0: phy: sgmii setting supported 0000000,00000000,000042ff advertising 0000000,00000000,000042ff
> [    3.252783] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
> [    3.259892] macb 20112000.ethernet eth0: major config sgmii
> [    3.265526] macb 20112000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/Unknown/Unknown adv=0000000,00000000,00000000 pause=00 link=0 an=0
> [    3.279249] macb 20112000.ethernet eth0: phy link down sgmii/Unknown/Unknown/off
> 
> I couldn't see any prints out of phy.c

I think I have found the problem. While the SMGII clock is not in
Linux's remit, the mac clocks are. Without CONFIG_PM I see
the following, where 5 represents the clock for MAC1:

[    0.907959] mpfs_periph_clk_enable: 5
[    1.312955] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    2.660376] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
[    2.670400] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
[    6.789474] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off

With CONFIG_PM, the MAC1 clock gets disabled between mac and phy
bringup. 4 is the clock for the other MAC:

[    0.932598] mpfs_periph_clk_enable: 5
[    1.327876] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    1.473632] mpfs_periph_clk_disable: 5
[    1.503327] mpfs_periph_clk_disable: 4
[    2.999528] mpfs_periph_clk_enable: 5
[    3.000300] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
[    3.018612] macb 20112000.ethernet eth0: Could not attach PHY (-22)
[    3.143594] mpfs_periph_clk_disable: 5

However the clock driver is actually not only disabling the clock,
but also putting peripherals into reset when the clock to them is
disabled. Removing the reset gives:

[    0.934717] mpfs_periph_clk_enable: 5
[    1.326564] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    1.473155] mpfs_periph_clk_disable: 5
[    1.502805] mpfs_periph_clk_disable: 4
[    3.006384] mpfs_periph_clk_enable: 5
[    3.007691] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
[    3.021409] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
[    7.114710] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off


Thanks for your help in figuring this out, looks like the problem
is mine to fix :)

Thanks again,
Conor.

Re: riscv defconfig CONFIG_PM/macb/generic PHY regression in v5.18-rc1

[Conor.Dooley]

On 06/04/2022 08:36, Conor Dooley wrote:
> On 05/04/2022 15:04, Andrew Lunn wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>
>>> [ 2.818894] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
>>> [ 2.828915] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
>>> [11.045411] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>>> [11.053247] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>
>> You have a multi-part link. You need that the PHY reports the line
>> side is up. Put some printk in genphy_update_link() and look at
>> phydev->link. You also need that the SGMII link between the PHY and
>> the SoC is up. That is a bit harder to see, but try adding #define
>> DEBUG at the top of phylink.c and phy.c so you get additional debug
>> prints for the state machines.
> 
> Tracked the state of phydev->link in genphy_update_link, never saw a
> value other than 0.
> 
> Using the debug prints in phylink.c I got the following:
> [    3.230364] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Vitesse VSC8662] (irq=POLL)
> [    3.240682] macb 20112000.ethernet eth0: phy: sgmii setting supported 0000000,00000000,000042ff advertising 0000000,00000000,000042ff
> [    3.252783] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
> [    3.259892] macb 20112000.ethernet eth0: major config sgmii
> [    3.265526] macb 20112000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/Unknown/Unknown adv=0000000,00000000,00000000 pause=00 link=0 an=0
> [    3.279249] macb 20112000.ethernet eth0: phy link down sgmii/Unknown/Unknown/off
> 
> I couldn't see any prints out of phy.c

I think I have found the problem. While the SMGII clock is not in
Linux's remit, the mac clocks are. Without CONFIG_PM I see
the following, where 5 represents the clock for MAC1:

[    0.907959] mpfs_periph_clk_enable: 5
[    1.312955] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    2.660376] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
[    2.670400] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
[    6.789474] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off

With CONFIG_PM, the MAC1 clock gets disabled between mac and phy
bringup. 4 is the clock for the other MAC:

[    0.932598] mpfs_periph_clk_enable: 5
[    1.327876] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    1.473632] mpfs_periph_clk_disable: 5
[    1.503327] mpfs_periph_clk_disable: 4
[    2.999528] mpfs_periph_clk_enable: 5
[    3.000300] macb 20112000.ethernet eth0: validation of sgmii with support 0000000,00000000,00006280 and advertisement 0000000,00000000,00004280 failed: -EINVAL
[    3.018612] macb 20112000.ethernet eth0: Could not attach PHY (-22)
[    3.143594] mpfs_periph_clk_disable: 5

However the clock driver is actually not only disabling the clock,
but also putting peripherals into reset when the clock to them is
disabled. Removing the reset gives:

[    0.934717] mpfs_periph_clk_enable: 5
[    1.326564] macb 20112000.ethernet eth0: Cadence GEM rev 0x0107010c at 0x20112000 irq 17 (00:04:a3:4d:4c:dc)
[    1.473155] mpfs_periph_clk_disable: 5
[    1.502805] mpfs_periph_clk_disable: 4
[    3.006384] mpfs_periph_clk_enable: 5
[    3.007691] macb 20112000.ethernet eth0: PHY [20112000.ethernet-ffffffff:09] driver [Generic PHY] (irq=POLL)
[    3.021409] macb 20112000.ethernet eth0: configuring for phy/sgmii link mode
[    7.114710] macb 20112000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off


Thanks for your help in figuring this out, looks like the problem
is mine to fix :)

Thanks again,
Conor.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv