Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3212359yba; Mon, 22 Apr 2019 23:00:36 -0700 (PDT) X-Google-Smtp-Source: APXvYqzAeE0C3564KZPHqqeUJorOduxHrIVN+sMTh8XTNdMZi03ZAaRML59EnsZy3z3gb3J9CFU4 X-Received: by 2002:a65:5cc8:: with SMTP id b8mr22068876pgt.36.1555999236825; Mon, 22 Apr 2019 23:00:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555999236; cv=none; d=google.com; s=arc-20160816; b=XhjNlP392CEgJ1o02/2DmOPdwqZcBQHUUEC2CAakthBETB/aZ0CWLy1TvHbg7Sxky/ 3gqWTDp+iFpwJQqx7bcIVn4ljiNKEi9CNXOzt2u192Ns+zZsSOKVn0dT0Wm5naHbvLQZ Xmo5NnwhxnFo/JpwJIn9KSbzyDzSToickoejF9QKPK3h4MRTFC3jxsybX5oa+ikCt2Ya CoIm8mUx4oTkKxMU6ya1ErOr7CxIur+bJhSOt1GJAoKTsJzb12I8lsaHz4ukcO5+GUXn MQslLhNB/bGOGTgl9j79PUqRhfBTu/6/5fzABZohkoCGio5IcxmRlk3GZFULKFS5O9Ug +0zQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=JAHOuSwkMWQRDImS/0hAlcZ5D1ol3J3IF1DxYjThZ6Y=; b=gwJuhSiGZuDdo4I4rREn47R49OTD0p/0QZnzw4cHPt/kysBiMLnDW4a7kbJT2nMIWX xT39cxdco3ndLz/30IazBp6tF/kZE4SaxfcgcMEWXK7x+f/EpVcxL6gajNc46FSo6Cp7 fjWF/DVyGaZ+Ew/cuu0+VvL/V3chJjlbrwi1oahO18q/7RPyO6jQtoVAWFDhHSoegW4g VOc7eWS5mjYo5xUggS4AdFzWj6snZNapFfedePReqjA1wQOMyaTEZ6CZYPpzHDtaZvcA ZErGIYrnfMvrZhpIODAWKFFZ7FnB4MpVrL3I8cJLfFkolfVdsWiak6PKBgQgFrDeKAM9 ek2w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u13si13460399pgr.456.2019.04.22.23.00.20; Mon, 22 Apr 2019 23:00:36 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726004AbfDWF7a (ORCPT + 99 others); Tue, 23 Apr 2019 01:59:30 -0400 Received: from mga03.intel.com ([134.134.136.65]:51115 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725916AbfDWF7a (ORCPT ); Tue, 23 Apr 2019 01:59:30 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Apr 2019 22:59:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,384,1549958400"; d="scan'208";a="153088247" Received: from rzhang-dell-9360.sh.intel.com ([10.239.161.125]) by orsmga002.jf.intel.com with ESMTP; 22 Apr 2019 22:59:27 -0700 Message-ID: <1555999165.26198.39.camel@intel.com> Subject: Re: [PATCH 3/7] thermal/drivers/core: Add init section table for self-encapsulation From: Zhang Rui To: Daniel Lezcano , edubezval@gmail.com Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Arnd Bergmann , "open list:GENERIC INCLUDE/ASM HEADER FILES" Date: Tue, 23 Apr 2019 13:59:25 +0800 In-Reply-To: References: <20190402161256.11044-1-daniel.lezcano@linaro.org> <20190402161256.11044-3-daniel.lezcano@linaro.org> <1555922585.26198.19.camel@intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Daniel, thanks for clarifying. It is true that we need to make thermal framework ready as early as possible. And a static table works for me as long as vmlinux.lds.h is the proper place. Arnd, are you okay with this patch? if yes, I suppose I can take it through my tree, right? thanks, rui On 一, 2019-04-22 at 14:11 +0200, Daniel Lezcano wrote: > Hi Zhang, > > > On 22/04/2019 10:43, Zhang Rui wrote: > > > > Hi, Daniel, > > > > Thanks for the patches, it looks good to me except this one and > > patch > > 4/7. > > > > First, I don't think this is a cyclic dependency issue as they are > > in > > the same module. > The governors have to export their [un]register functions in order to > have the core to use them. > > The core has to export the [un]register function in order to have the > governors to use them. > > From my point of view it is a cyclic dependency. In any other > subsystems, the plugins/governor/drivers/whatever don't have to > export > their functions to the core, they use the core's exported functions. > > > > > Second, I have not read include/asm-generic/vmlinux.lds.h before, > > it > > seems that it is used for architecture specific stuff. Fix a > > thermal > > issue in this way seems overkill to me. > It is not architecture specific, it belongs to asm-generic. All init > calls are defined in it and more. It is a common way to define static > tables from different files without adding dependency and unload it > after init. > > All clk, timers, acpi tables, irq chip, cpuidle and cpu methods are > defined this way. > > When the thermal_core.c uses at the end fs_initcall it uses the same > mechanism. > > > > > > IMO, to make the code clean, we can build the governors as separate > > modules just like we do for cpu governors. > > This brings to the old commit 80a26a5c22b9("Thermal: build thermal > > governors into thermal_sys module"), and that was introduced to fix > > a > > problem when CONFIG_THERMAL is set to 'm'. So I think we can switch > > back to the old way as the problem is gone now. > > > > what do you think? > IMO, having the governors built as module is not a good thing because > the SoC needs the governor to be ready as soon as possible at boot > time. > I've been told some boards reboot at boot time because the governor > comes too late with the userspace governor for example. > > If you don't like the vmlinuz.lds.h approch (but again it is a common > way to initialize table and I wrote it to extend to more thermal > table > in the future) we can change the thermal core to replace > fs_initcall() > by core_initcall() and use postcore_initcall() in the governor. > > > > > > > Patch 1,2,5,6,7 applied first. > > > > thanks, > > rui > > > > On 二, 2019-04-02 at 18:12 +0200, Daniel Lezcano wrote: > > > > > > Currently the governors are declared in their respective files > > > but > > > they > > > export their [un]register functions which in turn call the > > > [un]register > > > the governors core's functions. That implies a cyclic dependency > > > which is > > > not desirable. There is a way to self-encapsulate the governors > > > by > > > letting > > > them to declare themselves in a __init section table. > > > > > > Define the table in the asm generic linker description like the > > > other > > > tables and provide the specific macros to deal with. > > > > > > Signed-off-by: Daniel Lezcano > > > --- > > >  drivers/thermal/thermal_core.h    | 16 ++++++++++++++++ > > >  include/asm-generic/vmlinux.lds.h | 11 +++++++++++ > > >  2 files changed, 27 insertions(+) > > > > > > diff --git a/drivers/thermal/thermal_core.h > > > b/drivers/thermal/thermal_core.h > > > index 0df190ed82a7..28d18083e969 100644 > > > --- a/drivers/thermal/thermal_core.h > > > +++ b/drivers/thermal/thermal_core.h > > > @@ -15,6 +15,22 @@ > > >  /* Initial state of a cooling device during binding */ > > >  #define THERMAL_NO_TARGET -1UL > > >   > > > +/* Init section thermal table */ > > > +extern struct thermal_governor * __governor_thermal_table[]; > > > +extern struct thermal_governor * __governor_thermal_table_end[]; > > > + > > > +#define THERMAL_TABLE_ENTRY(table, name) > > > \ > > > +        static typeof(name) * __thermal_table_entry_##name > > > \ > > > + __used __section(__##table##_thermal_table) > > > \ > > > + = &name; > > > + > > > +#define THERMAL_GOVERNOR_DECLARE(name) THERMAL_TABLE_ENTR > > > Y(go > > > vernor, name) > > > + > > > +#define for_each_governor_table(__governor) \ > > > + for (__governor = __governor_thermal_table; \ > > > +      __governor < __governor_thermal_table_end; \ > > > +      __governor++) > > > + > > >  /* > > >   * This structure is used to describe the behavior of > > >   * a certain cooling device on a certain trip point > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm- > > > generic/vmlinux.lds.h > > > index f8f6f04c4453..9893a3ed242a 100644 > > > --- a/include/asm-generic/vmlinux.lds.h > > > +++ b/include/asm-generic/vmlinux.lds.h > > > @@ -239,6 +239,16 @@ > > >  #define ACPI_PROBE_TABLE(name) > > >  #endif > > >   > > > +#ifdef CONFIG_THERMAL > > > +#define THERMAL_TABLE(name) > > > > > > \ > > > +        . = ALIGN(8); > > > \ > > > +        __##name##_thermal_table = .; > > > \ > > > +        KEEP(*(__##name##_thermal_table)) > > > > > > \ > > > +        __##name##_thermal_table_end = .; > > > +#else > > > +#define THERMAL_TABLE(name) > > > +#endif > > > + > > >  #define KERNEL_DTB() > > > > > > \ > > >   STRUCT_ALIGN(); > > > \ > > >   __dtb_start = .; > > > \ > > > @@ -609,6 +619,7 @@ > > >   IRQCHIP_OF_MATCH_TABLE() > > > \ > > >   ACPI_PROBE_TABLE(irqchip) > > > > > > \ > > >   ACPI_PROBE_TABLE(timer) > > > \ > > > + THERMAL_TABLE(governor) > > > \ > > >   EARLYCON_TABLE() > > > \ > > >   LSM_TABLE() > > >   >