Re: [PATCH v2 2/3] phy: phy-rockchip-inno-usb2: Handle failed extcon allocation better

From: Dragan Simic
Date: Wed Aug 21 2024 - 15:05:19 EST


Hello Christophe,

On 2024-08-21 13:17, Christophe JAILLET wrote:
Le 21/08/2024 à 09:37, Dragan Simic a écrit :
Return the actual error code upon failure to allocate extcon device, instead
of hardcoding -ENOMEM. Use dev_err_probe() to also log appropriate messages,
which is fine because the containing function is used in the probe path.

Helped-by: Heiko Stubner <heiko@xxxxxxxxx>
Signed-off-by: Dragan Simic <dsimic@xxxxxxxxxxx>
---
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 113bfc717ff0..05af46dda11d 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -435,7 +435,8 @@ static int rockchip_usb2phy_extcon_register(struct rockchip_usb2phy *rphy)
rockchip_usb2phy_extcon_cable);
if (IS_ERR(edev))
- return -ENOMEM;
+ return dev_err_probe(rphy->dev, PTR_ERR(edev),
+ "failed to allocate extcon device\n");

Returning PTR_ERR(edev) may make sense, but I don't think that adding
a dev_err_probe() really helps.

devm_extcon_dev_allocate() can only return -EINVAL if it 2nd argument
is NULL. It is trivial to see that it can't happen here,
rockchip_usb2phy_extcon_cable is a global variable.

in all other cases, it returns -ENOMEM because of a failed memory
allocation. In this case, usually it is not needed to log anything
because it is already loud enough.

True, using dev_err_probe() in this case is somewhat redundant,
but it falls under the "still fine to use" category, [1] because
the error code passed to dev_err_probe() is received from another
function that was invoked.

On the other hand, another patch in this series tries to be strict
in another direction, by not using dev_err_probe() where the error
code passed to it is basically hardcoded. [2]

I hope this makes sense.

[1] https://lore.kernel.org/linux-phy/cover.1724225528.git.dsimic@xxxxxxxxxxx/T/#mc3af7d24e31ed885732e6f26ca0d107b157d478b
[2] https://lore.kernel.org/linux-phy/cover.1724225528.git.dsimic@xxxxxxxxxxx/T/#ma26b614412787814dab7923987b8c814f7e86beb

ret = devm_extcon_dev_register(rphy->dev, edev);
if (ret) {