On 02/07/2020 19:49, Daniel Lezcano wrote: [ ... ] >> Thanks! >> >> That confirms your suspicions. >> >> 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. > > Why not add change_mode for the acpi in order to enable or disable the > events and for imx_thermal use irq_enabled flag instead of the thermal > zone mode? Moreover it is very unclear why this function is needed in > imx_get_temp(), and I suspect we should be able to get rid of it. If you agree with that you can send a patch on top of your series so I can test it fixes the imx platform. -- <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
