[PATCH v2 09/18] iio: afe: iio-rescale: Simplify with dev_err_probe()

[Krzysztof Kozlowski]

On Thu, Aug 27, 2020 at 11:46:40PM +0200, Peter Rosin wrote:
> On 2020-08-27 21:26, Krzysztof Kozlowski wrote:
> > Common pattern of handling deferred probe can be simplified with
> > dev_err_probe().  Less code and also it prints the error value.
> > 
> > Signed-off-by: Krzysztof Kozlowski <krzk at kernel.org>
> > 
> > ---
> > 
> > Changes since v1:
> > 1. Wrap dev_err_probe() lines at 100 character
> > ---
> >  drivers/iio/afe/iio-rescale.c | 7 ++-----
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c
> > index 69c0f277ada0..8cd9645c50e8 100644
> > --- a/drivers/iio/afe/iio-rescale.c
> > +++ b/drivers/iio/afe/iio-rescale.c
> > @@ -276,11 +276,8 @@ static int rescale_probe(struct platform_device *pdev)
> >  	int ret;
> >  
> >  	source = devm_iio_channel_get(dev, NULL);
> > -	if (IS_ERR(source)) {
> > -		if (PTR_ERR(source) != -EPROBE_DEFER)
> > -			dev_err(dev, "failed to get source channel\n");
> > -		return PTR_ERR(source);
> > -	}
> > +	if (IS_ERR(source))
> > +		return dev_err_probe(dev, PTR_ERR(source), "failed to get source channel\n");
> 
> Hi!
> 
> Sorry to be a pain...but...
> 
> I'm not a huge fan of adding *one* odd line breaking the 80 column
> recommendation to any file. I like to be able to fit multiple
> windows side by side in a meaningful way. Also, I don't like having
> a shitload of emptiness on my screen, which is what happens when some
> lines are longer and you want to see it all. I strongly believe that
> the 80 column rule/recommendation is still as valid as it ever was.
> It's just hard to read longish lines; there's a reason newspapers
> columns are quite narrow...
> 
> Same comment for the envelope-detector (3/18).
> 
> You will probably never look at these files again, but *I* might have
> to revisit them for one reason or another, and these long lines will
> annoy me when that happens.

Initially I posted it with 80-characters wrap. Then I received a comment
- better to stick to the new 100, as checkpatch accepts it.

Now you write, better to go back to 80.

Maybe then someone else will write to me, better to go to 100.

And another person will reply, no, coding style still mentions 80, so
keep it at 80.

Sure guys, please first decide which one you prefer, then I will wrap it
accordingly. :)

Otherwise I will just jump from one to another depending on one person's
personal preference.

If there is no consensus among discussing people, I find this 100 line
more readable, already got review, checkpatch accepts it so if subsystem
maintainer likes it, I prefer to leave it like this.

> You did wrap the lines for dpot-dac (12/18) - which is excellent - but
> that makes me curious as to what the difference is?

Didn't fit into limit of 100.

Best regards,
Krzysztof