On 03/07/2020 03:49, Zhang Rui wrote: > On Thu, 2020-07-02 at 19:49 +0200, Daniel Lezcano wrote: [ ... ] >>> So the reason is that ->get_temp() is called while the mutex is >>> held and >>> thermal_zone_device_is_enabled() wants to take the same mutex. >> >> Yes, that's correct. >> >>> Is adding a comment to thermal_zone_device_is_enabled() to never >>> call >>> it while the mutex is held and adding another version of it which >>> does >>> not take the mutex ok? >> >> The thermal_zone_device_is_enabled() is only used in two places, acpi >> and this imx driver, and given: >> >> 1. as soon as the mutex is released, there is no guarantee the >> thermal >> zone won't be changed right after, the lock is pointless, thus the >> information also. >> >> 2. from a design point of view, I don't see why a driver should know >> if >> a thermal zone is disabled or not >> >> It would make sense to end with this function and do not give the >> different drivers an opportunity to access this information. > > I agree. >> >> Why not add change_mode for the acpi in order to enable or disable >> the >> events > > thermal_zone_device_is_enabled() is invoked in acpi thermal driver > because we only want to do thermal_zone_device_update() when the acpi > thermal zone is enabled. > > As thermal_zone_device_update() can handle a disabled thermal zone now, > we can just remove the check. Ah yes, good point! -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog
