Commit 448a5a552f336bd7b847b1951 ("drivers: base: cacheinfo: use OF
property_read_u32 instead of get_property,read_number") makes cache
size and number_of_sets be 0 if DT doesn't provide there values. I
think this is unreasonable so make them keep the old values, which is
the same as old kernels.
Signed-off-by: Huacai Chen <[email protected]>
---
drivers/base/cacheinfo.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 5d5b598..dd6a685 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -79,8 +79,7 @@ static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- if (of_property_read_u32(np, propname, &this_leaf->size))
- this_leaf->size = 0;
+ of_property_read_u32(np, propname, &this_leaf->size);
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
@@ -114,8 +113,7 @@ static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- if (of_property_read_u32(np, propname, &this_leaf->number_of_sets))
- this_leaf->number_of_sets = 0;
+ of_property_read_u32(np, propname, &this_leaf->number_of_sets);
}
static void cache_associativity(struct cacheinfo *this_leaf)
--
2.7.0
On Wed, Oct 17, 2018 at 09:26:03AM +0800, Huacai Chen wrote:
> Commit 448a5a552f336bd7b847b1951 ("drivers: base: cacheinfo: use OF
> property_read_u32 instead of get_property,read_number") makes cache
> size and number_of_sets be 0 if DT doesn't provide there values. I
> think this is unreasonable so make them keep the old values, which is
> the same as old kernels.
>
What old values does the kernel have ? Which architecture are you referring ?
If DT doesn't have entry then we can't expose sysfs, hence 0.
Please provide more details on the issue you are seeing.
--
Regards,
Sudeep
Hi, Sudeep,
Please see this call-graph:
static int detect_cache_attributes(unsigned int cpu)
....
ret = populate_cache_leaves(cpu);
....
ret = cache_shared_cpu_map_setup(cpu); -->
cache_setup_of_node() --> cache_of_set_props() -->
cache_size()/cache_nr_sets
populate_cache_leaves() is arch-specific, All archs except arm64 have
provide initial values to cacheinfo:size and cacheinfo:number_of_sets.
Related files:
arch/nds32/kernel/cacheinfo.c
arch/riscv/kernel/cacheinfo.c
arch/s390/kernel/cache.c
arch/mips/kernel/cacheinfo.c
arch/x86/kernel/cpu/cacheinfo.c
Regards,
Huacai
On Wed, Oct 17, 2018 at 5:35 PM Sudeep Holla <[email protected]> wrote:
>
> On Wed, Oct 17, 2018 at 09:26:03AM +0800, Huacai Chen wrote:
> > Commit 448a5a552f336bd7b847b1951 ("drivers: base: cacheinfo: use OF
> > property_read_u32 instead of get_property,read_number") makes cache
> > size and number_of_sets be 0 if DT doesn't provide there values. I
> > think this is unreasonable so make them keep the old values, which is
> > the same as old kernels.
> >
>
> What old values does the kernel have ? Which architecture are you referring ?
> If DT doesn't have entry then we can't expose sysfs, hence 0.
> Please provide more details on the issue you are seeing.
>
> --
> Regards,
> Sudeep
Hi Huacai,
On Thu, Oct 18, 2018 at 09:28:11AM +0800, Huacai Chen wrote:
> Hi, Sudeep,
>
> Please see this call-graph:
>
> static int detect_cache_attributes(unsigned int cpu)
> ....
> ret = populate_cache_leaves(cpu);
> ....
> ret = cache_shared_cpu_map_setup(cpu); -->
> cache_setup_of_node() --> cache_of_set_props() -->
> cache_size()/cache_nr_sets
>
> populate_cache_leaves() is arch-specific, All archs except arm64 have
> provide initial values to cacheinfo:size and cacheinfo:number_of_sets.
>
> Related files:
> arch/nds32/kernel/cacheinfo.c
> arch/mips/kernel/cacheinfo.c
Only above 2 could be affected, but I want to be sure. I wasn't aware
of MIPS arch setting values elsewhere, assumed DT, my bad.
You have still not answered my question. Which arch are you facing issue ?
Or are you proposing this by code inspection ? I changes look fine, but
want to be sure if the issue you are seeing is in above architectures.
--
Regards,
Sudeep
Hi, Sudeep,
I use MIPS, and there is no "size" in /sys/devices/system/cpu/cpuX/cache/indexX/ file after your patch. Because the DT node only has "next-level-cache = <&L2>;" but has no "size" information.
Huacai
------------------ Original ------------------
From: "Sudeep Holla"<[email protected]>;
Date: Thu, Oct 18, 2018 05:15 PM
To: "Huacai Chen"<[email protected]>;
Cc: "Greg Kroah-Hartman"<[email protected]>; "Rafael J . Wysocki"<[email protected]>; "LKML"<[email protected]>; "zhangfx"<[email protected]>; "wuzhangjin"<[email protected]>; "Sudeep Holla"<[email protected]>;
Subject: Re: [PATCH] cacheinfo: Keep the old value if of_property_read_u32fails
Hi Huacai,
On Thu, Oct 18, 2018 at 09:28:11AM +0800, Huacai Chen wrote:
> Hi, Sudeep,
>
> Please see this call-graph:
>
> static int detect_cache_attributes(unsigned int cpu)
> ....
> ret = populate_cache_leaves(cpu);
> ....
> ret = cache_shared_cpu_map_setup(cpu); -->
> cache_setup_of_node() --> cache_of_set_props() -->
> cache_size()/cache_nr_sets
>
> populate_cache_leaves() is arch-specific, All archs except arm64 have
> provide initial values to cacheinfo:size and cacheinfo:number_of_sets.
>
> Related files:
> arch/nds32/kernel/cacheinfo.c
> arch/mips/kernel/cacheinfo.c
Only above 2 could be affected, but I want to be sure. I wasn't aware
of MIPS arch setting values elsewhere, assumed DT, my bad.
You have still not answered my question. Which arch are you facing issue ?
Or are you proposing this by code inspection ? I changes look fine, but
want to be sure if the issue you are seeing is in above architectures.
--
Regards,
Sudeep
Hi,
On Fri, Oct 19, 2018 at 02:23:27PM +0800, 陈华才 wrote:
> Hi, Sudeep,
>
> I use MIPS, and there is no "size" in
> /sys/devices/system/cpu/cpuX/cache/indexX/ file after your patch. Because
> the DT node only has "next-level-cache = <&L2>;" but has no "size"
> information.
>
Thanks for the confirmation and your time. I was worried if this was ARM64
with local patches.
You can add:
Reviewed-by: Sudeep Holla <[email protected]>
Also please add:
Fixes: 448a5a552f33 ("drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number")
--
Regards,
Sudeep