[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201303151128.48432.arnd@arndb.de>
Date: Fri, 15 Mar 2013 11:28:48 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Fabio Porcedda <fabio.porcedda@...il.com>
Cc: Sascha Hauer <s.hauer@...gutronix.de>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
"linux-media" <linux-media@...r.kernel.org>,
"linux-ide" <linux-ide@...r.kernel.org>,
"lm-sensors" <lm-sensors@...sensors.org>,
"linux-input" <linux-input@...r.kernel.org>,
"linux-fbdev" <linux-fbdev@...r.kernel.org>,
"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
H Hartley Sweeten <hsweeten@...ionengravers.com>,
"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 Friday 15 March 2013, Fabio Porcedda wrote:
> >> * Regarding the use of module_platform_driver_probe, I'm a little worried about
> >> the interactions with deferred probing. I don't think there are any regressions,
> >> but we should probably make people aware that one cannot return -EPROBE_DEFER
> >> from a platform_driver_probe function.
>
> The use of module_platform_driver_probe() doesn't change anything about that,
> it's exactly the same thing as using "return platform_driver_probe()".
> I'm right or I'm missing something? Maybe are you just speaking about
> the misuse of "platform_driver_probe"?
Yes, that was what I meant. The point is that if we need to review or remove
all uses of platform_driver_probe, it would be better not to introduce a
module_platform_driver_probe() interface to make it easier to use.
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