sh: pfc: Fix up init ordering mess.
authorPaul Mundt <lethal@linux-sh.org>
Wed, 1 Aug 2012 07:27:38 +0000 (16:27 +0900)
committerPaul Mundt <lethal@linux-sh.org>
Wed, 1 Aug 2012 07:27:38 +0000 (16:27 +0900)
commit1e32dfe323d156d5d7b25b9feffe015d19713db2
treef68b06588fa03582565ae810dc4445fc5d73edfa
parent92f53a85db3730ae088aaeb7900f85909fd1eda6
sh: pfc: Fix up init ordering mess.

Commit ca5481c68e9fbcea62bb3c78ae6cccf99ca8fb73 ("sh: pfc: Rudimentary
pinctrl-backed GPIO support.") introduced a regression for platforms that
were doing early GPIO API calls (from arch_initcall() or earlier),
leading to a situation where our two-stage registration logic would trip
itself up and we'd -ENODEV out of the pinctrl registration path,
resulting in endless -EPROBE_DEFER errors. Further lack of checking any
sort of errors from gpio_request() resulted in boot time warnings,
tripping on the FLAG_REQUESTED test-and-set in gpio_ensure_requested().

As it turns out there's no particular need to bother with the two-stage
registration, as the platform bus is already available at the point that
we have to start caring. As such, it's easiest to simply fold these
together in to a single init path, the ordering of which is ensured
through the platform's mux registration, as usual.

Reported-by: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
drivers/sh/pfc/pinctrl.c