From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932407AbbJMN7s (ORCPT ); Tue, 13 Oct 2015 09:59:48 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:40428 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752501AbbJMN7n (ORCPT ); Tue, 13 Oct 2015 09:59:43 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfee68f-f796f6d0000014a4-c1-561d0e4cf61e Content-transfer-encoding: 8BIT Message-id: <561D0E4C.4010205@samsung.com> Date: Tue, 13 Oct 2015 22:59:40 +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> In-reply-to: <20151013135053.GB32409@x1> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsWyRsSkSNeHTzbM4OwmA4upD5+wWfybcoPd Yv6Rc6wW/W8Wslqce7WS0eL+16OMFpd3zWGzWHr9IpPF7cYVbBbL3/5ns5gwfS2LReveI+wO PB5r5q1h9Ljc18vksXL5FzaPTas62TzuXNvD5vFy4m82j74tqxg9Pm+SC+CI4rJJSc3JLEst 0rdL4Mro67nLXrBCuWL5lWWsDYxdMl2MnBwSAiYSTfdnskLYYhIX7q1n62Lk4hASWMEocf7I IlaYosadT9hAbCGBWYwSv96VgNi8AoISPybfY+li5OBgFpCXOHIpG8JUl5gyJRdizANGiQvH NrNBlGtJNEy6zQhSwyKgKtH/LRMkzAYU3v/iBhtIWFQgQqL7RCVIWEQgRmL+cZADuIAmTmWS 2NO/mhEkISwQKzGxeQMzxPw2ZokzO36ygCQ4BTQk/j3fyQSSkBDo5ZBYu/YxWIJFQEDi2+RD YHdKCMhKbDrADPGWpMTBFTdYJjCKzULyzSyEb2YhfLOAkXkVo2hqQXJBcVJ6kbFecWJucWle ul5yfu4mRmD8nv73rH8H490D1ocYBTgYlXh4X0TKhAmxJpYVV+YeYjQFumEis5Rocj4wSeSV xBsamxlZmJqYGhuZW5opifMulPoZLCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGxXGCv9/pd fpeUPGJeqt7u+fa6LdWdxdtbJPyuk4N53Lz5ldf0G0qtPdZaCD08o/z2lvuH6UFrGBa4JWY0 f31WGsd2Ws/VY1K0Wvr185IPBV/F8hVk5+vNCN0qIVYdEi9btHvD/bTn9ad3nToRejl2og+X T4bPqpMhHxZkzJ71o+nxa64N7+8psRRnJBpqMRcVJwIAEcwlv9oCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsVy+t9jQV0fPtkwg0/bNC2mPnzCZvFvyg12 i/lHzrFa9L9ZyGpx7tVKRov7X48yWlzeNYfNYun1i0wWtxtXsFksf/ufzWLC9LUsFq17j7A7 8HismbeG0eNyXy+Tx8rlX9g8Nq3qZPO4c20Pm8fLib/ZPPq2rGL0+LxJLoAjqoHRJiM1MSW1 SCE1Lzk/JTMv3VbJOzjeOd7UzMBQ19DSwlxJIS8xN9VWycUnQNctMwfoXiWFssScUqBQQGJx sZK+HaYJoSFuuhYwjRG6viFBcD1GBmggYQ1jRl/PXfaCFcoVy68sY21g7JLpYuTkkBAwkWjc +YQNwhaTuHBvPZgtJDCLUeLXuxIQm1dAUOLH5HssXYwcHMwC8hJHLmVDmOoSU6bkdjFyAVU/ YJS4cGwzG0S5lkTDpNuMIDUsAqoS/d8yQcJsQOH9L26wgYRFBSIkuk9UgoRFBGIk5h9fxAoy hllgKpPEnv7VjCAJYYFYiYnNG5gh5rcxS5zZ8ZMFJMEpoCHx7/lOpgmMQDciXDcL4bpZCNct YGRexSiRWpBcUJyUnmuUl1quV5yYW1yal66XnJ+7iRGcIp5J72A8vMv9EKMAB6MSD++LSJkw IdbEsuLK3EOMEhzMSiK8SS1AId6UxMqq1KL8+KLSnNTiQ4ymQO9NZJYSTc4Hpq+8knhDYxMz I0sjc0MLI2NzJXHeG4cYwoQE0hNLUrNTUwtSi2D6mDg4pRoYMwROJD1j+JAVVfGiKUiU9VbC 741MJ26dDGJ3jLa6sWxdp+9HofPr2M9nHHIvD1aetjJprtobi2ZH34O9Gw8yHP9RUPRM9b6G /jmdO2Iyykzhsi7GFy+s5P/2OnmPt9qUSIH1xqEdM8vWnm7nbyqK7srl5rw9W7pn54akGOsv wMiW/i8Wc0iJpTgj0VCLuag4EQCwL68EJwMAAA== 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 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. Thanks, Chanwoo Choi > >>>> 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. >> >> I also wish our designers would make less complex hardware sigh. >> >> Apologies I didn't mean to cause any offense here, I am just >> getting a bit concerned about how I can get any DT support for >> jack detection upstreamed. I am more than happy to fix up any >> comments anyone has or answer any questions about what things >> are or why they are required. > > Hopefully there won't be too many more bindings to come? > > My issue is that as they are not MFD related, I need some advice from > my colleagues to whom they are related to. > >> The jack detection on these chips is fairly complex and there are >> going to be plenty more patches before we have full support for >> it in DT. So I think it would be good for everyone if we can >> agree some process for how to handle this type of patch. > > Put them in the subsystem where they pertain to -- job done. >