[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201303191648.31527.arnd@arndb.de>
Date: Tue, 19 Mar 2013 16:48:31 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Fabio Porcedda <fabio.porcedda@...il.com>,
H Hartley Sweeten <hartleys@...ionengravers.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"linux-ide@...r.kernel.org" <linux-ide@...r.kernel.org>,
"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
"Hans-Christian Egtvedt" <hans-christian.egtvedt@...el.com>,
Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH 10/10] drivers: misc: use module_platform_driver_probe()
On Tuesday 19 March 2013, Geert Uytterhoeven wrote:
> Hmm, so we may have drivers that (now) work perfectly fine with
> module_platform_driver_probe()/platform_driver_probe(), but will start
> failing suddenly in the future?
They will fail if someone changes the initialization order. That would
already break drivers before deferred probing support (and was the reason
we added feature in the first place), but now we can be much more liberal
with the order in which drivers are initialized, except when they are
using platform_driver_probe()
> I guess we need a big fat WARN_ON(-EPROBE_DEFER) in
> platform_driver_probe() to catch these?
Yes, very good idea.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists