Re: [PATCH v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex
From: Rob Herring
Date: Wed Apr 15 2015 - 15:41:01 EST
On Mon, Apr 13, 2015 at 5:23 AM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote:
> On Mon, Apr 6, 2015 at 10:04 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote:
>> Mark, are you OK with the latest iteration from Suman? it would be
>> nice to get your +1 just to make sure we don't merge stuff you're
>> uncomfortable with.
>
> Quick update:
>
> As Tim pointed out, we can move forward with the driver binding patch
> according to the process described under II.2 of [1]. Both Bjorn and
> myself would still prefer to make sure Mark is satisfied with the
> response Bjorn sent to Mark's question, but we understand if Mark is
> swamped and we eventually would proceed according to the DT's
> submitting-patches guidance below. Tim, thanks for pointing that out
> as I wasn't aware of this.
>
> What we probably do need a DT ack on is the hwspinlock subsystem
> binding submitted by Suman, again according to the process described
> under II.2 of [1]: "Subsystem bindings (anything affecting more than a
> single device): then getting a devicetree maintainer to review it is
> required".
Right, you can't really merge this driver binding until the binding is
done and acked. Your binding would be referring to a binding doc that
doesn't exist in the tree if you merge this.
> Mark and Rob: thanks so much for all your help so far as you have
> substantially helped shaping the hwspinlock binding. Please let us
> know if you are satisfied with Suman's latest iteration, still prefer
> to take another look at it, or are too swamped. If the latter, then
> maybe we can ask Kumar to take a look, as this seems to be blocking
> Qualcomm's upstream roadmap.
While I think the binding looks fine, I'm not going to go around Mark
either. He's invested the most thought in this (of DT maintainers) and
should be the one to ack it. The part I'm not clear what the purpose
of "pool-hwlock" was.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/