Hi Ohad,
On 10/06/2014 04:44 AM, Ohad Ben-Cohen wrote:
On Fri, Sep 26, 2014 at 7:25 PM, Suman Anna s-a...@ti.com wrote:
I am yet to receive any comments on v6, but that series should address
both your need for a probe deferral and Ohad's request to not change any
return types. Please give it
Hi Suman,
On Thu, Nov 6, 2014 at 8:24 PM, Suman Anna s-a...@ti.com wrote:
Ping on this. Can you review the latest series v6 [1] and pick it up for
3.19? The MSM spinlock driver is also blocked/dependent on that series.
Sure, it's on my mind, I hope I'll get to it next week.
Thanks,
Ohad.
--
On Fri, Sep 26, 2014 at 7:25 PM, Suman Anna s-a...@ti.com wrote:
I am yet to receive any comments on v6, but that series should address
both your need for a probe deferral and Ohad's request to not change any
return types. Please give it a try and let me know if you have any comments.
Guys,
On Mon, Jan 13, 2014 at 4:19 PM, Suman Anna s-a...@ti.com wrote:
This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.
Hi Ohad, Suman
I'm about to send out some patches that depends on this functionality,
how do
Hi Bjorn,
On 09/26/2014 09:40 AM, Bjorn Andersson wrote:
On Mon, Jan 13, 2014 at 4:19 PM, Suman Anna s-a...@ti.com wrote:
This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.
Hi Ohad, Suman
I'm about to
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
Hi Suman,
On Tue, Mar 4, 2014 at 7:38 PM, Suman Anna s-a...@ti.com wrote:
Do you have any objections to the return code convention change?
Unless strictly needed, I prefer we don't switch to the ERR_PTR code
convention, as it reduces code readability and increases chances of
user bugs.
In
On Sun, Mar 2, 2014 at 10:19 PM, Bjorn Andersson bj...@kryo.se wrote:
When introducing the ability to reference a hwspin lock via a phandle
in device tree it makes a big difference to be able to differ between
the case of initialization failed or device not yet probed; so
that the client knows
On Fri, Mar 14, 2014 at 03:12:26PM +0200, Ohad Ben-Cohen wrote:
On Sun, Mar 2, 2014 at 10:19 PM, Bjorn Andersson bj...@kryo.se wrote:
When introducing the ability to reference a hwspin lock via a phandle
in device tree it makes a big difference to be able to differ between
the case of
On Tue, Mar 04, 2014 at 11:38:23AM -0600, Suman Anna wrote:
Hi Ohad,
On 03/02/2014 02:19 PM, Bjorn Andersson wrote:
On Sat, Mar 1, 2014 at 9:14 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Mon, Feb 10, 2014 at 9:14 PM, Suman Anna s-a...@ti.com wrote:
On 02/07/2014 04:49 PM, Bjorn Andersson
Hi Ohad,
On 03/02/2014 02:19 PM, Bjorn Andersson wrote:
On Sat, Mar 1, 2014 at 9:14 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Mon, Feb 10, 2014 at 9:14 PM, Suman Anna s-a...@ti.com wrote:
On 02/07/2014 04:49 PM, Bjorn Andersson wrote:
It seems to be standard practice to pass the error
Ohad,
On 03/02/2014 02:19 PM, Bjorn Andersson wrote:
On Sat, Mar 1, 2014 at 9:14 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Mon, Feb 10, 2014 at 9:14 PM, Suman Anna s-a...@ti.com wrote:
On 02/07/2014 04:49 PM, Bjorn Andersson wrote:
It seems to be standard practice to pass the error value
On Sat, Mar 1, 2014 at 9:14 PM, Ohad Ben-Cohen o...@wizery.com wrote:
On Mon, Feb 10, 2014 at 9:14 PM, Suman Anna s-a...@ti.com wrote:
On 02/07/2014 04:49 PM, Bjorn Andersson wrote:
It seems to be standard practice to pass the error value back to the
consumer, so you should
return
On Mon, Feb 10, 2014 at 9:14 PM, Suman Anna s-a...@ti.com wrote:
On 02/07/2014 04:49 PM, Bjorn Andersson wrote:
It seems to be standard practice to pass the error value back to the
consumer, so you should
return ERR_PTR(ret); here instead of the NULL...
I have modelled the return values in
Bjorn,
On 02/07/2014 04:49 PM, Bjorn Andersson wrote:
On Mon, Jan 13, 2014 at 4:19 PM, Suman Anna s-a...@ti.com wrote:
This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.
Nice, I ran in to the problem of needing
On Mon, Jan 13, 2014 at 4:19 PM, Suman Anna s-a...@ti.com wrote:
This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.
Nice, I ran in to the problem of needing a probe deferral on a
hwspinlock earlier this week so I
This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.
1. The of_hwspin_lock_get_num_locks() is a common helper
function to read the common 'hwlock-num-locks' property.
2. The of_hwspin_lock_simple_xlate() is a
17 matches
Mail list logo
