Re: [linux-iv:review/v5-viresh-cppc-counters 1/2] drivers/base/arch_topology.c:133:17: sparse: sparse: incorrect type in initializer (different address spaces)

[Ionela Voinescu <ionela.voinescu@arm.com>]

[-- Attachment #1: Type: text/plain, Size: 3932 bytes --]

Hey,

On Wednesday 10 Mar 2021 at 10:54:49 (+0530), Viresh Kumar wrote:
> On 10-03-21, 01:23, kernel test robot wrote:
> > tree:   https://git.gitlab.arm.com/linux-arm/linux-iv.git review/v5-viresh-cppc-counters
> > head:   7e9e155411e1181c6b4eb5615568693fbed7b264
> > commit: a7d9b7cc83c6f04b1e33b4b1b6dc76fc6c36c1ab [1/2] topology: Allow multiple entities to provide sched_freq_tick() callback
> > config: arm64-randconfig-s032-20210309 (attached as .config)
> > compiler: aarch64-linux-gcc (GCC) 9.3.0
> > reproduce:
> >         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >         chmod +x ~/bin/make.cross
> >         # apt-get install sparse
> >         # sparse version: v0.6.3-262-g5e674421-dirty
> >         git remote add linux-iv https://git.gitlab.arm.com/linux-arm/linux-iv.git
> >         git fetch --no-tags linux-iv review/v5-viresh-cppc-counters
> >         git checkout a7d9b7cc83c6f04b1e33b4b1b6dc76fc6c36c1ab
> >         # save the attached .config to linux build tree
> >         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm64 
> > 
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp@intel.com>
> > 
> > 
> > "sparse warnings: (new ones prefixed by >>)"
> > >> drivers/base/arch_topology.c:133:17: sparse: sparse: incorrect type in initializer (different address spaces) @@     expected void const [noderef] __percpu *__vpp_verify @@     got unsigned long * @@
> >    drivers/base/arch_topology.c:133:17: sparse:     expected void const [noderef] __percpu *__vpp_verify
> >    drivers/base/arch_topology.c:133:17: sparse:     got unsigned long *
> > 
> > vim +133 drivers/base/arch_topology.c
> > 
> > 2ef7a2953c81ee Juri Lelli       2017-05-31  112  
> > a20b7053b5c47c Ionela Voinescu  2020-09-24  113  void topology_set_freq_scale(const struct cpumask *cpus, unsigned long cur_freq,
> > 0e27c567d16731 Dietmar Eggemann 2017-09-26  114  			     unsigned long max_freq)
> > 2ef7a2953c81ee Juri Lelli       2017-05-31  115  {
> > 0e27c567d16731 Dietmar Eggemann 2017-09-26  116  	unsigned long scale;
> > 0e27c567d16731 Dietmar Eggemann 2017-09-26  117  	int i;
> > 0e27c567d16731 Dietmar Eggemann 2017-09-26  118  
> > 0a10d3fe3e5c60 Ionela Voinescu  2020-09-01  119  	if (WARN_ON_ONCE(!cur_freq || !max_freq))
> > 0a10d3fe3e5c60 Ionela Voinescu  2020-09-01  120  		return;
> > 0a10d3fe3e5c60 Ionela Voinescu  2020-09-01  121  
> > cd0ed03a8903a0 Ionela Voinescu  2020-03-05  122  	/*
> > cd0ed03a8903a0 Ionela Voinescu  2020-03-05  123  	 * If the use of counters for FIE is enabled, just return as we don't
> > cd0ed03a8903a0 Ionela Voinescu  2020-03-05  124  	 * want to update the scale factor with information from CPUFREQ.
> > cd0ed03a8903a0 Ionela Voinescu  2020-03-05  125  	 * Instead the scale factor will be updated from arch_scale_freq_tick.
> > cd0ed03a8903a0 Ionela Voinescu  2020-03-05  126  	 */
> > a7d9b7cc83c6f0 Viresh Kumar     2021-03-01  127  	if (supports_scale_freq_counters(cpus))
> > cd0ed03a8903a0 Ionela Voinescu  2020-03-05  128  		return;
> > cd0ed03a8903a0 Ionela Voinescu  2020-03-05  129  
> > 0e27c567d16731 Dietmar Eggemann 2017-09-26  130  	scale = (cur_freq << SCHED_CAPACITY_SHIFT) / max_freq;
> > 0e27c567d16731 Dietmar Eggemann 2017-09-26  131  
> > 0e27c567d16731 Dietmar Eggemann 2017-09-26  132  	for_each_cpu(i, cpus)
> > 0e27c567d16731 Dietmar Eggemann 2017-09-26 @133  		per_cpu(freq_scale, i) = scale;
> 
> I am not sure how to fix such sparse warnings, any idea ? This is a simple
> per-cpu variable and should have worked as the same works everywhere else in
> kernel.
> 

This is caused by EXPORT_SYMBOL_GPL(freq_scale). It needs to be
EXPORT_PER_CPU_SYMBOL_GPL(freq_scale).

Thanks,
Ionela.

> -- 
> viresh