Re: [PATCH] gpiolib: Defer failed gpio requests by default

2012-07-17 Thread Linus Walleij
On Mon, Jul 9, 2012 at 1:22 PM, Mark Brown wrote: > Since users must be explicitly provided with a GPIO number in order to > request one the overwhelmingly common case for failing to request will > be that the required GPIO driver has not yet registered and we should > therefore defer until it ha

Re: [PATCH] gpiolib: Defer failed gpio requests by default

2012-07-10 Thread Mark Brown
On Mon, Jul 09, 2012 at 10:54:41PM +0100, Grant Likely wrote: > I'm fine with this patch, but the patch that adds the twizzling of the > dpm_list when probing needs some tweaking, and this patch must be > applied after that one. I'll go and reply to that patch now (and cc > you if you're not alre

Re: [PATCH] gpiolib: Defer failed gpio requests by default

2012-07-09 Thread Grant Likely
On Mon, Jul 9, 2012 at 9:31 PM, Linus Walleij wrote: > On Mon, Jul 9, 2012 at 1:22 PM, Mark Brown > wrote: > >> Since users must be explicitly provided with a GPIO number in order to >> request one the overwhelmingly common case for failing to request will >> be that the required GPIO driver has

Re: [PATCH] gpiolib: Defer failed gpio requests by default

2012-07-09 Thread Linus Walleij
On Mon, Jul 9, 2012 at 1:22 PM, Mark Brown wrote: > Since users must be explicitly provided with a GPIO number in order to > request one the overwhelmingly common case for failing to request will > be that the required GPIO driver has not yet registered and we should > therefore defer until it ha

[PATCH] gpiolib: Defer failed gpio requests by default

2012-07-09 Thread Mark Brown
Since users must be explicitly provided with a GPIO number in order to request one the overwhelmingly common case for failing to request will be that the required GPIO driver has not yet registered and we should therefore defer until it has registered. In order to avoid having to code this logic i