Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp883726pxb; Wed, 27 Oct 2021 14:25:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxlzjiCrDbGpdMd+EugSri776gkKQGoFYI0R7jTlWQxCNQKZ/I/iZ4laZQXCLOatZNltjCY X-Received: by 2002:a17:906:1706:: with SMTP id c6mr46411eje.343.1635369953564; Wed, 27 Oct 2021 14:25:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635369953; cv=none; d=google.com; s=arc-20160816; b=yZOJkEY1buDYH/rqyqt7BALeGgvrg/Hv5FK1xwsJ2zOYZgpge2RSvrNI3KQAdNxN+R hFblivGc/HuxNOU3lRulSG/btQbQqrg6AfN58JoniIKPZ1qZvPulagy8Pu24oHylu30L yIGj3GYWPMQH1+d3/yACR4BO1Js9k0gd+rP26KmezWpDKnCsRoVN9icck76FOuiYEK1M TjjWA37lwdS917QEOr4X7339uT2wB3bRMf3qJMl13Ti73/oFdxcXhu5rGlpPjlIBaB1E 2um2AikM4TFcJAK+oHYLAHDImSVYKeuCeSfhU0QUDyuSSrBiK9jJS9OypBlsKNKTXKF+ qRkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:organization:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=BW72URFNQ5yev2mOcmhByu5pFgdoYEH7M8C27DCiY1o=; b=vhBHTXGFrq5S3xzw9kYMO9xmhbGrevV0Lu1Wv6l1+wXYTbmFSEGaGCpddC82zUvQ+h TBDtWtxrOMVXs6rvliVyZsHBflL48IiXuL6ipLqDqPfJaqyYtb+EPFCxcxrRZGLcr55u 1kvrPK0qO3xlHfis0cvd3B24T2skE8cH8TlFyezlCzEjXv+SiBA4MDdbAetlCrgqhF28 sjWVvJaNPZItDCeS6c5VM6wEmqG06vFbJ+B4qPsirWds6ODGD8eL8YL9bx7YojgB9K3w QXPUQydR45NfrxVls/Qb3LseIohCa8Ik5ZNjyTwCld1nl11v7GVvN0pkYutuKwrKY9Cj a3wA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h15si1229328ejj.98.2021.10.27.14.25.28; Wed, 27 Oct 2021 14:25:53 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241450AbhJ0Kfy (ORCPT + 97 others); Wed, 27 Oct 2021 06:35:54 -0400 Received: from mga02.intel.com ([134.134.136.20]:39239 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232538AbhJ0Kfx (ORCPT ); Wed, 27 Oct 2021 06:35:53 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10149"; a="217302551" X-IronPort-AV: E=Sophos;i="5.87,186,1631602800"; d="scan'208";a="217302551" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2021 03:33:28 -0700 X-IronPort-AV: E=Sophos;i="5.87,186,1631602800"; d="scan'208";a="494749377" Received: from smile.fi.intel.com ([10.237.72.184]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Oct 2021 03:33:21 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1mfgEu-001R9N-7R; Wed, 27 Oct 2021 13:33:00 +0300 Date: Wed, 27 Oct 2021 13:32:59 +0300 From: Andy Shevchenko To: Emil Renner Berthing Cc: Stephen Boyd , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-clk , "open list:GPIO SUBSYSTEM" , linux-riscv , "open list:SERIAL DRIVERS" , Geert Uytterhoeven , Palmer Dabbelt , Paul Walmsley , Rob Herring , Michael Turquette , Thomas Gleixner , Marc Zyngier , Philipp Zabel , Linus Walleij , Greg Kroah-Hartman , Daniel Lezcano , Jiri Slaby , Maximilian Luz , Sagar Kadam , Drew Fustini , Michael Zhu , Fu Wei , Anup Patel , Atish Patra , Linux Kernel Mailing List Subject: Re: [PATCH v2 06/16] clk: starfive: Add JH7100 clock generator driver Message-ID: References: <20211021174223.43310-1-kernel@esmil.dk> <20211021174223.43310-7-kernel@esmil.dk> <163527959276.15791.14765586510805526101@swboyd.mtv.corp.google.com> <163529604399.15791.378104318036812951@swboyd.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 27, 2021 at 12:24:07PM +0200, Emil Renner Berthing wrote: > On Wed, 27 Oct 2021 at 02:54, Stephen Boyd wrote: > > Quoting Emil Renner Berthing (2021-10-26 15:35:36) > > > On Tue, 26 Oct 2021 at 22:20, Stephen Boyd wrote: > > > > Quoting Emil Renner Berthing (2021-10-21 10:42:13) ... > > > > > +static int __init clk_starfive_jh7100_probe(struct platform_device *pdev) > > > > > > > > Drop __init as this can be called after kernel init is over. > > > > > > Oh interesting, I'd like to know when that can happen. The comment for > > > the builtin_platform_driver macro says it's just a wrapper for > > > > I thought this was using module_platform_driver() macro? > > > > > device_initcall. > > > > > > Won't we then need to remove all the __initconst tags too since the > > > probe function walks through jh7100_clk_data which eventually > > > references all __initconst data? > > > > Yes. If it's builtin_platform_driver() it can't be a module/tristate > > Kconfig, in which case all the init markings can stay. > > Yes, it's already bool in the Kconfig file. After looking into this I > think it's better to do like the rockchip drivers and use > builtin_platform_driver_probe to make sure the probe function only > called at kernel init time: > > static struct platform_driver clk_starfive_jh7100_driver = { > .driver = { > .name = "clk-starfive-jh7100", > .of_match_table = clk_starfive_jh7100_match, > .suppress_bind_attrs = true, > }, > }; > builtin_platform_driver_probe(clk_starfive_jh7100_driver, > clk_starfive_jh7100_probe); > > @Andy: is the supress_bind_attrs what you were asking about? Clever chap! :-) Yes, that's what I have in mind. ... > > If it's never going to be a module then don't add any module_* things. > > So does that just mean no MODULE_DEVICE_TABLE or should I also remove > MODULE_DESCRIPTION, MODULE_AUTHOR and MODULE_LICENSE? I'm just double > checking because the rockchip drivers seem to have MODULE_DESCRIPTION > and MODULE_LICENSE lines. You may comment them out. Convert them to comments or so. But in general yes, they are no-ops in such case. -- With Best Regards, Andy Shevchenko