linux-kernel - Re: [PATCH v1] i2c: max2175: Simplify with dev_err

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f3388c4c-52f7-49f8-8a30-08665856637d@kernel.org>
Date: Fri, 30 Aug 2024 20:31:59 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Yan Zhen <yanzhen@...o.com>, rashanmu@...il.com, mchehab@...nel.org,
 Andi Shyti <andi.shyti@...nel.org>, Wolfram Sang <wsa@...nel.org>
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
 opensource.kernel@...o.com
Subject: Re: [PATCH v1] i2c: max2175: Simplify with dev_err_probe()

On 28/08/2024 11:45, Yan Zhen wrote:
> Switch to use dev_err_probe() to simplify the error path and
> unify a message template.
> 
> Using this helper 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 and the fact that
> the error code is returned which allows more compact error paths.
> 
> Signed-off-by: Yan Zhen <yanzhen@...o.com>
> ---
>  drivers/media/i2c/max2175.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/i2c/max2175.c b/drivers/media/i2c/max2175.c
> index bf02ca23a284..700a70a6cee3 100644
> --- a/drivers/media/i2c/max2175.c
> +++ b/drivers/media/i2c/max2175.c
> @@ -1299,9 +1299,8 @@ static int max2175_probe(struct i2c_client *client)
>  		ret = max2175_refout_load_to_bits(client, refout_load,
>  						  &refout_bits);
>  		if (ret) {
> -			dev_err(&client->dev, "invalid refout_load %u\n",
> -				refout_load);

Another example, one of many from @vivo.com, where you touch one line
and leave everything else not modified.

Are you going to send 5 different patches - one per each line? You
generate tremendous amount of work for reviewers to handle this.

Since ~2 weeks there is tremendous amount of trivial patches coming from
vivo.com. I identified at least 6 buggy, where the contributor did not
understand the code. Not sure about intention, but I advise extra
carefulness when dealing with these "trivial" improvements (because we
tend to apply things which look trivial).


Best regards,
Krzysztof