Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3068522yba; Sun, 28 Apr 2019 16:24:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqyT2brHphfewObVb0977irwoxv5ncYBrcbrRpQZxHusqK/cx5sFZodgKSPap7l2yv+ThEbt X-Received: by 2002:aa7:991b:: with SMTP id z27mr32285358pff.168.1556493871408; Sun, 28 Apr 2019 16:24:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556493871; cv=none; d=google.com; s=arc-20160816; b=VySEPb/PYCz39xyAvPTysLKTDthsTBckg6cF9Bb2REaX7+UEcEaYJIBWDScoLuXVuf d2aFssErucEsf+ETvOIrc9nuAPv6nLZ6rxxeFTi7XJw1scfxoNA8e/qJPn7LtQzoF1Ii T9GLbor1ZCr9kMVf2t/EC6GQ1DLb4+k1YF90NWOX4492L61cUTXL8OCCYGxt/tEAgDwf ivj4m+eEwLDDL36g0cVgRPR9ELgihwSGe1cqV/PnEatDNRhg1vG004S6Zfmeio3gNX/U DnbfdJUWw0t4H1QAI61VEGF02+cCb9/MJWmnE6vQg1iggd5WJOCa46qNXETGQq/VEJ56 XZZw== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=sFibqTzckd76beem9F5bCskmi7SB/Bj+0SdWxridQMM=; b=XSlb6lzET4FnVmjUU3qGQz2/SR+vq8FVPC9Zpr5/g/R5B5UOZVAP2ycoeueJ8cOHua j3JpwNdl3KDeZBZcHZpmUzQanKmc9P8sCcjbdo1hqeIOjK8UcsODKcupoXM8q9D/2WkD Lslp5DBW94kjsQai9rDUW7Ohx8DGdzEM5jvFlTV4nbuqbq07aFajPQzbrmxgW4Py9ceJ /SHOWRgR/wCDWuBYCzpicmdulxqF79UOcRZV4vJNaTbii1zKcvJnc263zEON3apknaTY /69JEzz8A/HdpZ/xxN1hx3NgCkctzLxSaITlreIxB3LlzB4I716MY/JMQAIu0pmtHpTZ sCOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=sNaFnAv+; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 30si23999523pgo.5.2019.04.28.16.24.16; Sun, 28 Apr 2019 16:24:31 -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; dkim=pass header.i=@linaro.org header.s=google header.b=sNaFnAv+; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726618AbfD1XX1 (ORCPT + 99 others); Sun, 28 Apr 2019 19:23:27 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:35519 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726544AbfD1XX1 (ORCPT ); Sun, 28 Apr 2019 19:23:27 -0400 Received: by mail-wm1-f66.google.com with SMTP id y197so12976051wmd.0 for ; Sun, 28 Apr 2019 16:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sFibqTzckd76beem9F5bCskmi7SB/Bj+0SdWxridQMM=; b=sNaFnAv+mR9LPXBttWPjaMs42DQrViVwbahxcKH2g+lH/u6XmrHZpSTSMv/7Pqme15 kG9zyev1TVbYrvlWymonLMmDcult6Urp0lzGhFtiS7y431KBwcjOVjRo6irPrCxQAnmu TFOfCdj2JAaZPfdxgI2GDBzSZ7dPq5t1MwMYLdaXsTyqftO/8KW7vt16U+vSxVnX5u1v l7YHqGUQHV8Op1u3U65xQEnU4CQcsc/MhkQBM9Ovs2GxsFBWjcrjlAQ2Mi+UQVXPNFyx l1CA4j0HrERevFRyRWGTOWgID9nf2Jq721r/xC+v+M1ojkWyQhq9nJRr2or9La2uug2+ iMAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sFibqTzckd76beem9F5bCskmi7SB/Bj+0SdWxridQMM=; b=Xx513IUaHw5Yv8K1jR87yyCr2J6MojDkDRrV+IBxPqyE35dGbC1Yn59Njgm51V2LX5 mACISnvevXGcQ5DrAndJJzUJOTp0d02shCQ9qFZQbF3Orfkmk5mb8jXgKFvv48mkEnve tng8vD8MkxGbUj9ZzMYnOD0znJxP4/1o7ztOa/AYfBxLamwCMTW0KfypdhaHmMM9YWuj RhSlCoueFIn2ssSNIf1ew1MO7+J6epBAj4RQSYMM6zUkaAc0gNtH6FXx8AcD3kMkRKdG Mx4t2BsGgPP6k7mn/RkqXaY4HjPxh7ToFxug9PcWJeCqeezpjnfQmKN14MZSV1dBT+KM MnTg== X-Gm-Message-State: APjAAAUKI3/ic+F+wCVwYs0C4NSRc8MsmEdCgTaCbHIodpMNIA1TRgAZ 2deExE+fvcuyKC/6spInCnrgLg== X-Received: by 2002:a05:600c:204d:: with SMTP id p13mr39185wmg.53.1556493804055; Sun, 28 Apr 2019 16:23:24 -0700 (PDT) Received: from [192.168.0.41] (86.204.129.77.rev.sfr.net. [77.129.204.86]) by smtp.googlemail.com with ESMTPSA id u189sm42326728wme.25.2019.04.28.16.23.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Apr 2019 16:23:22 -0700 (PDT) Subject: Re: [PATCH 3/7] thermal/drivers/core: Add init section table for self-encapsulation To: Arnd Bergmann Cc: Zhang Rui , edubezval@gmail.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, "open list:GENERIC INCLUDE/ASM HEADER FILES" References: <20190402161256.11044-1-daniel.lezcano@linaro.org> <20190402161256.11044-3-daniel.lezcano@linaro.org> <1555922585.26198.19.camel@intel.com> <1555999165.26198.39.camel@intel.com> From: Daniel Lezcano Message-ID: <2c0bc40d-328a-fc96-73da-9d65fee253fb@linaro.org> Date: Mon, 29 Apr 2019 01:23:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <1555999165.26198.39.camel@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/04/2019 07:59, Zhang Rui wrote: > 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? Arnd? > 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() >>>>   >> -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog