[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240830181625.GD1368797@kernel.org>
Date: Fri, 30 Aug 2024 19:16:25 +0100
From: Simon Horman <horms@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Shen Lichuan <shenlichuan@...o.com>, alex.aring@...il.com,
stefan@...enfreihafen.org, miquel.raynal@...tlin.com,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, linux-wpan@...r.kernel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
opensource.kernel@...o.com
Subject: Re: [PATCH v1] ieee802154: at86rf230: Simplify with dev_err_probe()
On Fri, Aug 30, 2024 at 07:43:30PM +0200, Krzysztof Kozlowski wrote:
> On 30/08/2024 18:02, Simon Horman wrote:
> > On Fri, Aug 30, 2024 at 04:14:02PM +0800, Shen Lichuan wrote:
> >> 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: Shen Lichuan <shenlichuan@...o.com>
> >
> > ...
> >
> >> @@ -1576,9 +1574,8 @@ static int at86rf230_probe(struct spi_device *spi)
> >>
> >> lp->regmap = devm_regmap_init_spi(spi, &at86rf230_regmap_spi_config);
> >> if (IS_ERR(lp->regmap)) {
> >> - rc = PTR_ERR(lp->regmap);
> >> - dev_err(&spi->dev, "Failed to allocate register map: %d\n",
> >> - rc);
> >> + dev_err_probe(&spi->dev, PTR_ERR(lp->regmap),
> >> + "Failed to allocate register map\n");
> >> goto free_dev;
> >
> > After branching to dev_free the function will return rc.
> > So I think it still needs to be set a in this error path.
>
> Another bug introduced by @vivo.com.
>
> Since ~2 weeks there is tremendous amount of trivial patches coming from
> vivo.com. I identified at least 5 buggy, where the contributor did not
> understand the code.
>
> All these "trivial" improvements should be really double-checked.
Are you concerned about those that have been accepted?
Powered by blists - more mailing lists