Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932798AbbDJJmv (ORCPT ); Fri, 10 Apr 2015 05:42:51 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:62721 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932443AbbDJJmb (ORCPT ); Fri, 10 Apr 2015 05:42:31 -0400 X-AuditID: cbfec7f5-b7f1e6d00000617c-c6-55279a57e75f Message-id: <55279B03.7060202@samsung.com> Date: Fri, 10 Apr 2015 11:42:27 +0200 From: Robert Baldyga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-version: 1.0 To: Chanwoo Choi Cc: myungjoo.ham@samsung.com, rogerq@ti.com, linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, m.szyprowski@samsung.com Subject: Re: [PATCH v3 2/4] extcon: usb-gpio: add support for VBUS detection References: <1427980385-21285-1-git-send-email-r.baldyga@samsung.com> <1427980385-21285-3-git-send-email-r.baldyga@samsung.com> <5525E012.5050207@samsung.com> <552630E4.9030309@samsung.com> <55264148.8070903@samsung.com> <55264534.4020006@samsung.com> <55277910.2070000@samsung.com> <55277FA2.6090700@samsung.com> <55278580.2090809@samsung.com> <55278DD3.3020409@samsung.com> <55279550.1060609@samsung.com> In-reply-to: <55279550.1060609@samsung.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsVy+t/xa7rhs9RDDV7ekLO4/uU5q8X8I+dY LS7vmsNmsWhZK7PF2iN32S1uN65gs+h5pOXA7tG3ZRWjx/Eb25k8Pm+SC2CO4rJJSc3JLEst 0rdL4Mo4+fIrW8E76YrPvZOZGhiPinUxcnBICJhIzHut3cXICWSKSVy4t56ti5GLQ0hgKaPE v0k7WCCcj4wSLROOsII08ApoSTT/FwBpYBFQlZj/pJUFxGYT0JHY8n0CI0iJqECExO3LnCBh XgFBiR+T74GViAhoSMz8e4URZCSzwDxGicVz37OD1AsL+EgsvMEKUiMksIhZ4uQRLxCbU0Bb YsraM2BbmQX0JO5f1AIJMwvIS2xe85Z5AqPALCQbZiFUzUJStYCReRWjaGppckFxUnqukV5x Ym5xaV66XnJ+7iZGSBh/3cG49JjVIUYBDkYlHt4fLGqhQqyJZcWVuYcYJTiYlUR4/7aohwrx piRWVqUW5ccXleakFh9iZOLglGpgbKj1Ou9Wz6G46ETl0Xmbys/blF7yXXQod0XJ+WY1zrcG 9z/PPFd9/3XfjfvrhLSmv7Zz+1ot2zRrhe/tFOf6awoK6WGXQ/YedruVO2XNqjVFW2xPel+W f5G3am/Xji+nFBcI3p9ferDok1BuovkNvkM8fgr/vxy9yOCeVZOzQC9Xmfe6weanrkosxRmJ hlrMRcWJADuV6ZRBAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3730 Lines: 86 On 04/10/2015 11:18 AM, Chanwoo Choi wrote: > On 04/10/2015 05:46 PM, Robert Baldyga wrote: >> On 04/10/2015 10:10 AM, Chanwoo Choi wrote: >>> On 04/10/2015 04:45 PM, Robert Baldyga wrote: >>>> On 04/10/2015 09:17 AM, Chanwoo Choi wrote: >>>>> Hi Robert, >>>>> >>>>> On 04/09/2015 06:24 PM, Robert Baldyga wrote: >>>>>> Hi Chanwoo, >>>>>> >>>>>> On 04/09/2015 11:07 AM, Chanwoo Choi wrote: >>>>>>> Hi Robert, >>>>>>> >>>>>>> On 04/09/2015 04:57 PM, Robert Baldyga wrote: >>>>>>>> Hi Chanwoo, >>>>>>>> >>>>>>>> On 04/09/2015 04:12 AM, Chanwoo Choi wrote: >>>>>>>>> Hi Robert, >>>>>>>>> >>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>>>> But, I have one question about case[3] >>>>>>>>> >>>>>>>>> If id is low and vbus is high, this patch will update the state of both USB and USB-HOST cable as attached state. >>>>>>>>> Is it possible that two different cables (both USB and USB-HOST) are connected to one port simultaneously? >>>>>>>>> >>>>>>>> >>>>>>>> It's because state of single USB cable connection cannot be completely >>>>>>>> described using single extcon cable. USB cable state has two bits (VBUS >>>>>>>> and ID), so we need to use two cables for single cable connection. We >>>>>>>> use following convention: >>>>>>>> cable "USB" = VBUS >>>>>>>> cable "USB-HOST" = !ID. >>>>>>> >>>>>>> I think that extcon provider driver have to update the only one cable state >>>>>>> of either USB or USB-HOST because USB and USB-HOST feature can not be used >>>>>>> at the same time through one h/w port. >>>>>>> >>>>>>> If extcon-usb-gpio.c update two connected event of both USB and USB-HOST cable >>>>>>> at the same time, the extcon consumer driver can not decide what handle either USB or USB-HOST. >>>>>>> >>>>>> >>>>>> It can. USB OTG allows for that. Moreover device can be host even if >>>>>> ID=1 (so detected cable type is USB device), or peripheral when ID=0 (so >>>>>> detected cable type is USB host). Devices would need to have complete >>>>>> information about USB cable connection, because OTG state machine needs >>>>> >>>>> As I knew, USB OTG port don't send the attached cable of both USB and USB-HOST >>>>> at the same time. The case3 in your patch update two cable state about one h/w port. >>>>> >>>> >>>> It's because simple "USB" or "USB-HOST" means nothing for USB OTG >>>> machine. It needs to know exact VBUS and ID states, which cannot be >>>> concluded basing on cable type only. That's why I have used "USB-HOST" >>>> name together with "USB" to pass additional information about USB cable >>>> connection. >>> >>> I think this method is not proper to support this case. >>> It may cause the confusion about other case using USB/USB-HOST cable state >>> except of you commented case. >> >> That's why I finally proposed to use "USB-ID" and "USB-VBUS" in parallel >> with old names. It seems to be simpler solution than adding new >> mechanism notifying about VBUS and ID states changes. > > > As I commented on previous reply, I don't agree to use 'USB-ID' and 'USB-VBUS'. > If we add new strange 'USB-ID' and 'USB-VBUS' name, we would add non-general cable > name continuoulsy. > > I think that extcon core provide the helper API to get the value of VBUS. > But I need to consider it. We need more than API for getting VBUS value - we need to be notified about its changes, because if we don't distinguish between USB-HOST with VBUS on, and USB-HOST with VBUS off, then we will not receive notification from extcon at VBUS state change. Thanks, Robert Baldyga -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/