Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2797643imm; Fri, 20 Jul 2018 05:14:13 -0700 (PDT) X-Google-Smtp-Source: AAOMgpc5mlLUXLzy+d6qUyQ6vS4sa4UhoNA1TjLZhkcfyMXIrKEHXvgRIvnDvOxMGHODW8EBMCAf X-Received: by 2002:a63:9a01:: with SMTP id o1-v6mr1824792pge.439.1532088853395; Fri, 20 Jul 2018 05:14:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532088853; cv=none; d=google.com; s=arc-20160816; b=ZhT+FqyNU4mXyuQHfiw9xj2csdJMOdJyDTVIEtg7oOv2mt+E8A1u2dINQrKK7hGOyz uT1qWDUQhFwdirQMxO9xXGrqA5QzvRZPYnZQTeor2vnwaCkNn5Y3/Fdb9zJmRiedIwlm 4E1Pp711kzH8mCGVbv/1KFoRQQnuFnLMSMf+Cr7YiAuqDzHuzN7LAkFiV1DTGIuJxG3L YigWywV1YoES63WJheRPXXPzSOvYftrKTRzLeK3KxjnhB1WUa0wRdaU2OJfm5FkbEmyu yBKBkVWZx+vFUaiIJWWk+xypHiiEsMwRmMt8ISls7fff7sfQmhNY4x4ZHqQgXSIaGQkT Q5PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:arc-authentication-results; bh=ezACFng6wnNK/UZDF+TEnLrEQ27l/0mTQzufK1GgAVA=; b=TVt7canAxPsH8omQIywXIYCes08nhOwDy9XweSTECxj0zCoJU+qN7dOA/kJh6vwCVE KCcD+akZ0lyAHcky4RvDFKVSATr9Uc2zzbpPNt+zl/kct1nyOvj8E/AX5kZd7oJma0Gz /fPezi14P6KJx6sL6MzSD+fVJXCpootb/DIqy2HBM+p5Ch96fMBLJh9wrbjep2fNa9YD XZQPHI2OIKDazGdsC2OqcL57MpmVj7y1F86c9vRn92CDAQc29BwskjtI9vcHC8EahD+6 DqR0u8szJYMFu1l6z+Igxn8ecPvd9rhxLiKLmgN4qFEhPEM1HAYIHYUUwGZGMbqiG1Ev 6TxQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d24-v6si1721711pfb.262.2018.07.20.05.13.58; Fri, 20 Jul 2018 05:14:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728409AbeGTNAj (ORCPT + 99 others); Fri, 20 Jul 2018 09:00:39 -0400 Received: from mail-vk0-f65.google.com ([209.85.213.65]:44112 "EHLO mail-vk0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727755AbeGTNAj (ORCPT ); Fri, 20 Jul 2018 09:00:39 -0400 Received: by mail-vk0-f65.google.com with SMTP id 125-v6so5951423vke.11; Fri, 20 Jul 2018 05:12:42 -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; bh=ezACFng6wnNK/UZDF+TEnLrEQ27l/0mTQzufK1GgAVA=; b=amnx2mBZgO5pSMOHOd17DWhdvWU+Eu668++ObVEYoT5LrrurG7CAwduk/kO4qYFKMD QRinhQj8ZrcrxnAzkVMIcsO0032/QAD/HoG2OP63FtyQGZKFUAQlJiUi/WizxfkfE5nI ohWK2bRBvj+gsJllJofzmz/60PfJNX6MsnfC08FNUgy/7g//iTC2MQfGibxel+pnhrpG D7rB+UxHs37aSt3f0LJMbSGLycvmOq78w545Pca5z2dNx1MMWHZATt3Y1RcgHdftG+qf RIfNuFCaPi1ZUKP/kbx5ohtvu6p+AmSrZ76Uoq+3OWqsOlSFugrIhwp70DbxSyKST7XN 6enw== X-Gm-Message-State: AOUpUlGwZE8yfjSxd65IqRN6KgwyduX06JagALro0BzUxhez0ljzPW0r YXM2FrCkODCMSpwO35DI4pa/ZgEnvBixJxH8u9g= X-Received: by 2002:a1f:6b11:: with SMTP id g17-v6mr989639vkc.82.1532088762104; Fri, 20 Jul 2018 05:12:42 -0700 (PDT) MIME-Version: 1.0 References: <1531924476-23261-1-git-send-email-phil.edworthy@renesas.com> In-Reply-To: From: Geert Uytterhoeven Date: Fri, 20 Jul 2018 14:12:29 +0200 Message-ID: Subject: Re: [PATCH] clk: renesas: r9a06g032: Avoid needless probe deferring To: Phil Edworthy Cc: Simon Horman , linux-clk , Linux Kernel Mailing List , Linux-Renesas Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Phil, On Fri, Jul 20, 2018 at 2:06 PM Phil Edworthy wrote: > On 20 July 2018 12:21, Geert Uytterhoeven wrote: > > On Wed, Jul 18, 2018 at 4:34 PM Phil Edworthy wrote: > > > To avoid all SoC peripheral drivers deferring their probes, both clock > > > and pinctrl drivers should already be probed. Since the pinctrl driver > > > requires a clock to access the registers, the clock driver should be > > > probed before the pinctrl driver. > > > > > > Therefore, move the clock driver from subsys_initcall to core_initcall. > > > > > > Signed-off-by: Phil Edworthy > > > > Thanks for your patch! > Thanks for your review! > > > The (not yet upstreamed) pinctrl driver uses postcore_initcall(), right? > No, the pinctrl driver uses subsys_initcall, but postcore_initcall or > arch_initcall may be better to make it clear about the dependencies. if the pinctrl driver uses subsys_initcall(), ... > > > --- a/drivers/clk/renesas/r9a06g032-clocks.c > > > +++ b/drivers/clk/renesas/r9a06g032-clocks.c > > > @@ -877,17 +877,18 @@ static const struct of_device_id > > r9a06g032_match[] = { > > > { } > > > }; > > > > > > -static struct platform_driver r9a06g032_clock_driver = { > > > +static struct platform_driver r9a06g032_clock_driver __refdata = { > > > .driver = { > > > .name = "renesas,r9a06g032-sysctrl", > > > .of_match_table = r9a06g032_match, > > > }, > > > + .probe = r9a06g032_clocks_probe, > > > }; > > > > > > static int __init r9a06g032_clocks_init(void) { > > > - return platform_driver_probe(&r9a06g032_clock_driver, > > > - r9a06g032_clocks_probe); > > > + platform_driver_register(&r9a06g032_clock_driver); > > > + return 0; > That should be: > + return platform_driver_register(&r9a06g032_clock_driver); > > > > } > > > > Why are all of the above changes needed? > > Shouldn't the platform_driver_probe() keep on working? > > If it does not, it means the clock driver has some other dependency, and > > cannot be bound immediately. This is potentially a dangerous situation, as > > r9a06g032_clocks_probe() is __init, but can still be called at any time later. > > Hence using platform_driver_probe() is the safe thing to do, possibly with a > > different reshuffling of the clock and pinctrl initcall priorities. > No, you cannot call platform_driver_probe() from core_initcall. > All drivers that are in core_initcall call platform_driver_register(). Hence they cannot have their probe function __init. > > Thanks > Phil > > > > -subsys_initcall(r9a06g032_clocks_init); > > > +core_initcall(r9a06g032_clocks_init); ... using postcore_initcall() or arch_initcall() here, should work with platform_driver_probe()? 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