Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1762316pxj; Wed, 19 May 2021 13:20:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx0GjmMC/4avwNfStEJUtt6uN2ASSLi09OTYtojwqiljrhyoVDVvHthcojKX9ZSrsCnQFQd X-Received: by 2002:a02:7f57:: with SMTP id r84mr1145007jac.108.1621455607726; Wed, 19 May 2021 13:20:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621455607; cv=none; d=google.com; s=arc-20160816; b=VE1emcq2EcO0vfviPByrfbZfalbJx3Wjpncb59r+4C0+5PpqDosfO4kHBUvLco+art 6/upIL2inq2sraEnfl7jdFINEqbemjr2G8c4MUucZvD8HStdEPPUGDHvGjW7ZqmiJBpT uwIUNzN05y9FB/J3jUJCP1eR80qOTGdNtw2SC+HI0M0aBazj+os7HomfEm9weaLh/McU /YzzXXreWE2OacbZV4bejfw+tsJrkyUu+mq7svvC6YdFwcVjLiwtqcq266jP127u4IJM MAMExToHJbvoW0cqmzO/E0ovZ0Prfpy28U9JQ/hD2fL+lK8SvoFMCuDWluahctXchyL7 NcYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version; bh=OHUwbXr004AiYdchpIUh+RzrlP3Mfn1ctQFE5A0yCck=; b=FmDWBUbwv13IaC3E0dA9h6kSRPQoEcw573Q5GlKAmPaonqmCA8sEqV+zrqTC7Yvnaw eK+/7Wrfb9U6N8bDA8LfdcVylYwAmOMQFSsItGCcaWLXTiftRfp4LfbLQZxurM2RjqDd Id76IIjDVz7sJ1WKrzpVil5UUysW90X0nQSmh1QpmIn3DQAwTYKa8ADuHngLpqVq4PUP +mBV85ElEG2CVSiF7bCaD02LuXC/R1sBMXUIJQPIm7poJvL1JUBrV/9i2ZNHxikdAz0x KhpyiI7IvyDlVsOETwrQ+e+PrN0tMlFG4Off5HowbgX9C8DqmgWhTcfHGITuMHsF84UV QAUg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o13si608741ilt.118.2021.05.19.13.19.54; Wed, 19 May 2021 13:20:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230252AbhESSSy convert rfc822-to-8bit (ORCPT + 99 others); Wed, 19 May 2021 14:18:54 -0400 Received: from mail-ua1-f51.google.com ([209.85.222.51]:42959 "EHLO mail-ua1-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230363AbhESSSw (ORCPT ); Wed, 19 May 2021 14:18:52 -0400 Received: by mail-ua1-f51.google.com with SMTP id 14so4731898uac.9; Wed, 19 May 2021 11:17:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2rY1yW/YsvOZYFTiuIc2+ehXyRnGQoCM7oBhn+XshDI=; b=fk6eP+41rU/FeynydG46bB4kpyT7GEIseuXdHSTqtvJd6z7CX1p/kkanj3Krv5Nk0H OGlZDIPGlKBs4xPoFFAxcW/KP6DD4PTUOyQ5SLAEeGtcItjKnFWuAVV93WI0yy2mf8g7 uQW9t2wVKKYPKutb74kN3OFbKDq16ySgqo9OXOHqT+t0fZ56rJVX43W9do7lL7dZMWSn UcmpgIVGOUE1tr8yRsyxuB4j6f7NOl8wzqj/8czdSdHfq/puyZbDxyujoh0AHw/roGzT evlAmz1BqXaN5/Qen1GZLLDt0p67MiIiG7gRqYCMBcP8Jj1G41mxWQCElzDb5p7N4Msp x72A== X-Gm-Message-State: AOAM531CQXTOB5UVUst849HhJX47jwwXU7/pDQU62jkxJwSpL2xVmSfi lkx09clmJWQ0CszimT0GiU5dZbvGnQ8PZIGkVvo= X-Received: by 2002:ab0:7705:: with SMTP id z5mr1011167uaq.2.1621448248375; Wed, 19 May 2021 11:17:28 -0700 (PDT) MIME-Version: 1.0 References: <20201209094916.17383-1-zong.li@sifive.com> <87v99qyjaz.fsf@igel.home> <87lfaj7cki.fsf@igel.home> <871rc4on36.fsf@igel.home> <87a6qrk2pw.fsf@igel.home> <874kgyfetu.fsf@igel.home> <87h7kukzy4.fsf@igel.home> <87tuob7n8g.fsf@igel.home> In-Reply-To: From: Geert Uytterhoeven Date: Wed, 19 May 2021 20:17:16 +0200 Message-ID: Subject: Re: [PATCH v7 0/5] clk: add driver for the SiFive FU740 To: Zong Li Cc: Yixun Lan , Andreas Schwab , Paul Walmsley , Palmer Dabbelt , Stephen Boyd , Pragnesh Patel , Albert Ou , Michael Turquette , "linux-kernel@vger.kernel.org List" , linux-clk , linux-riscv Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Zong, On Wed, May 19, 2021 at 5:55 PM Zong Li wrote: > On Tue, May 11, 2021 at 4:57 PM Yixun Lan wrote: > > On Wed, Apr 14, 2021 at 2:25 PM Zong Li wrote: > > > On Mon, Apr 12, 2021 at 7:31 PM Andreas Schwab 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 -- 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