On 7/29/21 2:17 AM, Viresh Kumar wrote:

On 28-07-21, 18:19, Thara Gopinath wrote:

quoted

Ha! I was too lazy to write this down! So how about I make this a mutex and

mutex may not work as you come here from irq.

Hi!

So the interrupt handler is a threaded handler. I moved it in v4 since 
one of the "_opp" api has an underlying mutex and was causing issues. So 
using a mutex should be pretty safe in this case.

quoted

put mod_delayed_work() inside the lock. So it will be something like below

qcom_lmh_dcvs_notify()			qcom_cpufreq_hw_lmh_exit()

mutex_lock()				mutex_lock()
   if (data->cancel_throttle) {		cancel_throttle = true
	mutex_unlock()			mutex_unlock()
	return				cancel_delayed_work_sync()
   }					free_irq()
   enable_irq() / mod_delayed_work()
mutex_unlock()

I will let you break it!

I can't any further :)

Consider merging below to this patch, it fixes sever other minor
issues I see in the code.

IIUC, the main change you are suggesting below is to include 
enable_irq() / mod_delayed_work() under the spin_lock as well. Is that 
right ? In which case isn't a mutex better than spinlock?

-- 
Warm Regards
Thara (She/Her/Hers)