On Thursday 08 March 2012 03:04 PM, Tomi Valkeinen wrote:
On Thu, 2012-03-08 at 14:52 +0530, Archit Taneja wrote:
On Thursday 08 March 2012 02:16 PM, Tomi Valkeinen wrote:
On Thu, 2012-03-08 at 14:04 +0530, Archit Taneja wrote:
<snip>
Oh okay. But the comment after the patch set still says "It's ok if the
output-driver register fails.", we could change it to "It's ok if the
output-driver probe fails."
Well, I guess this goes into nitpicking area, but if there are no
devices, probe is not called at all. So I think it's the driver register
that fails in that case. If there is a device, and it is probed, and
that fails, then it's probe which fails.
Yes, that's fair enough I guess.
<snip>
If we ensure that none of our probes return ENODEV(even though it may
make sense to return it if a func within probe fails), we could
differentiate between the 2 cases, right?
True, I thought about that. But we can never be sure that the functions
called by the probe (clk_get, or whatever) won't return ENODEV. Of
course, we could check what they return, and change the error to
something else, but I'm not sure if that's good either.
That's true.
<snip>
Alternatively, if the platform driver code was changed to tell us
clearly if it was the probe that failed or if there just weren't any
devices, we could also use that.
Yes, I wonder how that could be done.
Archit
Tomi
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
