Re: [PATCH] gpio: Propagate errors from chip->get()

2015-09-08 Thread Linus Walleij
On Tue, Sep 1, 2015 at 7:16 AM, Bjorn Andersson wrote: > Linus, Alexandre, please feel free to apply this with -ENOTSUPP in > accordance to Alexandre's comment in [1], if you prefer that. I picked > -EIO as that's what's used in most other places when the get() op is > missing. I applied as-is f

Re: [PATCH] gpio: Propagate errors from chip->get()

2015-09-08 Thread Linus Walleij
On Fri, Aug 28, 2015 at 6:44 PM, Bjorn Andersson wrote: > It's possible to have gpio chips hanging off unreliable remote buses > where the get() operation will fail to acquire a readout of the current > gpio state. Propagate these errors to the consumer so that they can > act on, retry or ignore

Re: [PATCH] gpio: Propagate errors from chip->get()

2015-09-02 Thread Alexandre Courbot
On Tue, Sep 1, 2015 at 2:16 PM, Bjorn Andersson wrote: > On Fri 28 Aug 09:44 PDT 2015, Bjorn Andersson wrote: > >> It's possible to have gpio chips hanging off unreliable remote buses >> where the get() operation will fail to acquire a readout of the current >> gpio state. Propagate these errors t

Re: [PATCH] gpio: Propagate errors from chip->get()

2015-08-31 Thread Bjorn Andersson
On Fri 28 Aug 09:44 PDT 2015, Bjorn Andersson wrote: > It's possible to have gpio chips hanging off unreliable remote buses > where the get() operation will fail to acquire a readout of the current > gpio state. Propagate these errors to the consumer so that they can > act on, retry or ignore thes

[PATCH] gpio: Propagate errors from chip->get()

2015-08-28 Thread Bjorn Andersson
It's possible to have gpio chips hanging off unreliable remote buses where the get() operation will fail to acquire a readout of the current gpio state. Propagate these errors to the consumer so that they can act on, retry or ignore these failing reads, instead of treating them as the line being he