Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CCDAC678D4 for ; Wed, 1 Mar 2023 22:45:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229834AbjCAWph (ORCPT ); Wed, 1 Mar 2023 17:45:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229827AbjCAWpf (ORCPT ); Wed, 1 Mar 2023 17:45:35 -0500 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6111C32524; Wed, 1 Mar 2023 14:45:18 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id C6966CE1E60; Wed, 1 Mar 2023 22:45:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C56AC433D2; Wed, 1 Mar 2023 22:45:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677710715; bh=3mXPGGvNPE55M7kc8dODyu5KJeDpvTT9zpBKLudWDK4=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=Wbv6I/PETUmB4uYc3XdiyHS9xeDU+JQk+SdjgD5UqmLgrr4k+aip74Wpuhr9GMn2b ZaODJsSP4EVOJCNerefdx0zQk0zAYzq/fT4sLUjbLUzzMAsPAUyOto6G0MDGlio5tJ H1F/8O1V15WUaeyJJjWsa9SKcjcy9ByXFlHFp6A4O0TtITb2x3v4U/UgDSI5PUH5f8 czbqxjTFQVerwpno4JdiqJMsOPHKNd/hDANokp1hVXP7kfqiqGpdlETLyJs20UqOW4 qFOqq+83c3TA6jq3qw0yC5lHKPQHW2kPCa94F2F61/xEdjDHWRzeiQF5YzjzEigL7f CGNiPXRoMRsTg== Message-ID: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20230301012506.1401883-1-saravanak@google.com> <31ae9957edf319416d4551f14eba2071.sboyd@kernel.org> <7cca9a24b24d849565cd6a4f40ddbee9.sboyd@kernel.org> Subject: Re: [PATCH v1] clk: Mark a fwnode as initialized when using CLK_OF_DECLARE* macros From: Stephen Boyd Cc: Greg Kroah-Hartman , Michael Turquette , Linus Walleij , kernel-team@android.com, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org To: Saravana Kannan Date: Wed, 01 Mar 2023 14:45:12 -0800 User-Agent: alot/0.10 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Saravana Kannan (2023-03-01 13:25:13) > On Wed, Mar 1, 2023 at 12:48=E2=80=AFPM Stephen Boyd w= rote: > > > > Quoting Stephen Boyd (2023-03-01 12:40:03) > > > Quoting Saravana Kannan (2023-02-28 17:25:06) > > > > The CLK_OF_DECLARE macros sometimes prevent the creation of struct > > > > devices for the device node being handled. It does this by > > > > setting/clearing OF_POPULATED flag. This can block the probing of s= ome > > > > devices because fw_devlink will block the consumers of this node ti= ll a > > > > struct device is created and probed. > > > > > > Why can't you use CLK_OF_DECLARE_DRIVER()? > > > > Ah I misunderstood. CLK_OF_DECLARE() _always_ prevents the creation of a > > struct device for the device node being handled. The 'sometimes' threw > > me off. >=20 > The "sometimes" is because dependending on the macro we go back and > clear the flag. Ok. Maybe instead of this paragraph you can explain the problem being fixed, specifically ux500 container node not being marked as "initialized" and that preventing consumer devices from probing. That would help the reviewer understand the specific problem you're solving. >=20 > > > > > > > > > > > Set the appropriate fwnode flags when these device nodes are initia= lized > > > > by the clock framework and when OF_POPULATED flag is set/cleared. T= his > > > > will allow fw_devlink to handle the dependencies correctly. This is the "what" and not the "why". > > > > How is this different from commit 3c9ea42802a1 ("clk: Mark fwnodes when > > their clock provider is added/removed")? Do you have some user of > > CLK_OF_DECLARE() that isn't registering an OF clk provider? >=20 > So it looks like drivers don't always register the same node used for > CLK_OF_DECLARE() as the clock provider. So, this is covering for the > case when that's not true. Please add this information to the commit text. Otherwise the patch looks entirely unnecessary. If the node used for CLK_OF_DECLARE() isn't the same as the node as the clock provider then how are we certain that the CLK_OF_DECLARE() probe function has actually registered a clk provider? Should we simply remove the calls to fwnode_dev_initialized() in the OF clk provider functions and put the call in CLK_OF_DECLARE() (and specifically _not_ CLK_OF_DECLARE_DRIVER) as this patch does? What about bindings that are registering clks early with CLK_OF_DECLARE_DRIVER() and then probing something like a reset controller later with a platform device created by an MFD matching the same compatible as the CLK_OF_DECLARE_DRIVER() compatible?