On Fri, Oct 07, 2011 at 04:09:38PM -0600, Grant Likely wrote:
On Fri, Oct 7, 2011 at 4:06 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Fri, 07 Oct 2011 10:33:09 +0500
G, Manjunath Kondaiah manj...@ti.com wrote:
The gpio library should return -EPROBE_DEFER in gpio_request
if gpio
On Wed, Oct 12, 2011 at 11:44:32AM +0530, G, Manjunath Kondaiah wrote:
On Fri, Oct 07, 2011 at 04:09:38PM -0600, Grant Likely wrote:
On Fri, Oct 7, 2011 at 4:06 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Fri, 07 Oct 2011 10:33:09 +0500
G, Manjunath Kondaiah manj...@ti.com wrote:
On Fri, 07 Oct 2011 10:33:09 +0500
G, Manjunath Kondaiah manj...@ti.com wrote:
The gpio library should return -EPROBE_DEFER in gpio_request
if gpio driver is not ready.
Why not use the perfectly good existing error codes we have for this ?
We have EAGAIN and EUNATCH both of which look
On Fri, Oct 7, 2011 at 4:06 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
On Fri, 07 Oct 2011 10:33:09 +0500
G, Manjunath Kondaiah manj...@ti.com wrote:
The gpio library should return -EPROBE_DEFER in gpio_request
if gpio driver is not ready.
Why not use the perfectly good existing error
The gpio library should return -EPROBE_DEFER in gpio_request
if gpio driver is not ready. If drivers pass this error code through to
their caller (which they really should) then this will ensure that the
probe is retried later when further devices become available.
Signed-off-by: G, Manjunath
The gpio library should return -EPROBE_DEFER in gpio_request
if gpio driver is not ready. If drivers pass this error code through to
their caller (which they really should) then this will ensure that the
probe is retried later when further devices become available.
Signed-off-by: G, Manjunath
