trap in modprobing sun50i_cpufreq_nvmem - collective thinking needed....

[piotr.o...@gmail.com]

Guys - I need some collective thinking....

I'm working on adding cpufreq support on h616 and can't overcome kernel traps when i'm modprobing sun50i_cpufreq_nvmem module. 

Module seems correctly read nvmem cpu speed bin but later traps are like this: https://pastebin.com/hrTrRvY5

Looking on trap log i see 

"WARNING: CPU: 1 PID: 4709 at drivers/opp/core.c:1908 dev_pm_opp_set_prop_name+0x94/0xa0".
This seems to correspond to https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/opp/core.c?h=v5.12.10#n1878
I'm reading this as maybe issue of more than 1 updators are updating DT (i.e. like maybe multiple CPU doing in parallel?)

This sun50i_cpufreq_nvmem module loads ok on h6 - but traps on h616 with error code -17 (file exists). 
I started to think maybe root cause is: input data supplied to dev_pm_opp_set_prop_name is different between h6 and h616. So I made sure h616 cpu definitions in DT are exactly the same like in working h6. Used h616 opp table also is  as close as possible to working h6 (in fact i renamed h6 opp table & update only cpu Vcc fileds). With this module still traps.... 

Next I added in module code some printks:
printk("dev_pm_opp_set_prop_name for cpu:%d name:%s\n", cpu, name) 
before https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/cpufreq/sun50i-cpufreq-nvmem.c?h=v5.12.10#n114; 

It prints exactly the same like in  working h6 and not working h616:

[  170.197292] speedbin from nvram:0

[  170.197321] dev_pm_opp_set_prop_name for cpu:0 name:speed0

[  170.197390] dev_pm_opp_set_prop_name for cpu:1 name:speed0

[  170.197418] dev_pm_opp_set_prop_name for cpu:2 name:speed0

[  170.197443] dev_pm_opp_set_prop_name for cpu:3 name:speed0

it looks to me like issue is dev_pm_opp_set_prop_name function is called multiple in parallel to update dt. Module loading error code -17 (file exist) might be logical here (updator1 meets already updated by updator2).  

For reference: DT with opp &  cpu defs i'm using is like this: https://pastebin.com/vqE9UFZu 

maybe you have some hints here?

[piotr.o...@gmail.com]

oh - i forgot to add:

another hypothesis candidate is cpu enablement: maybe psci on h616 not fully "correct" yet (i.e. some cpufreq structs are filled wrongly or only partially)?