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