[PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Li Yang]

Since commit 1c4b6c3bcf30 ("i2c: imx: implement bus recovery") the
driver starts to use gpio/pinctrl to do i2c bus recovery.  But pinctrl
is not always available for platforms with this controller such as ls1021a
and ls1043a, and the device tree binding also mentioned this gpio based
recovery mechanism as optional.  The patch makes it really optional that
the probe function won't bailout but just disable the bus recovery function
when pinctrl is not available.

Signed-off-by: Li Yang <leoyang.li@nxp.com>
Cc: Gao Pan <pandy.gao@nxp.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
v5:
Revert the last minute change of recovery info initialization timing, it
will cause problem if initialized after i2c_add_numbered_adapter()

v4:
Remove the use of IS_ERR_OR_NULL
Move the condition judgement to i2c_imx_init_recovery_info()
Change the timing of recovery initialization to be after bus registration

v3:
Rebased to Wolfram's for-next branch
Added acked-by from Linus Walleij
Update to use new nxp email addresses due to company merge

 drivers/i2c/busses/i2c-imx.c | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 1844bc9..7ae7992 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -989,6 +989,15 @@ static void i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
 {
 	struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
 
+	/* if pinctrl is not supported on the system */
+	if (IS_ERR(i2c_imx->pinctrl))
+		i2c_imx->pinctrl = NULL;
+
+	if (!i2c_imx->pinctrl) {
+		dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
+		return;
+	}
+
 	i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
 			PINCTRL_STATE_DEFAULT);
 	i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
@@ -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;
 	}
@@ -1125,6 +1137,7 @@ static int i2c_imx_probe(struct platform_device *pdev)
 			i2c_imx, IMX_I2C_I2CR);
 	imx_i2c_write_reg(i2c_imx->hwdata->i2sr_clr_opcode, i2c_imx, IMX_I2C_I2SR);
 
+	/* Init bus recovery info if supported */
 	i2c_imx_init_recovery_info(i2c_imx, pdev);
 
 	/* Add I2C adapter */
-- 
1.9.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Uwe Kleine-König]

On Fri, Aug 19, 2016 at 05:05:22PM -0500, Li Yang wrote:
> Since commit 1c4b6c3bcf30 ("i2c: imx: implement bus recovery") the
> driver starts to use gpio/pinctrl to do i2c bus recovery.  But pinctrl
> is not always available for platforms with this controller such as ls1021a
> and ls1043a, and the device tree binding also mentioned this gpio based
> recovery mechanism as optional.  The patch makes it really optional that
> the probe function won't bailout but just disable the bus recovery function
> when pinctrl is not available.
> 
> Signed-off-by: Li Yang <leoyang.li@nxp.com>
> Cc: Gao Pan <pandy.gao@nxp.com>
> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> v5:
> Revert the last minute change of recovery info initialization timing, it
> will cause problem if initialized after i2c_add_numbered_adapter()
> 
> v4:
> Remove the use of IS_ERR_OR_NULL
> Move the condition judgement to i2c_imx_init_recovery_info()
> Change the timing of recovery initialization to be after bus registration
> 
> v3:
> Rebased to Wolfram's for-next branch
> Added acked-by from Linus Walleij
> Update to use new nxp email addresses due to company merge
> 
>  drivers/i2c/busses/i2c-imx.c | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 1844bc9..7ae7992 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -989,6 +989,15 @@ static void i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
>  {
>  	struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
>  
> +	/* if pinctrl is not supported on the system */
> +	if (IS_ERR(i2c_imx->pinctrl))
> +		i2c_imx->pinctrl = NULL;
> +
> +	if (!i2c_imx->pinctrl) {
> +		dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
> +		return;
> +	}
> +
>  	i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
>  			PINCTRL_STATE_DEFAULT);
>  	i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
> @@ -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.

Also I'd put

	i2c_imx->pinctrl = NULL;

directly after devm_pinctrl_get() which I consider the more obvious
place for this.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Leo Li]

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:
>> Since commit 1c4b6c3bcf30 ("i2c: imx: implement bus recovery") the
>> driver starts to use gpio/pinctrl to do i2c bus recovery.  But pinctrl
>> is not always available for platforms with this controller such as ls1021a
>> and ls1043a, and the device tree binding also mentioned this gpio based
>> recovery mechanism as optional.  The patch makes it really optional that
>> the probe function won't bailout but just disable the bus recovery function
>> when pinctrl is not available.
>>
>> Signed-off-by: Li Yang <leoyang.li@nxp.com>
>> Cc: Gao Pan <pandy.gao@nxp.com>
>> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> v5:
>> Revert the last minute change of recovery info initialization timing, it
>> will cause problem if initialized after i2c_add_numbered_adapter()
>>
>> v4:
>> Remove the use of IS_ERR_OR_NULL
>> Move the condition judgement to i2c_imx_init_recovery_info()
>> Change the timing of recovery initialization to be after bus registration
>>
>> v3:
>> Rebased to Wolfram's for-next branch
>> Added acked-by from Linus Walleij
>> Update to use new nxp email addresses due to company merge
>>
>>  drivers/i2c/busses/i2c-imx.c | 15 ++++++++++++++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
>> index 1844bc9..7ae7992 100644
>> --- a/drivers/i2c/busses/i2c-imx.c
>> +++ b/drivers/i2c/busses/i2c-imx.c
>> @@ -989,6 +989,15 @@ static void i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
>>  {
>>       struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
>>
>> +     /* if pinctrl is not supported on the system */
>> +     if (IS_ERR(i2c_imx->pinctrl))
>> +             i2c_imx->pinctrl = NULL;
>> +
>> +     if (!i2c_imx->pinctrl) {
>> +             dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
>> +             return;
>> +     }
>> +
>>       i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
>>                       PINCTRL_STATE_DEFAULT);
>>       i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
>> @@ -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
devm_pinctrl_get() to explain that the pinctrl is optional.  Hopefully
you are not suggesting to explain what -ENOMEM and -EPROBE_DEFER mean
in the comment. :)

>
> Also I'd put
>
>         i2c_imx->pinctrl = NULL;
>
> directly after devm_pinctrl_get() which I consider the more obvious
> place for this.

On the other hand, put it together with the actually judgement can
make it clear that it is catching both IS_ERR and NULL returns from
devm_pinctrl_get()?

-- 
- Leo

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Uwe Kleine-König]

On Tue, Sep 06, 2016 at 03:06:41PM -0500, 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:
> >> Since commit 1c4b6c3bcf30 ("i2c: imx: implement bus recovery") the
> >> driver starts to use gpio/pinctrl to do i2c bus recovery.  But pinctrl
> >> is not always available for platforms with this controller such as ls1021a
> >> and ls1043a, and the device tree binding also mentioned this gpio based
> >> recovery mechanism as optional.  The patch makes it really optional that
> >> the probe function won't bailout but just disable the bus recovery function
> >> when pinctrl is not available.
> >>
> >> Signed-off-by: Li Yang <leoyang.li@nxp.com>
> >> Cc: Gao Pan <pandy.gao@nxp.com>
> >> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> >> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> >> ---
> >> v5:
> >> Revert the last minute change of recovery info initialization timing, it
> >> will cause problem if initialized after i2c_add_numbered_adapter()
> >>
> >> v4:
> >> Remove the use of IS_ERR_OR_NULL
> >> Move the condition judgement to i2c_imx_init_recovery_info()
> >> Change the timing of recovery initialization to be after bus registration
> >>
> >> v3:
> >> Rebased to Wolfram's for-next branch
> >> Added acked-by from Linus Walleij
> >> Update to use new nxp email addresses due to company merge
> >>
> >>  drivers/i2c/busses/i2c-imx.c | 15 ++++++++++++++-
> >>  1 file changed, 14 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> >> index 1844bc9..7ae7992 100644
> >> --- a/drivers/i2c/busses/i2c-imx.c
> >> +++ b/drivers/i2c/busses/i2c-imx.c
> >> @@ -989,6 +989,15 @@ static void i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
> >>  {
> >>       struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
> >>
> >> +     /* if pinctrl is not supported on the system */
> >> +     if (IS_ERR(i2c_imx->pinctrl))
> >> +             i2c_imx->pinctrl = NULL;
> >> +
> >> +     if (!i2c_imx->pinctrl) {
> >> +             dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
> >> +             return;
> >> +     }
> >> +
> >>       i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
> >>                       PINCTRL_STATE_DEFAULT);
> >>       i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
> >> @@ -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
> devm_pinctrl_get() to explain that the pinctrl is optional.  Hopefully
> you are not suggesting to explain what -ENOMEM and -EPROBE_DEFER mean
> in the comment. :)

You wrote

	/* optional bus recovery feature through pinctrl */

there. I'd expect to read something like:

	/*
	 * If pinctrl is available it might be possible to switch the
	 * SDA and SCL lines to their GPIO functions and do a recovery
	 * procedure in this mode. If there is anything wrong with
	 * pinctrl we cannot do this and simply skip it.
	 */
 
> > Also I'd put
> >
> >         i2c_imx->pinctrl = NULL;
> >
> > directly after devm_pinctrl_get() which I consider the more obvious
> > place for this.
> 
> On the other hand, put it together with the actually judgement can
> make it clear that it is catching both IS_ERR and NULL returns from
> devm_pinctrl_get()?

When you do it immediately, you have:

	if (i2c_imx->pinctrl)
		use_it();
	else
		ignore_it();

which looks clean. And if later another piece of code is added that
works on the pinctrl value, you don't have to care about the order (or
set it to NULL at two places). Instead you can consider the value const
in the complete driver apart from the little snippet that assigns to it
in .probe().

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Leo Li]

On Tue, Sep 6, 2016 at 4:07 PM, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> On Tue, Sep 06, 2016 at 03:06:41PM -0500, 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:
>> >> Since commit 1c4b6c3bcf30 ("i2c: imx: implement bus recovery") the
>> >> driver starts to use gpio/pinctrl to do i2c bus recovery.  But pinctrl
>> >> is not always available for platforms with this controller such as ls1021a
>> >> and ls1043a, and the device tree binding also mentioned this gpio based
>> >> recovery mechanism as optional.  The patch makes it really optional that
>> >> the probe function won't bailout but just disable the bus recovery function
>> >> when pinctrl is not available.
>> >>
>> >> Signed-off-by: Li Yang <leoyang.li@nxp.com>
>> >> Cc: Gao Pan <pandy.gao@nxp.com>
>> >> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> >> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> >> ---
>> >> v5:
>> >> Revert the last minute change of recovery info initialization timing, it
>> >> will cause problem if initialized after i2c_add_numbered_adapter()
>> >>
>> >> v4:
>> >> Remove the use of IS_ERR_OR_NULL
>> >> Move the condition judgement to i2c_imx_init_recovery_info()
>> >> Change the timing of recovery initialization to be after bus registration
>> >>
>> >> v3:
>> >> Rebased to Wolfram's for-next branch
>> >> Added acked-by from Linus Walleij
>> >> Update to use new nxp email addresses due to company merge
>> >>
>> >>  drivers/i2c/busses/i2c-imx.c | 15 ++++++++++++++-
>> >>  1 file changed, 14 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
>> >> index 1844bc9..7ae7992 100644
>> >> --- a/drivers/i2c/busses/i2c-imx.c
>> >> +++ b/drivers/i2c/busses/i2c-imx.c
>> >> @@ -989,6 +989,15 @@ static void i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
>> >>  {
>> >>       struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
>> >>
>> >> +     /* if pinctrl is not supported on the system */
>> >> +     if (IS_ERR(i2c_imx->pinctrl))
>> >> +             i2c_imx->pinctrl = NULL;
>> >> +
>> >> +     if (!i2c_imx->pinctrl) {
>> >> +             dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
>> >> +             return;
>> >> +     }
>> >> +
>> >>       i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
>> >>                       PINCTRL_STATE_DEFAULT);
>> >>       i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
>> >> @@ -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
>> devm_pinctrl_get() to explain that the pinctrl is optional.  Hopefully
>> you are not suggesting to explain what -ENOMEM and -EPROBE_DEFER mean
>> in the comment. :)
>
> You wrote
>
>         /* optional bus recovery feature through pinctrl */
>
> there. I'd expect to read something like:
>
>         /*
>          * If pinctrl is available it might be possible to switch the
>          * SDA and SCL lines to their GPIO functions and do a recovery
>          * procedure in this mode. If there is anything wrong with
>          * pinctrl we cannot do this and simply skip it.
>          */

Thanks.  I will use this.  This does looks more clear.  And more verbose too. :)

>
>> > Also I'd put
>> >
>> >         i2c_imx->pinctrl = NULL;
>> >
>> > directly after devm_pinctrl_get() which I consider the more obvious
>> > place for this.
>>
>> On the other hand, put it together with the actually judgement can
>> make it clear that it is catching both IS_ERR and NULL returns from
>> devm_pinctrl_get()?
>
> When you do it immediately, you have:
>
>         if (i2c_imx->pinctrl)
>                 use_it();
>         else
>                 ignore_it();
>

But you suggested the other way last time "Or maybe make
i2c_imx_init_recovery_info aware of this situation to keep the caller
simple?"  :)  Either way I think it is just personal preferences with
both subtle pros and cons.  I don't think we should spend too much
time on this.

Regards,
Leo

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Stefan Agner]

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:
>>> Since commit 1c4b6c3bcf30 ("i2c: imx: implement bus recovery") the
>>> driver starts to use gpio/pinctrl to do i2c bus recovery.  But pinctrl
>>> is not always available for platforms with this controller such as ls1021a
>>> and ls1043a, and the device tree binding also mentioned this gpio based
>>> recovery mechanism as optional.  The patch makes it really optional that
>>> the probe function won't bailout but just disable the bus recovery function
>>> when pinctrl is not available.
>>>
>>> Signed-off-by: Li Yang <leoyang.li@nxp.com>
>>> Cc: Gao Pan <pandy.gao@nxp.com>
>>> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>> v5:
>>> Revert the last minute change of recovery info initialization timing, it
>>> will cause problem if initialized after i2c_add_numbered_adapter()
>>>
>>> v4:
>>> Remove the use of IS_ERR_OR_NULL
>>> Move the condition judgement to i2c_imx_init_recovery_info()
>>> Change the timing of recovery initialization to be after bus registration
>>>
>>> v3:
>>> Rebased to Wolfram's for-next branch
>>> Added acked-by from Linus Walleij
>>> Update to use new nxp email addresses due to company merge
>>>
>>>  drivers/i2c/busses/i2c-imx.c | 15 ++++++++++++++-
>>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
>>> index 1844bc9..7ae7992 100644
>>> --- a/drivers/i2c/busses/i2c-imx.c
>>> +++ b/drivers/i2c/busses/i2c-imx.c
>>> @@ -989,6 +989,15 @@ static void i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
>>>  {
>>>       struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
>>>
>>> +     /* if pinctrl is not supported on the system */
>>> +     if (IS_ERR(i2c_imx->pinctrl))
>>> +             i2c_imx->pinctrl = NULL;
>>> +
>>> +     if (!i2c_imx->pinctrl) {
>>> +             dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
>>> +             return;
>>> +     }
>>> +
>>>       i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
>>>                       PINCTRL_STATE_DEFAULT);
>>>       i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
>>> @@ -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.

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)

...

--
Stefan

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Leo Li]

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:
>>>> Since commit 1c4b6c3bcf30 ("i2c: imx: implement bus recovery") the
>>>> driver starts to use gpio/pinctrl to do i2c bus recovery.  But pinctrl
>>>> is not always available for platforms with this controller such as ls1021a
>>>> and ls1043a, and the device tree binding also mentioned this gpio based
>>>> recovery mechanism as optional.  The patch makes it really optional that
>>>> the probe function won't bailout but just disable the bus recovery function
>>>> when pinctrl is not available.
>>>>
>>>> Signed-off-by: Li Yang <leoyang.li@nxp.com>
>>>> Cc: Gao Pan <pandy.gao@nxp.com>
>>>> Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>>>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>>>> ---
>>>> v5:
>>>> Revert the last minute change of recovery info initialization timing, it
>>>> will cause problem if initialized after i2c_add_numbered_adapter()
>>>>
>>>> v4:
>>>> Remove the use of IS_ERR_OR_NULL
>>>> Move the condition judgement to i2c_imx_init_recovery_info()
>>>> Change the timing of recovery initialization to be after bus registration
>>>>
>>>> v3:
>>>> Rebased to Wolfram's for-next branch
>>>> Added acked-by from Linus Walleij
>>>> Update to use new nxp email addresses due to company merge
>>>>
>>>>  drivers/i2c/busses/i2c-imx.c | 15 ++++++++++++++-
>>>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
>>>> index 1844bc9..7ae7992 100644
>>>> --- a/drivers/i2c/busses/i2c-imx.c
>>>> +++ b/drivers/i2c/busses/i2c-imx.c
>>>> @@ -989,6 +989,15 @@ static void i2c_imx_init_recovery_info(struct imx_i2c_struct *i2c_imx,
>>>>  {
>>>>       struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
>>>>
>>>> +     /* if pinctrl is not supported on the system */
>>>> +     if (IS_ERR(i2c_imx->pinctrl))
>>>> +             i2c_imx->pinctrl = NULL;
>>>> +
>>>> +     if (!i2c_imx->pinctrl) {
>>>> +             dev_info(&pdev->dev, "can't get pinctrl, bus recovery not supported\n");
>>>> +             return;
>>>> +     }
>>>> +
>>>>       i2c_imx->pinctrl_pins_default = pinctrl_lookup_state(i2c_imx->pinctrl,
>>>>                       PINCTRL_STATE_DEFAULT);
>>>>       i2c_imx->pinctrl_pins_gpio = pinctrl_lookup_state(i2c_imx->pinctrl,
>>>> @@ -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.

Regards,
Leo

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Uwe Kleine-König]

Hello,

On Tue, Sep 06, 2016 at 06:35:38PM -0500, Tracy Smith wrote:
> >The patch makes it really optional that
> >the probe function won't bailout but just disable the bus recovery function
> >when pinctrl is not available.
> 
> in the case of the LS1043A and LS1021A, if the bus recovery function is
> disabled, how will bus recovery occur?  Is there no option to recover the
> bus for the LS1021a and LS1043a?

Right. That's the situation that we had for all drivers some time ago.
Most of the time this is no problem.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Leo Li]

On Wed, Sep 7, 2016 at 5:07 AM, Tracy Smith <tlsmith3777@gmail.com> wrote:
> Hello, bus recovery is needed generally speaking because of potential
> protocol errors that might cause a failure condition hanging the bus.
>
> It happens frequently during bring-up of new I2C devices because firmware in
> I2C controllers fail to handle properly protocol errors.
>
> Can NXP add bus recovery for the LS1021A and LS1043A in a separate patch--
> unless there is no HW bus recovery mechanism?
>
> The concern is while fixing I.MX, NXP will fail to fix the driver bus
> recovery for the LS1021A and LS1043A and the bus will hang.
>
> If bus recovery is supported on the LS1021A and the LS1043A, a patch should
> be provided or added in this patch instead of simply disabling bus recovery.
> Request NXP to consider the patch if there is HW support for bus recovery.

I'm not the right person to answer if this is possible.  I will
forward your request to the related developer.

Thanks,
Leo

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Leo Li]

On Wed, Sep 7, 2016 at 5:07 AM, Tracy Smith <tlsmith3777@gmail.com> wrote:
> Hello, bus recovery is needed generally speaking because of potential
> protocol errors that might cause a failure condition hanging the bus.
>
> It happens frequently during bring-up of new I2C devices because firmware in
> I2C controllers fail to handle properly protocol errors.
>
> Can NXP add bus recovery for the LS1021A and LS1043A in a separate patch--
> unless there is no HW bus recovery mechanism?
>
> The concern is while fixing I.MX, NXP will fail to fix the driver bus
> recovery for the LS1021A and LS1043A and the bus will hang.
>
> If bus recovery is supported on the LS1021A and the LS1043A, a patch should
> be provided or added in this patch instead of simply disabling bus recovery.
> Request NXP to consider the patch if there is HW support for bus recovery.

FYI.  http://patchwork.ozlabs.org/patch/573879/  This seem to be the
patch you are asking for.  I have asked the original developer to
update the patch according to Wolfram's comment and work together with
the current pinctrl/gpio based recovery.  In the meanwhile you can
make use of the patch for now for LS1021A and LS1043A if necessary.

Regards,
Leo

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Leo Li]

On Mon, Sep 12, 2016 at 11:35 AM, Leo Li <pku.leo@gmail.com> wrote:
> On Wed, Sep 7, 2016 at 5:07 AM, Tracy Smith <tlsmith3777@gmail.com> wrote:
>> Hello, bus recovery is needed generally speaking because of potential
>> protocol errors that might cause a failure condition hanging the bus.
>>
>> It happens frequently during bring-up of new I2C devices because firmware in
>> I2C controllers fail to handle properly protocol errors.
>>
>> Can NXP add bus recovery for the LS1021A and LS1043A in a separate patch--
>> unless there is no HW bus recovery mechanism?
>>
>> The concern is while fixing I.MX, NXP will fail to fix the driver bus
>> recovery for the LS1021A and LS1043A and the bus will hang.
>>
>> If bus recovery is supported on the LS1021A and the LS1043A, a patch should
>> be provided or added in this patch instead of simply disabling bus recovery.
>> Request NXP to consider the patch if there is HW support for bus recovery.
>
> FYI.  http://patchwork.ozlabs.org/patch/573879/

Hi Gao Pan,

Do you think the operations in the proposed patch is also usable on
the I.MX SoC for bus recovery?  If so, would it be better to align the
bus recovery implementation for both I.MX and QorIQ to use the same
logic inside the IP?

Regards,
Leo

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Stefan Agner]

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

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Leo Li]

On Thu, Sep 8, 2016 at 5:39 PM, Stefan Agner <stefan@agner.ch> wrote:
> 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.

With this patch the i2c bus recovery feature will be disabled if the
devm_pinctrl_get() fails.  The pin mux setting will not be changed in
either i2c probe stage or at runtime.  I don't think it can cause any
trouble to normal I2C operation.  IMO, it is not good to *force*
people fix problem that they don't really care by deliberately enlarge
the problem.  That's why we don't panic() on any error we found.  For
those who do care about the bus recovery, they can get the information
from the console.

Regards,
Leo

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Stefan Agner]

On 2016-09-08 16:57, Leo Li wrote:
> On Thu, Sep 8, 2016 at 5:39 PM, Stefan Agner <stefan@agner.ch> wrote:
>> 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.
> 
> With this patch the i2c bus recovery feature will be disabled if the
> devm_pinctrl_get() fails.  The pin mux setting will not be changed in
> either i2c probe stage or at runtime.  I don't think it can cause any
> trouble to normal I2C operation.  IMO, it is not good to *force*

If you have a pin controller, and you make a typo in your device tree
which leads to a wrong phandle and devm_pinctrl_get returning -EINVAL,
the system won't mux the pins... And that will certainly affect normal
I2C operation!

> people fix problem that they don't really care by deliberately enlarge
> the problem.  That's why we don't panic() on any error we found.  For
> those who do care about the bus recovery, they can get the information
> from the console.

IMHO, it is just stupid to ignore errors and then let the developer
later on trace back what the initial issue was. Error out early is a
common sense software design principle...

I am not asking for a panic(), I am just suggesting to only ignore
pinctrl if it returns -ENODEV, the case you care are about.

--
Stefan

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Leo Li]

On Fri, Sep 9, 2016 at 11:51 AM, Stefan Agner <stefan@agner.ch> wrote:
> On 2016-09-08 16:57, Leo Li wrote:
>> On Thu, Sep 8, 2016 at 5:39 PM, Stefan Agner <stefan@agner.ch> wrote:
>>> 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.
>>
>> With this patch the i2c bus recovery feature will be disabled if the
>> devm_pinctrl_get() fails.  The pin mux setting will not be changed in
>> either i2c probe stage or at runtime.  I don't think it can cause any
>> trouble to normal I2C operation.  IMO, it is not good to *force*
>
> If you have a pin controller, and you make a typo in your device tree
> which leads to a wrong phandle and devm_pinctrl_get returning -EINVAL,
> the system won't mux the pins... And that will certainly affect normal
> I2C operation!

I see why we are having different understanding now.  The i2c-imx
driver doesn't rely on the pinctrl to get the correct pin-mux setting
for I2C operation.   The pinctrl code was just added for recently for
the bus recovery function.  The assumption is that the correct
pin-muxing has been taken care of by platform code or reset logic.
The pinctrl is only used to enter/exit bus recovery mode, nothing
else.  Hence optional.  So a typo in the pinctrl node only impacts bus
recovery function.

>
>> people fix problem that they don't really care by deliberately enlarge
>> the problem.  That's why we don't panic() on any error we found.  For
>> those who do care about the bus recovery, they can get the information
>> from the console.
>
> IMHO, it is just stupid to ignore errors and then let the developer
> later on trace back what the initial issue was. Error out early is a
> common sense software design principle...
>
> I am not asking for a panic(), I am just suggesting to only ignore
> pinctrl if it returns -ENODEV, the case you care are about.

It was just an analogy for enlarging the problem for getting
attention.  But you probably thought that it was not enlarging the
problem as you think pinctrl is required by the driver instead of an
optional thing.

Regards,
Leo

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Stefan Agner]

On 2016-09-09 12:37, Leo Li wrote:
> On Fri, Sep 9, 2016 at 11:51 AM, Stefan Agner <stefan@agner.ch> wrote:
>> On 2016-09-08 16:57, Leo Li wrote:
>>> On Thu, Sep 8, 2016 at 5:39 PM, Stefan Agner <stefan@agner.ch> wrote:
>>>> 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.
>>>
>>> With this patch the i2c bus recovery feature will be disabled if the
>>> devm_pinctrl_get() fails.  The pin mux setting will not be changed in
>>> either i2c probe stage or at runtime.  I don't think it can cause any
>>> trouble to normal I2C operation.  IMO, it is not good to *force*
>>
>> If you have a pin controller, and you make a typo in your device tree
>> which leads to a wrong phandle and devm_pinctrl_get returning -EINVAL,
>> the system won't mux the pins... And that will certainly affect normal
>> I2C operation!
> 
> I see why we are having different understanding now.  The i2c-imx
> driver doesn't rely on the pinctrl to get the correct pin-mux setting
> for I2C operation.   The pinctrl code was just added for recently for
> the bus recovery function.  The assumption is that the correct
> pin-muxing has been taken care of by platform code or reset logic.
> The pinctrl is only used to enter/exit bus recovery mode, nothing
> else.  Hence optional.  So a typo in the pinctrl node only impacts bus
> recovery function.
> 

You are right, the framework usually makes sure that default pinctrl
gets applied. I got that wrong.

>>
>>> people fix problem that they don't really care by deliberately enlarge
>>> the problem.  That's why we don't panic() on any error we found.  For
>>> those who do care about the bus recovery, they can get the information
>>> from the console.
>>
>> IMHO, it is just stupid to ignore errors and then let the developer
>> later on trace back what the initial issue was. Error out early is a
>> common sense software design principle...
>>
>> I am not asking for a panic(), I am just suggesting to only ignore
>> pinctrl if it returns -ENODEV, the case you care are about.
> 
> It was just an analogy for enlarging the problem for getting
> attention.  But you probably thought that it was not enlarging the
> problem as you think pinctrl is required by the driver instead of an
> optional thing.

Yeah it is a bit a wording thing: In my understanding, pinctrl is
required on SoC's witch have a pin controller... It is just that the
driver does not need to get the pinctrl by itself because the stack is
taking care of it implicitly. And yes, that makes the particular example
not a real world example.

However, I still feel that only bailing out if -ENODEV is returned is
the cleaner solution, and expresses better what your intention is. But
then I am not the pinctrl maintainer and I don't feel that it is worth
debating more around it, so whatever...

--
Stefan

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Uwe Kleine-König]

Hello,

On Fri, Sep 09, 2016 at 01:34:31PM -0700, Stefan Agner wrote:
> Yeah it is a bit a wording thing: In my understanding, pinctrl is
> required on SoC's witch have a pin controller... It is just that the
> driver does not need to get the pinctrl by itself because the stack is
> taking care of it implicitly. And yes, that makes the particular example
> not a real world example.

At first I thought, too, that it's a fatal problem if getting the
pinctrl stuff fails. IMHO that shows that the comments (or the code) are
still not good enough.

Maybe we should do something like that:

/*
 * As the IP doesn't support bus recovery, we have to switch SCL and SDA
 * to their GPIO function and do some bitbanging. These alternative
 * pinmux settings can be described in the device tree by a separate
 * pinctrl state "gpio". If this is missing this is not a big problem,
 * the only implication is that we can't do bus recovery.
 */
static void i2c_imx_init_recovery_info(...)
{
	...

and then put

        i2c_imx->pinctrl = devm_pinctrl_get(&pdev->dev);
        if (IS_ERR(i2c_imx->pinctrl))
		return;

into this function (and remove it from i2c_imx_probe). This makes it
more obvious that .pinctrl is only ever used for recovery and as
i2c_imx_init_recovery_info is void there is no error to propagate.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Leo Li]

On Fri, Sep 9, 2016 at 3:59 PM, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> Hello,
>
> On Fri, Sep 09, 2016 at 01:34:31PM -0700, Stefan Agner wrote:
>> Yeah it is a bit a wording thing: In my understanding, pinctrl is
>> required on SoC's witch have a pin controller... It is just that the
>> driver does not need to get the pinctrl by itself because the stack is
>> taking care of it implicitly. And yes, that makes the particular example
>> not a real world example.
>
> At first I thought, too, that it's a fatal problem if getting the
> pinctrl stuff fails. IMHO that shows that the comments (or the code) are
> still not good enough.

Ya.  If it has confused more than one people, it is likely to confuse
more.  I agree with you that we should make it more clear.

Thanks,
Leo

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Lothar Waßmann]

Hi,

On Fri, 9 Sep 2016 14:37:12 -0500 Leo Li wrote:
> On Fri, Sep 9, 2016 at 11:51 AM, Stefan Agner <stefan@agner.ch> wrote:
> > On 2016-09-08 16:57, Leo Li wrote:
[...]
> >> people fix problem that they don't really care by deliberately enlarge
> >> the problem.  That's why we don't panic() on any error we found.  For
> >> those who do care about the bus recovery, they can get the information
> >> from the console.
> >
> > IMHO, it is just stupid to ignore errors and then let the developer
> > later on trace back what the initial issue was. Error out early is a
> > common sense software design principle...
> >
> > I am not asking for a panic(), I am just suggesting to only ignore
> > pinctrl if it returns -ENODEV, the case you care are about.
> 
> It was just an analogy for enlarging the problem for getting
> attention.  But you probably thought that it was not enlarging the
> problem as you think pinctrl is required by the driver instead of an
> optional thing.
> 
The I2C bus recovery is a feature which is not used during normal
operation and you won't find that it's not working unless something
unusual happens (probably only in a productive environment). It may even
be hard to trigger a condition to test the feature.
Thus IMO it is vital that the driver complains loudly if something is
missing to make this feature work if requested.


Lothar Waßmann

Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional

[Leo Li]

On Mon, Sep 12, 2016 at 3:21 AM, Lothar Waßmann <LW@karo-electronics.de> wrote:
> Hi,
>
> On Fri, 9 Sep 2016 14:37:12 -0500 Leo Li wrote:
>> On Fri, Sep 9, 2016 at 11:51 AM, Stefan Agner <stefan@agner.ch> wrote:
>> > On 2016-09-08 16:57, Leo Li wrote:
> [...]
>> >> people fix problem that they don't really care by deliberately enlarge
>> >> the problem.  That's why we don't panic() on any error we found.  For
>> >> those who do care about the bus recovery, they can get the information
>> >> from the console.
>> >
>> > IMHO, it is just stupid to ignore errors and then let the developer
>> > later on trace back what the initial issue was. Error out early is a
>> > common sense software design principle...
>> >
>> > I am not asking for a panic(), I am just suggesting to only ignore
>> > pinctrl if it returns -ENODEV, the case you care are about.
>>
>> It was just an analogy for enlarging the problem for getting
>> attention.  But you probably thought that it was not enlarging the
>> problem as you think pinctrl is required by the driver instead of an
>> optional thing.
>>
> The I2C bus recovery is a feature which is not used during normal
> operation and you won't find that it's not working unless something
> unusual happens (probably only in a productive environment). It may even
> be hard to trigger a condition to test the feature.
> Thus IMO it is vital that the driver complains loudly if something is
> missing to make this feature work if requested.

I agree.  A message is already added in this patch to mention that bus
recovery is not supported due to pinctrl when there is a problem.

Regards,
Leo