From: Stefan Agner <stefan@agner.ch>
To: Leo Li <pku.leo@gmail.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Gao Pan" <pandy.gao@nxp.com>, "Wolfram Sang" <wsa@the-dreams.de>,
lkml <linux-kernel@vger.kernel.org>,
"Li Yang" <leoyang.li@nxp.com>,
linux-gpio@vger.kernel.org, linux-i2c@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional
Date: Thu, 08 Sep 2016 15:39:03 -0700 [thread overview]
Message-ID: <8f8f7ffc4aef513ef5064ba0491fbc63@agner.ch> (raw)
In-Reply-To: <CADRPPNSPye45bmFshfwb+gDA0x0ygs4Ofa6HMYbKt9ER0oeccg@mail.gmail.com>
On 2016-09-06 15:40, Leo Li wrote:
> On Tue, Sep 6, 2016 at 4:51 PM, Stefan Agner <stefan@agner.ch> wrote:
>> On 2016-09-06 13:06, Leo Li wrote:
>>> On Tue, Sep 6, 2016 at 1:58 PM, Uwe Kleine-König
>>> <u.kleine-koenig@pengutronix.de> wrote:
>>>> On Fri, Aug 19, 2016 at 05:05:22PM -0500, Li Yang wrote:
<snip>
>>>>> @@ -1081,8 +1090,11 @@ static int i2c_imx_probe(struct platform_device *pdev)
>>>>> return ret;
>>>>> }
>>>>>
>>>>> + /* optional bus recovery feature through pinctrl */
>>>>> i2c_imx->pinctrl = devm_pinctrl_get(&pdev->dev);
>>>>> - if (IS_ERR(i2c_imx->pinctrl)) {
>>>>> + /* bailout on -ENOMEM or -EPROBE_DEFER, continue for other errors */
>>>>> + if (PTR_ERR(i2c_imx->pinctrl) == -ENOMEM ||
>>>>> + PTR_ERR(i2c_imx->pinctrl) == -EPROBE_DEFER) {
>>>>> ret = PTR_ERR(i2c_imx->pinctrl);
>>>>> goto clk_disable;
>>>>> }
>>>>
>>>> devm_pinctrl_get might return the following error-valued pointers:
>>>> - -EINVAL
>>>> - -ENOMEM
>>>> - -ENODEV
>>>> - -EPROBE_DEFER
>>>>
>>>> There are several error paths returning -EINVAL, one is when an invalid
>>>> phandle is used. Do you really want to ignore that?
>>>>
>>>> IMO error handling is better done with inverse logic, that is continue
>>>> on some explicit error, bail out on all unknown stuff. This tends to be
>>>> more robust. Also the comment should be improved to not explain that for
>>>> -ENOMEM and -EPROBE_DEFER we bail out (which should be obvious for
>>>> anyone who can read C) but to explain why.
>>>
>>> What you said is true for normal error handling, but in this scenario
>>> it is intentional to ignore all pinctrl related errors except critical
>>> ones because failing to have pinctrl for an optional feature shouldn't
>>> impact the function of normal i2c. We choose to catch -ENOMEM because
>>> the error could also cause problem for i2c probe, and -EPROBE_DEFER
>>> because it's possible that the pinctrl will be ready later and we want
>>> to give it a chance. The i2c driver really don't care why the pinctrl
>>> was not usable. I thought I added comment before the
>>
>> I don't agree. E.g. -EINVAL would appear if you pass devm_pinctrl_get an
>> invalid device. Currently you would silently ignore that, which is not
>> what you want.
>
> It is not silently ignored, there will be a message printed out saying
> pinctrl is not available and bus recovery is not supported. On the
> contrary, without this change the entire i2c driver fails to work
> silently if pinctrl is somehow not working. And if the system is so
> broken that the pointer to the i2c device is NULL, the probe of i2c
> would have already failed before this point. We shouldn't count on an
> optional function of the driver to catch fundamental issues like this.
>
>>
>> You want to get the pinctrl in any case expect there isn't one. And that
>> is how you should formulate your if statement.
>>
>> /*
>> * It is ok if no pinctrl device is available. We'll not be able to use
>> the
>> * bus recovery feature, but otherwise the driver works fine...
>> */
>> if (PTR_ERR(i2c_imx->pinctrl) != -ENODEV)
>
> I agree that there could be other possibilities that the pinctrl
> failed to work beside the reason I described in the commit
> message(platform doesn't support pinctrl at all). But I don't think
> any of them other than the -ENOMEM and -EPROBE_DEFER deserves a bail
> out for the entire i2c driver.
FWIW, I disagree. If there is pinctrl defined, you want be sure that it
gets applied properly, no matter what. E.g. when devm_pinctrl_get return
EINVAL (Uwe's example) the driver will continue and likely fail in
mysterious ways later on because the pins have not been muxed properly.
The driver should not load in that situation so that the developer is
forced to fix his mistakes. The only reason to bail out here is if there
is no pin controller (ENODEV). And it seems that Uwe also tends to that
solution.
--
Stefan
next prev parent reply other threads:[~2016-09-08 22:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-19 22:05 [PATCH v5] i2c: imx: make bus recovery through pinctrl optional Li Yang
2016-09-06 18:58 ` Uwe Kleine-König
2016-09-06 20:06 ` Leo Li
2016-09-06 21:07 ` Uwe Kleine-König
2016-09-06 23:14 ` Leo Li
2016-09-06 21:51 ` Stefan Agner
2016-09-06 22:40 ` Leo Li
[not found] ` <CAChUvXOGjTn6K5588UVgjbRWUY+weDtk2qbOU-NM4=kA2znh=Q@mail.gmail.com>
2016-09-07 5:55 ` Uwe Kleine-König
[not found] ` <CAChUvXMPDZB7=ZArQ5+6ae42N=Bsgv_OczGXnyhBjEdjt_yvsw@mail.gmail.com>
2016-09-07 16:40 ` Leo Li
2016-09-12 16:35 ` Leo Li
2016-09-12 18:29 ` Leo Li
2016-09-08 22:39 ` Stefan Agner [this message]
2016-09-08 23:57 ` Leo Li
2016-09-09 16:51 ` Stefan Agner
2016-09-09 19:37 ` Leo Li
2016-09-09 20:34 ` Stefan Agner
2016-09-09 20:59 ` Uwe Kleine-König
2016-09-12 16:47 ` Leo Li
2016-09-12 8:21 ` Lothar Waßmann
2016-09-12 16:27 ` Leo Li
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=8f8f7ffc4aef513ef5064ba0491fbc63@agner.ch \
--to=stefan@agner.ch \
--cc=leoyang.li@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pandy.gao@nxp.com \
--cc=pku.leo@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=wsa@the-dreams.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox