On 03/07/2020 12:45, Andrzej Pietrasiewicz wrote: > Hi, > > W dniu 03.07.2020 o 08:38, Daniel Lezcano pisze: >> 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! >> >> >> > > I sent a short series with fixes. Daniel, can you kindly test it? I confirm the i.MX is now correctly booting with the thermal zone temperature available. -- <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
