Re: [PATCH v4 3/5] thermal: qcom-spmi-temp-alarm: Prepare to support additional Temp Alarm subtypes

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 29/05/2025 00:50, Anjelique Melendez wrote:
> @@ -356,16 +378,12 @@ static int qpnp_tm_init(struct qpnp_tm_chip *chip)
> 
>   	mutex_unlock(&chip->lock);
> 
> -	ret = thermal_zone_get_crit_temp(chip->tz_dev, &crit_temp);
> -	if (ret)
> -		crit_temp = THERMAL_TEMP_INVALID;
> +	ret = chip->data->configure_trip_temps(chip);
> +	if (ret < 0)
> +		return ret;
> 
>   	mutex_lock(&chip->lock);

Could we just drop the mutex lock in tm_init ();

probe()
   tm_init();
     mutex_lock();
     do stuff;
     mutex_unlock();
     ->configure_trip_temps();
         mutex_lock();
         do other stuff
         mutex_unlock();
     mutex_lock();
     back to doing stuff in tm_init();
     mutex_unlock();

There's little rationality to tm_init() being a critical section but 
also doing lock/unlock three times inside of that critical section.

Since tm_init() is only called during probe() what exactly is the 
parallel context we are premepting with the lock ?

If we can't answer that question the tm_init() mutex should be dropped.

---
bod