Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6341946yba; Thu, 11 Apr 2019 17:57:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqwa0nWYXbPKxLPF1Uhp1Rb2furS5hvCJBFWaW6jiU/wmVir0UPW54cvXvq+whK9sdglhW6X X-Received: by 2002:a62:5797:: with SMTP id i23mr51939180pfj.12.1555030635529; Thu, 11 Apr 2019 17:57:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555030635; cv=none; d=google.com; s=arc-20160816; b=nh2DKwIW0Xq18bMZu85WBbTOEuzMJNS4y0ZYsm3z2C2uaepFv6OaOvMIpsKD2a8oKk BuH236k03fGkmaV141WpkyCMYheISNt/R+fl/iqQzY49kPPfq+mKMDxulzU51ohW3Mz5 +VBIFVxzTmGrHvQ35ptY1cFokD/d15YMdHDK3TBcXYl/Zp73G2cG3Q5Cy/BFx8AVNINa h1+d8fbKpORsVDNLv93Vobvn5lLA9cOH4aROKlMy78WyXtiG0tKbJW5GNm89cdhWddB8 jEUXwkxLqsDWiwD25I4W3ZSsrKm4MkRz7L1CncsQb9LjryTpiliKuGTcqbqg24BGLEWU 2CYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=9fx65PGs+hcTLW3v5Oxc17IQCXrFa7XQEHDSKo+zIjg=; b=jNUAmm26APpc+/9A7vzE3dguxmZVuOiPoTv7/p9Btio3pundS8uo/x3JfHz6EpDHgJ qSfl6Bvj6hSut6LU1ma30DBigNw3ZnyscoQYlH/5LWToYMMdRhJzHahm6zYj2xcTb/7G mcSPnmmwxRueshgBeW5zqObLRC+JjnRYmYii7jiChrYyqbiiaumhjZOF6K86u9B+Wdac ssiJb/W+lnZeX3B0NRKf5TSp+lDRue2apvdmCh3aJlmTCzbeflRagX3nq6PUfEHo1v+7 6oJHIvJ2QrjsmUX825glwO5xUIZYBkIu/IORQjNPNWQViLzlwAcrvmGn8AqEzBytNaiy ZMDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=TsjlWIJv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u71si18574395pgd.147.2019.04.11.17.56.59; Thu, 11 Apr 2019 17:57:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=TsjlWIJv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726730AbfDLAzr (ORCPT + 99 others); Thu, 11 Apr 2019 20:55:47 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:45981 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726661AbfDLAzr (ORCPT ); Thu, 11 Apr 2019 20:55:47 -0400 Received: by mail-wr1-f67.google.com with SMTP id s15so9637616wra.12 for ; Thu, 11 Apr 2019 17:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9fx65PGs+hcTLW3v5Oxc17IQCXrFa7XQEHDSKo+zIjg=; b=TsjlWIJv+DW3+CPH6/AwmnLDzKKYSz2qaedQ4z4004P48t2r8voIdztozBT9E386a/ 5rc3Vr9fAhascrbg5ePHArL72NqgpsSWIBir2VCUou4q1kWw708b0EFVvXVgCbNFc1/9 DmvaU/A42NIyQW2VCV9GCWxI9OQUM5SfS/OH+OfEr9XH+eLbj8T7VriJ9yCdv7leTUe8 8uJTdVstjDmG7dXzwAVuzmdUpd9qFapAszN+dEMcWPEoodwUKvqAJPU/CJPpSns+1waA GfM6RDT5ZVa5VktjBTBjgHx9dpzo/J4ddOW5N3pGHU0LKriUrmFlTfZe1I7eUxtYe6SC Ve0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9fx65PGs+hcTLW3v5Oxc17IQCXrFa7XQEHDSKo+zIjg=; b=oVeasZZdYUzHxECaVGF9DdzJeWO/y+Up823R5xXuXUDfkn3deqUvBin6gvXbGwjG3V 2jMQhX/4fFpit4rzaK6dBzHJzbATav+dsahqJQ3zW+k2wxYRMQaD32Fg6U3OpI10wRnw sELT4rZCb8Qh84YPxQyfXm6LRtg68nKkv3DgAzSI6dBGtwdYD59wsB9bisSwOn8Iw/MA 7LgfG1BqsctyinSW5R7sfOZRtqBqEtM9sCi60+bHi+oI9Vv59lMh9VRh48BojuAtBiF8 Q1mm9dMJJXLIyEajF1Ukh8HkJRAfV/i9su4S1TvbYsR5Xyu6vcqwQdBxNk6cueKHdHsI KDiw== X-Gm-Message-State: APjAAAVhMptsmjviZOXHt56P8F9WuR2DyDc7xD22Ksb6uHe0vodMTyWO WfFYIHr0p4rZ7/2kIZ1IloC9eD9JWZepGj60DnfNSg== X-Received: by 2002:adf:b612:: with SMTP id f18mr22392914wre.236.1555030544590; Thu, 11 Apr 2019 17:55:44 -0700 (PDT) MIME-Version: 1.0 References: <20190329041409.70138-1-chenyu56@huawei.com> <20190329041409.70138-12-chenyu56@huawei.com> In-Reply-To: <20190329041409.70138-12-chenyu56@huawei.com> From: John Stultz Date: Thu, 11 Apr 2019 17:55:32 -0700 Message-ID: Subject: Re: [PATCH v5 11/13] hikey960: Support usb functionality of Hikey960 To: Yu Chen Cc: Linux USB List , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , lkml , Zhuangluan Su , Kongfei , "Liuyu (R)" , wanghu17@hisilicon.com, butao , chenyao11@huawei.com, fangshengzhou@hisilicon.com, Li Pengcheng , songxiaowei@hisilicon.com, YiPing Xu , xuyoujun4@huawei.com, Yudongbin , Zang Leigang , Chunfeng Yun , Andy Shevchenko , Arnd Bergmann , Greg Kroah-Hartman , Binghui Wang , Heikki Krogerus Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 28, 2019 at 9:14 PM Yu Chen wrote: > > This driver handles usb hub power on and typeC port event of HiKey960 board: > 1)DP&DM switching between usb hub and typeC port base on typeC port > state > 2)Control power of usb hub on Hikey960 > 3)Control vbus of typeC port Hey Yu Chen! Wanted to say thanks again for sending these patches out so persistently. I did catch an issue with this driver that I wanted to let you know about. > +static int hisi_hikey_role_switch(struct notifier_block *nb, > + unsigned long state, void *data) > +{ > + struct hisi_hikey_usb *hisi_hikey_usb; > + > + hisi_hikey_usb = container_of(nb, struct hisi_hikey_usb, nb); > + > + switch (state) { > + case USB_ROLE_NONE: > + usb_typec_power_ctrl(hisi_hikey_usb, TYPEC_VBUS_POWER_OFF); > + usb_switch_ctrl(hisi_hikey_usb, USB_SWITCH_TO_HUB); > + hub_power_ctrl(hisi_hikey_usb, HUB_VBUS_POWER_ON); > + break; > + case USB_ROLE_HOST: > + usb_switch_ctrl(hisi_hikey_usb, USB_SWITCH_TO_TYPEC); > + usb_typec_power_ctrl(hisi_hikey_usb, TYPEC_VBUS_POWER_ON); > + break; > + case USB_ROLE_DEVICE: > + hub_power_ctrl(hisi_hikey_usb, HUB_VBUS_POWER_OFF); > + usb_typec_power_ctrl(hisi_hikey_usb, TYPEC_VBUS_POWER_OFF); > + usb_switch_ctrl(hisi_hikey_usb, USB_SWITCH_TO_TYPEC); > + break; > + default: > + break; > + } > + > + return 0; > +} > + > +static int hisi_hikey_usb_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct hisi_hikey_usb *hisi_hikey_usb; > + int ret; > + > + hisi_hikey_usb = devm_kzalloc(dev, sizeof(*hisi_hikey_usb), GFP_KERNEL); > + if (!hisi_hikey_usb) > + return -ENOMEM; > + > + hisi_hikey_usb->nb.notifier_call = hisi_hikey_role_switch; > + > + hisi_hikey_usb->typec_vbus = devm_gpiod_get(dev, "typec-vbus", > + GPIOD_OUT_LOW); > + if (IS_ERR(hisi_hikey_usb->typec_vbus)) > + return PTR_ERR(hisi_hikey_usb->typec_vbus); > + > + hisi_hikey_usb->otg_switch = devm_gpiod_get(dev, "otg-switch", > + GPIOD_OUT_HIGH); > + if (IS_ERR(hisi_hikey_usb->otg_switch)) > + return PTR_ERR(hisi_hikey_usb->otg_switch); > + > + /* hub-vdd33-en is optional */ > + hisi_hikey_usb->hub_vbus = devm_gpiod_get_optional(dev, "hub-vdd33-en", > + GPIOD_OUT_HIGH); > + if (IS_ERR(hisi_hikey_usb->hub_vbus)) > + return PTR_ERR(hisi_hikey_usb->hub_vbus); > + > + hisi_hikey_usb->role_sw = usb_role_switch_get(dev); > + if (!hisi_hikey_usb->role_sw) > + return -EPROBE_DEFER; > + if (IS_ERR(hisi_hikey_usb->role_sw)) > + return PTR_ERR(hisi_hikey_usb->role_sw); > + > + ret = usb_role_switch_register_notifier(hisi_hikey_usb->role_sw, > + &hisi_hikey_usb->nb); > + if (ret) { > + usb_role_switch_put(hisi_hikey_usb->role_sw); > + return ret; > + } > + > + platform_set_drvdata(pdev, hisi_hikey_usb); > + > + return 0; > +} The issue I found is that if due to module load order or other randomization in bootup timing, this driver loads much later then the other USB infrastructure, the usb_role_switch notifier that is registered may be registered after any state initialization or change has occurred that would trigger the notifier callbacks. This means initially this driver could be out of sync with the core usb_role_switch state. I've tried doing something like the following on probe to force the initialization: cur_role = usb_role_switch_get_role(hisi_hikey_usb->role_sw); usb_role_switch_set_role(hisi_hikey_usb->role_sw, cur_role); But this is racy, as a state change can happen in between the call to get_role and set_role, which would end up overwriting the proper state. I suspect a proper fix needs to happen in the usb_role_switch_register_notifier(), where the callback gets called with the initial state while holding the lock to avoid races. I'll comment more in that patch. thanks -john