linux-kernel - Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151013141822.GC32409@x1>
Date:	Tue, 13 Oct 2015 15:18:22 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Chanwoo Choi <cw00.choi@...sung.com>
Cc:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>,
	Mark Brown <broonie@...nel.org>, robh+dt@...nel.org,
	pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	myungjoo.ham@...sung.com, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, patches@...nsource.wolfsonmicro.com
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/