[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ea956f88-e627-3485-e20f-d050499eae10@linaro.org>
Date: Tue, 4 Jan 2022 09:57:08 +0100
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: rjw@...ysocki.net, lukasz.luba@....com, robh@...nel.org,
heiko@...ech.de, arnd@...aro.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
"open list:GENERIC INCLUDE/ASM HEADER FILES"
<linux-arch@...r.kernel.org>
Subject: Re: [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init
to data section
Hi Ulf,
thanks for your comments
On 31/12/2021 14:33, Ulf Hansson wrote:
> On Sat, 18 Dec 2021 at 14:00, Daniel Lezcano <daniel.lezcano@...aro.org> wrote:
>>
>> The dtpm table is used to let the different dtpm backends to register
>> their setup callbacks in a single place and preventing to export
>> multiple functions all around the kernel. That allows the dtpm code to
>> be self-encapsulated.
>
> Well, that's not entirely true. The dtpm code and its backends (or
> ops, whatever we call them) are already maintained from a single
> place, the /drivers/powercap/* directory. I assume we intend to keep
> it like this going forward too, right?
Hopefully we can add more devices like the battery or the backlight, but
I'm not sure they will be in drivers/powercap.
> That is also what patch4 with the devfreq backend continues to conform to.
>
>>
>> The dtpm hierarchy will be passed as a parameter by a platform
>> specific code and that will lead to the creation of the different dtpm
>> nodes.
>>
>> The function creating the hierarchy could be called from a module at
>> init time or when it is loaded. However, at this moment the table is
>> already freed as it belongs to the init section and the creation will
>> lead to a invalid memory access.
>>
>> Fix this by moving the table to the data section.
>
> With the above said, I find it a bit odd to put a table in the data
> section like this. Especially, since the only remaining argument for
> why, is to avoid exporting functions, which isn't needed anyway.
>
> I mean, it would be silly if we should continue to put subsystem
> specific tables in here, to just let them contain a set of subsystem
> specific callbacks.
Do you have an alternative without introducing cyclic dependencies ?
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
>
> Kind regards
> Uffe
>
>> ---
>> include/asm-generic/vmlinux.lds.h | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
>> index 42f3866bca69..50d494d94d6c 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.h
>> @@ -362,7 +362,8 @@
>> BRANCH_PROFILE() \
>> TRACE_PRINTKS() \
>> BPF_RAW_TP() \
>> - TRACEPOINT_STR()
>> + TRACEPOINT_STR() \
>> + DTPM_TABLE()
>>
>> /*
>> * Data section helpers
>> @@ -723,7 +724,6 @@
>> ACPI_PROBE_TABLE(irqchip) \
>> ACPI_PROBE_TABLE(timer) \
>> THERMAL_TABLE(governor) \
>> - DTPM_TABLE() \
>> EARLYCON_TABLE() \
>> LSM_TABLE() \
>> EARLY_LSM_TABLE() \
>> --
>> 2.25.1
>>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists