mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chen Yu <chenyu56@huawei.com>
To: John Stultz <john.stultz@linaro.org>
Cc: <liuyu712@hisilicon.com>,
	Linux USB List <linux-usb@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, lkml <linux-kernel@vger.kernel.org>,
	"Zhuangluan Su" <suzhuangluan@hisilicon.com>,
	Kongfei <kongfei@hisilicon.com>, <wanghu17@hisilicon.com>,
	butao <butao@hisilicon.com>, <chenyao11@huawei.com>,
	<fangshengzhou@hisilicon.com>,
	Li Pengcheng <lipengcheng8@huawei.com>,
	<songxiaowei@hisilicon.com>, YiPing Xu <xuyiping@hisilicon.com>,
	<xuyoujun4@huawei.com>, Yudongbin <yudongbin@hisilicon.com>,
	Zang Leigang <zangleigang@hisilicon.com>,
	Jun Li <lijun.kernel@gmail.com>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Felipe Balbi <balbi@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Subject: Re: [PATCH v5 10/13] usb: dwc3: Registering a role switch in the DRD code.
Date: Fri, 12 Apr 2019 09:23:42 +0800	[thread overview]
Message-ID: <7d5ba117-735e-3fb0-97f7-33be328a4ae6@huawei.com> (raw)
In-Reply-To: <CALAqxLVdrzNS2t1OYT=Pziu81VO+zWq5LYghHhMJO53cSvNNtQ@mail.gmail.com>

Hi John,

On 2019/4/12 8:48, John Stultz wrote:
> On Thu, Mar 28, 2019 at 9:14 PM Yu Chen <chenyu56@huawei.com> wrote:
>>
>> The Type-C drivers use USB role switch API to inform the
>> system about the negotiated data role, so registering a role
>> switch in the DRD code in order to support platforms with
>> USB Type-C connectors.
>>
> 
> Hey Yu Chen!
>   Thanks so much for sending these patches out!  I have run into some
> troubles on bootup where things aren't working properly at first, that
> seem to be due to state initialization races.  In chasing those down,
> I've found some other quirks I wanted to bring up.
> 
>> --- a/drivers/usb/dwc3/drd.c
>> +++ b/drivers/usb/dwc3/drd.c
>> @@ -479,6 +479,43 @@ static struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
>>         return edev;
>>  }
>>
>> +static int dwc3_usb_role_switch_set(struct device *dev, enum usb_role role)
>> +{
>> +       struct dwc3 *dwc = dev_get_drvdata(dev);
>> +       u32 mode;
>> +
>> +       switch (role) {
>> +       case USB_ROLE_HOST:
>> +               mode = DWC3_GCTL_PRTCAP_HOST;
>> +               break;
>> +       case USB_ROLE_DEVICE:
>> +               mode = DWC3_GCTL_PRTCAP_DEVICE;
>> +               break;
>> +       default:
>> +               if (dwc->role_switch_default_mode == USB_DR_MODE_HOST)
>> +                       mode = DWC3_GCTL_PRTCAP_HOST;
>> +               else
>> +                       mode = DWC3_GCTL_PRTCAP_DEVICE;
>> +               break;
>> +       }
>> +
>> +       dwc3_set_mode(dwc, mode);
>> +       return 0;
>> +}
>> +
>> +static enum usb_role dwc3_usb_role_switch_get(struct device *dev)
>> +{
>> +       struct dwc3 *dwc = dev_get_drvdata(dev);
>> +       unsigned long flags;
>> +       enum usb_role role;
>> +
>> +       spin_lock_irqsave(&dwc->lock, flags);
>> +       role = dwc->current_otg_role;
>> +       spin_unlock_irqrestore(&dwc->lock, flags);
>> +
>> +       return role;
>> +}
>> +
> 
> So the two functions above are a bit asymmetric.  The
> dwc3_usb_role_switch_set() can put the device into host or device
> mode, which eventually sets the current_dr_role value.  However on the
> dwc3_usb_role_switch_get() we return the current_otg_role value.
> current_otg_role isn't set unless current_dr_role is
> DWC3_GCTL_PRTCAP_OTG, which doesn't seem to happen here.
> 
> I suspect in dwc3_usb_role_switch_get() we should return
> current_dr_role, unless current_dr_role==DWC3_GCTL_PRTCAP_OTG, in
> which case we'd want to return current_otg_role.
> 
> Does that make sense?
> 
Yes, you are right! The dwc3_usb_role_switch_get() should return current_dr_role
. Actually if we register the dwc3_role_switch, the current_dr_role would not be DWC3_GCTL_PRTCAP_OTG.
> Nothing really actually use this dwc3_usb_role_switch_get() yet, so
> this was easy to overlook, and I only caught it as I was trying to
> debug some of the initialization races.
> 
> thanks
> -john
> 
> .
> 


  reply	other threads:[~2019-04-12  1:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-29  4:13 [PATCH v5 00/13] Add support for usb on Hikey960 Yu Chen
2019-03-29  4:13 ` [PATCH v5 01/13] dt-bindings: phy: Add support for HiSilicon's hi3660 USB PHY Yu Chen
2019-03-29  4:13 ` [PATCH v5 02/13] dt-bindings: misc: Add bindings for HiSilicon usb hub and data role switch functionality on HiKey960 Yu Chen
2019-03-29  4:13 ` [PATCH v5 03/13] usb: dwc3: dwc3-of-simple: Add support for dwc3 of Hisilicon Soc Platform Yu Chen
2019-03-29  4:14 ` [PATCH v5 04/13] usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc Yu Chen
2019-03-29  4:14 ` [PATCH v5 05/13] usb: dwc3: Execute GCTL Core Soft Reset while switch mdoe " Yu Chen
2019-03-29  4:14 ` [PATCH v5 06/13] usb: dwc3: Increase timeout for CmdAct cleared by device controller Yu Chen
2019-03-29  4:14 ` [PATCH v5 07/13] phy: Add usb phy support for hi3660 Soc of Hisilicon Yu Chen
2019-04-17  6:42   ` Kishon Vijay Abraham I
2019-04-17  7:19     ` Chen Yu
2019-03-29  4:14 ` [PATCH v5 08/13] usb: roles: Introduce stubs for the exiting functions in role.h Yu Chen
2019-04-04 13:25   ` Heikki Krogerus
2019-03-29  4:14 ` [PATCH v5 09/13] usb: roles: Add usb role switch notifier Yu Chen
2019-04-04 13:26   ` Heikki Krogerus
2019-04-12  1:12   ` John Stultz
2019-04-12  3:59     ` John Stultz
2019-03-29  4:14 ` [PATCH v5 10/13] usb: dwc3: Registering a role switch in the DRD code Yu Chen
2019-04-12  0:48   ` John Stultz
2019-04-12  1:23     ` Chen Yu [this message]
2019-03-29  4:14 ` [PATCH v5 11/13] hikey960: Support usb functionality of Hikey960 Yu Chen
2019-04-12  0:55   ` John Stultz
2019-03-29  4:14 ` [PATCH v5 12/13] usb: gadget: Add configfs attribuite for controling match_existing_only Yu Chen
2019-03-29  4:14 ` [PATCH v5 13/13] dts: hi3660: Add support for usb on Hikey960 Yu Chen
2019-04-01 14:57 ` [PATCH v5 00/13] " Valentin Schneider

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7d5ba117-735e-3fb0-97f7-33be328a4ae6@huawei.com \
    --to=chenyu56@huawei.com \
    --cc=balbi@kernel.org \
    --cc=butao@hisilicon.com \
    --cc=chenyao11@huawei.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fangshengzhou@hisilicon.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=john.stultz@linaro.org \
    --cc=kongfei@hisilicon.com \
    --cc=lijun.kernel@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lipengcheng8@huawei.com \
    --cc=liuyu712@hisilicon.com \
    --cc=songxiaowei@hisilicon.com \
    --cc=suzhuangluan@hisilicon.com \
    --cc=valentin.schneider@arm.com \
    --cc=wanghu17@hisilicon.com \
    --cc=xuyiping@hisilicon.com \
    --cc=xuyoujun4@huawei.com \
    --cc=yudongbin@hisilicon.com \
    --cc=zangleigang@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®