public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] w1-gpio: handle of_get_gpio() returning -EPROBE_DEFER better
@ 2014-02-13 22:05 Uwe Kleine-König
  2014-02-18  1:26 ` zbr
  0 siblings, 1 reply; 5+ messages in thread
From: Uwe Kleine-König @ 2014-02-13 22:05 UTC (permalink / raw)
  To: Evgeniy Polyakov; +Cc: kernel, Greg Kroah-Hartman, linux-kernel

of_get_gpio() might return -EPROBE_DEFER meaning that the driver
providing the gpio isn't ready yet. If that happens for the first gpio
the resulting kernel output without this patch is:

	w1-gpio somename: Failed to parse DT
	platform somename: Driver w1-gpio requests probe deferral

The first message is misleading and so is suppressed with this patch.

Further if determining the gpio to switch the external pullup yields
-EPROBE_DEFER this error should be passed back to the caller instead of
just continuing without pullup.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
Actually I'm not completely happy with this change because IMHO if a
device tree node contains:

	gpios = <&gpio5 0 0 4>;

where gpio5's #gpio-cells property is <2> I'd prefer to not bind the
driver with an error message instead of treating it as if

	gpios = <&gpio5 0 0>;

was specified. Still this patch is a correct first step.

So something like that would be nice:

	len = get_len_of_gpio_array();
	if (len < 0)
		/* not well-formed */
		return len;

	if (len == 1)
		go on without pullup
	else if (len == 2)
		go on with pullup
	else
		scream
---
 drivers/w1/masters/w1-gpio.c | 19 ++++++++++++++-----
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index e36b18b2817b..4b581228a4d9 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -68,11 +68,22 @@ static int w1_gpio_probe_dt(struct platform_device *pdev)
 		pdata->is_open_drain = 1;
 
 	gpio = of_get_gpio(np, 0);
-	if (gpio < 0)
+	if (gpio < 0) {
+		if (gpio != -EPROBE_DEFER)
+			dev_err(&pdev->dev,
+					"Failed to parse gpio property for data pin (%d)\n",
+					gpio);
+
 		return gpio;
+	}
 	pdata->pin = gpio;
 
-	pdata->ext_pullup_enable_pin = of_get_gpio(np, 1);
+	gpio = of_get_gpio(np, 1);
+	if (gpio == -EPROBE_DEFER)
+		return gpio;
+	/* ignore other errors as the pullup gpio is optional */
+	pdata->ext_pullup_enable_pin = gpio;
+
 	pdev->dev.platform_data = pdata;
 
 	return 0;
@@ -86,10 +97,8 @@ static int w1_gpio_probe(struct platform_device *pdev)
 
 	if (of_have_populated_dt()) {
 		err = w1_gpio_probe_dt(pdev);
-		if (err < 0) {
-			dev_err(&pdev->dev, "Failed to parse DT\n");
+		if (err < 0)
 			return err;
-		}
 	}
 
 	pdata = dev_get_platdata(&pdev->dev);
-- 
1.8.5.3


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] w1-gpio: handle of_get_gpio() returning -EPROBE_DEFER better
  2014-02-13 22:05 [PATCH] w1-gpio: handle of_get_gpio() returning -EPROBE_DEFER better Uwe Kleine-König
@ 2014-02-18  1:26 ` zbr
  2014-02-18  8:24   ` Uwe Kleine-König
  0 siblings, 1 reply; 5+ messages in thread
From: zbr @ 2014-02-18  1:26 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: kernel@pengutronix.de, Greg Kroah-Hartman,
	linux-kernel@vger.kernel.org

Hi

14.02.2014, 02:05, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>:
> of_get_gpio() might return -EPROBE_DEFER meaning that the driver
> providing the gpio isn't ready yet. If that happens for the first gpio
> the resulting kernel output without this patch is:
>
>         w1-gpio somename: Failed to parse DT
>         platform somename: Driver w1-gpio requests probe deferral
>
> The first message is misleading and so is suppressed with this patch.
>
> Further if determining the gpio to switch the external pullup yields
> -EPROBE_DEFER this error should be passed back to the caller instead of
> just continuing without pullup.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

I'm ok with this patch, but I virtually do not understand what it does :)
Since I know nothing about device trees.

But yet it looks innocent enough to merge.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] w1-gpio: handle of_get_gpio() returning -EPROBE_DEFER better
  2014-02-18  1:26 ` zbr
@ 2014-02-18  8:24   ` Uwe Kleine-König
  2014-02-18 14:34     ` Evgeniy Polyakov
  0 siblings, 1 reply; 5+ messages in thread
From: Uwe Kleine-König @ 2014-02-18  8:24 UTC (permalink / raw)
  To: zbr; +Cc: kernel@pengutronix.de, Greg Kroah-Hartman,
	linux-kernel@vger.kernel.org

On Tue, Feb 18, 2014 at 05:26:20AM +0400, zbr@ioremap.net wrote:
> Hi
> 
> 14.02.2014, 02:05, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>:
> > of_get_gpio() might return -EPROBE_DEFER meaning that the driver
> > providing the gpio isn't ready yet. If that happens for the first gpio
> > the resulting kernel output without this patch is:
> >
> >         w1-gpio somename: Failed to parse DT
> >         platform somename: Driver w1-gpio requests probe deferral
> >
> > The first message is misleading and so is suppressed with this patch.
> >
> > Further if determining the gpio to switch the external pullup yields
> > -EPROBE_DEFER this error should be passed back to the caller instead of
> > just continuing without pullup.
> >
> > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> 
> I'm ok with this patch, but I virtually do not understand what it does :)
> Since I know nothing about device trees.
The thing is that the w1-gpio device might be probed before the gpio's
controller is available. In this case of_get_gpio returns -EPROBE_DEFER
and this makes the device core retry probing the w1-gpio device later
again. So this is not a dt-parsing problem but just dependency stuff.

The 2nd issue addressed didn't happen to me, but it might occur that the
first of_get_gpio for the data pin succeeds, but the getting the pullup
gpio fails with -EPROBE_DEFER (e.g. because it sits on a different
controller). In this case you still want to retry probing later instead
of ignoring the problem.
 
Does that make it clearer?

Best regards
Uwe

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] w1-gpio: handle of_get_gpio() returning -EPROBE_DEFER better
  2014-02-18  8:24   ` Uwe Kleine-König
@ 2014-02-18 14:34     ` Evgeniy Polyakov
  2014-02-18 17:47       ` Greg Kroah-Hartman
  0 siblings, 1 reply; 5+ messages in thread
From: Evgeniy Polyakov @ 2014-02-18 14:34 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: kernel@pengutronix.de, Greg Kroah-Hartman,
	linux-kernel@vger.kernel.org

Hi

18.02.2014, 12:24, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>:

> The thing is that the w1-gpio device might be probed before the gpio's
> controller is available. In this case of_get_gpio returns -EPROBE_DEFER
> and this makes the device core retry probing the w1-gpio device later
> again. So this is not a dt-parsing problem but just dependency stuff.
>
> The 2nd issue addressed didn't happen to me, but it might occur that the
> first of_get_gpio for the data pin succeeds, but the getting the pullup
> gpio fails with -EPROBE_DEFER (e.g. because it sits on a different
> controller). In this case you still want to retry probing later instead
> of ignoring the problem.
>
> Does that make it clearer?

Well, yes, thank you :)

Greg, please pull this patch into your tree.

Acked-by: Evgeniy Polyakov <zbr@ioremap.net>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] w1-gpio: handle of_get_gpio() returning -EPROBE_DEFER better
  2014-02-18 14:34     ` Evgeniy Polyakov
@ 2014-02-18 17:47       ` Greg Kroah-Hartman
  0 siblings, 0 replies; 5+ messages in thread
From: Greg Kroah-Hartman @ 2014-02-18 17:47 UTC (permalink / raw)
  To: Evgeniy Polyakov
  Cc: Uwe Kleine-König, kernel@pengutronix.de,
	linux-kernel@vger.kernel.org

On Tue, Feb 18, 2014 at 06:34:07PM +0400, Evgeniy Polyakov wrote:
> Hi
> 
> 18.02.2014, 12:24, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>:
> 
> > The thing is that the w1-gpio device might be probed before the gpio's
> > controller is available. In this case of_get_gpio returns -EPROBE_DEFER
> > and this makes the device core retry probing the w1-gpio device later
> > again. So this is not a dt-parsing problem but just dependency stuff.
> >
> > The 2nd issue addressed didn't happen to me, but it might occur that the
> > first of_get_gpio for the data pin succeeds, but the getting the pullup
> > gpio fails with -EPROBE_DEFER (e.g. because it sits on a different
> > controller). In this case you still want to retry probing later instead
> > of ignoring the problem.
> >
> > Does that make it clearer?
> 
> Well, yes, thank you :)
> 
> Greg, please pull this patch into your tree.

Already merged :)

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2014-02-18 17:46 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-13 22:05 [PATCH] w1-gpio: handle of_get_gpio() returning -EPROBE_DEFER better Uwe Kleine-König
2014-02-18  1:26 ` zbr
2014-02-18  8:24   ` Uwe Kleine-König
2014-02-18 14:34     ` Evgeniy Polyakov
2014-02-18 17:47       ` Greg Kroah-Hartman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox