* [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section [not found] <20211218130014.4037640-1-daniel.lezcano@linaro.org> @ 2021-12-18 13:00 ` Daniel Lezcano 2021-12-31 13:33 ` Ulf Hansson 0 siblings, 1 reply; 6+ messages in thread From: Daniel Lezcano @ 2021-12-18 13:00 UTC (permalink / raw) To: daniel.lezcano, rjw Cc: lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm, ulf.hansson, Arnd Bergmann, open list:GENERIC INCLUDE/ASM HEADER FILES 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. 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. Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> --- 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section 2021-12-18 13:00 ` [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section Daniel Lezcano @ 2021-12-31 13:33 ` Ulf Hansson 2022-01-04 8:57 ` Daniel Lezcano 2022-01-07 13:15 ` Daniel Lezcano 0 siblings, 2 replies; 6+ messages in thread From: Ulf Hansson @ 2021-12-31 13:33 UTC (permalink / raw) To: Daniel Lezcano Cc: rjw, lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm, Arnd Bergmann, open list:GENERIC INCLUDE/ASM HEADER FILES On Sat, 18 Dec 2021 at 14:00, Daniel Lezcano <daniel.lezcano@linaro.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? 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. > > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section 2021-12-31 13:33 ` Ulf Hansson @ 2022-01-04 8:57 ` Daniel Lezcano 2022-01-07 13:15 ` Daniel Lezcano 1 sibling, 0 replies; 6+ messages in thread From: Daniel Lezcano @ 2022-01-04 8:57 UTC (permalink / raw) To: Ulf Hansson Cc: rjw, lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm, Arnd Bergmann, open list:GENERIC INCLUDE/ASM HEADER FILES 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@linaro.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@linaro.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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section 2021-12-31 13:33 ` Ulf Hansson 2022-01-04 8:57 ` Daniel Lezcano @ 2022-01-07 13:15 ` Daniel Lezcano 2022-01-07 14:49 ` Ulf Hansson 1 sibling, 1 reply; 6+ messages in thread From: Daniel Lezcano @ 2022-01-07 13:15 UTC (permalink / raw) To: Ulf Hansson Cc: rjw, lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm, Arnd Bergmann, open list:GENERIC INCLUDE/ASM HEADER FILES On 31/12/2021 14:33, Ulf Hansson wrote: > On Sat, 18 Dec 2021 at 14:00, Daniel Lezcano <daniel.lezcano@linaro.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? > > 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. So I tried to change the approach and right now I was not able to find an alternative keeping the code self-encapsulate and without introducing cyclic dependencies. I suggest to keep the patch as it is and double check if it makes sense to change it after adding more dtpm backends Alternatively I can copy the table to a dynamically allocated table. >> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section 2022-01-07 13:15 ` Daniel Lezcano @ 2022-01-07 14:49 ` Ulf Hansson 2022-01-10 13:33 ` Daniel Lezcano 0 siblings, 1 reply; 6+ messages in thread From: Ulf Hansson @ 2022-01-07 14:49 UTC (permalink / raw) To: Daniel Lezcano Cc: rjw, lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm, Arnd Bergmann, open list:GENERIC INCLUDE/ASM HEADER FILES On Fri, 7 Jan 2022 at 14:15, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: > > On 31/12/2021 14:33, Ulf Hansson wrote: > > On Sat, 18 Dec 2021 at 14:00, Daniel Lezcano <daniel.lezcano@linaro.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? > > > > 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. > > So I tried to change the approach and right now I was not able to find > an alternative keeping the code self-encapsulate and without introducing > cyclic dependencies. > > I suggest to keep the patch as it is and double check if it makes sense > to change it after adding more dtpm backends > > Alternatively I can copy the table to a dynamically allocated table. I am not sure I understand the problem. You don't need a "table of callbacks" at all, at least to start with. Instead, what you need is to make a call to a function, or actually one call per supported dtpm type from dtpm_setup_dt() (introduced in patch2). For CPUs, you would simply call dtpm_cpu_setup() (introduced in patch3) from dtpm_setup_dt(), rather than walking the dtpm table an invoking the ->setup() callback. Did that make sense to you? Going forward, when we decide to introduce the option to add/remove support for dtpm types dynamically, you can then convert to a dynamically allocated table. [...] Kind regards Uffe ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section 2022-01-07 14:49 ` Ulf Hansson @ 2022-01-10 13:33 ` Daniel Lezcano 0 siblings, 0 replies; 6+ messages in thread From: Daniel Lezcano @ 2022-01-10 13:33 UTC (permalink / raw) To: Ulf Hansson Cc: rjw, lukasz.luba, robh, heiko, arnd, linux-kernel, linux-pm, Arnd Bergmann, open list:GENERIC INCLUDE/ASM HEADER FILES On 07/01/2022 15:49, Ulf Hansson wrote: > On Fri, 7 Jan 2022 at 14:15, Daniel Lezcano <daniel.lezcano@linaro.org> wrote: >> >> On 31/12/2021 14:33, Ulf Hansson wrote: >>> On Sat, 18 Dec 2021 at 14:00, Daniel Lezcano <daniel.lezcano@linaro.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? >>> >>> 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. >> >> So I tried to change the approach and right now I was not able to find >> an alternative keeping the code self-encapsulate and without introducing >> cyclic dependencies. >> >> I suggest to keep the patch as it is and double check if it makes sense >> to change it after adding more dtpm backends >> >> Alternatively I can copy the table to a dynamically allocated table. > > I am not sure I understand the problem. You don't need a "table of > callbacks" at all, at least to start with. > > Instead, what you need is to make a call to a function, or actually > one call per supported dtpm type from dtpm_setup_dt() (introduced in > patch2). > > For CPUs, you would simply call dtpm_cpu_setup() (introduced in > patch3) from dtpm_setup_dt(), rather than walking the dtpm table an > invoking the ->setup() callback. > > Did that make sense to you? Yeah, I already got the point ;) I'll convert it to something else, and we will see in the future if that needs to be converted back to the table. > Going forward, when we decide to introduce the option to add/remove > support for dtpm types dynamically, you can then convert to a > dynamically allocated table. > > [...] > > Kind regards > Uffe > -- <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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-01-10 13:33 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20211218130014.4037640-1-daniel.lezcano@linaro.org>
2021-12-18 13:00 ` [PATCH v5 1/6] powercap/drivers/dtpm: Move dtpm table from init to data section Daniel Lezcano
2021-12-31 13:33 ` Ulf Hansson
2022-01-04 8:57 ` Daniel Lezcano
2022-01-07 13:15 ` Daniel Lezcano
2022-01-07 14:49 ` Ulf Hansson
2022-01-10 13:33 ` Daniel Lezcano
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).