[PATCH] iio: adc: xilinx-ams: Use devm_delayed_work_autocancel() to simplify code

[PATCH] iio: adc: xilinx-ams: Use devm_delayed_work_autocancel() to simplify code

[Christophe JAILLET]

Use devm_delayed_work_autocancel() instead of hand writing it. This is
less verbose and saves a few lines of code.

devm_delayed_work_autocancel() uses devm_add_action() instead of
devm_add_action_or_reset(). This is fine, because if the underlying memory
allocation fails, no work has been scheduled yet. So there is nothing to
undo.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
 drivers/iio/adc/xilinx-ams.c | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
index 8343c5f74121..6ffddf4038b8 100644
--- a/drivers/iio/adc/xilinx-ams.c
+++ b/drivers/iio/adc/xilinx-ams.c
@@ -12,6 +12,7 @@
 #include <linux/bitfield.h>
 #include <linux/clk.h>
 #include <linux/delay.h>
+#include <linux/devm-helpers.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/iopoll.h>
@@ -1348,11 +1349,6 @@ static void ams_clk_disable_unprepare(void *data)
 	clk_disable_unprepare(data);
 }
 
-static void ams_cancel_delayed_work(void *data)
-{
-	cancel_delayed_work(data);
-}
-
 static int ams_probe(struct platform_device *pdev)
 {
 	struct iio_dev *indio_dev;
@@ -1389,9 +1385,8 @@ static int ams_probe(struct platform_device *pdev)
 	if (ret < 0)
 		return ret;
 
-	INIT_DELAYED_WORK(&ams->ams_unmask_work, ams_unmask_worker);
-	ret = devm_add_action_or_reset(&pdev->dev, ams_cancel_delayed_work,
-				       &ams->ams_unmask_work);
+	ret = devm_delayed_work_autocancel(&pdev->dev, &ams->ams_unmask_work,
+					   ams_unmask_worker);
 	if (ret < 0)
 		return ret;
 
-- 
2.32.0

Re: [PATCH] iio: adc: xilinx-ams: Use devm_delayed_work_autocancel() to simplify code

[Jonathan Cameron]

On Sun, 13 Feb 2022 19:29:05 +0100
Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote:

> Use devm_delayed_work_autocancel() instead of hand writing it. This is
> less verbose and saves a few lines of code.
> 
> devm_delayed_work_autocancel() uses devm_add_action() instead of
> devm_add_action_or_reset(). This is fine, because if the underlying memory
> allocation fails, no work has been scheduled yet. So there is nothing to
> undo.
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Looks good to me, but I'd ideally like some input from someone familiar with
the driver.

Thanks,

Jonathan

> ---
>  drivers/iio/adc/xilinx-ams.c | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c
> index 8343c5f74121..6ffddf4038b8 100644
> --- a/drivers/iio/adc/xilinx-ams.c
> +++ b/drivers/iio/adc/xilinx-ams.c
> @@ -12,6 +12,7 @@
>  #include <linux/bitfield.h>
>  #include <linux/clk.h>
>  #include <linux/delay.h>
> +#include <linux/devm-helpers.h>
>  #include <linux/interrupt.h>
>  #include <linux/io.h>
>  #include <linux/iopoll.h>
> @@ -1348,11 +1349,6 @@ static void ams_clk_disable_unprepare(void *data)
>  	clk_disable_unprepare(data);
>  }
>  
> -static void ams_cancel_delayed_work(void *data)
> -{
> -	cancel_delayed_work(data);
> -}
> -
>  static int ams_probe(struct platform_device *pdev)
>  {
>  	struct iio_dev *indio_dev;
> @@ -1389,9 +1385,8 @@ static int ams_probe(struct platform_device *pdev)
>  	if (ret < 0)
>  		return ret;
>  
> -	INIT_DELAYED_WORK(&ams->ams_unmask_work, ams_unmask_worker);
> -	ret = devm_add_action_or_reset(&pdev->dev, ams_cancel_delayed_work,
> -				       &ams->ams_unmask_work);
> +	ret = devm_delayed_work_autocancel(&pdev->dev, &ams->ams_unmask_work,
> +					   ams_unmask_worker);
>  	if (ret < 0)
>  		return ret;
>  

Re: [PATCH] iio: adc: xilinx-ams: Use devm_delayed_work_autocancel() to simplify code

[Michal Simek]

Hi,

On 2/20/22 12:45, Jonathan Cameron wrote:
> On Sun, 13 Feb 2022 19:29:05 +0100
> Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote:
> 
>> Use devm_delayed_work_autocancel() instead of hand writing it. This is
>> less verbose and saves a few lines of code.
>>
>> devm_delayed_work_autocancel() uses devm_add_action() instead of
>> devm_add_action_or_reset(). This is fine, because if the underlying memory
>> allocation fails, no work has been scheduled yet. So there is nothing to
>> undo.
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> Looks good to me, but I'd ideally like some input from someone familiar with
> the driver.

Anand told me that the change is fine that's why here is my
Acked-by: Michal Simek <michal.simek@xilinx.com>

Jonathan: Anand decided to do change in his carrier that's why that emails won't 
go through. But I am still around if you need something xilinx/amd to test.

Thanks,
Michal

Re: [PATCH] iio: adc: xilinx-ams: Use devm_delayed_work_autocancel() to simplify code

[Jonathan Cameron]

On Mon, 21 Feb 2022 11:02:00 +0100
Michal Simek <monstr@monstr.eu> wrote:

> Hi,
> 
> On 2/20/22 12:45, Jonathan Cameron wrote:
> > On Sun, 13 Feb 2022 19:29:05 +0100
> > Christophe JAILLET <christophe.jaillet@wanadoo.fr> wrote:
> >   
> >> Use devm_delayed_work_autocancel() instead of hand writing it. This is
> >> less verbose and saves a few lines of code.
> >>
> >> devm_delayed_work_autocancel() uses devm_add_action() instead of
> >> devm_add_action_or_reset(). This is fine, because if the underlying memory
> >> allocation fails, no work has been scheduled yet. So there is nothing to
> >> undo.
> >>
> >> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>  
> > Looks good to me, but I'd ideally like some input from someone familiar with
> > the driver.  
> 
> Anand told me that the change is fine that's why here is my
> Acked-by: Michal Simek <michal.simek@xilinx.com>
> 
> Jonathan: Anand decided to do change in his carrier that's why that emails won't 
> go through. But I am still around if you need something xilinx/amd to test.
> 
> Thanks,
> Michal

Thanks Michal and best wishes to Anand for whatever comes next!

Applied to the togreg branch of iio.git and pushed out as testing for
0-day to take a quick look before I expose this to linux-next.

Thanks,

Jonathan