| Message ID | 20201209094916.17383-1-zong.li@sifive.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | clk: add driver for the SiFive FU740 | expand |
On Dez 09 2020, Zong Li wrote: > Add a driver for the SiFive FU740 PRCI IP block, which handles more > clocks than FU540. These patches also refactor the original > implementation by spliting the dependent-code of fu540 and fu740 > respectively. That breaks ethernet on the fu540. Andreas.
On Wed, Mar 17, 2021 at 3:45 AM Andreas Schwab <schwab@linux-m68k.org> wrote: > > On Dez 09 2020, Zong Li wrote: > > > Add a driver for the SiFive FU740 PRCI IP block, which handles more > > clocks than FU540. These patches also refactor the original > > implementation by spliting the dependent-code of fu540 and fu740 > > respectively. > > That breaks ethernet on the fu540. > I would check that, thanks for the report. > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
On Thu, Mar 18, 2021 at 10:07 AM Zong Li <zong.li@sifive.com> wrote: > > On Wed, Mar 17, 2021 at 3:45 AM Andreas Schwab <schwab@linux-m68k.org> wrote: > > > > On Dez 09 2020, Zong Li wrote: > > > > > Add a driver for the SiFive FU740 PRCI IP block, which handles more > > > clocks than FU540. These patches also refactor the original > > > implementation by spliting the dependent-code of fu540 and fu740 > > > respectively. > > > > That breaks ethernet on the fu540. > > > > I would check that, thanks for the report. > Hi Andreas, Could you please point me out how to test the ethernet from your side? I had tried to quick test by using iperf and wget, the ethernet seems to work fine to me. Thanks. > > Andreas. > > > > -- > > Andreas Schwab, schwab@linux-m68k.org > > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > > "And now for something completely different."
HI Zong, Andreas: On Fri, Mar 19, 2021 at 8:21 AM Zong Li <zong.li@sifive.com> wrote: > > On Thu, Mar 18, 2021 at 10:07 AM Zong Li <zong.li@sifive.com> wrote: > > > > On Wed, Mar 17, 2021 at 3:45 AM Andreas Schwab <schwab@linux-m68k.org> wrote: > > > > > > On Dez 09 2020, Zong Li wrote: > > > > > > > Add a driver for the SiFive FU740 PRCI IP block, which handles more > > > > clocks than FU540. These patches also refactor the original > > > > implementation by spliting the dependent-code of fu540 and fu740 > > > > respectively. > > > > > > That breaks ethernet on the fu540. > > > > > > > I would check that, thanks for the report. > > > > Hi Andreas, > > Could you please point me out how to test the ethernet from your side? > I had tried to quick test by using iperf and wget, the ethernet seems > to work fine to me. > I will give it a shot during this weekend, since I'm facing the same issue.. Yixun Lan
On Mär 19 2021, Zong Li wrote:
> Could you please point me out how to test the ethernet from your side?
Please use
<https://github.com/openSUSE/kernel-source/blob/stable/config/riscv64/default>.
Andreas.
Were you able to reproduce the problem? Andreas.
On Wed, Mar 24, 2021 at 6:36 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > Were you able to reproduce the problem? > Hi Andreas, Sorry, I'm not available past few days, I'm just coming back, I would take a look at this again. Could you also let me know which bootloader you used (FSBL or U-boot-SPL)? Thanks. > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
On Mär 25 2021, Zong Li wrote: > take a look at this again. Could you also let me know which bootloader > you used (FSBL or U-boot-SPL)? Thanks. U-Boot SPL Please try this image: http://download.opensuse.org/ports/riscv/tumbleweed/images/openSUSE-Tumbleweed-RISC-V-JeOS-hifiveunleashed.riscv64.raw.xz Andreas.
On Thu, Mar 25, 2021 at 5:22 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > On Mär 25 2021, Zong Li wrote: > > > take a look at this again. Could you also let me know which bootloader > > you used (FSBL or U-boot-SPL)? Thanks. > > U-Boot SPL > > Please try this image: > > http://download.opensuse.org/ports/riscv/tumbleweed/images/openSUSE-Tumbleweed-RISC-V-JeOS-hifiveunleashed.riscv64.raw.xz > Hi Andreas, The following is the result of the test so far. I would continue to see what happened there. 1. Boot on openSUSE-Tumbleweed-RISC-V-JeOS-hifiveunleashed.riscv64.raw.xz w/ plugging ethernet cable - It seems that I encountered a different situation with you, my system hung up and I didn't see the boot message you mentioned yet. [ OK ] Finished Generate issue file for login session. [ OK ] Finished Apply settings from /etc/sysconfig/keyboard. [ OK ] Started User Login Management. [ *** ] (3 of 3) A start job is running for…upplicant service (58s / 1min 51s) [** ] (3 of 3) A start job is running for…cant service (1min 28s / 1min 51s) [ ***] (2 of 3) A start job is running for…cant service (1min 58s / 3min 21s) [ ***] (1 of 3) A start job is running for…cant service (2min 28s / 3min 21s) [** ] (3 of 3) A start job is running for…cant service (2min 58s / 3min 21s) [ *** ] (2 of 3) A start job is running for…cant service (3min 28s / 4min 51s) [ *] (1 of 3) A start job is running for…cant service (3min 58s / 4min 51s) [ *** ] (3 of 3) A start job is running for…cant service (4min 28s / 4min 51s) [*** ] (2 of 3) A start job is running for…cant service (4min 59s / 6min 22s) [ **] (1 of 3) A start job is running for…cant service (5min 29s / 6min 22s) [ *** ] (3 of 3) A start job is running for…cant service (5min 59s / 6min 22s) [* ] (2 of 3) A start job is running for…cant service (6min 29s / 7min 52s) [ *** ] (1 of 3) A start job is running for…cant service (6min 59s / 7min 52s) [ **] (3 of 3) A start job is running for…cant service (7min 29s / 7min 52s) [FAILED] Failed to start wicked AutoIPv4 supplicant service. See 'systemctl status wickedd-auto4.service' for details. [FAILED] Failed to start wicked DHCPv4 supplicant service. See 'systemctl status wickedd-dhcp4.service' for details. [FAILED] Failed to start wicked DHCPv6 supplicant service. See 'systemctl status wickedd-dhcp6.service' for details. Starting wicked network management service daemon... [ **] A start job is running for wicked n…rvice daemon (7min 59s / 9min 22s) [*** ] A start job is running for wicked n…rvice daemon (8min 29s / 9min 22s) [ 603.364988] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 36s! [*** ] A start job is running for wicked n…rvice daemon (8min 59s / 9min 22s) [ 633.444986] BUG: workqueue lockup - pool cpus=1 node=0 flags=0x0 nice=0 stuck for 66s! Stopping Flush Journal to Persistent Storage... [ OK ] Stopped Flush Journal to Persistent Storage. [ OK ] Stopped Journal Service. 2. Boot on kernel image which built by opensuse defconfig with changing CONFIG_MACB to y instead of m - Although I got some problem for mounting the root filesystem on this image now, but I didn't hang up at the message you mentioned, I could go through after macb driver initialization [ 2.350309] libphy: Fixed MDIO Bus: probed [ 2.354476] macb 10090000.ethernet: Registered clk switch 'sifive-gemgxl-mgmt' [ 2.358752] macb 10090000.ethernet: GEM doesn't support hardware ptp. [ 2.361464] libphy: MACB_mii_bus: probed [ 2.366289] macb 10090000.ethernet eth0: Cadence GEM rev 0x10070109 at 0x10090000 irq 16 (70:b3:d5:92:f2:6c) [ 2.375570] e1000e: Intel(R) PRO/1000 Network Driver [ 2.380323] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. [ 2.386338] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ... [ 2.687447] Waiting for root device /dev/mmcblk0p4... 3. I check the patch set of supporting fu740, it shouldn't impact fu540, I'm going to dump and comparing the prci content and give more testing. > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
On Mär 26 2021, Zong Li wrote: > 1. Boot on openSUSE-Tumbleweed-RISC-V-JeOS-hifiveunleashed.riscv64.raw.xz > w/ plugging ethernet cable > - It seems that I encountered a different situation with you, my > system hung up and I didn't see the boot message you mentioned yet. That's exactly the issue. The process is stuck in D. Andreas.
On Fri, Mar 26, 2021 at 5:24 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > On Mär 26 2021, Zong Li wrote: > > > 1. Boot on openSUSE-Tumbleweed-RISC-V-JeOS-hifiveunleashed.riscv64.raw.xz > > w/ plugging ethernet cable > > - It seems that I encountered a different situation with you, my > > system hung up and I didn't see the boot message you mentioned yet. > > That's exactly the issue. The process is stuck in D. > Yes, I could get the network problem by using the defconfig you provided, the system hung up when executing 'ifconfig' immediately after installing macb driver module, the network can work by only reverting the commit 732374a0b440d9a79c8412f318a25cd37ba6f4e2. But the network is fine by using the mainline's defconfig, this is a little bit weird, I will check that and try to find the difference. > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
On Mär 29 2021, Zong Li wrote: > Yes, I could get the network problem by using the defconfig you > provided, the system hung up when executing 'ifconfig' immediately > after installing macb driver module, the network can work by only > reverting the commit 732374a0b440d9a79c8412f318a25cd37ba6f4e2. But the > network is fine by using the mainline's defconfig, this is a little > bit weird, I will check that and try to find the difference. My guess would be that it is an init dependency problem between the phy driver and the clock driver, which causes the clock to be enabled too late. Andreas.
On Mon, Mar 29, 2021 at 6:37 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > On Mär 29 2021, Zong Li wrote: > > > Yes, I could get the network problem by using the defconfig you > > provided, the system hung up when executing 'ifconfig' immediately > > after installing macb driver module, the network can work by only > > reverting the commit 732374a0b440d9a79c8412f318a25cd37ba6f4e2. But the > > network is fine by using the mainline's defconfig, this is a little > > bit weird, I will check that and try to find the difference. > > My guess would be that it is an init dependency problem between the phy > driver and the clock driver, which causes the clock to be enabled too > late. > I found that the gemgxlpll was disabled immediately by power management after macb driver install. The mainline's defconfig doesn't enable CONFIG_PM, so the network is fine on it. The opensuse defconfig enables CONFIG_PM, and the patch 732374a0b440d9a79c8412f318a25cd37ba6f4e2 added the enable/disable callback functions, so the gemgxlpll PLL, I have no idea why power management disable it, I would keep trace it. By the way, I tried to disable CONFIG_PM on oenpsuse defconfig, the system didn't hang anymore, on the contrary, I enable CONFIG_PM on mainline's defconfig, I expect that the system would hang up as well, unfortunately, I cannot boot successfully by just enabling CONFIG_PM easily. > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
On Mär 31 2021, Zong Li wrote: > I found that the gemgxlpll was disabled immediately by power > management after macb driver install. The mainline's defconfig doesn't > enable CONFIG_PM, so the network is fine on it. The opensuse defconfig > enables CONFIG_PM, and the patch > 732374a0b440d9a79c8412f318a25cd37ba6f4e2 added the enable/disable > callback functions, so the gemgxlpll PLL, I have no idea why power > management disable it, I would keep trace it. Does that mean that CONFIG_PM also affects the FU740? Andreas.
On Mon, Apr 12, 2021 at 7:31 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > On Mär 31 2021, Zong Li wrote: > > > I found that the gemgxlpll was disabled immediately by power > > management after macb driver install. The mainline's defconfig doesn't > > enable CONFIG_PM, so the network is fine on it. The opensuse defconfig > > enables CONFIG_PM, and the patch > > 732374a0b440d9a79c8412f318a25cd37ba6f4e2 added the enable/disable > > callback functions, so the gemgxlpll PLL, I have no idea why power > > management disable it, I would keep trace it. > > Does that mean that CONFIG_PM also affects the FU740? > Yes, we got the same problem on the FU740. We are checking the issue. > Andreas. > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different."
On Wed, Apr 14, 2021 at 2:25 PM Zong Li <zong.li@sifive.com> wrote: > > On Mon, Apr 12, 2021 at 7:31 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > > > On Mär 31 2021, Zong Li wrote: > > > > > I found that the gemgxlpll was disabled immediately by power > > > management after macb driver install. The mainline's defconfig doesn't > > > enable CONFIG_PM, so the network is fine on it. The opensuse defconfig > > > enables CONFIG_PM, and the patch > > > 732374a0b440d9a79c8412f318a25cd37ba6f4e2 added the enable/disable > > > callback functions, so the gemgxlpll PLL, I have no idea why power > > > management disable it, I would keep trace it. > > > > Does that mean that CONFIG_PM also affects the FU740? > > > > Yes, we got the same problem on the FU740. We are checking the issue. > Just a mild ping, any progress regarding this issue? Yxun
On Tue, May 11, 2021 at 4:57 PM Yixun Lan <yixun.lan@gmail.com> wrote: > > On Wed, Apr 14, 2021 at 2:25 PM Zong Li <zong.li@sifive.com> wrote: > > > > On Mon, Apr 12, 2021 at 7:31 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > > > > > On Mär 31 2021, Zong Li wrote: > > > > > > > I found that the gemgxlpll was disabled immediately by power > > > > management after macb driver install. The mainline's defconfig doesn't > > > > enable CONFIG_PM, so the network is fine on it. The opensuse defconfig > > > > enables CONFIG_PM, and the patch > > > > 732374a0b440d9a79c8412f318a25cd37ba6f4e2 added the enable/disable > > > > callback functions, so the gemgxlpll PLL, I have no idea why power > > > > management disable it, I would keep trace it. > > > > > > Does that mean that CONFIG_PM also affects the FU740? > > > > > > > Yes, we got the same problem on the FU740. We are checking the issue. > > > Just a mild ping, any progress regarding this issue? Currently, if runtime power management is enabled, macb driver would go to sleep at the end of macb_probe, then the gigabit ethernet PLL would be disabled. During this period of time, the system would hang up if we try to access GEMGXL control registers, it means that we can't access GEMGXL control registers before the gigabit ethernet PLL is resumed again. There are some cases, for example, if we execute the 'ifconfig' command, it would eventually go to the macb_get_status to access GEMGXL control registers and cause the system to hang up. Give more example here, if we execute 'ip link set lo up & ip addr add 127.0.0.1/8 dev lo', it would cause the system to hang up, because these commands would try to query the interfaces and eventually go to macb_get_status as well. However, if we can resume the gigabit ethernet PLL first, such as 'ip link set eth0 up' or 'udhcpc', then everything goes well. I'm trying to figure out if there are some hooks that we can check the PLL status in the macb driver before it actually touches the control registers. If anyone has an idea about that, please feel free to point it out to me, thanks. > > Yxun
Hi Zong, On Wed, May 19, 2021 at 5:55 PM Zong Li <zong.li@sifive.com> wrote: > On Tue, May 11, 2021 at 4:57 PM Yixun Lan <yixun.lan@gmail.com> wrote: > > On Wed, Apr 14, 2021 at 2:25 PM Zong Li <zong.li@sifive.com> wrote: > > > On Mon, Apr 12, 2021 at 7:31 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > > > On Mär 31 2021, Zong Li wrote: > > > > > I found that the gemgxlpll was disabled immediately by power > > > > > management after macb driver install. The mainline's defconfig doesn't > > > > > enable CONFIG_PM, so the network is fine on it. The opensuse defconfig > > > > > enables CONFIG_PM, and the patch > > > > > 732374a0b440d9a79c8412f318a25cd37ba6f4e2 added the enable/disable > > > > > callback functions, so the gemgxlpll PLL, I have no idea why power > > > > > management disable it, I would keep trace it. > > > > > > > > Does that mean that CONFIG_PM also affects the FU740? > > > > > > Yes, we got the same problem on the FU740. We are checking the issue. > > > > > Just a mild ping, any progress regarding this issue? > > Currently, if runtime power management is enabled, macb driver would > go to sleep at the end of macb_probe, then the gigabit ethernet PLL > would be disabled. During this period of time, the system would hang > up if we try to access GEMGXL control registers, it means that we > can't access GEMGXL control registers before the gigabit ethernet PLL > is resumed again. There are some cases, for example, if we execute the Sounds familiar. > 'ifconfig' command, it would eventually go to the macb_get_status to Do you mean mac_get_stats()? macb_get_status() does not exist. > access GEMGXL control registers and cause the system to hang up. Give > more example here, if we execute 'ip link set lo up & ip addr add > 127.0.0.1/8 dev lo', it would cause the system to hang up, because > these commands would try to query the interfaces and eventually go to > macb_get_status as well. However, if we can resume the gigabit > ethernet PLL first, such as 'ip link set eth0 up' or 'udhcpc', then > everything goes well. I'm trying to figure out if there are some hooks > that we can check the PLL status in the macb driver before it actually > touches the control registers. If anyone has an idea about that, > please feel free to point it out to me, thanks. And you cannot call pm_runtime_get_sync(), as this is called from atomic contect. Other drivers avoid accessing the registers while the device is not up, cfr. e.g. commit 7fa2955ff70ce453 ("sh_eth: Fix sleeping function called from invalid context"). Gr{oetje,eeting}s, Geert
On Thu, May 20, 2021 at 2:17 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Zong, > > On Wed, May 19, 2021 at 5:55 PM Zong Li <zong.li@sifive.com> wrote: > > On Tue, May 11, 2021 at 4:57 PM Yixun Lan <yixun.lan@gmail.com> wrote: > > > On Wed, Apr 14, 2021 at 2:25 PM Zong Li <zong.li@sifive.com> wrote: > > > > On Mon, Apr 12, 2021 at 7:31 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > > > > On Mär 31 2021, Zong Li wrote: > > > > > > I found that the gemgxlpll was disabled immediately by power > > > > > > management after macb driver install. The mainline's defconfig doesn't > > > > > > enable CONFIG_PM, so the network is fine on it. The opensuse defconfig > > > > > > enables CONFIG_PM, and the patch > > > > > > 732374a0b440d9a79c8412f318a25cd37ba6f4e2 added the enable/disable > > > > > > callback functions, so the gemgxlpll PLL, I have no idea why power > > > > > > management disable it, I would keep trace it. > > > > > > > > > > Does that mean that CONFIG_PM also affects the FU740? > > > > > > > > Yes, we got the same problem on the FU740. We are checking the issue. > > > > > > > Just a mild ping, any progress regarding this issue? > > > > Currently, if runtime power management is enabled, macb driver would > > go to sleep at the end of macb_probe, then the gigabit ethernet PLL > > would be disabled. During this period of time, the system would hang > > up if we try to access GEMGXL control registers, it means that we > > can't access GEMGXL control registers before the gigabit ethernet PLL > > is resumed again. There are some cases, for example, if we execute the > > Sounds familiar. > > > 'ifconfig' command, it would eventually go to the macb_get_status to > > Do you mean mac_get_stats()? macb_get_status() does not exist. Sorry for the typo, it should be macb_get_stats. > > > access GEMGXL control registers and cause the system to hang up. Give > > more example here, if we execute 'ip link set lo up & ip addr add > > 127.0.0.1/8 dev lo', it would cause the system to hang up, because > > these commands would try to query the interfaces and eventually go to > > macb_get_status as well. However, if we can resume the gigabit > > ethernet PLL first, such as 'ip link set eth0 up' or 'udhcpc', then > > everything goes well. I'm trying to figure out if there are some hooks > > that we can check the PLL status in the macb driver before it actually > > touches the control registers. If anyone has an idea about that, > > please feel free to point it out to me, thanks. > > And you cannot call pm_runtime_get_sync(), as this is called from > atomic contect. Other drivers avoid accessing the registers while > the device is not up, cfr. e.g. commit 7fa2955ff70ce453 ("sh_eth: > Fix sleeping function called from invalid context"). > Thanks for your help. I have done the similar modification by following the patch you provided. I also verified the bug that we use pm_runtime_get_sync there. I'm going to post the fix patch by adding the is_opened flag. Thanks again. > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
On Fri, May 21, 2021 at 6:34 PM Zong Li <zong.li@sifive.com> wrote: > > On Thu, May 20, 2021 at 2:17 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > Hi Zong, > > > > On Wed, May 19, 2021 at 5:55 PM Zong Li <zong.li@sifive.com> wrote: > > > On Tue, May 11, 2021 at 4:57 PM Yixun Lan <yixun.lan@gmail.com> wrote: > > > > On Wed, Apr 14, 2021 at 2:25 PM Zong Li <zong.li@sifive.com> wrote: > > > > > On Mon, Apr 12, 2021 at 7:31 PM Andreas Schwab <schwab@linux-m68k.org> wrote: > > > > > > On Mär 31 2021, Zong Li wrote: > > > > > > > I found that the gemgxlpll was disabled immediately by power > > > > > > > management after macb driver install. The mainline's defconfig doesn't > > > > > > > enable CONFIG_PM, so the network is fine on it. The opensuse defconfig > > > > > > > enables CONFIG_PM, and the patch > > > > > > > 732374a0b440d9a79c8412f318a25cd37ba6f4e2 added the enable/disable > > > > > > > callback functions, so the gemgxlpll PLL, I have no idea why power > > > > > > > management disable it, I would keep trace it. > > > > > > > > > > > > Does that mean that CONFIG_PM also affects the FU740? > > > > > > > > > > Yes, we got the same problem on the FU740. We are checking the issue. > > > > > > > > > Just a mild ping, any progress regarding this issue? > > > > > > Currently, if runtime power management is enabled, macb driver would > > > go to sleep at the end of macb_probe, then the gigabit ethernet PLL > > > would be disabled. During this period of time, the system would hang > > > up if we try to access GEMGXL control registers, it means that we > > > can't access GEMGXL control registers before the gigabit ethernet PLL > > > is resumed again. There are some cases, for example, if we execute the > > > > Sounds familiar. > > > > > 'ifconfig' command, it would eventually go to the macb_get_status to > > > > Do you mean mac_get_stats()? macb_get_status() does not exist. > > Sorry for the typo, it should be macb_get_stats. > > > > > > access GEMGXL control registers and cause the system to hang up. Give > > > more example here, if we execute 'ip link set lo up & ip addr add > > > 127.0.0.1/8 dev lo', it would cause the system to hang up, because > > > these commands would try to query the interfaces and eventually go to > > > macb_get_status as well. However, if we can resume the gigabit > > > ethernet PLL first, such as 'ip link set eth0 up' or 'udhcpc', then > > > everything goes well. I'm trying to figure out if there are some hooks > > > that we can check the PLL status in the macb driver before it actually > > > touches the control registers. If anyone has an idea about that, > > > please feel free to point it out to me, thanks. > > > > And you cannot call pm_runtime_get_sync(), as this is called from > > atomic contect. Other drivers avoid accessing the registers while > > the device is not up, cfr. e.g. commit 7fa2955ff70ce453 ("sh_eth: > > Fix sleeping function called from invalid context"). > > > > Thanks for your help. I have done the similar modification by > following the patch you provided. I also verified the bug that we use > pm_runtime_get_sync there. I'm going to post the fix patch by adding > the is_opened flag. > > Thanks again. I have posted a patch to fix this problem. Many thanks to all in this thread. https://lore.kernel.org/netdev/20210521124859.101012-1-zong.li@sifive.com/T/#u > > > Gr{oetje,eeting}s, > > > > Geert > > > > -- > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > > > In personal conversations with technical people, I call myself a hacker. But > > when I'm talking to journalists I just say "programmer" or something like that. > > -- Linus Torvalds