Re: [PATCH 3/7] thermal/drivers/core: Add init section table for self-encapsulation

[Zhang Rui]

On ä, 2019-05-03 at 22:28 +0200, Daniel Lezcano wrote:
> 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?
> Hi Zhang,
> 
> given the Acked-by from Arnd, will you add the missing patches in the
> tree for 5.2?
> 
I got a lot of checkpatch warnings when applying this patch.
"total: 9 errors, 6 warnings, 45 lines checked"
please resend with those errors/warnings addressed.

I don't think I will include it in the pull request for this merge
window. But I will try to queue them for -rc2 as cleanups.

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 <daniel.lezcano@xxxxxxxxxx>
> > > > > ---
> > > > > Â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()
> > > > > Â
>