Hi Bjorn, On 09/30/2014 03:54 PM, Bjorn Andersson wrote: > On Fri, Sep 12, 2014 at 1:24 PM, Suman Anna <s-anna@xxxxxx> wrote: >> Hi Ohad, >> >> This is an update to the hwspinlock dt support series. The series >> is rebased onto v3.17-rc3, and addresses the review comments on the >> previous v5 series. I have also split and left out the RFC patches >> about the support for reserved locks (will post these as a separate >> series) and return code convention changes in the hwspinlock core >> (will not be needed anymore). The support for deferred probing of >> clients is supported in the new of_hwspin_lock_get_id() function >> itself. >> > > Thanks for your reply to me, I had missed that you continued this work. > > > I find it somewhat awkward to have to call both of_hwspin_lock_get_id() and > then hwspin_lock_request_specific(), but I found the request from Ohad, so > let's stick with it. > > Am I right that hwlock-num-locks and hwlock-base-id are optional from the > frameworks perspective and only there to aid the hwspin drivers? If so it is > strange to have in the common binding and have the helper functions in the core > for simply reading hwspin device specific properties. The hwlock-num-locks and hwlock-base-id would be common features to all the hwspinlock drivers, so they are added as common bindings which the individual implementations should use instead of defining their own properties. These are added based on discussion way back on v1. You ought to replace the "qcom,num-locks" with the first one. I will respond to your v4 with a few comments so that we don't loose the context in that thread. > > Otherwise I think it looks sane, although I haven't spend that much time > reviewing it. > > I did throw it into my tree and gave it a testrun with the Qualcomm code I've > been working on. So for the non-omap parts: > > Tested-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxx> > Thanks for testing this with the new Qualcomm driver. regards Suman -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
