Re: [PATCH -next v2] usb: musb: mediatek: Simplify code with dev_err_probe()

From: Guoqing Jiang
Date: Mon Sep 09 2024 - 05:31:43 EST




On 9/7/24 16:13, Lin Ruifeng wrote:
The combination of dev_err() and the returned error code could be
replaced by dev_err_probe() in driver's probe function. Let's,
converting to dev_err_probe() to make code more simple.

Signed-off-by: Lin Ruifeng <linruifeng4@xxxxxxxxxx>
---
v2:
- The wrong message is modified.
drivers/usb/musb/mediatek.c | 27 +++++++++++----------------
1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/drivers/usb/musb/mediatek.c b/drivers/usb/musb/mediatek.c
index 0a35aab3ab81..63c86c046b98 100644
--- a/drivers/usb/musb/mediatek.c
+++ b/drivers/usb/musb/mediatek.c
@@ -416,10 +416,9 @@ static int mtk_musb_probe(struct platform_device *pdev)
return -ENOMEM;
ret = of_platform_populate(np, NULL, NULL, dev);
- if (ret) {
- dev_err(dev, "failed to create child devices at %p\n", np);
- return ret;
- }
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to create child devices at %p\n", np);
ret = mtk_musb_clks_get(glue);
if (ret)
@@ -448,23 +447,19 @@ static int mtk_musb_probe(struct platform_device *pdev)
glue->role = USB_ROLE_NONE;
break;
default:
- dev_err(&pdev->dev, "Error 'dr_mode' property\n");
- return -EINVAL;
+ return dev_err_probe(&pdev->dev, -EINVAL,
+ "Error 'dr_mode' property\n");
}
glue->phy = devm_of_phy_get_by_index(dev, np, 0);
- if (IS_ERR(glue->phy)) {
- dev_err(dev, "fail to getting phy %ld\n",
- PTR_ERR(glue->phy));
- return PTR_ERR(glue->phy);
- }
+ if (IS_ERR(glue->phy))
+ return dev_err_probe(dev, PTR_ERR(glue->phy),
+ "fail to getting phy\n");
glue->usb_phy = usb_phy_generic_register();
- if (IS_ERR(glue->usb_phy)) {
- dev_err(dev, "fail to registering usb-phy %ld\n",
- PTR_ERR(glue->usb_phy));
- return PTR_ERR(glue->usb_phy);
- }
+ if (IS_ERR(glue->usb_phy))
+ return dev_err_probe(dev, PTR_ERR(glue->usb_phy),
+ "fail to registering usb-phy\n");
glue->xceiv = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
if (IS_ERR(glue->xceiv)) {

Sorry, this is probably out of topic. I had seen one relevant kmemleak report (probably false
positive) which is related to dev_err_probe.

[<ffff800083692200>] kmemleak_alloc+0xe0/0x120
[<ffff800080a1d7f4>] __kmalloc_node_track_caller+0x354/0x4d0
[<ffff800081443520>] kvasprintf+0xd0/0x1a0
[<ffff8000814438bc>] kasprintf+0xac/0x120
[<ffff8000820b5578>] device_set_deferred_probe_reason+0x68/0x148
[<ffff8000820a1844>] dev_err_probe+0x164/0x1b0
[<ffff800081ba00a8>] __clk_bulk_get+0x108/0x238
[<ffff800081ba0248>] clk_bulk_get_optional+0x20/0x50
[<ffff800081b9f294>] devm_clk_bulk_get_optional+0x6c/0x160
[<ffff800081791efc>] mtk_tphy_probe+0x38c/0x7a8
[<ffff8000820bbe98>] platform_probe+0xd0/0x240
[<ffff8000820b35c8>] really_probe+0x368/0xa10
[<ffff8000820b3de0>] __driver_probe_device+0x170/0x420
[<ffff8000820b40f8>] driver_probe_device+0x68/0x1f0
[<ffff8000820b47fc>] __driver_attach+0x234/0x558
[<ffff8000820ae1b8>] bus_for_each_dev+0x108/0x1c8

Not sure if this patch could trigger the same report.

Thanks,
Guoqing