Messages in this thread | | | Subject | Re: [RFC] memory: exynos5422-dmc: Document mutex scope | From | Lukasz Luba <> | Date | Tue, 11 Aug 2020 10:27:31 +0100 |
| |
On 8/9/20 10:12 AM, Krzysztof Kozlowski wrote: > On Tue, Aug 04, 2020 at 11:40:07AM +0100, Lukasz Luba wrote: >> Hi Krzysztof, >> >> On 7/24/20 7:08 PM, Krzysztof Kozlowski wrote: >>> Document scope of the mutex used by driver. >>> >>> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> >>> >>> --- >>> >>> It seems mutex was introduced to protect: >>> 1. setting actual frequency/voltage, >>> 2. dmc->curr_rate (in exynos5_dmc_get_cur_freq()). >>> >>> However dmc->curr_rate in exynos5_dmc_get_status() is not protected. Is >>> it a bug? >> >> The callback get_dev_status() from devfreq->profile, which here is the >> exynos5_dmc_get_status() should be already called with devfreq->lock >> mutex hold, like e.g from simple_ondemand governor or directly >> using update_devfreq exported function: >> update_devfreq() >> ->get_target_freq() >> devfreq_update_stats() >> df->profile->get_dev_status() >> >> The dmc->curr_rate is also used from sysfs interface from devfreq. >> The local dmc lock serializes also this use case (when the HW freq >> has changed but not set yet into curr_rate. > > These are different locks. You cannot protect dmc->curr_rate with > devfreq->lock in one place and dmc-lock in other place. This won't > protect it.
There are different paths that framework goes and mainly they are protected by the df->lock. But I tend to agree, I will send a patch which adds some locking.
Regards, Lukasz
| |