From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 29BFAC531DC for ; Wed, 21 Aug 2024 09:35:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date: MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=V8e/e9QlFlV6uwCMmOmikTDXDk3xFAB5P6WHKtcf88s=; b=X8cdH3JvxVTQOmpff1HRSjP5k+ iVOzc8Erp9sLdVzocT3MTIvZ8OzIADy5g/Qmv/hbL0YvleTs+Bic03PuglQJ0k6Ghcg9agCcUwQYr qT41beg6LrSnEIBVANpW0Q4Z2DUptPeBYXD+Mq9i1y3LMNV8j0b9+vT0xw6IFub8809bguiH3I4AH IuJPH/+TX5QhSK3v7Jn+vRcjA7sjeb0CnMIIr0sNtR6UtCh0MtyD0jk7z74ar1lhoudvxJq96cdb5 5sbHj4Jl9OKECu8rmCSWBsZXyJrnKF7bbk/xLzxGkVD6rf8JFpXxZssHFUlKmiJuYAAm2WZTKuUXm yVHfYKdw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sghkV-00000008GgW-2yTD; Wed, 21 Aug 2024 09:35:27 +0000 Received: from mail.manjaro.org ([2a01:4f8:c0c:51f3::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sghjn-00000008GbJ-0p5k; Wed, 21 Aug 2024 09:34:45 +0000 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manjaro.org; s=2021; t=1724232881; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V8e/e9QlFlV6uwCMmOmikTDXDk3xFAB5P6WHKtcf88s=; b=QOQfuhlkcimw9aAAxs1j94XFG7lGoAQDN7M5OECnYc3o68jxbxWmG8dOJFTncx6XHc1Ima r+6ob2LaILkY8fSymKEnNvM5jYRqEH41fE5xc9SWOx+465Fzt2rWMRmBTdrxdAHzfgN5NR dDLUHnpJSt9A2/HRjjs8O7rjt22TlQiZlltPAxjsc1WIh6GMCuXPBDRh+e1z7PGqK6+Ojd HM9FGGgyaArc+BQBHd3lF2tjdjGabBzVcemZMH+PDpxW40fzGdDOQ0jC9PK8EjlFsofMbd f17kDDn7AV+CZBGXmzH/Y98wgHteg3pPvSbcDX4xJLq5SWlJMfEVbJnvjZwzhg== Date: Wed, 21 Aug 2024 11:34:41 +0200 From: Dragan Simic To: =?UTF-8?Q?Heiko_St=C3=BCbner?= Cc: linux-rockchip@lists.infradead.org, linux-phy@lists.infradead.org, vkoul@kernel.org, kishon@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 3/3] phy: phy-rockchip-inno-usb2: Improve error handling while probing In-Reply-To: <6073817.31tnzDBltd@diego> References: <12869965.VsHLxoZxqI@diego> <486bddb6aad14d05a3fb2d876d0d9d0d@manjaro.org> <6073817.31tnzDBltd@diego> Message-ID: <8bb17c887eb9122d90e0887068b32da2@manjaro.org> X-Sender: dsimic@manjaro.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Authentication-Results: ORIGINATING; auth=pass smtp.auth=dsimic@manjaro.org smtp.mailfrom=dsimic@manjaro.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240821_023443_602612_F25ECEB5 X-CRM114-Status: GOOD ( 28.69 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2024-08-21 11:17, Heiko Stübner wrote: > Am Mittwoch, 21. August 2024, 11:09:03 CEST schrieb Dragan Simic: >> On 2024-08-21 10:44, Heiko Stübner wrote: >> > Am Mittwoch, 21. August 2024, 09:37:55 CEST schrieb Dragan Simic: >> >> Improve error handling in the probe path by using function >> >> dev_err_probe() >> >> where appropriate, and by no longer using it rather pointlessly in one >> >> place >> >> that actually produces a single, hardcoded error code. >> >> >> >> Signed-off-by: Dragan Simic >> > >> >> @@ -1375,8 +1372,10 @@ static int rockchip_usb2phy_probe(struct >> >> platform_device *pdev) >> >> rphy->irq = platform_get_irq_optional(pdev, 0); >> >> platform_set_drvdata(pdev, rphy); >> >> >> >> - if (!phy_cfgs) >> >> - return dev_err_probe(dev, -EINVAL, "phy configs are not >> >> assigned!\n"); >> >> + if (!phy_cfgs) { >> >> + dev_err(dev, "phy configs are not assigned\n"); >> >> + return -EINVAL; >> >> + } >> >> >> >> ret = rockchip_usb2phy_extcon_register(rphy); >> >> if (ret) >> > >> > I really don't understand the rationale here. Using dev_err_probe here >> > is just fine and with that change you just introduce more lines of code >> > for exactly the same functionality? >> >> As we know, dev_err_probe() decides how to log the received error >> message >> based on the error code it receives, but in this case the error code >> is >> hardcoded as -EINVAL. Thus, in this case it isn't about keeping the >> LoC >> count a bit lower, but about using dev_err() where the resulting >> outcome >> of error logging is aleady known, and where logging the error code >> actually >> isn't helpful, because it's hardcoded and the logged error message >> already >> tells everything about the error condition. >> >> In other words, it's about being as precise as possible when deciding >> between >> dev_err() and dev_err_probe(), in both directions. I hope it makes >> sense. > > I'd disagree a bit, using one format only creates a way nicer pattern > in the > driver, by not mixing different styles. > > dev_err_probe documentation seems to agree [0], by stating: > > "Using this helper in your probe function is totally fine even if @err > is > known to never be -EPROBE_DEFER. > The benefit compared to a normal dev_err() is the standardized format > of the error code, it being emitted symbolically (i.e. you get > "EAGAIN" > instead of "-35") and the fact that the error code is returned which > allows > more compact error paths." Yes, I saw that already in the documentation. Though, it might be debatable does hardcoding the passed error code to some value qualifies as knowing that it can't be -EPROBE_DEFER. The way I read that part of the documentation is that using dev_err_probe() is fine without going into the implementation of the previously invoked function that may fail, and researching can it actually return -EPROBE_DEFER or not. Also, the invoked function may change at some point in future and start returning -EPROBE_DEFER, but a hardcoded error code that's produced locally can't become changed that way. In addition to that, we already have at least a couple of instances [1][2] in the same function in which dev_err() is used when the error code is hardcoded, so there's actually already another pattern to follow. I know that replacing dev_err_probe() with dev_err() may look strange in a patch that mostly performs the opposite replacement, but the patch just tries to be strict and precise, and to follow other examples of how dev_err() is already used in the same function when the error code is produced locally instead of being received from another invoked function. > [0] > https://elixir.bootlin.com/linux/v6.10.6/source/drivers/base/core.c#L5009 [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/rockchip/phy-rockchip-inno-usb2.c?h=v6.11-rc4#n1361 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/phy/rockchip/phy-rockchip-inno-usb2.c?h=v6.11-rc4#n1369