Messages in this thread | | | Date | Tue, 18 Feb 2014 09:24:36 +0100 | From | Uwe Kleine-König <> | Subject | Re: [PATCH] w1-gpio: handle of_get_gpio() returning -EPROBE_DEFER better |
| |
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/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |