| Message ID | 20250310143450.8276-5-linux.amoon@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Exynos Thermal code improvement | expand |
On 10/03/2025 15:34, Anand Moon wrote: > Using guard notation makes the code more compact and error handling > more robust by ensuring that mutexes are released in all code paths > when control leaves critical section. > Subject: typo, exynos > Signed-off-by: Anand Moon <linux.amoon@gmail.com> > --- > v4: used DEFINE_GUARD macro to guard exynos_tmu_data structure. > However, incorporating guard(exynos_tmu_data)(data); results > in a recursive deadlock with the mutex during initialization, as this > data structure is common to all the code configurations of Exynos TMU > v3: New patch If you ever use cleanup or guards, you must build your code with recent clang and W=1. Failure to do so means you ask reviewers manually to spot issues not visible in the context, instead of using tools. It's a NAK for me. > --- > drivers/thermal/samsung/exynos_tmu.c | 25 +++++++++++-------------- > 1 file changed, 11 insertions(+), 14 deletions(-) > > diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c > index a71cde0a4b17e..85f88c5e0f11c 100644 > --- a/drivers/thermal/samsung/exynos_tmu.c > +++ b/drivers/thermal/samsung/exynos_tmu.c > @@ -12,6 +12,7 @@ > */ > > #include <linux/clk.h> > +#include <linux/cleanup.h> > #include <linux/io.h> > #include <linux/interrupt.h> > #include <linux/module.h> > @@ -199,6 +200,9 @@ struct exynos_tmu_data { > void (*tmu_clear_irqs)(struct exynos_tmu_data *data); > }; > > +DEFINE_GUARD(exynos_tmu_data, struct exynos_tmu_data *, I do not understand why do you need custom guard. > + mutex_lock(&_T->lock), mutex_unlock(&_T->lock)) > + > /* > * TMU treats temperature as a mapped temperature code. > * The temperature is converted differently depending on the calibration type. > @@ -256,7 +260,7 @@ static int exynos_tmu_initialize(struct platform_device *pdev) > unsigned int status; > int ret = 0; > > - mutex_lock(&data->lock); > + guard(mutex)(&data->lock); Which you do not use... Please don't use cleanup.h if you do not know it. It leads to bugs. Best regards, Krzysztof
Hi Krzysztof, Thanks for your review comments. On Tue, 11 Mar 2025 at 23:00, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 10/03/2025 15:34, Anand Moon wrote: > > Using guard notation makes the code more compact and error handling > > more robust by ensuring that mutexes are released in all code paths > > when control leaves critical section. > > > > Subject: typo, exynos Ok. > > > Signed-off-by: Anand Moon <linux.amoon@gmail.com> > > --- > > v4: used DEFINE_GUARD macro to guard exynos_tmu_data structure. > > However, incorporating guard(exynos_tmu_data)(data); results > > in a recursive deadlock with the mutex during initialization, as this > > data structure is common to all the code configurations of Exynos TMU > > v3: New patch > > If you ever use cleanup or guards, you must build your code with recent > clang and W=1. Failure to do so means you ask reviewers manually to spot > issues not visible in the context, instead of using tools. It's a NAK > for me. Ok, I will check this next time before submitting the changes. > > > --- > > drivers/thermal/samsung/exynos_tmu.c | 25 +++++++++++-------------- > > 1 file changed, 11 insertions(+), 14 deletions(-) > > > > diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c > > index a71cde0a4b17e..85f88c5e0f11c 100644 > > --- a/drivers/thermal/samsung/exynos_tmu.c > > +++ b/drivers/thermal/samsung/exynos_tmu.c > > @@ -12,6 +12,7 @@ > > */ > > > > #include <linux/clk.h> > > +#include <linux/cleanup.h> > > #include <linux/io.h> > > #include <linux/interrupt.h> > > #include <linux/module.h> > > @@ -199,6 +200,9 @@ struct exynos_tmu_data { > > void (*tmu_clear_irqs)(struct exynos_tmu_data *data); > > }; > > > > +DEFINE_GUARD(exynos_tmu_data, struct exynos_tmu_data *, > > I do not understand why do you need custom guard. I thought this should add a global guard to exynos_tmu_data using mutex_lock and mutex_unlock. I'll drop this if it turns out to be unnecessary. > > > + mutex_lock(&_T->lock), mutex_unlock(&_T->lock)) > > + > > /* > > * TMU treats temperature as a mapped temperature code. > > * The temperature is converted differently depending on the calibration type. > > @@ -256,7 +260,7 @@ static int exynos_tmu_initialize(struct platform_device *pdev) > > unsigned int status; > > int ret = 0; > > > > - mutex_lock(&data->lock); > > + guard(mutex)(&data->lock); > > Which you do not use... Please don't use cleanup.h if you do not know > it. It leads to bugs. > Ok, I will drop this include of cleanup.h. > > Best regards, > Krzysztof Thanks -Anand
diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c index a71cde0a4b17e..85f88c5e0f11c 100644 --- a/drivers/thermal/samsung/exynos_tmu.c +++ b/drivers/thermal/samsung/exynos_tmu.c @@ -12,6 +12,7 @@ */ #include <linux/clk.h> +#include <linux/cleanup.h> #include <linux/io.h> #include <linux/interrupt.h> #include <linux/module.h> @@ -199,6 +200,9 @@ struct exynos_tmu_data { void (*tmu_clear_irqs)(struct exynos_tmu_data *data); }; +DEFINE_GUARD(exynos_tmu_data, struct exynos_tmu_data *, + mutex_lock(&_T->lock), mutex_unlock(&_T->lock)) + /* * TMU treats temperature as a mapped temperature code. * The temperature is converted differently depending on the calibration type. @@ -256,7 +260,7 @@ static int exynos_tmu_initialize(struct platform_device *pdev) unsigned int status; int ret = 0; - mutex_lock(&data->lock); + guard(mutex)(&data->lock); clk_enable(data->clk); clk_enable(data->clk_sec); @@ -270,7 +274,6 @@ static int exynos_tmu_initialize(struct platform_device *pdev) clk_disable(data->clk_sec); clk_disable(data->clk); - mutex_unlock(&data->lock); return ret; } @@ -292,13 +295,12 @@ static int exynos_thermal_zone_configure(struct platform_device *pdev) return ret; } - mutex_lock(&data->lock); + guard(mutex)(&data->lock); clk_enable(data->clk); data->tmu_set_crit_temp(data, temp / MCELSIUS); clk_disable(data->clk); - mutex_unlock(&data->lock); return 0; } @@ -325,12 +327,11 @@ static void exynos_tmu_control(struct platform_device *pdev, bool on) { struct exynos_tmu_data *data = platform_get_drvdata(pdev); - mutex_lock(&data->lock); + guard(mutex)(&data->lock); clk_enable(data->clk); data->tmu_control(pdev, on); data->enabled = on; clk_disable(data->clk); - mutex_unlock(&data->lock); } static void exynos_tmu_update_bit(struct exynos_tmu_data *data, int reg_off, @@ -645,7 +646,7 @@ static int exynos_get_temp(struct thermal_zone_device *tz, int *temp) */ return -EAGAIN; - mutex_lock(&data->lock); + guard(mutex)(&data->lock); clk_enable(data->clk); value = data->tmu_read(data); @@ -655,7 +656,6 @@ static int exynos_get_temp(struct thermal_zone_device *tz, int *temp) *temp = code_to_temp(data, value) * MCELSIUS; clk_disable(data->clk); - mutex_unlock(&data->lock); return ret; } @@ -720,11 +720,10 @@ static int exynos_tmu_set_emulation(struct thermal_zone_device *tz, int temp) if (temp && temp < MCELSIUS) goto out; - mutex_lock(&data->lock); + guard(mutex)(&data->lock); clk_enable(data->clk); data->tmu_set_emulation(data, temp); clk_disable(data->clk); - mutex_unlock(&data->lock); return 0; out: return ret; @@ -760,14 +759,13 @@ static irqreturn_t exynos_tmu_threaded_irq(int irq, void *id) thermal_zone_device_update(data->tzd, THERMAL_EVENT_UNSPECIFIED); - mutex_lock(&data->lock); + guard(mutex)(&data->lock); clk_enable(data->clk); /* TODO: take action based on particular interrupt */ data->tmu_clear_irqs(data); clk_disable(data->clk); - mutex_unlock(&data->lock); return IRQ_HANDLED; } @@ -987,7 +985,7 @@ static int exynos_set_trips(struct thermal_zone_device *tz, int low, int high) { struct exynos_tmu_data *data = thermal_zone_device_priv(tz); - mutex_lock(&data->lock); + guard(mutex)(&data->lock); clk_enable(data->clk); if (low > INT_MIN) @@ -1000,7 +998,6 @@ static int exynos_set_trips(struct thermal_zone_device *tz, int low, int high) data->tmu_disable_high(data); clk_disable(data->clk); - mutex_unlock(&data->lock); return 0; }
Using guard notation makes the code more compact and error handling more robust by ensuring that mutexes are released in all code paths when control leaves critical section. Signed-off-by: Anand Moon <linux.amoon@gmail.com> --- v4: used DEFINE_GUARD macro to guard exynos_tmu_data structure. However, incorporating guard(exynos_tmu_data)(data); results in a recursive deadlock with the mutex during initialization, as this data structure is common to all the code configurations of Exynos TMU v3: New patch --- drivers/thermal/samsung/exynos_tmu.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-)