* [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