diff mbox series

of: export of_find_next_cache_node() for modules

Message ID 20231011112726.166052-1-dmitry.baryshkov@linaro.org (mailing list archive)
State Handled Elsewhere, archived
Headers show
Series of: export of_find_next_cache_node() for modules | expand

Commit Message

Dmitry Baryshkov Oct. 11, 2023, 11:27 a.m. UTC
The qcom-cpufreq-nvmem module uses of_find_next_cache_node() function,
so export it to be available to the modules.

Fixes: 7683a63c08ff ("cpufreq: qcom-nvmem: create L2 cache device")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---

This patch fixes the discrepancy caused by the patch for the
qcom-cpufreq-nvmem. I'd like to ask for this patch to be also merged via
the cpufreq tree.

---
 drivers/of/base.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Konrad Dybcio Oct. 11, 2023, 11:30 a.m. UTC | #1
On 10/11/23 13:27, Dmitry Baryshkov wrote:
> The qcom-cpufreq-nvmem module uses of_find_next_cache_node() function,
> so export it to be available to the modules.
> 
> Fixes: 7683a63c08ff ("cpufreq: qcom-nvmem: create L2 cache device")
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>

Pity the testing robot didn't catch this

Konrad
Rob Herring Oct. 11, 2023, 12:52 p.m. UTC | #2
On Wed, Oct 11, 2023 at 6:27 AM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> The qcom-cpufreq-nvmem module uses of_find_next_cache_node() function,
> so export it to be available to the modules.

You really should be using the cacheinfo API which has already parsed
the cache nodes.

Also, why do you need a platform_device? I don't see a driver.
cacheinfo already creates a struct device, so kind of weird to have 2
devices.

Rob
Dmitry Baryshkov Oct. 11, 2023, 12:59 p.m. UTC | #3
On Wed, 11 Oct 2023 at 15:52, Rob Herring <robh+dt@kernel.org> wrote:
>
> On Wed, Oct 11, 2023 at 6:27 AM Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> wrote:
> >
> > The qcom-cpufreq-nvmem module uses of_find_next_cache_node() function,
> > so export it to be available to the modules.
>
> You really should be using the cacheinfo API which has already parsed
> the cache nodes.
>
> Also, why do you need a platform_device? I don't see a driver.
> cacheinfo already creates a struct device, so kind of weird to have 2
> devices.

The driver is pending as a part of the series at [1]. We need to scale
the L2 supplies and clock frequency following the core frequency
changes.

[1] https://lore.kernel.org/linux-arm-msm/20230827115033.935089-9-dmitry.baryshkov@linaro.org/
Viresh Kumar Oct. 16, 2023, 3:23 a.m. UTC | #4
On 11-10-23, 15:59, Dmitry Baryshkov wrote:
> On Wed, 11 Oct 2023 at 15:52, Rob Herring <robh+dt@kernel.org> wrote:
> >
> > On Wed, Oct 11, 2023 at 6:27 AM Dmitry Baryshkov
> > <dmitry.baryshkov@linaro.org> wrote:
> > >
> > > The qcom-cpufreq-nvmem module uses of_find_next_cache_node() function,
> > > so export it to be available to the modules.
> >
> > You really should be using the cacheinfo API which has already parsed
> > the cache nodes.
> >
> > Also, why do you need a platform_device? I don't see a driver.
> > cacheinfo already creates a struct device, so kind of weird to have 2
> > devices.
> 
> The driver is pending as a part of the series at [1]. We need to scale
> the L2 supplies and clock frequency following the core frequency
> changes.

Guys, can we please resolve this soon ? I had to revert the patches
for the time being to avoid these failures.
Dmitry Baryshkov Oct. 16, 2023, 4:21 a.m. UTC | #5
On Mon, 16 Oct 2023 at 06:24, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>
> On 11-10-23, 15:59, Dmitry Baryshkov wrote:
> > On Wed, 11 Oct 2023 at 15:52, Rob Herring <robh+dt@kernel.org> wrote:
> > >
> > > On Wed, Oct 11, 2023 at 6:27 AM Dmitry Baryshkov
> > > <dmitry.baryshkov@linaro.org> wrote:
> > > >
> > > > The qcom-cpufreq-nvmem module uses of_find_next_cache_node() function,
> > > > so export it to be available to the modules.
> > >
> > > You really should be using the cacheinfo API which has already parsed
> > > the cache nodes.
> > >
> > > Also, why do you need a platform_device? I don't see a driver.
> > > cacheinfo already creates a struct device, so kind of weird to have 2
> > > devices.
> >
> > The driver is pending as a part of the series at [1]. We need to scale
> > the L2 supplies and clock frequency following the core frequency
> > changes.
>
> Guys, can we please resolve this soon ? I had to revert the patches
> for the time being to avoid these failures.

Rob pointed out that I should rework my code to use the cacheinfo
device for the L2 cache. This means that L2 device population should
be dropped from cpufreq. I'll post newer series as soon as I finish
the implementation.
diff mbox series

Patch

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 8d93cb6ea9cd..c4cf558e60d9 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1905,6 +1905,7 @@  struct device_node *of_find_next_cache_node(const struct device_node *np)
 
 	return NULL;
 }
+EXPORT_SYMBOL_GPL(of_find_next_cache_node);
 
 /**
  * of_find_last_cache_level - Find the level at which the last cache is