All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Nikita Yushchenko <nikita.yoush@cogentembedded.com>,
	Cosmin Tanislav <demonsingur@gmail.com>,
	Jagath Jog J <jagathjog1996@gmail.com>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, "Mutanen,
	Mikko" <Mikko.Mutanen@fi.rohmeurope.com>,
	"Haikola, Heikki" <Heikki.Haikola@fi.rohmeurope.com>
Subject: Re: [RFC PATCH 4/5] iio: accel: Support Kionix/ROHM KX022A accelerometer
Date: Wed, 28 Sep 2022 19:23:06 +0300	[thread overview]
Message-ID: <e3abc0a9-ad5b-f6ef-8cba-0b4c6c8325c0@gmail.com> (raw)
In-Reply-To: <YzRU9aRNReonSqbg@smile.fi.intel.com>

Hi Andy,

On 9/28/22 17:06, Andy Shevchenko wrote:
> On Wed, Sep 28, 2022 at 02:14:14PM +0300, Matti Vaittinen wrote:
>> On 9/22/22 20:03, Jonathan Cameron wrote:
>>> On Wed, 21 Sep 2022 14:45:35 +0300
> 
> ...
> 
>>>> +		dev_err(dev, "no regmap\n");
>>>
>>> Use dev_err_probe() for all dev_err() stuff in probe paths.
>>> It ends up cleaner and we don't care about the tiny overhead
>>> of checking for deferred.
>>
>> This one bothers me a bit. It just does not feel correct to pass -EINVAL for
>> the dev_err_probe() so the dev_err_probe() can check if -EINVAL !=
>> -EPROBE_DEFER. I do understand perfectly well the consistent use of
>> dev_err_probe() for all cases where we get an error-code from a function and
>> return it - but using dev_err_probe() when we hard-code the return value in
>> code calling the dev_err_probe() does not feel like "the right thing to do"
>> (tm).
>>
>> Eg, I agree that
>> return dev_err_probe(dev, ret, "bar");
>> is nice even if we know the function that gave us the "ret" never requests
>> defer (as that can change some day).
>>
>> However, I don't like issuing:
>> return dev_err_probe(dev, -EINVAL, "bar");
> 
> This case specifically was added into documentation by 7065f92255bb ("driver
> core: Clarify that dev_err_probe() is OK even w/out -EPROBE_DEFER").

Yes. And this is exactly what I meant with:
 >> Eg, I agree that
 >> return dev_err_probe(dev, ret, "bar");
 >> is nice even if we know the function that gave us the "ret" never 
requests
 >> defer

There is still (in my opinion) a significant difference if we call:
 >> return dev_err_probe(dev, -EINVAL, "bar");

- where we really hard-code the -EINVAL as a parameter to the 
dev_err_probe()

>> Well, please let me know if you think the dev_err_probe() should be used
>> even in cases where we hard code the return to something...
> 
> And this should be, of course, maintainer's decision.

Ultimately, yes.

Best Regards
	--Matti

-- 
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~

  reply	other threads:[~2022-09-28 16:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 11:40 [RFC PATCH 0/5] iio: Support ROHM/Kionix kx022a Matti Vaittinen
2022-09-21 11:42 ` [RFC PATCH 1/5] regulator: Add devm helpers for get and enable Matti Vaittinen
2022-09-21 11:43 ` [RFC PATCH 2/5] " Matti Vaittinen
2022-09-21 11:45 ` [RFC PATCH 3/5] dt-bindings: iio: Add KX022A accelerometer Matti Vaittinen
2022-09-21 19:11   ` Krzysztof Kozlowski
2022-09-21 19:30     ` Vaittinen, Matti
2022-09-21 19:56       ` Krzysztof Kozlowski
2022-09-22  3:49         ` Matti Vaittinen
2022-09-21 11:45 ` [RFC PATCH 4/5] iio: accel: Support Kionix/ROHM " Matti Vaittinen
2022-09-21 19:18   ` Vaittinen, Matti
2022-09-22 17:03   ` Jonathan Cameron
2022-09-23  6:31     ` Matti Vaittinen
2022-09-24 15:17       ` Jonathan Cameron
2022-09-26  5:02         ` Vaittinen, Matti
2022-10-02 11:11           ` Jonathan Cameron
2022-09-28 11:14     ` Matti Vaittinen
2022-09-28 14:06       ` Andy Shevchenko
2022-09-28 16:23         ` Matti Vaittinen [this message]
2022-10-02 11:14           ` Jonathan Cameron
2022-10-02 11:18       ` Jonathan Cameron
2022-10-02 14:31         ` Matti Vaittinen
2022-09-21 11:46 ` [RFC PATCH 5/5] MAINTAINERS: Add KX022A maintainer entry Matti Vaittinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3abc0a9-ad5b-f6ef-8cba-0b4c6c8325c0@gmail.com \
    --to=mazziesaccount@gmail.com \
    --cc=Heikki.Haikola@fi.rohmeurope.com \
    --cc=Mikko.Mutanen@fi.rohmeurope.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=demonsingur@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jagathjog1996@gmail.com \
    --cc=jic23@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nikita.yoush@cogentembedded.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.