diff mbox series

[v4,3/3] spi: geni-qcom: Use devm functions to simplify code

Message ID 20240909132810.1296786-4-ruanjinjie@huawei.com (mailing list archive)
State New
Headers show
Series spi: geni-qcom: Undo runtime PM changes at driver exit time | expand

Commit Message

Jinjie Ruan Sept. 9, 2024, 1:28 p.m. UTC
Use devm_pm_runtime_enable(), devm_request_irq() and
devm_spi_register_controller() to simplify code.

And also register a callback spi_geni_release_dma_chan() with
devm_add_action_or_reset(), to release dma channel in both error
and device detach path, which can make sure the release sequence is
consistent with the original one.

1. Unregister spi controller.
2. Free the IRQ.
3. Free DMA chans
4. Disable runtime PM.

So the remove function can also be removed.

Suggested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
v4:
- Correct the "data" of devm_add_action_or_reset().
v3:
- Land the rest of the cleanups afterwards.
---
 drivers/spi/spi-geni-qcom.c | 37 +++++++++++++------------------------
 1 file changed, 13 insertions(+), 24 deletions(-)

Comments

Doug Anderson Sept. 11, 2024, 10:53 p.m. UTC | #1
Hi,

On Mon, Sep 9, 2024 at 6:19 AM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
> Use devm_pm_runtime_enable(), devm_request_irq() and
> devm_spi_register_controller() to simplify code.
>
> And also register a callback spi_geni_release_dma_chan() with
> devm_add_action_or_reset(), to release dma channel in both error
> and device detach path, which can make sure the release sequence is
> consistent with the original one.
>
> 1. Unregister spi controller.
> 2. Free the IRQ.
> 3. Free DMA chans
> 4. Disable runtime PM.
>
> So the remove function can also be removed.
>
> Suggested-by: Doug Anderson <dianders@chromium.org>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> v4:
> - Correct the "data" of devm_add_action_or_reset().
> v3:
> - Land the rest of the cleanups afterwards.
> ---
>  drivers/spi/spi-geni-qcom.c | 37 +++++++++++++------------------------
>  1 file changed, 13 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index 6f4057330444..5cb002d7d4a6 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -632,8 +632,10 @@ static int spi_geni_grab_gpi_chan(struct spi_geni_master *mas)
>         return ret;
>  }
>
> -static void spi_geni_release_dma_chan(struct spi_geni_master *mas)
> +static void spi_geni_release_dma_chan(void *data)
>  {
> +       struct spi_geni_master *mas = data;
> +
>         if (mas->rx) {
>                 dma_release_channel(mas->rx);
>                 mas->rx = NULL;
> @@ -1132,6 +1134,12 @@ static int spi_geni_probe(struct platform_device *pdev)
>         if (ret)
>                 return ret;
>
> +       ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
> +       if (ret) {
> +               dev_err(dev, "Unable to add action.\n");
> +               return ret;
> +       }

Use dev_err_probe() to simplify.

ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
if (ret)
  return dev_err_probe(dev, ret, "Unable to add action.\n");


Personally I'd also rather that you do the devm_add_action_or_reset()
call straight in spi_geni_grab_gpi_chan(). That makes it much more
obvious what's happening. You can still use dev_err_probe() in there
since it's called (indirectly) from probe. In that case you'd probably
replace the "return 0;" in that function with just "return
dev_err_probe(...)".


> @@ -1146,33 +1154,15 @@ static int spi_geni_probe(struct platform_device *pdev)
>         if (mas->cur_xfer_mode == GENI_GPI_DMA)
>                 spi->flags = SPI_CONTROLLER_MUST_TX;
>
> -       ret = request_irq(mas->irq, geni_spi_isr, 0, dev_name(dev), spi);
> +       ret = devm_request_irq(dev, mas->irq, geni_spi_isr, 0, dev_name(dev), spi);
>         if (ret)
> -               goto spi_geni_release_dma;
> +               return ret;
>
> -       ret = spi_register_controller(spi);
> +       ret = devm_spi_register_controller(dev, spi);
>         if (ret)
> -               goto spi_geni_probe_free_irq;
> +               return ret;
>
>         return 0;

You no longer need the "if" statement or even to assign to "ret". Just:

return devm_spi_register_controller(dev, spi);


Those are just nits, though. I'd be OK with:

Reviewed-by: Douglas Anderson <dianders@chromium.org>

...since Mark has already landed the first two patches, your v5 would
just contain this one patch.

-Doug
Jinjie Ruan Sept. 12, 2024, 3:53 a.m. UTC | #2
On 2024/9/12 6:53, Doug Anderson wrote:
> Hi,
> 
> On Mon, Sep 9, 2024 at 6:19 AM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>>
>> Use devm_pm_runtime_enable(), devm_request_irq() and
>> devm_spi_register_controller() to simplify code.
>>
>> And also register a callback spi_geni_release_dma_chan() with
>> devm_add_action_or_reset(), to release dma channel in both error
>> and device detach path, which can make sure the release sequence is
>> consistent with the original one.
>>
>> 1. Unregister spi controller.
>> 2. Free the IRQ.
>> 3. Free DMA chans
>> 4. Disable runtime PM.
>>
>> So the remove function can also be removed.
>>
>> Suggested-by: Doug Anderson <dianders@chromium.org>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> v4:
>> - Correct the "data" of devm_add_action_or_reset().
>> v3:
>> - Land the rest of the cleanups afterwards.
>> ---
>>  drivers/spi/spi-geni-qcom.c | 37 +++++++++++++------------------------
>>  1 file changed, 13 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
>> index 6f4057330444..5cb002d7d4a6 100644
>> --- a/drivers/spi/spi-geni-qcom.c
>> +++ b/drivers/spi/spi-geni-qcom.c
>> @@ -632,8 +632,10 @@ static int spi_geni_grab_gpi_chan(struct spi_geni_master *mas)
>>         return ret;
>>  }
>>
>> -static void spi_geni_release_dma_chan(struct spi_geni_master *mas)
>> +static void spi_geni_release_dma_chan(void *data)
>>  {
>> +       struct spi_geni_master *mas = data;
>> +
>>         if (mas->rx) {
>>                 dma_release_channel(mas->rx);
>>                 mas->rx = NULL;
>> @@ -1132,6 +1134,12 @@ static int spi_geni_probe(struct platform_device *pdev)
>>         if (ret)
>>                 return ret;
>>
>> +       ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
>> +       if (ret) {
>> +               dev_err(dev, "Unable to add action.\n");
>> +               return ret;
>> +       }
> 
> Use dev_err_probe() to simplify.
> 
> ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
> if (ret)
>   return dev_err_probe(dev, ret, "Unable to add action.\n");

It seems that if it only return -ENOMEM or 0, using dev_err_probe() has
not not much value for many community maintainers.

> 
> 
> Personally I'd also rather that you do the devm_add_action_or_reset()
> call straight in spi_geni_grab_gpi_chan(). That makes it much more

Yes, it will be more clear.

> obvious what's happening. You can still use dev_err_probe() in there
> since it's called (indirectly) from probe. In that case you'd probably
> replace the "return 0;" in that function with just "return
> dev_err_probe(...)".
> 
> 
>> @@ -1146,33 +1154,15 @@ static int spi_geni_probe(struct platform_device *pdev)
>>         if (mas->cur_xfer_mode == GENI_GPI_DMA)
>>                 spi->flags = SPI_CONTROLLER_MUST_TX;
>>
>> -       ret = request_irq(mas->irq, geni_spi_isr, 0, dev_name(dev), spi);
>> +       ret = devm_request_irq(dev, mas->irq, geni_spi_isr, 0, dev_name(dev), spi);
>>         if (ret)
>> -               goto spi_geni_release_dma;
>> +               return ret;
>>
>> -       ret = spi_register_controller(spi);
>> +       ret = devm_spi_register_controller(dev, spi);
>>         if (ret)
>> -               goto spi_geni_probe_free_irq;
>> +               return ret;
>>
>>         return 0;
> 
> You no longer need the "if" statement or even to assign to "ret". Just:
> 
> return devm_spi_register_controller(dev, spi);

Right!

> 
> 
> Those are just nits, though. I'd be OK with:
> 
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> 
> ...since Mark has already landed the first two patches, your v5 would
> just contain this one patch.
> 
> -Doug
Doug Anderson Sept. 12, 2024, 1:38 p.m. UTC | #3
Hi,

On Wed, Sep 11, 2024 at 8:53 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
> >> @@ -1132,6 +1134,12 @@ static int spi_geni_probe(struct platform_device *pdev)
> >>         if (ret)
> >>                 return ret;
> >>
> >> +       ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
> >> +       if (ret) {
> >> +               dev_err(dev, "Unable to add action.\n");
> >> +               return ret;
> >> +       }
> >
> > Use dev_err_probe() to simplify.
> >
> > ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
> > if (ret)
> >   return dev_err_probe(dev, ret, "Unable to add action.\n");
>
> It seems that if it only return -ENOMEM or 0, using dev_err_probe() has
> not not much value for many community maintainers.

While I won't insist, it still has some value to use dev_err_probe()
as I talked about in commit 7065f92255bb ("driver core: Clarify that
dev_err_probe() is OK even w/out -EPROBE_DEFER").

-Doug
Jinjie Ruan Sept. 13, 2024, 6:44 a.m. UTC | #4
On 2024/9/12 21:38, Doug Anderson wrote:
> Hi,
> 
> On Wed, Sep 11, 2024 at 8:53 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>>
>>>> @@ -1132,6 +1134,12 @@ static int spi_geni_probe(struct platform_device *pdev)
>>>>         if (ret)
>>>>                 return ret;
>>>>
>>>> +       ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
>>>> +       if (ret) {
>>>> +               dev_err(dev, "Unable to add action.\n");
>>>> +               return ret;
>>>> +       }
>>>
>>> Use dev_err_probe() to simplify.
>>>
>>> ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
>>> if (ret)
>>>   return dev_err_probe(dev, ret, "Unable to add action.\n");
>>
>> It seems that if it only return -ENOMEM or 0, using dev_err_probe() has
>> not not much value for many community maintainers.
> 
> While I won't insist, it still has some value to use dev_err_probe()
> as I talked about in commit 7065f92255bb ("driver core: Clarify that
> dev_err_probe() is OK even w/out -EPROBE_DEFER")
The main difference is that when use dev_err_probe(),there will print
anything on -ENOMEM now.



> 
> -Doug
Doug Anderson Sept. 13, 2024, 4:27 p.m. UTC | #5
Hi,

On Thu, Sep 12, 2024 at 11:44 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
> On 2024/9/12 21:38, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, Sep 11, 2024 at 8:53 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
> >>
> >>>> @@ -1132,6 +1134,12 @@ static int spi_geni_probe(struct platform_device *pdev)
> >>>>         if (ret)
> >>>>                 return ret;
> >>>>
> >>>> +       ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
> >>>> +       if (ret) {
> >>>> +               dev_err(dev, "Unable to add action.\n");
> >>>> +               return ret;
> >>>> +       }
> >>>
> >>> Use dev_err_probe() to simplify.
> >>>
> >>> ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
> >>> if (ret)
> >>>   return dev_err_probe(dev, ret, "Unable to add action.\n");
> >>
> >> It seems that if it only return -ENOMEM or 0, using dev_err_probe() has
> >> not not much value for many community maintainers.
> >
> > While I won't insist, it still has some value to use dev_err_probe()
> > as I talked about in commit 7065f92255bb ("driver core: Clarify that
> > dev_err_probe() is OK even w/out -EPROBE_DEFER")
> The main difference is that when use dev_err_probe(),there will print
> anything on -ENOMEM now.

Oh, I see. You're saying that we should just get rid of the print
altogether because the only error case is -ENOMEM and the kernel
already splats there? Yeah, that sounds right to me. That doesn't
match what you did in v5, though...

-Doug
Jinjie Ruan Sept. 14, 2024, 1:17 a.m. UTC | #6
On 2024/9/14 0:27, Doug Anderson wrote:
> Hi,
> 
> On Thu, Sep 12, 2024 at 11:44 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>>
>> On 2024/9/12 21:38, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Wed, Sep 11, 2024 at 8:53 PM Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>>>>
>>>>>> @@ -1132,6 +1134,12 @@ static int spi_geni_probe(struct platform_device *pdev)
>>>>>>         if (ret)
>>>>>>                 return ret;
>>>>>>
>>>>>> +       ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
>>>>>> +       if (ret) {
>>>>>> +               dev_err(dev, "Unable to add action.\n");
>>>>>> +               return ret;
>>>>>> +       }
>>>>>
>>>>> Use dev_err_probe() to simplify.
>>>>>
>>>>> ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
>>>>> if (ret)
>>>>>   return dev_err_probe(dev, ret, "Unable to add action.\n");
>>>>
>>>> It seems that if it only return -ENOMEM or 0, using dev_err_probe() has
>>>> not not much value for many community maintainers.
>>>
>>> While I won't insist, it still has some value to use dev_err_probe()
>>> as I talked about in commit 7065f92255bb ("driver core: Clarify that
>>> dev_err_probe() is OK even w/out -EPROBE_DEFER")
>> The main difference is that when use dev_err_probe(),there will print
>> anything on -ENOMEM now.
> 
> Oh, I see. You're saying that we should just get rid of the print
> altogether because the only error case is -ENOMEM and the kernel
> already splats there? Yeah, that sounds right to me. That doesn't
> match what you did in v5, though...

I think the following 2 soultion is both fine:

1、return ret directly.

2、dev_err() and return.

> 
> -Doug
diff mbox series

Patch

diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index 6f4057330444..5cb002d7d4a6 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -632,8 +632,10 @@  static int spi_geni_grab_gpi_chan(struct spi_geni_master *mas)
 	return ret;
 }
 
-static void spi_geni_release_dma_chan(struct spi_geni_master *mas)
+static void spi_geni_release_dma_chan(void *data)
 {
+	struct spi_geni_master *mas = data;
+
 	if (mas->rx) {
 		dma_release_channel(mas->rx);
 		mas->rx = NULL;
@@ -1132,6 +1134,12 @@  static int spi_geni_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	ret = devm_add_action_or_reset(dev, spi_geni_release_dma_chan, mas);
+	if (ret) {
+		dev_err(dev, "Unable to add action.\n");
+		return ret;
+	}
+
 	/*
 	 * check the mode supported and set_cs for fifo mode only
 	 * for dma (gsi) mode, the gsi will set cs based on params passed in
@@ -1146,33 +1154,15 @@  static int spi_geni_probe(struct platform_device *pdev)
 	if (mas->cur_xfer_mode == GENI_GPI_DMA)
 		spi->flags = SPI_CONTROLLER_MUST_TX;
 
-	ret = request_irq(mas->irq, geni_spi_isr, 0, dev_name(dev), spi);
+	ret = devm_request_irq(dev, mas->irq, geni_spi_isr, 0, dev_name(dev), spi);
 	if (ret)
-		goto spi_geni_release_dma;
+		return ret;
 
-	ret = spi_register_controller(spi);
+	ret = devm_spi_register_controller(dev, spi);
 	if (ret)
-		goto spi_geni_probe_free_irq;
+		return ret;
 
 	return 0;
-spi_geni_probe_free_irq:
-	free_irq(mas->irq, spi);
-spi_geni_release_dma:
-	spi_geni_release_dma_chan(mas);
-	return ret;
-}
-
-static void spi_geni_remove(struct platform_device *pdev)
-{
-	struct spi_controller *spi = platform_get_drvdata(pdev);
-	struct spi_geni_master *mas = spi_controller_get_devdata(spi);
-
-	/* Unregister _before_ disabling pm_runtime() so we stop transfers */
-	spi_unregister_controller(spi);
-
-	free_irq(mas->irq, spi);
-
-	spi_geni_release_dma_chan(mas);
 }
 
 static int __maybe_unused spi_geni_runtime_suspend(struct device *dev)
@@ -1254,7 +1244,6 @@  MODULE_DEVICE_TABLE(of, spi_geni_dt_match);
 
 static struct platform_driver spi_geni_driver = {
 	.probe  = spi_geni_probe,
-	.remove_new = spi_geni_remove,
 	.driver = {
 		.name = "geni_spi",
 		.pm = &spi_geni_pm_ops,