Re: [PATCH] cacheinfo: Keep the old value if of_property_read_u32fails
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 = <>;" 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 Also please add: Fixes: 448a5a552f33 ("drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number") -- Regards, Sudeep
Re: [PATCH] cacheinfo: Keep the old value if of_property_read_u32fails
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 = <>;" 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 Also please add: Fixes: 448a5a552f33 ("drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number") -- Regards, Sudeep
Re: [PATCH] cacheinfo: Keep the old value if of_property_read_u32fails
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 = <>;" but has no "size" information. Huacai -- Original -- From: "Sudeep Holla"; Date: Thu, Oct 18, 2018 05:15 PM To: "Huacai Chen"; Cc: "Greg Kroah-Hartman"; "Rafael J . Wysocki"; "LKML"; "zhangfx"; "wuzhangjin"; "Sudeep Holla"; 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
Re: [PATCH] cacheinfo: Keep the old value if of_property_read_u32fails
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 = <>;" but has no "size" information. Huacai -- Original -- From: "Sudeep Holla"; Date: Thu, Oct 18, 2018 05:15 PM To: "Huacai Chen"; Cc: "Greg Kroah-Hartman"; "Rafael J . Wysocki"; "LKML"; "zhangfx"; "wuzhangjin"; "Sudeep Holla"; 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