This is a couple of fixes and clean-ups to use preferred CPU accessors
rather than directly parsing DT "reg" properties. It's part of a larger
effort to remove open coded parsing of "reg". The existing code is
fragile depending on the CPU architecture details and is wrong for
arm64 (though the dts files are also wrong).
Compile tested only.
Signed-off-by: Rob Herring <[email protected]>
---
Rob Herring (3):
MAINTAINERS: Add Marvell mvebu clock drivers
clk: mvebu: Use of_get_cpu_hwid() to read CPU ID
clk: mvebu: Iterate over possible CPUs instead of DT CPU nodes
MAINTAINERS | 1 +
drivers/clk/mvebu/ap-cpu-clk.c | 16 ++++++++--------
drivers/clk/mvebu/clk-cpu.c | 14 +++-----------
3 files changed, 12 insertions(+), 19 deletions(-)
---
base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
change-id: 20230327-mvebu-clk-fixes-f4a1365fa0b7
Best regards,
--
Rob Herring <[email protected]>
Use of_get_cpu_hwid() rather than the open coded reading of the CPU
nodes "reg" property. The existing code is in fact wrong as the "reg"
address cells size is 2 cells for arm64. The existing code happens to
work because the DTS files are wrong as well.
Signed-off-by: Rob Herring <[email protected]>
---
Note this should be marked for stable so that if/when the DTS files are
fixed, then at least stable kernels will work. This is untested, so I
didn't mark for stable.
---
drivers/clk/mvebu/ap-cpu-clk.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/mvebu/ap-cpu-clk.c b/drivers/clk/mvebu/ap-cpu-clk.c
index 71bdd7c3ff03..d8a7a4c90d54 100644
--- a/drivers/clk/mvebu/ap-cpu-clk.c
+++ b/drivers/clk/mvebu/ap-cpu-clk.c
@@ -253,12 +253,12 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
*/
nclusters = 1;
for_each_of_cpu_node(dn) {
- int cpu, err;
+ u64 cpu;
- err = of_property_read_u32(dn, "reg", &cpu);
- if (WARN_ON(err)) {
+ cpu = of_get_cpu_hwid(dn, 0);
+ if (WARN_ON(cpu == OF_BAD_ADDR)) {
of_node_put(dn);
- return err;
+ return -EINVAL;
}
/* If cpu2 or cpu3 is enabled */
@@ -288,12 +288,12 @@ static int ap_cpu_clock_probe(struct platform_device *pdev)
struct clk_init_data init;
const char *parent_name;
struct clk *parent;
- int cpu, err;
+ u64 cpu;
- err = of_property_read_u32(dn, "reg", &cpu);
- if (WARN_ON(err)) {
+ cpu = of_get_cpu_hwid(dn, 0);
+ if (WARN_ON(cpu == OF_BAD_ADDR)) {
of_node_put(dn);
- return err;
+ return -EINVAL;
}
cluster_index = cpu & APN806_CLUSTER_NUM_MASK;
--
2.39.2
drivers/clk/mvebu/ is missing a maintainers entry. Add it to the
existing entry for the Marvell mvebu platforms.
Signed-off-by: Rob Herring <[email protected]>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8d5bc223f305..b9d04f781524 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2356,6 +2356,7 @@ F: arch/arm/configs/mvebu_*_defconfig
F: arch/arm/mach-mvebu/
F: arch/arm64/boot/dts/marvell/armada*
F: arch/arm64/boot/dts/marvell/cn913*
+F: drivers/clk/mvebu/
F: drivers/cpufreq/armada-37xx-cpufreq.c
F: drivers/cpufreq/armada-8k-cpufreq.c
F: drivers/cpufreq/mvebu-cpufreq.c
--
2.39.2
Rework iterating over DT CPU nodes to iterate over possible CPUs
instead. There's no need to walk the DT CPU nodes again. Possible CPUs
is equal to the number of CPUs defined in the DT. Using the "reg" value
for an array index is fragile as it assumes "reg" is 0-N which often is
not the case.
Signed-off-by: Rob Herring <[email protected]>
---
drivers/clk/mvebu/clk-cpu.c | 14 +++-----------
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
index c2af3395cf13..db2b38c21304 100644
--- a/drivers/clk/mvebu/clk-cpu.c
+++ b/drivers/clk/mvebu/clk-cpu.c
@@ -168,8 +168,8 @@ static void __init of_cpu_clk_setup(struct device_node *node)
struct cpu_clk *cpuclk;
void __iomem *clock_complex_base = of_iomap(node, 0);
void __iomem *pmu_dfs_base = of_iomap(node, 1);
- int ncpus = 0;
- struct device_node *dn;
+ int ncpus = num_possible_cpus();
+ int cpu;
if (clock_complex_base == NULL) {
pr_err("%s: clock-complex base register not set\n",
@@ -181,9 +181,6 @@ static void __init of_cpu_clk_setup(struct device_node *node)
pr_warn("%s: pmu-dfs base register not set, dynamic frequency scaling not available\n",
__func__);
- for_each_of_cpu_node(dn)
- ncpus++;
-
cpuclk = kcalloc(ncpus, sizeof(*cpuclk), GFP_KERNEL);
if (WARN_ON(!cpuclk))
goto cpuclk_out;
@@ -192,19 +189,14 @@ static void __init of_cpu_clk_setup(struct device_node *node)
if (WARN_ON(!clks))
goto clks_out;
- for_each_of_cpu_node(dn) {
+ for_each_possible_cpu(cpu) {
struct clk_init_data init;
struct clk *clk;
char *clk_name = kzalloc(5, GFP_KERNEL);
- int cpu, err;
if (WARN_ON(!clk_name))
goto bail_out;
- err = of_property_read_u32(dn, "reg", &cpu);
- if (WARN_ON(err))
- goto bail_out;
-
sprintf(clk_name, "cpu%d", cpu);
cpuclk[cpu].parent_name = of_clk_get_parent_name(node, 0);
--
2.39.2
On Mon, Mar 27, 2023 at 01:43:18PM -0500, Rob Herring wrote:
> drivers/clk/mvebu/ is missing a maintainers entry. Add it to the
> existing entry for the Marvell mvebu platforms.
>
> Signed-off-by: Rob Herring <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Andrew
Quoting Rob Herring (2023-03-27 11:43:19)
> Use of_get_cpu_hwid() rather than the open coded reading of the CPU
> nodes "reg" property. The existing code is in fact wrong as the "reg"
> address cells size is 2 cells for arm64. The existing code happens to
> work because the DTS files are wrong as well.
>
> Signed-off-by: Rob Herring <[email protected]>
> ---
> Note this should be marked for stable so that if/when the DTS files are
> fixed, then at least stable kernels will work. This is untested, so I
> didn't mark for stable.
That makes it sound like it breaks for existing DTS files. Is that the
case?
On Mon, Apr 10, 2023 at 04:36:21PM -0700, Stephen Boyd wrote:
> Quoting Rob Herring (2023-03-27 11:43:19)
> > Use of_get_cpu_hwid() rather than the open coded reading of the CPU
> > nodes "reg" property. The existing code is in fact wrong as the "reg"
> > address cells size is 2 cells for arm64. The existing code happens to
> > work because the DTS files are wrong as well.
> >
> > Signed-off-by: Rob Herring <[email protected]>
> > ---
> > Note this should be marked for stable so that if/when the DTS files are
> > fixed, then at least stable kernels will work. This is untested, so I
> > didn't mark for stable.
>
> That makes it sound like it breaks for existing DTS files. Is that the
> case?
No, if the DTS files are fixed, then they will not work with the
existing code. This change should work for both existing and fixed DTS
files.
Rob