From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755876AbbE2Kxp (ORCPT ); Fri, 29 May 2015 06:53:45 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:45152 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755547AbbE2Kxg (ORCPT ); Fri, 29 May 2015 06:53:36 -0400 X-AuditID: cbfee68f-f793b6d000005f66-ab-5568452ed8a6 Message-id: <5568452E.8050903@samsung.com> Date: Fri, 29 May 2015 19:53:34 +0900 From: Chanwoo Choi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-version: 1.0 To: Peter Chen Cc: Roger Quadros , "Ivan T. Ivanov" , Chanwoo Choi , balbi@ti.com, jun.li@freescale.com, linux-kernel@vger.kernel.org, r.baldyga@samsung.com, kishon@ti.com, myungjoo.ham@samsung.com Subject: Re: [PATCH v2 0/2] extcon: Inform the state of both ID and VBUS pin for USB References: <1432728910-10761-1-git-send-email-cw00.choi@samsung.com> <1432802731.2348.25.camel@mm-sol.com> <556724FD.2010606@ti.com> <20150529012226.GB14122@shlinux2> In-reply-to: <20150529012226.GB14122@shlinux2> Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsWyRsSkRFfPNSPU4M89GYuD9+stnh3Vtng2 8SGjxdXZ29gsLjztYbO4vGsOm8XtxhVsFsdm/2WyeHB4J7tFzyMtBy6Pf4f7mTx2zrrL7rFp /zRmj74tqxg9jt/YzuTxeZNcAFsUl01Kak5mWWqRvl0CV8bVz/0sBdvlKn5MeMnSwPhKvIuR k0NCwESiYXcXG4QtJnHh3nowW0hgKaPE/U12MDVX/p5hhYgvYpSY0FDbxcgFZD9glJjxag5Y A6+AlsShA3+ZQGwWAVWJZesnMIPYbEDx/S9ugNWICoRJrJx+hQWiXlDix+R7YLaIgKbEuvPH mECGMgt8ZpQ48OM6O0hCGKhhYs8GNohtqxklDq65AJbgFNCTmP35KCOIzSygI7G/dRobhC0v sXnNW2aQBgmBl+wSjyccZIY4SUDi2+RDQOs4gBKyEpsOMEO8JilxcMUNlgmMYrOQHDULydhZ SMYuYGRexSiaWpBcUJyUXmSsV5yYW1yal66XnJ+7iREYm6f/PevfwXj3gPUhRgEORiUe3o4b 6aFCrIllxZW5hxhNga6YyCwlmpwPTAB5JfGGxmZGFqYmpsZG5pZmSuK8C6V+BgsJpCeWpGan phakFsUXleakFh9iZOLglGpg3JnhJxN544VZ1NraL1KJnN/D3XUetX2Yd1Xv0OzWLWkiFyz1 j224+kvW9Na8RN0lzwIuKG0xq/MX0d0k1XKF9ee/0xZMK/x8pnF0XvaeHdDf9HfNo9S1y458 0zI68kncwax20QkJhUbPdNH5qw+9W7MifavYyi3Pj3grRNpEnotcW9ksJyV6S4mlOCPRUIu5 qDgRAHTg7OzIAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42I5/e+xgK6ea0aowYp/whYH79dbPDuqbfFs 4kNGi6uzt7FZXHjaw2ZxedccNovbjSvYLI7N/stk8eDwTnaLnkdaDlwe/w73M3nsnHWX3WPT /mnMHn1bVjF6HL+xncnj8ya5ALaoBkabjNTElNQihdS85PyUzLx0WyXv4HjneFMzA0NdQ0sL cyWFvMTcVFslF58AXbfMHKDDlBTKEnNKgUIBicXFSvp2mCaEhrjpWsA0Ruj6hgTB9RgZoIGE NYwZVz/3sxRsl6v4MeElSwPjK/EuRk4OCQETiSt/z7BC2GISF+6tZwOxhQQWMUpMaKjtYuQC sh8wSsx4NQcswSugJXHowF8mEJtFQFVi2foJzCA2G1B8/4sbYDWiAmESK6dfYYGoF5T4Mfke mC0ioCmx7vwxJpChzAKfGSUO/LjODpIQBmqY2LOBDWLbakaJg2sugCU4BfQkZn8+yghiMwvo SOxvncYGYctLbF7zlnkCo8AsJEtmISmbhaRsASPzKkbR1ILkguKk9FxDveLE3OLSvHS95Pzc TYzg2H8mtYNxZYPFIUYBDkYlHt6OG+mhQqyJZcWVuYcYJTiYlUR4d+lkhArxpiRWVqUW5ccX leakFh9iNAWGwURmKdHkfGBayiuJNzQ2MTOyNDI3tDAyNlcS5z2Z7xMqJJCeWJKanZpakFoE 08fEwSnVwDi/+9O/ZjH2SelvVl+ZNuUdk898Lmvp/umvlh5YcGf/XPlwBt/NR7seKR/6tmeW cfm7dtU7G1+v5bE882w+n5PhYpnYC4UxK7dna+xenKCy7KMIv0NO0tbXPlvs36/b7GBoJLK3 UOTFMe0Nu9+t6n5cbH7rulJ51IpdvUbrcxYLFcybEKp3esI2JZbijERDLeai4kQABGH5JxMD AAA= 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 Peter, On 05/29/2015 10:22 AM, Peter Chen wrote: > On Thu, May 28, 2015 at 05:23:57PM +0300, Roger Quadros wrote: >> +Peter & Li, >> >> Ivan, >> >> On 28/05/15 11:45, Ivan T. Ivanov wrote: >>> >>> Hi Chanwoo, >>> >>> On Wed, 2015-05-27 at 21:15 +0900, Chanwoo Choi wrote: >>>> Previously, I discussed how to inform the changed state of both ID >>>> and VBUS pin for USB connector on patch-set[1]. >>>> [1] https://lkml.org/lkml/2015/4/2/310 >>>> >>>> So, this patch adds the extcon_set_cable_line_state() function to inform >>>> the additional state of external connectors without additional register/ >>>> unregister functions. This function uses the existing notifier chain >>>> which is registered by extcon_register_notifier() / extcon_register_interest(). >>>> >>>> The extcon_set_cable_line_state() can inform the new state of both >>>> ID and VBUS pin state through extcon_set_cable_line_state(). >>>> >>>> For exmaple: >>>> - On extcon-usb-gpio.c as extcon provider driver as following: >>>> static void usb_extcon_detect_cable(struct work_struct *work) >>>> { >>>> ... >>>> /* check ID and update cable state */ >>>> id = gpiod_get_value_cansleep(info->id_gpiod); >>>> if (id) { >>>> extcon_set_cable_state_(info->edev, EXTCON_USB_HOST, false); >>>> extcon_set_cable_state_(info->edev, EXTCON_USB, true); >>>> >>>> extcon_set_cable_line_state(info->edev, EXTCON_USB, >>>> EXTCON_USB_ID_HIGH); >>> >>> I am getting more and more confused :-). Why EXTCON_USB is now used for ID notifications? >>> It should be EXTCON_USB_HOST, no? Why we need another function, framework already have >>> required information from the function one line above, do I miss something? >> >> This is because the existing EXTCON_USB_HOST and EXTCON_USB do not capture all >> the 4 states of ID and VBUS pins that we need for a real USB driver to work. >> >> It looks like it was designed from user space users perspective where they are >> only interested in USB role. i.e. host or peripheral. >> >> Right now we are mixing both ID/VBUS and HOST/Peripheral states. >> This will break when we consider OTG role switching. >> With role switching, the USB device might start as a peripheral but switch role to host >> on the fly and the existing setup (including these patches) can't cater to that >> if user space is relying on EXTCON_USB_HOST/EXTCON_USB events. >> Because they are hard-wired to the ID pin state which doesn't change during >> role switch without cable switch. >> >> The USB driver doesn't care about EXTCON_USB_HOST/peripheral states. >> It just needs ID/VBUS states and should decide the Host/Peripheral state from >> that and other inputs (like HNP/user request/etc). >> >> The flow could be like this >> >> (extcon-usb-driver) -> [ID/VBUS states] -> (USB driver) -> [HOST/Peripheral states] > > Agree. Chanwoo, USB driver knows better than extcon driver about USB > role (host/peripheral), so the app should use USB interface to know it, > in fact, I don't be aware any use case needs to know USB role? > Are there any users for EXTCON_USB and EXTCON_USB_HOST currently? You're right. But, extcon can just distinguish the type of external connectors and inform the type to the user-space and extcon consumer driver in kernel-space. When USB mouse or keyboard is attached, user-space can check the state of externel connector which is attaced to the H/W target as following: - /sys/class/extcon/extconX/cable.0/name -> USB - /sys/class/extcon/extconX/cable.0/state -> 0 - /sys/class/extcon/extconX/cable.1/name -> USB-HOST - /sys/class/extcon/extconX/cable.1/state -> 1 Thanks, Chanwoo Choi