From: Rob Herring <robh@kernel.org> Date: 2021-10-06 16:43:41
The first 10 patches add a new function, of_get_cpu_hwid(), which parses
CPU DT node 'reg' property, and then use it to replace all the open
coded versions of parsing CPU node 'reg' properties.
The last 2 patches add support for populating the cacheinfo 'id' on DT
platforms. The minimum associated CPU hwid is used for the id. The id is
optional, but necessary for resctrl which is being adapted for Arm MPAM.
Tested on arm64. Compile tested on arm, x86 and powerpc.
Rob
Rob Herring (12):
of: Add of_get_cpu_hwid() to read hardware ID from CPU nodes
ARM: Use of_get_cpu_hwid()
ARM: broadcom: Use of_get_cpu_hwid()
arm64: Use of_get_cpu_hwid()
csky: Use of_get_cpu_hwid()
openrisc: Use of_get_cpu_hwid()
powerpc: Use of_get_cpu_hwid()
riscv: Use of_get_cpu_hwid()
sh: Use of_get_cpu_hwid()
x86: dt: Use of_get_cpu_hwid()
cacheinfo: Allow for >32-bit cache 'id'
cacheinfo: Set cache 'id' based on DT data
arch/arm/kernel/devtree.c | 22 ++-------------------
arch/arm/mach-bcm/bcm63xx_pmb.c | 6 +++---
arch/arm64/kernel/smp.c | 31 ++----------------------------
arch/csky/kernel/smp.c | 6 ++----
arch/openrisc/kernel/smp.c | 6 +-----
arch/powerpc/kernel/smp.c | 7 +------
arch/riscv/kernel/cpu.c | 3 ++-
arch/sh/boards/of-generic.c | 5 ++---
arch/x86/kernel/devicetree.c | 5 ++---
drivers/base/cacheinfo.c | 34 ++++++++++++++++++++++++++++++++-
drivers/of/base.c | 22 +++++++++++++++++++++
include/linux/cacheinfo.h | 2 +-
include/linux/of.h | 1 +
13 files changed, 74 insertions(+), 76 deletions(-)
--
2.30.2
From: Rob Herring <robh@kernel.org> Date: 2021-10-06 16:43:43
There are various open coded implementions parsing the CPU node 'reg'
property which contains the CPU's hardware ID. Introduce a new function,
of_get_cpu_hwid(), to read the hardware ID.
All the callers should be DT only code, so no need for an empty
function.
Cc: Frank Rowand <redacted>
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/of/base.c | 22 ++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 23 insertions(+)
From: Rob Herring <robh@kernel.org> Date: 2021-10-06 16:43:45
Replace the open coded parsing of CPU nodes' 'reg' property with
of_get_cpu_hwid().
This change drops an error message for missing 'reg' property, but that
should not be necessary as the DT tools will ensure 'reg' is present.
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm/kernel/devtree.c | 22 ++--------------------
1 file changed, 2 insertions(+), 20 deletions(-)
From: Rob Herring <robh@kernel.org> Date: 2021-10-06 16:43:47
Replace open coded parsing of CPU nodes 'reg' property with
of_get_cpu_hwid().
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm/mach-bcm/bcm63xx_pmb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
@@ -91,10 +91,10 @@ static int bcm63xx_pmb_get_resources(struct device_node *dn,structof_phandle_argsargs;intret;-ret=of_property_read_u32(dn,"reg",cpu);-if(ret){+*cpu=of_get_cpu_hwid(dn,0);+if(*cpu==~0U){pr_err("CPU is missing a reg node\n");-returnret;+return-ENODEV;}ret=of_parse_phandle_with_args(dn,"resets","#reset-cells",
From: Rob Herring <robh@kernel.org> Date: 2021-10-06 16:43:51
Replace the open coded parsing of CPU nodes' 'reg' property with
of_get_cpu_hwid().
This change drops an error message for missing 'reg' property, but that
should not be necessary as the DT tools will ensure 'reg' is present.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm64/kernel/smp.c | 31 ++-----------------------------
1 file changed, 2 insertions(+), 29 deletions(-)
@@ -22,7 +22,8 @@ int riscv_of_processor_hartid(struct device_node *node)return-ENODEV;}-if(of_property_read_u32(node,"reg",&hart)){+hart=of_get_cpu_hwid(node,0);+if(hart==~0U){pr_warn("Found CPU without hart ID\n");return-ENODEV;}
From: Rob Herring <robh@kernel.org> Date: 2021-10-06 16:44:10
In preparation to set the cache 'id' based on the CPU h/w ids, allow for
64-bit bit 'id' value. The only case that needs this is arm64, so
unsigned long is sufficient.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/base/cacheinfo.c | 8 +++++++-
include/linux/cacheinfo.h | 2 +-
2 files changed, 8 insertions(+), 2 deletions(-)
From: Rob Herring <robh@kernel.org> Date: 2021-10-06 16:44:14
Use the minimum CPU h/w id of the CPUs associated with the cache for the
cache 'id'. This will provide a stable id value for a given system. As
we need to check all possible CPUs, we can't use the shared_cpu_map
which is just online CPUs. As there's not a cache to CPUs mapping in DT,
we have to walk all CPU nodes and then walk cache levels.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
---
drivers/base/cacheinfo.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
You have defined of_get_cpu_hwid to return u64, will this create compiler
warnings when since we are storing a u64 into a u32?
It seems only if we make with W=3.
I thought we usually warned on this. Oh well, for the openrisc bits.
Acked-by: Stafford Horne <shorne@gmail.com>
if (cpu_id < NR_CPUS)
set_cpu_possible(cpu_id, true);
}
--
2.30.2
On Thu, Oct 07, 2021 at 05:44:00AM +0900, Stafford Horne wrote:
You have defined of_get_cpu_hwid to return u64, will this create compiler
warnings when since we are storing a u64 into a u32?
It seems only if we make with W=3.
Yes. This is done by -Wconversion, "Warn for implicit conversions that
may alter a value."
I thought we usually warned on this.
This warning is not in -Wall or -Wextra either, it suffers too much from
false positives. It is very natural to just ignore the high bits of
modulo types (which is what "unsigned" types *are*). Or the bits that
"fall off" on a conversion. The C standard makes this required
behaviour, it is useful, and it is the only convenient way of getting
this!
Segher
Hi Segher,
On Wed, Oct 06, 2021 at 04:27:28PM -0500, Segher Boessenkool wrote:
On Thu, Oct 07, 2021 at 05:44:00AM +0900, Stafford Horne wrote:
quoted
You have defined of_get_cpu_hwid to return u64, will this create compiler
warnings when since we are storing a u64 into a u32?
It seems only if we make with W=3.
Yes. This is done by -Wconversion, "Warn for implicit conversions that
may alter a value."
Yeah, that is what I found out when I looked into it.
quoted
I thought we usually warned on this.
This warning is not in -Wall or -Wextra either, it suffers too much from
false positives. It is very natural to just ignore the high bits of
modulo types (which is what "unsigned" types *are*). Or the bits that
"fall off" on a conversion. The C standard makes this required
behaviour, it is useful, and it is the only convenient way of getting
this!
Thanks for the background, It does make sense. I guess I was confused with java
which requires casting when you store to a smaller size. I.e.
Test.java:5: error: incompatible types: possible lossy conversion from int to short
s = i;
-Stafford
The first 10 patches add a new function, of_get_cpu_hwid(), which parses
CPU DT node 'reg' property, and then use it to replace all the open
coded versions of parsing CPU node 'reg' properties.
The last 2 patches add support for populating the cacheinfo 'id' on DT
platforms. The minimum associated CPU hwid is used for the id. The id is
optional, but necessary for resctrl which is being adapted for Arm MPAM.
Tested on arm64. Compile tested on arm, x86 and powerpc.
On ARM and ARM64:
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
lscpu -C continues to work on ARM64 as before with cache properties
provided in the FDT.
--
Florian
Replace open coded parsing of CPU nodes 'reg' property with
of_get_cpu_hwid().
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Rob Herring <robh@kernel.org>
From: David Laight <hidden> Date: 2021-10-07 07:53:14
From: Segher Boessenkool
Sent: 06 October 2021 22:27
On Thu, Oct 07, 2021 at 05:44:00AM +0900, Stafford Horne wrote:
quoted
You have defined of_get_cpu_hwid to return u64, will this create compiler
warnings when since we are storing a u64 into a u32?
It seems only if we make with W=3.
Yes. This is done by -Wconversion, "Warn for implicit conversions that
may alter a value."
quoted
I thought we usually warned on this.
The microsoft compiler does - best to turn all those warnings off.
This warning is not in -Wall or -Wextra either, it suffers too much from
false positives. It is very natural to just ignore the high bits of
modulo types (which is what "unsigned" types *are*). Or the bits that
"fall off" on a conversion. The C standard makes this required
behaviour, it is useful, and it is the only convenient way of getting
this!
I've also seen a compiler convert:
struct->char_member = (char)(int_val & 0xff);
into:
reg = int_val;
reg &= 0xff; // for the & 0xff
reg &= 0xff; // for the cast
struct->char_member = low_8bits(reg);
You really don't want the extra noise.
I'll bet that (char)int_val is actually an arithmetic expression.
So its type will be 'int'.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
From: Will Deacon <will@kernel.org> Date: 2021-10-07 08:08:14
On Wed, Oct 06, 2021 at 11:43:24AM -0500, Rob Herring wrote:
Replace the open coded parsing of CPU nodes' 'reg' property with
of_get_cpu_hwid().
This change drops an error message for missing 'reg' property, but that
should not be necessary as the DT tools will ensure 'reg' is present.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
---
arch/arm64/kernel/smp.c | 31 ++-----------------------------
1 file changed, 2 insertions(+), 29 deletions(-)
Acked-by: Will Deacon <will@kernel.org>
It's a shame INVALID_HWID can't be removed too, but looks like it's still
used in a couple of places.
Will
@@ -1313,18 +1313,13 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)intcpu_to_core_id(intcpu){structdevice_node*np;-const__be32*reg;intid=-1;np=of_get_cpu_node(cpu,NULL);if(!np)gotoout;-reg=of_get_property(np,"reg",NULL);-if(!reg)-gotoout;--id=be32_to_cpup(reg);+id=of_get_cpu_hwid(np,0);out:of_node_put(np);returnid;
This looks OK to me.
All the systems I can find have a /cpus/#address-cells of 1, so the
change to use of_n_addr_cells() in of_get_cpu_hwid() should be fine.
I booted it on a bunch of systems with no issues.
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
On Wed, Oct 06, 2021 at 11:43:21AM -0500, Rob Herring wrote:
There are various open coded implementions parsing the CPU node 'reg'
property which contains the CPU's hardware ID. Introduce a new function,
of_get_cpu_hwid(), to read the hardware ID.
All the callers should be DT only code, so no need for an empty
function.
Thanks for doing this. I postponed and forgot about this though I had
planned for this when I touched code around this.
Reviewed-by: Sudeep Holla <redacted>
--
Regards,
Sudeep
On Wed, Oct 06, 2021 at 11:43:24AM -0500, Rob Herring wrote:
Replace the open coded parsing of CPU nodes' 'reg' property with
of_get_cpu_hwid().
This change drops an error message for missing 'reg' property, but that
should not be necessary as the DT tools will ensure 'reg' is present.
On Wed, Oct 06, 2021 at 11:43:31AM -0500, Rob Herring wrote:
In preparation to set the cache 'id' based on the CPU h/w ids, allow for
64-bit bit 'id' value. The only case that needs this is arm64, so
unsigned long is sufficient.
On Wed, Oct 06, 2021 at 11:43:32AM -0500, Rob Herring wrote:
Use the minimum CPU h/w id of the CPUs associated with the cache for the
cache 'id'. This will provide a stable id value for a given system. As
we need to check all possible CPUs, we can't use the shared_cpu_map
which is just online CPUs. As there's not a cache to CPUs mapping in DT,
we have to walk all CPU nodes and then walk cache levels.
From: Rob Herring <robh@kernel.org> Date: 2021-10-20 18:48:09
On Wed, Oct 6, 2021 at 11:43 AM Rob Herring [off-list ref] wrote:
The first 10 patches add a new function, of_get_cpu_hwid(), which parses
CPU DT node 'reg' property, and then use it to replace all the open
coded versions of parsing CPU node 'reg' properties.
The last 2 patches add support for populating the cacheinfo 'id' on DT
platforms. The minimum associated CPU hwid is used for the id. The id is
optional, but necessary for resctrl which is being adapted for Arm MPAM.
Tested on arm64. Compile tested on arm, x86 and powerpc.
Rob
Rob Herring (12):
of: Add of_get_cpu_hwid() to read hardware ID from CPU nodes
ARM: Use of_get_cpu_hwid()
ARM: broadcom: Use of_get_cpu_hwid()
arm64: Use of_get_cpu_hwid()
csky: Use of_get_cpu_hwid()
openrisc: Use of_get_cpu_hwid()
powerpc: Use of_get_cpu_hwid()
riscv: Use of_get_cpu_hwid()
sh: Use of_get_cpu_hwid()
x86: dt: Use of_get_cpu_hwid()
cacheinfo: Allow for >32-bit cache 'id'
cacheinfo: Set cache 'id' based on DT data
I've fixed up the openrisc error and applied 1-10 to the DT tree.
The cacheinfo part is going to need some more work. I've found I will
need the cache affinity (of possible cpus) as well, so I plan to also
store the affinity instead of looping thru caches and cpus again.
Rob