* [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs
@ 2025-10-23 14:54 Rakuram Eswaran
2025-10-28 15:50 ` Khalid Aziz
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Rakuram Eswaran @ 2025-10-23 14:54 UTC (permalink / raw)
To: ulf.hansson, u.kleine-koenig
Cc: chenhuacai, dan.carpenter, david.hunter.linux, khalid, zhoubinbin,
linux-kernel-mentees, linux-kernel, linux-mmc, lkp, rakuram.e96,
skhan
This patch refactors pxamci_probe() to use devm-managed resource
allocation (e.g. devm_dma_request_chan) and dev_err_probe() for
improved readability and automatic cleanup on probe failure.
It also removes redundant NULL assignments and manual resource release
logic from pxamci_probe(), and eliminates the corresponding release
calls from pxamci_remove().
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Closes: https://lore.kernel.org/r/202510041841.pRlunIfl-lkp@intel.com/
Fixes: 58c40f3faf742c ("mmc: pxamci: Use devm_mmc_alloc_host() helper")
Suggested-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Signed-off-by: Rakuram Eswaran <rakuram.e96@gmail.com>
---
Changes since v2:
- Dropped redundant dma_release_channel() calls from pxamci_remove() as
devm_dma_request_chan() automatically handles resource cleanup.
- Added link to v2 for reference:
https://lore.kernel.org/linux-mmc/20251014184657.111144-1-rakuram.e96@gmail.com/
Changes since v1:
Following Uwe Kleine-König’s suggestion:
- Replaced dma_request_chan() with devm_dma_request_chan() to make DMA
channel allocation devm-managed and avoid manual release paths.
- Adopted dev_err_probe() for improved error reporting and consistent
probe failure handling.
- Removed redundant NULL assignments and obsolete goto-based cleanup logic.
- Updated commit message to better describe the intent of the change.
- Added link to v1 for reference:
https://lore.kernel.org/linux-mmc/20251007161948.12442-1-rakuram.e96@gmail.com/
Testing note:
I do not have access to appropriate hardware for runtime testing.
Any help verifying on actual hardware would be appreciated.
Build and Analysis:
This patch was compiled against the configuration file reported by
0day CI in the above link (config: s390-randconfig-r071-20251004) using
`s390x-linux-gnu-gcc (Ubuntu 14.2.0-19ubuntu2) 14.2.0`.
Static analysis was performed with Smatch to ensure the reported warning
no longer reproduces after applying this fix.
Command used for verification:
ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- \
~/project/smatch/smatch_scripts/kchecker ./drivers/mmc/host/pxamci.c
drivers/mmc/host/pxamci.c | 56 +++++++++++++--------------------------
1 file changed, 18 insertions(+), 38 deletions(-)
diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
index 26d03352af63..b5ea058ed467 100644
--- a/drivers/mmc/host/pxamci.c
+++ b/drivers/mmc/host/pxamci.c
@@ -652,10 +652,9 @@ static int pxamci_probe(struct platform_device *pdev)
host->clkrt = CLKRT_OFF;
host->clk = devm_clk_get(dev, NULL);
- if (IS_ERR(host->clk)) {
- host->clk = NULL;
- return PTR_ERR(host->clk);
- }
+ if (IS_ERR(host->clk))
+ return dev_err_probe(dev, PTR_ERR(host->clk),
+ "Failed to acquire clock\n");
host->clkrate = clk_get_rate(host->clk);
@@ -703,46 +702,37 @@ static int pxamci_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mmc);
- host->dma_chan_rx = dma_request_chan(dev, "rx");
- if (IS_ERR(host->dma_chan_rx)) {
- host->dma_chan_rx = NULL;
+ host->dma_chan_rx = devm_dma_request_chan(dev, "rx");
+ if (IS_ERR(host->dma_chan_rx))
return dev_err_probe(dev, PTR_ERR(host->dma_chan_rx),
"unable to request rx dma channel\n");
- }
- host->dma_chan_tx = dma_request_chan(dev, "tx");
- if (IS_ERR(host->dma_chan_tx)) {
- dev_err(dev, "unable to request tx dma channel\n");
- ret = PTR_ERR(host->dma_chan_tx);
- host->dma_chan_tx = NULL;
- goto out;
- }
+
+ host->dma_chan_tx = devm_dma_request_chan(dev, "tx");
+ if (IS_ERR(host->dma_chan_tx))
+ return dev_err_probe(dev, PTR_ERR(host->dma_chan_tx),
+ "unable to request tx dma channel\n");
if (host->pdata) {
host->detect_delay_ms = host->pdata->detect_delay_ms;
host->power = devm_gpiod_get_optional(dev, "power", GPIOD_OUT_LOW);
- if (IS_ERR(host->power)) {
- ret = PTR_ERR(host->power);
- dev_err(dev, "Failed requesting gpio_power\n");
- goto out;
- }
+ if (IS_ERR(host->power))
+ return dev_err_probe(dev, PTR_ERR(host->power),
+ "Failed requesting gpio_power\n");
/* FIXME: should we pass detection delay to debounce? */
ret = mmc_gpiod_request_cd(mmc, "cd", 0, false, 0);
- if (ret && ret != -ENOENT) {
- dev_err(dev, "Failed requesting gpio_cd\n");
- goto out;
- }
+ if (ret && ret != -ENOENT)
+ return dev_err_probe(dev, ret, "Failed requesting gpio_cd\n");
if (!host->pdata->gpio_card_ro_invert)
mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
ret = mmc_gpiod_request_ro(mmc, "wp", 0, 0);
- if (ret && ret != -ENOENT) {
- dev_err(dev, "Failed requesting gpio_ro\n");
- goto out;
- }
+ if (ret && ret != -ENOENT)
+ return dev_err_probe(dev, ret, "Failed requesting gpio_ro\n");
+
if (!ret)
host->use_ro_gpio = true;
@@ -759,16 +749,8 @@ static int pxamci_probe(struct platform_device *pdev)
if (ret) {
if (host->pdata && host->pdata->exit)
host->pdata->exit(dev, mmc);
- goto out;
}
- return 0;
-
-out:
- if (host->dma_chan_rx)
- dma_release_channel(host->dma_chan_rx);
- if (host->dma_chan_tx)
- dma_release_channel(host->dma_chan_tx);
return ret;
}
@@ -791,8 +773,6 @@ static void pxamci_remove(struct platform_device *pdev)
dmaengine_terminate_all(host->dma_chan_rx);
dmaengine_terminate_all(host->dma_chan_tx);
- dma_release_channel(host->dma_chan_rx);
- dma_release_channel(host->dma_chan_tx);
}
}
--
2.48.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs
2025-10-23 14:54 [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs Rakuram Eswaran
@ 2025-10-28 15:50 ` Khalid Aziz
2025-10-29 10:06 ` Uwe Kleine-König
2025-11-11 17:36 ` Ulf Hansson
2 siblings, 0 replies; 8+ messages in thread
From: Khalid Aziz @ 2025-10-28 15:50 UTC (permalink / raw)
To: Rakuram Eswaran, ulf.hansson, u.kleine-koenig
Cc: chenhuacai, dan.carpenter, david.hunter.linux, zhoubinbin,
linux-kernel-mentees, linux-kernel, linux-mmc, lkp, skhan
On 10/23/25 8:54 AM, Rakuram Eswaran wrote:
> This patch refactors pxamci_probe() to use devm-managed resource
> allocation (e.g. devm_dma_request_chan) and dev_err_probe() for
> improved readability and automatic cleanup on probe failure.
>
> It also removes redundant NULL assignments and manual resource release
> logic from pxamci_probe(), and eliminates the corresponding release
> calls from pxamci_remove().
>
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Closes: https://lore.kernel.org/r/202510041841.pRlunIfl-lkp@intel.com/
> Fixes: 58c40f3faf742c ("mmc: pxamci: Use devm_mmc_alloc_host() helper")
> Suggested-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> Signed-off-by: Rakuram Eswaran <rakuram.e96@gmail.com>
> ---
This looks good to me now.
Reviewed-by: Khalid Aziz <khalid@kernel.org>
--
Khalid
>
> Changes since v2:
> - Dropped redundant dma_release_channel() calls from pxamci_remove() as
> devm_dma_request_chan() automatically handles resource cleanup.
> - Added link to v2 for reference:
> https://lore.kernel.org/linux-mmc/20251014184657.111144-1-rakuram.e96@gmail.com/
>
> Changes since v1:
> Following Uwe Kleine-König’s suggestion:
> - Replaced dma_request_chan() with devm_dma_request_chan() to make DMA
> channel allocation devm-managed and avoid manual release paths.
> - Adopted dev_err_probe() for improved error reporting and consistent
> probe failure handling.
> - Removed redundant NULL assignments and obsolete goto-based cleanup logic.
> - Updated commit message to better describe the intent of the change.
> - Added link to v1 for reference:
> https://lore.kernel.org/linux-mmc/20251007161948.12442-1-rakuram.e96@gmail.com/
>
> Testing note:
> I do not have access to appropriate hardware for runtime testing.
> Any help verifying on actual hardware would be appreciated.
>
> Build and Analysis:
> This patch was compiled against the configuration file reported by
> 0day CI in the above link (config: s390-randconfig-r071-20251004) using
> `s390x-linux-gnu-gcc (Ubuntu 14.2.0-19ubuntu2) 14.2.0`.
>
> Static analysis was performed with Smatch to ensure the reported warning
> no longer reproduces after applying this fix.
>
> Command used for verification:
> ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- \
> ~/project/smatch/smatch_scripts/kchecker ./drivers/mmc/host/pxamci.c
>
> drivers/mmc/host/pxamci.c | 56 +++++++++++++--------------------------
> 1 file changed, 18 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
> index 26d03352af63..b5ea058ed467 100644
> --- a/drivers/mmc/host/pxamci.c
> +++ b/drivers/mmc/host/pxamci.c
> @@ -652,10 +652,9 @@ static int pxamci_probe(struct platform_device *pdev)
> host->clkrt = CLKRT_OFF;
>
> host->clk = devm_clk_get(dev, NULL);
> - if (IS_ERR(host->clk)) {
> - host->clk = NULL;
> - return PTR_ERR(host->clk);
> - }
> + if (IS_ERR(host->clk))
> + return dev_err_probe(dev, PTR_ERR(host->clk),
> + "Failed to acquire clock\n");
>
> host->clkrate = clk_get_rate(host->clk);
>
> @@ -703,46 +702,37 @@ static int pxamci_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, mmc);
>
> - host->dma_chan_rx = dma_request_chan(dev, "rx");
> - if (IS_ERR(host->dma_chan_rx)) {
> - host->dma_chan_rx = NULL;
> + host->dma_chan_rx = devm_dma_request_chan(dev, "rx");
> + if (IS_ERR(host->dma_chan_rx))
> return dev_err_probe(dev, PTR_ERR(host->dma_chan_rx),
> "unable to request rx dma channel\n");
> - }
>
> - host->dma_chan_tx = dma_request_chan(dev, "tx");
> - if (IS_ERR(host->dma_chan_tx)) {
> - dev_err(dev, "unable to request tx dma channel\n");
> - ret = PTR_ERR(host->dma_chan_tx);
> - host->dma_chan_tx = NULL;
> - goto out;
> - }
> +
> + host->dma_chan_tx = devm_dma_request_chan(dev, "tx");
> + if (IS_ERR(host->dma_chan_tx))
> + return dev_err_probe(dev, PTR_ERR(host->dma_chan_tx),
> + "unable to request tx dma channel\n");
>
> if (host->pdata) {
> host->detect_delay_ms = host->pdata->detect_delay_ms;
>
> host->power = devm_gpiod_get_optional(dev, "power", GPIOD_OUT_LOW);
> - if (IS_ERR(host->power)) {
> - ret = PTR_ERR(host->power);
> - dev_err(dev, "Failed requesting gpio_power\n");
> - goto out;
> - }
> + if (IS_ERR(host->power))
> + return dev_err_probe(dev, PTR_ERR(host->power),
> + "Failed requesting gpio_power\n");
>
> /* FIXME: should we pass detection delay to debounce? */
> ret = mmc_gpiod_request_cd(mmc, "cd", 0, false, 0);
> - if (ret && ret != -ENOENT) {
> - dev_err(dev, "Failed requesting gpio_cd\n");
> - goto out;
> - }
> + if (ret && ret != -ENOENT)
> + return dev_err_probe(dev, ret, "Failed requesting gpio_cd\n");
>
> if (!host->pdata->gpio_card_ro_invert)
> mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
>
> ret = mmc_gpiod_request_ro(mmc, "wp", 0, 0);
> - if (ret && ret != -ENOENT) {
> - dev_err(dev, "Failed requesting gpio_ro\n");
> - goto out;
> - }
> + if (ret && ret != -ENOENT)
> + return dev_err_probe(dev, ret, "Failed requesting gpio_ro\n");
> +
> if (!ret)
> host->use_ro_gpio = true;
>
> @@ -759,16 +749,8 @@ static int pxamci_probe(struct platform_device *pdev)
> if (ret) {
> if (host->pdata && host->pdata->exit)
> host->pdata->exit(dev, mmc);
> - goto out;
> }
>
> - return 0;
> -
> -out:
> - if (host->dma_chan_rx)
> - dma_release_channel(host->dma_chan_rx);
> - if (host->dma_chan_tx)
> - dma_release_channel(host->dma_chan_tx);
> return ret;
> }
>
> @@ -791,8 +773,6 @@ static void pxamci_remove(struct platform_device *pdev)
>
> dmaengine_terminate_all(host->dma_chan_rx);
> dmaengine_terminate_all(host->dma_chan_tx);
> - dma_release_channel(host->dma_chan_rx);
> - dma_release_channel(host->dma_chan_tx);
> }
> }
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs
2025-10-23 14:54 [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs Rakuram Eswaran
2025-10-28 15:50 ` Khalid Aziz
@ 2025-10-29 10:06 ` Uwe Kleine-König
2025-11-11 17:36 ` Ulf Hansson
2 siblings, 0 replies; 8+ messages in thread
From: Uwe Kleine-König @ 2025-10-29 10:06 UTC (permalink / raw)
To: Rakuram Eswaran
Cc: ulf.hansson, chenhuacai, dan.carpenter, david.hunter.linux,
khalid, zhoubinbin, linux-kernel-mentees, linux-kernel, linux-mmc,
lkp, skhan
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
Hello,
On Thu, Oct 23, 2025 at 08:24:32PM +0530, Rakuram Eswaran wrote:
> This patch refactors pxamci_probe() to use devm-managed resource
> allocation (e.g. devm_dma_request_chan) and dev_err_probe() for
> improved readability and automatic cleanup on probe failure.
>
> It also removes redundant NULL assignments and manual resource release
> logic from pxamci_probe(), and eliminates the corresponding release
> calls from pxamci_remove().
>
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Closes: https://lore.kernel.org/r/202510041841.pRlunIfl-lkp@intel.com/
> Fixes: 58c40f3faf742c ("mmc: pxamci: Use devm_mmc_alloc_host() helper")
> Suggested-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> Signed-off-by: Rakuram Eswaran <rakuram.e96@gmail.com>
LGTM, thanks
Acked-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs
2025-10-23 14:54 [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs Rakuram Eswaran
2025-10-28 15:50 ` Khalid Aziz
2025-10-29 10:06 ` Uwe Kleine-König
@ 2025-11-11 17:36 ` Ulf Hansson
2025-11-18 14:23 ` Rakuram Eswaran
2 siblings, 1 reply; 8+ messages in thread
From: Ulf Hansson @ 2025-11-11 17:36 UTC (permalink / raw)
To: Rakuram Eswaran
Cc: u.kleine-koenig, chenhuacai, dan.carpenter, david.hunter.linux,
khalid, zhoubinbin, linux-kernel-mentees, linux-kernel, linux-mmc,
lkp, skhan
On Thu, 23 Oct 2025 at 16:54, Rakuram Eswaran <rakuram.e96@gmail.com> wrote:
>
> This patch refactors pxamci_probe() to use devm-managed resource
> allocation (e.g. devm_dma_request_chan) and dev_err_probe() for
> improved readability and automatic cleanup on probe failure.
>
> It also removes redundant NULL assignments and manual resource release
> logic from pxamci_probe(), and eliminates the corresponding release
> calls from pxamci_remove().
>
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> Closes: https://lore.kernel.org/r/202510041841.pRlunIfl-lkp@intel.com/
> Fixes: 58c40f3faf742c ("mmc: pxamci: Use devm_mmc_alloc_host() helper")
> Suggested-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> Signed-off-by: Rakuram Eswaran <rakuram.e96@gmail.com>
Applied for fixes, thanks!
Kind regards
Uffe
> ---
>
> Changes since v2:
> - Dropped redundant dma_release_channel() calls from pxamci_remove() as
> devm_dma_request_chan() automatically handles resource cleanup.
> - Added link to v2 for reference:
> https://lore.kernel.org/linux-mmc/20251014184657.111144-1-rakuram.e96@gmail.com/
>
> Changes since v1:
> Following Uwe Kleine-König’s suggestion:
> - Replaced dma_request_chan() with devm_dma_request_chan() to make DMA
> channel allocation devm-managed and avoid manual release paths.
> - Adopted dev_err_probe() for improved error reporting and consistent
> probe failure handling.
> - Removed redundant NULL assignments and obsolete goto-based cleanup logic.
> - Updated commit message to better describe the intent of the change.
> - Added link to v1 for reference:
> https://lore.kernel.org/linux-mmc/20251007161948.12442-1-rakuram.e96@gmail.com/
>
> Testing note:
> I do not have access to appropriate hardware for runtime testing.
> Any help verifying on actual hardware would be appreciated.
>
> Build and Analysis:
> This patch was compiled against the configuration file reported by
> 0day CI in the above link (config: s390-randconfig-r071-20251004) using
> `s390x-linux-gnu-gcc (Ubuntu 14.2.0-19ubuntu2) 14.2.0`.
>
> Static analysis was performed with Smatch to ensure the reported warning
> no longer reproduces after applying this fix.
>
> Command used for verification:
> ARCH=s390 CROSS_COMPILE=s390x-linux-gnu- \
> ~/project/smatch/smatch_scripts/kchecker ./drivers/mmc/host/pxamci.c
>
> drivers/mmc/host/pxamci.c | 56 +++++++++++++--------------------------
> 1 file changed, 18 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/mmc/host/pxamci.c b/drivers/mmc/host/pxamci.c
> index 26d03352af63..b5ea058ed467 100644
> --- a/drivers/mmc/host/pxamci.c
> +++ b/drivers/mmc/host/pxamci.c
> @@ -652,10 +652,9 @@ static int pxamci_probe(struct platform_device *pdev)
> host->clkrt = CLKRT_OFF;
>
> host->clk = devm_clk_get(dev, NULL);
> - if (IS_ERR(host->clk)) {
> - host->clk = NULL;
> - return PTR_ERR(host->clk);
> - }
> + if (IS_ERR(host->clk))
> + return dev_err_probe(dev, PTR_ERR(host->clk),
> + "Failed to acquire clock\n");
>
> host->clkrate = clk_get_rate(host->clk);
>
> @@ -703,46 +702,37 @@ static int pxamci_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, mmc);
>
> - host->dma_chan_rx = dma_request_chan(dev, "rx");
> - if (IS_ERR(host->dma_chan_rx)) {
> - host->dma_chan_rx = NULL;
> + host->dma_chan_rx = devm_dma_request_chan(dev, "rx");
> + if (IS_ERR(host->dma_chan_rx))
> return dev_err_probe(dev, PTR_ERR(host->dma_chan_rx),
> "unable to request rx dma channel\n");
> - }
>
> - host->dma_chan_tx = dma_request_chan(dev, "tx");
> - if (IS_ERR(host->dma_chan_tx)) {
> - dev_err(dev, "unable to request tx dma channel\n");
> - ret = PTR_ERR(host->dma_chan_tx);
> - host->dma_chan_tx = NULL;
> - goto out;
> - }
> +
> + host->dma_chan_tx = devm_dma_request_chan(dev, "tx");
> + if (IS_ERR(host->dma_chan_tx))
> + return dev_err_probe(dev, PTR_ERR(host->dma_chan_tx),
> + "unable to request tx dma channel\n");
>
> if (host->pdata) {
> host->detect_delay_ms = host->pdata->detect_delay_ms;
>
> host->power = devm_gpiod_get_optional(dev, "power", GPIOD_OUT_LOW);
> - if (IS_ERR(host->power)) {
> - ret = PTR_ERR(host->power);
> - dev_err(dev, "Failed requesting gpio_power\n");
> - goto out;
> - }
> + if (IS_ERR(host->power))
> + return dev_err_probe(dev, PTR_ERR(host->power),
> + "Failed requesting gpio_power\n");
>
> /* FIXME: should we pass detection delay to debounce? */
> ret = mmc_gpiod_request_cd(mmc, "cd", 0, false, 0);
> - if (ret && ret != -ENOENT) {
> - dev_err(dev, "Failed requesting gpio_cd\n");
> - goto out;
> - }
> + if (ret && ret != -ENOENT)
> + return dev_err_probe(dev, ret, "Failed requesting gpio_cd\n");
>
> if (!host->pdata->gpio_card_ro_invert)
> mmc->caps2 |= MMC_CAP2_RO_ACTIVE_HIGH;
>
> ret = mmc_gpiod_request_ro(mmc, "wp", 0, 0);
> - if (ret && ret != -ENOENT) {
> - dev_err(dev, "Failed requesting gpio_ro\n");
> - goto out;
> - }
> + if (ret && ret != -ENOENT)
> + return dev_err_probe(dev, ret, "Failed requesting gpio_ro\n");
> +
> if (!ret)
> host->use_ro_gpio = true;
>
> @@ -759,16 +749,8 @@ static int pxamci_probe(struct platform_device *pdev)
> if (ret) {
> if (host->pdata && host->pdata->exit)
> host->pdata->exit(dev, mmc);
> - goto out;
> }
>
> - return 0;
> -
> -out:
> - if (host->dma_chan_rx)
> - dma_release_channel(host->dma_chan_rx);
> - if (host->dma_chan_tx)
> - dma_release_channel(host->dma_chan_tx);
> return ret;
> }
>
> @@ -791,8 +773,6 @@ static void pxamci_remove(struct platform_device *pdev)
>
> dmaengine_terminate_all(host->dma_chan_rx);
> dmaengine_terminate_all(host->dma_chan_tx);
> - dma_release_channel(host->dma_chan_rx);
> - dma_release_channel(host->dma_chan_tx);
> }
> }
>
> --
> 2.48.1
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs
2025-11-11 17:36 ` Ulf Hansson
@ 2025-11-18 14:23 ` Rakuram Eswaran
2025-11-18 16:14 ` Uwe Kleine-König
0 siblings, 1 reply; 8+ messages in thread
From: Rakuram Eswaran @ 2025-11-18 14:23 UTC (permalink / raw)
To: ulf.hansson, u.kleine-koenig
Cc: chenhuacai, dan.carpenter, david.hunter.linux, khalid,
linux-kernel-mentees, linux-kernel, linux-mmc, lkp, rakuram.e96,
skhan, zhoubinbin
On Tue, 11 Nov 2025 at 23:06, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Thu, 23 Oct 2025 at 16:54, Rakuram Eswaran <rakuram.e96@gmail.com> wrote:
> >
> > This patch refactors pxamci_probe() to use devm-managed resource
> > allocation (e.g. devm_dma_request_chan) and dev_err_probe() for
> > improved readability and automatic cleanup on probe failure.
> >
> > It also removes redundant NULL assignments and manual resource release
> > logic from pxamci_probe(), and eliminates the corresponding release
> > calls from pxamci_remove().
> >
> > Reported-by: kernel test robot <lkp@intel.com>
> > Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
> > Closes: https://lore.kernel.org/r/202510041841.pRlunIfl-lkp@intel.com/
> > Fixes: 58c40f3faf742c ("mmc: pxamci: Use devm_mmc_alloc_host() helper")
> > Suggested-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
> > Signed-off-by: Rakuram Eswaran <rakuram.e96@gmail.com>
>
> Applied for fixes, thanks!
>
> Kind regards
> Uffe
>
Hi Ulf Hansson,
Thank you for applying to fixes branch.
Hi Uwe,
Shall I start to send the patch to remove the redundant if condition
check from pxamic_remove() function?
Link to prior discussion:
https://lore.kernel.org/linux-mmc/pvid2ycmgbkbmegnnzwl4hyev6e2smusxk5olkuqxfwxzykz2e@jlvolirolrxl/
I can pull Uffe fixes branch to send the above patch? Any inputs will be
really helpful to start working on this.
Another point, I would like to ask is about the below discussion. You have
mentioned about WIP suggestion for clk_get_rate().
Link to that discussion:
https://lore.kernel.org/linux-mmc/20251020183209.11040-1-rakuram.e96@gmail.com/
Was my understanding is correct?
Best Regards,
Rakuram
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs
2025-11-18 14:23 ` Rakuram Eswaran
@ 2025-11-18 16:14 ` Uwe Kleine-König
2025-11-19 16:28 ` Rakuram Eswaran
0 siblings, 1 reply; 8+ messages in thread
From: Uwe Kleine-König @ 2025-11-18 16:14 UTC (permalink / raw)
To: Rakuram Eswaran
Cc: ulf.hansson, chenhuacai, dan.carpenter, david.hunter.linux,
khalid, linux-kernel-mentees, linux-kernel, linux-mmc, lkp, skhan,
zhoubinbin
[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]
Hello Rakuram,
On Tue, Nov 18, 2025 at 07:53:11PM +0530, Rakuram Eswaran wrote:
> Shall I start to send the patch to remove the redundant if condition
> check from pxamic_remove() function?
> [...]
> I can pull Uffe fixes branch to send the above patch? Any inputs will be
> really helpful to start working on this.
It's sensible to build on top of your previous patch, yes. If you do
that by using next as development tree once Ulf's commit made it into
there, or if you apply it yourself (and then use `git format-patch
--base` correctly) doesn't matter much.
> Another point, I would like to ask is about the below discussion. You have
> mentioned about WIP suggestion for clk_get_rate().
>
> Link to that discussion:
> https://lore.kernel.org/linux-mmc/20251020183209.11040-1-rakuram.e96@gmail.com/
>
> Was my understanding is correct?
I think so. In my understanding clk_get_rate() must only called for an
enabled clock. (Though the wording in include/linux/clk.h is a bit
ambigous. It says: "[the returned clock rate] is only valid once the
clock source has been enabled." That can mean "The return value doesn't
mean anything when called for a disabled clock." or "The returned rate
is the real one once the clock is enabled." Some time ago I tried to
improve the wording, but IIRC I didn't get relevant feedback on my
patch. Assuming the former semantic is safe for sure.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs
2025-11-18 16:14 ` Uwe Kleine-König
@ 2025-11-19 16:28 ` Rakuram Eswaran
2025-11-19 17:15 ` Ulf Hansson
0 siblings, 1 reply; 8+ messages in thread
From: Rakuram Eswaran @ 2025-11-19 16:28 UTC (permalink / raw)
To: u.kleine-koenig
Cc: chenhuacai, dan.carpenter, david.hunter.linux, khalid,
linux-kernel-mentees, linux-kernel, linux-mmc, lkp, rakuram.e96,
skhan, ulf.hansson, zhoubinbin
On Tue, 18 Nov 2025 at 21:44, Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote:
>
> Hello Rakuram,
>
> On Tue, Nov 18, 2025 at 07:53:11PM +0530, Rakuram Eswaran wrote:
> > Shall I start to send the patch to remove the redundant if condition
> > check from pxamic_remove() function?
> > [...]
> > I can pull Uffe fixes branch to send the above patch? Any inputs will be
> > really helpful to start working on this.
>
> It's sensible to build on top of your previous patch, yes. If you do
> that by using next as development tree once Ulf's commit made it into
> there, or if you apply it yourself (and then use `git format-patch
> --base` correctly) doesn't matter much.
>
Ok, Uwe. Previous patch is already made it to linux-next branch. I will send the
patch for this on top of next.
I will make sure to run this command `git format-patch --base` before sending.
> > Another point, I would like to ask is about the below discussion. You have
> > mentioned about WIP suggestion for clk_get_rate().
> >
> > Link to that discussion:
> > https://lore.kernel.org/linux-mmc/20251020183209.11040-1-rakuram.e96@gmail.com/
> >
> > Was my understanding is correct?
>
> I think so. In my understanding clk_get_rate() must only called for an
> enabled clock. (Though the wording in include/linux/clk.h is a bit
> ambigous. It says: "[the returned clock rate] is only valid once the
> clock source has been enabled." That can mean "The return value doesn't
> mean anything when called for a disabled clock." or "The returned rate
> is the real one once the clock is enabled." Some time ago I tried to
> improve the wording, but IIRC I didn't get relevant feedback on my
> patch. Assuming the former semantic is safe for sure.
>
On this one, I'll look into other implementation on how they handled it in
sometime.
Best Regards,
Rakuram
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs
2025-11-19 16:28 ` Rakuram Eswaran
@ 2025-11-19 17:15 ` Ulf Hansson
0 siblings, 0 replies; 8+ messages in thread
From: Ulf Hansson @ 2025-11-19 17:15 UTC (permalink / raw)
To: Rakuram Eswaran
Cc: u.kleine-koenig, chenhuacai, dan.carpenter, david.hunter.linux,
khalid, linux-kernel-mentees, linux-kernel, linux-mmc, lkp, skhan,
zhoubinbin
On Wed, 19 Nov 2025 at 17:29, Rakuram Eswaran <rakuram.e96@gmail.com> wrote:
>
> On Tue, 18 Nov 2025 at 21:44, Uwe Kleine-König <u.kleine-koenig@baylibre.com> wrote:
> >
> > Hello Rakuram,
> >
> > On Tue, Nov 18, 2025 at 07:53:11PM +0530, Rakuram Eswaran wrote:
> > > Shall I start to send the patch to remove the redundant if condition
> > > check from pxamic_remove() function?
> > > [...]
> > > I can pull Uffe fixes branch to send the above patch? Any inputs will be
> > > really helpful to start working on this.
> >
> > It's sensible to build on top of your previous patch, yes. If you do
> > that by using next as development tree once Ulf's commit made it into
> > there, or if you apply it yourself (and then use `git format-patch
> > --base` correctly) doesn't matter much.
> >
>
> Ok, Uwe. Previous patch is already made it to linux-next branch. I will send the
> patch for this on top of next.
If you are working on mmc I strongly recommend to base your patches on top of:
git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git next
As is described in the MAINTAINERS file.
[...]
Kind regards
Uffe
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2025-11-19 17:16 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-23 14:54 [PATCH v3] mmc: pxamci: Simplify pxamci_probe() error handling using devm APIs Rakuram Eswaran
2025-10-28 15:50 ` Khalid Aziz
2025-10-29 10:06 ` Uwe Kleine-König
2025-11-11 17:36 ` Ulf Hansson
2025-11-18 14:23 ` Rakuram Eswaran
2025-11-18 16:14 ` Uwe Kleine-König
2025-11-19 16:28 ` Rakuram Eswaran
2025-11-19 17:15 ` Ulf Hansson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox