[PATCH v8] reset: Add driver for gpio-controlled reset pins
shawn.guo at linaro.org
Thu Jul 18 23:23:30 EDT 2013
On Thu, Jul 18, 2013 at 11:45:29AM -0700, Olof Johansson wrote:
> On Thu, Jul 18, 2013 at 4:25 AM, Pavel Machek <pavel at denx.de> wrote:
> > It sound to me like keeping ammount of -EPROBE_DEFER to minimum is
> > still preferred.
> Hand-crafting initcall level ordering of various drivers and subsystem
> is probably an even greater evil though. We've done it in the past,
> but now that we have deferred probe we have the option of not having
> to do it every time, such as this.
> You're spending an awful lot of energy arguing over this, but nobody
> has actually shown data of how much deferral is happening -- and that
> it's a real problem. Until someone does so there's no reason to change
> it from the default module init level at all, I'd say.
On imx6qdl-sabreauto board, there are 3 MAX7310 units as IO expanders to
output 3 x 8 = 24 GPIOs. 18 of them are used for resets, enables and
pin steering for various peripherals on the board.
Most of these GPIOs need to set up properly at client device driver's
probe stage - module_init() time. So if we have all these service
providers resets/enables/steering API registered at module_init() too,
the probes of all these client device drivers stand a good chance to be
More information about the linux-arm-kernel