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
>
> .
>
next prev parent 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®