Re: [PATCH v2 5/5] mfd: arizona: Update DT binding document for jack detection invert

[Lee Jones]

On Mon, 12 Oct 2015, Charles Keepax wrote:

> On Mon, Oct 05, 2015 at 11:01:05AM +0100, Lee Jones wrote:
> > On Fri, 02 Oct 2015, Charles Keepax wrote:
> > 
> > > Add additional binding for inverting the polarity of the detection on
> > > the jack detection pins.
> > > 
> > > Signed-off-by: Charles Keepax <ckeepax@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> > > ---
> > >  Documentation/devicetree/bindings/mfd/arizona.txt |    2 ++
> > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
> > > index b98a11b..ef59696 100644
> > > --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> > > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> > > @@ -73,6 +73,8 @@ Optional properties:
> > >      If this node is not mentioned or if the value is unknown, then
> > >      headphone detection mode is set to HPDETL.
> > >  
> > > +  - wlf,jd-invert : Invert the polarity of the jack detection switch
> > > +
> > 
> > There are other jack detection properties in the bindings docs.
> > 
> > Please generify.
> 
> Apologies but not sure I follow what you want me to do here? Do
> you just want me to drop the wlf, prefix on this one?

I'm trying to avoid every vendor having their own audio jack
properties, when many of them have exactly the same function.

Please take a look at each of your bindings and make an informed
decision on which you think are unique to you and which you think
others can/will make use of.

Of course, if you have a unique requirement for a property and can
justify its existence, then it should be submitted with your vendor
prefix.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org â Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/