From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932116AbbJMIC1 (ORCPT ); Tue, 13 Oct 2015 04:02:27 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:38170 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752157AbbJMICW (ORCPT ); Tue, 13 Oct 2015 04:02:22 -0400 Date: Tue, 13 Oct 2015 09:02:18 +0100 From: Lee Jones To: Mark Brown Cc: Charles Keepax , cw00.choi@samsung.com, robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, myungjoo.ham@samsung.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, patches@opensource.wolfsonmicro.com Subject: Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection Message-ID: <20151013080218.GV17172@x1> References: <1443803363-3251-1-git-send-email-ckeepax@opensource.wolfsonmicro.com> <1443803363-3251-5-git-send-email-ckeepax@opensource.wolfsonmicro.com> <20151007100017.GB12635@sirena.org.uk> <20151007122642.GH17172@x1> <20151012084554.GB8805@ck-lbox> <20151012134309.GE1542@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20151012134309.GE1542@sirena.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. > 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. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog