Messages in this thread | | | From | Zong Li <> | Date | Fri, 21 May 2021 20:52:35 +0800 | Subject | Re: [PATCH v7 0/5] clk: add driver for the SiFive FU740 |
| |
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
| |