From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753161AbbJMOJr (ORCPT ); Tue, 13 Oct 2015 10:09:47 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:36862 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752295AbbJMOJp (ORCPT ); Tue, 13 Oct 2015 10:09:45 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfee691-f79d66d000001509-23-561d10a75b49 Content-transfer-encoding: 8BIT Message-id: <561D10A6.7040504@samsung.com> Date: Tue, 13 Oct 2015 23:09:42 +0900 From: Chanwoo Choi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Lee Jones , Charles Keepax Cc: Mark Brown , 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 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> <20151013080218.GV17172@x1> <20151013121450.GD8805@ck-lbox> <20151013135053.GB32409@x1> <561D0E4C.4010205@samsung.com> In-reply-to: <561D0E4C.4010205@samsung.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsWyRsSkWHe5gGyYwcdPHBZTHz5hs/g35Qa7 xfwj51gt+t8sZLU492olo8X9r0cZLS7vmsNmsfT6RSaL240r2CyWv/3PZjFh+loWi9a9R9gd eDzWzFvD6HG5r5fJY+XyL2wem1Z1snncubaHzePlxN9sHn1bVjF6fN4kF8ARxWWTkpqTWZZa pG+XwJXRMbeVseCETMWL3inMDYy/xboYOTkkBEwkLj6czwphi0lcuLeerYuRi0NIYAWjxPYv 95hhilb+X8gKkVjKKLFq4Vx2kASvgKDEj8n3WLoYOTiYBeQljlzKhjDVJaZMyYUof8Ao8eNj EytEuZbE/xebWUBsFgFViZ8PJ4LZbEDx/S9usIH0igpESHSfqAQJiwjESMw/vghsLbPAVCaJ Pf2rGUESwgKxEhObNzBD3cMs0X31EDtIM6eAtsSb3WYgcQmBXg6J/undTBDLBCS+TT4EdqeE gKzEpgNQf0lKHFxxg2UCo9gsJN/MQvhmFsI3CxiZVzGKphYkFxQnpReZ6hUn5haX5qXrJefn bmIERvDpf88m7mC8f8D6EKMAB6MSD++LSJkwIdbEsuLK3EOMpkA3TGSWEk3OB6aJvJJ4Q2Mz IwtTE1NjI3NLMyVxXh3pn8FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGOcKelzPmVpssJHn mJ3bq/6n1wLe3dplwqwpmblKe8msA6HnzV63LnmunnPozielbGcPI9PUnsLUz5oldb7xv15b Mpw9Elx5s4iBJ+Axv2jyxBWfHNS/rMvKnnZoYlbw+4mLlgqz9OX3bjJexrz5Gov5t4zlzA7n 8zvqHoj/fPKGq0An78VjTSWW4oxEQy3mouJEAHymidrbAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsVy+t9jAd3lArJhBt9/sVtMffiEzeLflBvs FvOPnGO16H+zkNXi3KuVjBb3vx5ltLi8aw6bxdLrF5ksbjeuYLNY/vY/m8WE6WtZLFr3HmF3 4PFYM28No8flvl4mj5XLv7B5bFrVyeZx59oeNo+XE3+zefRtWcXo8XmTXABHVAOjTUZqYkpq kUJqXnJ+SmZeuq2Sd3C8c7ypmYGhrqGlhbmSQl5ibqqtkotPgK5bZg7QvUoKZYk5pUChgMTi YiV9O0wTQkPcdC1gGiN0fUOC4HqMDNBAwhrGjI65rYwFJ2QqXvROYW5g/C3WxcjJISFgIrHy /0JWCFtM4sK99WxdjFwcQgJLGSVWLZzLDpLgFRCU+DH5HksXIwcHs4C8xJFL2RCmusSUKbkQ 5Q8YJX58bGKFKNeS+P9iMwuIzSKgKvHz4UQwmw0ovv/FDTaQXlGBCInuE5UgYRGBGIn5xxex gsxhFpjKJLGnfzUjSEJYIFZiYvMGZqh7mCW6rx5iB2nmFNCWeLPbbAKjwCwk181CuG4WwnUL GJlXMUqkFiQXFCel5xrmpZbrFSfmFpfmpesl5+duYgQniWdSOxgP7nI/xCjAwajEw/siUiZM iDWxrLgy9xCjBAezkghvUgtQiDclsbIqtSg/vqg0J7X4EKMp0HsTmaVEk/OBCSyvJN7Q2MTM yNLI3NDCyNhcSZz3xiGGMCGB9MSS1OzU1ILUIpg+Jg5OqQbGxnPV86teT7B765lUvGzemfjV c4/EtUu9eGnxO+dLx5qLGw9fYFC8+IVf+8/i2dden7prOkG6qybi2NJvGS9VF+/84xxgkGXl NbuV5/D7uD1dnuIb50m80Cq337d0x8Qj7bMyD9r0l5R3Xg/fWl7H+VFkUuvXS+FLPSWbRbdV iFZZ3udd/dOuTImlOCPRUIu5qDgRAKCQjVcoAwAA DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2015년 10월 13일 22:59, Chanwoo Choi wrote: > Hi Lee, > > 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. [snip] Thanks, Chanwoo Choi