lkml.org 
[lkml]   [2015]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection
On Tue, 13 Oct 2015, Chanwoo Choi wrote:
> On 2015년 10월 13일 22:59, Chanwoo Choi wrote:
> > On 2015년 10월 13일 22:50, Lee Jones wrote:
> >> On Tue, 13 Oct 2015, Charles Keepax wrote:
> >>
> >>> On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> >>>> On Mon, 12 Oct 2015, Mark Brown wrote:
> >>>>
> >>>>> On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> >>>>>> On Wed, Oct 07, 2015 at 01:26:42PM +0100, Lee Jones wrote:
> >>>>>>> On Wed, 07 Oct 2015, Mark Brown wrote:
> >>>>>
> >>>>>>>> This all seems pretty much fine to me - the things it is controlling are
> >>>>>>>> fairly specific to the way the former Wolfson devices do, they only
> >>>>>>>> really make sense with a fairly particular algorithm which isn't widely
> >>>>>>>> implemented.
> >>>>>
> >>>>>>> Is that an Ack?
> >>>>>
> >>>>>> I am guessing Mark is slightly hesitant to ack as he probably
> >>>>>> doesn't want to add reviewing all our jack detection bindings to
> >>>>>> his already fairly sizable work load and doing so here likely
> >>>>>> means it will be expected in the future. From talking to people at
> >>>>
> >>>> Providing Acks should not (and has not to my knowledge) be a binding
> >>>> contract to continue providing Acks. However, should more bindings be
> >>>> submitted which appear as though they are related to a particular
> >>>> maintainer, then sure, you'll be asked for your expert eye again.
> >>>
> >>> Its not a binding contract to continue providing them but we are
> >>> making that a condition of merging any patches, which means I
> >>> will need to chase Mark for Acks, as it seems the DT maintainers
> >>> won't have any interest in reviewing/acking these.
> >>
> >> I've already made it a condition, as I refuse to blindly accept
> >> unknown bindings. Taking a sea of bindings I have no knowledge of
> >> would be a bad-thing(tm). If these were GPIO bindings, I'd be asking
> >> Linus for help, likewise if they were I2C, I'd be asking Wolfram.
> >>
> >>>>> Pretty much (plus generally being busy at ELC-E last week) - if there's
> >>>>> specific questions that's one thing but if it's just general requests to
> >>>>> look at bindings then it seems like the relevant subsystem maintainers
> >>>>
> >>>> This is exactly my point. I am not the 'relevant subsystem
> >>>> maintainer' for these properties and subsequently know nothing of
> >>>> microphone detection, headsets, bias', etc. These look like Audio
> >>>> related properties to me (the uninitiated), which is why you were
> >>>> asked.
> >>>
> >>> It would be sensible I guess to define whether I should be
> >>> including audio people on jack detection patches even if they
> >>> don't touch audio subsystems. I was treating jack detection
> >>> as an extcon thing and thus assuming that the extcon maintainer
> >>> would be sufficient, but perhaps that is an incorrect assumption.
> >>
> >> Now I know that jack detection is an Extcon thing and Extcon Ack will
> >> do just nicely. However, that begs the question; if they are an
> >> Extcon thing, why aren't they in the Extcon binding document?
> >
> > As I knew, the arizona-extcon is one device of the MFD devices
> > for WMxxxx series in the driver/mfd/arizona-core.c. So, If arizona-extcon
> > driver needs the some property for dt support, some property should be
> > included in MFD device tree node. There is no separate device tree node for
> > arizona-extcon driver.
>
> If creating the separate extcon doc for extcon-arizona.c driver, it is possible
> to make the child device tree node which is located at the below of arizona MFD
> device tree node.
>
> I agree about Lee's opinion to make the separate the Extcon doc for extcon-arizona.c.

This is how we normally document MFDs. Extcon doesn't even need to
have it's own child-node (it can if you want though -- it's however
you want to represent it), you can just put something like this in the
MFD binding doc:

Optional properties
this : Does this
that : Does that

Also any child device specific property:
GPIO See: ../extcon/arizona.txt
Extcon See: ../gpio/arizona.txt

Etc. Or words to that effect. See some other MFDs for examples.

--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


\
 
 \ /
  Last update: 2015-10-13 16:41    [W:0.099 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site