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]

Date:	Wed, 14 Oct 2015 08:28:12 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>,
	cw00.choi@...sung.com, 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, Mark Brown 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:
> 
> > > > 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.
> 
> It's a bit concerning when it seems like my review is becoming a blocker
> for something and I don't understand why.

Not necessarily _your_ review.  Just someone, other than the
submitter, who I trust and knows about this stuff.  You just happen 
to tick those boxes this time.  Cross pollination and knowledge sharing
is one of the characteristics of MLs which I'm particularly proud of.

> > > 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.
> 
> They're extcon things (and there are accompanying driver changes to the
> extcon driver parsing them).

Yes, I'm aware of that now.  Hence the "(uninitiated)" part.

> > > should have the confidence to review straightfoward device properties
> > > like this.
> 
> > I don't think these bindings are particularly straightforward.  The
> > contain many terms which I'm unfamiliar with, and again, to me (the
> > uninitiated) this looks like way too many bindings just to see if an
> > audio jack is plugged in or not.
> 
> When your power budget is in the low double digit microamps and you're
> trying to respond promptly and reliably to rapidly changing and variable
> physical inputs it gets complicated.

This is exactly why I asked you.

Thanks for adding structure to my PoV. ;) 

-- 
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/