drivers/media/i2c/max2175.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
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@vivo.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);
- return -EINVAL;
+ return dev_err_probe(&client->dev, -EINVAL,
+ "invalid refout_load %u\n", refout_load);
}
}
--
2.34.1
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@vivo.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
© 2016 - 2025 Red Hat, Inc.