On Fri, Mar 14, 2014 at 5:23 PM, Josh Cartwright <jo...@codeaurora.org> wrote: > So, are you suggesting that because fatal errors should be "extremely > rare", a consuming driver should just assume that if NULL is returned > from a hwspin_lock_request*() function that it was the "device not yet > probed" case that was hit?
No - it's not the scarcity, it's the severity. The error path that will be optimized here is an invalid id. If this happens, the consumer will crash and burn, and I'm not sure that slightly optimizing his death is very interesting? BTW the hwspinlock core once did use ERR_PTR and friends, and it was changed due to convincing arguments against that methodology on this mailing list. We can change it back but we need a strong(er) case. > Note that having the consumer/hwspinlock device relationship modeled in > devicetree introduces more potential failure cases... Yeah. Even the error above, presumed to be EPROBE_DEFER, may be a symptom of some other fatal error that occurred, and we can't be sure that a future request will surely be satisfied. So before we bloat our code, I suggest that we wait for consumers to show up and see if there's real benefit. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
