Received: by 10.223.185.116 with SMTP id b49csp935381wrg; Tue, 20 Feb 2018 10:11:53 -0800 (PST) X-Google-Smtp-Source: AH8x224Y0vn0k5gv0bHnp5YEvlMoGFgM6aoveNuvw3bXxCo6/uxtLwqF5joEFBu1rWDJduFXr6q0 X-Received: by 2002:a17:902:2e03:: with SMTP id q3-v6mr454209plb.362.1519150313878; Tue, 20 Feb 2018 10:11:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519150313; cv=none; d=google.com; s=arc-20160816; b=wuitgDGv34pXr9WXHFJIGr1StUaOmTsrOfLHi5uNLTtuXJAVCbKGNWmluR9fg4h96J W9SCH/BfauU73jcyF6owUtJ1u2X/AYGkZyedxpSjScaTsyYODPMfnQ4wIiI2zoD8ish9 fkuD8d6/doVxwKU58yk/wgj5llbVFYzUjI02R6+jv2EBnjLS5Nf+cLtFmgHXYKlTBohW wtX4nFkT7ivCpAbE47f0XYM9VqWfTjyZgCErHD5Fx+OEscic3XSfdyd/cQAzxPhjmDzq V50UbB/hcqa+8lqwOWjg59aImqWiHP8hsK1VYn56rbLgWQ7YlvDlka2ieJaCTMl5p/ey kdgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=EdetG3ZzLwxDAzy8dxJAm30ybdXpcHfzV5z09EuT+pA=; b=U+j5kebfbxG73Hu+d4S3SbC6QeSPvxooq6Mv/SeTV8/HxvXVJv1EUtoOQ7ANY3eWbW WSM+LobfGfJP3g3TB2QvASxHcSstbnFfT1rm5wCNhw0ZWTyCavsN9JMp9KFEmoipzj5I 68woVTqRH7h7ED6vYsMeEv4SR5jW5I61l8seJ3rhrCZfH0H8rJCT5jwxSBv1FEk9TVSe fVuE1BOi0f6RSxmncu0hZ3bZyt+NnAyzlDz4087FQRNonbpoEv1Hflcn+11sMMs7JD4m lnY24l5wKG3Jt50lw5XzsT7rMt3+uM7bjyztogvDt5gU0zpntHvKhDSsqWrBp3k9WgMl 0tvg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e3si1131278pga.1.2018.02.20.10.11.33; Tue, 20 Feb 2018 10:11:53 -0800 (PST) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753386AbeBTSKe (ORCPT + 99 others); Tue, 20 Feb 2018 13:10:34 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:59792 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752771AbeBTSKc (ORCPT ); Tue, 20 Feb 2018 13:10:32 -0500 Received: (qmail 4467 invoked by uid 2102); 20 Feb 2018 13:10:30 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Feb 2018 13:10:30 -0500 Date: Tue, 20 Feb 2018 13:10:30 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Roger Quadros cc: Amelie DELAUNAY , Greg Kroah-Hartman , Rob Herring , Mark Rutland , Tony Prisk , "linux-usb@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v2] usb: host: ehci-platform: add support for optional external vbus supply In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 20 Feb 2018, Roger Quadros wrote: > On 20/02/18 16:46, Amelie DELAUNAY wrote: > > Hi, > > > > On 02/20/2018 03:00 PM, Roger Quadros wrote: > >> Hi, > >> > >> On 20/02/18 14:58, Amelie Delaunay wrote: > >>> On some boards, especially when vbus supply requires large current, > >>> and the charge pump on the PHY isn't enough, an external vbus power switch > >>> may be used. > >>> Add support for this optional external vbus supply in ehci-platform. > >>> > >>> Signed-off-by: Amelie Delaunay > >>> > >>> --- > >>> Changes in v2: > >>> * Address Roger Quadros comments: move regulator_enable/disable from > >>> ehci_platform_power_on/off to ehci_platform_port_power. > >>> --- > >>> Documentation/devicetree/bindings/usb/usb-ehci.txt | 1 + > >>> drivers/usb/host/ehci-platform.c | 31 ++++++++++++++++++++++ > >>> 2 files changed, 32 insertions(+) > >>> > >>> diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt > >>> index 3efde12..fc480cd 100644 > >>> --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt > >>> +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt > >>> @@ -19,6 +19,7 @@ Optional properties: > >>> - phys : phandle + phy specifier pair > >>> - phy-names : "usb" > >>> - resets : phandle + reset specifier pair > >>> + - vbus-supply : phandle of regulator supplying vbus > >>> > >> > >> Can platforms have more than one regulator e.g. one regulator per port? > >> > > > > I imagine that yes, platforms could have one regulator per port. > > Regulator consumers bindings impose a -supply property per > > regulator, so, what do you think about : > > vbus0-supply for port#0 > > vbus1-supply for port#1 > > ... > > vbusN-supply for port#N > > > > And then in probe, allocate 'struct regulator *vbus_supplies' with a > > size corresponding to 'HCS_N_PORTS(ehci->hcs_params) * sizeof(struct > > regulator *)'. > > And loop to get optional regulator vbus0, vbus1,..., vbusN. > > And then enable/disable the corresponding regulator in > > ehci_platform_port_power thanks to portnum. > > Looks fine to me but we need to get Alan's opinion if this is worth the effort. > If there isn't a single platform needing it we could probably do without it > but the DT binding must be scalable to add this feature in the future. I agree that for now there don't seem to be any platforms requiring more than one regulator, but this should be implemented in a way that could be expanded if necessary. Anyway, the basic idea is reasonable. I don't know to what extent people want to power-off their EHCI ports, but if they do then we ought to turn off external regulators at the same time. Is there a real-life use case for this? Alan Stern > And what if it is ganged power? i.e. one regulator for more than one port. > Probably they all can point to the same regulator instance and it should work. > > > > >>> Example (Sequoia 440EPx): > >>> ehci@e0000300 { > >>> diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c > >>> index b065a96..05be100 100644 > >>> --- a/drivers/usb/host/ehci-platform.c > >>> +++ b/drivers/usb/host/ehci-platform.c > >>> @@ -29,6 +29,7 @@ > >>> #include > >>> #include > >>> #include > >>> +#include > >>> #include > >>> #include > >>> #include > >>> @@ -46,6 +47,7 @@ struct ehci_platform_priv { > >>> struct reset_control *rsts; > >>> struct phy **phys; > >>> int num_phys; > >>> + struct regulator *vbus_supply; > >>> bool reset_on_resume; > >>> }; > >>> > >>> @@ -76,6 +78,25 @@ static int ehci_platform_reset(struct usb_hcd *hcd) > >>> return 0; > >>> } > >>> > >>> +static int ehci_platform_port_power(struct usb_hcd *hcd, int portnum, > >>> + bool enable) > >>> +{ > >>> + struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd); > >>> + int ret = 0; > >>> + > >>> + if (priv->vbus_supply) { > >>> + if (enable) > >>> + ret = regulator_enable(priv->vbus_supply); > >>> + else > >>> + ret = regulator_disable(priv->vbus_supply); > >>> + if (ret) > >>> + dev_err(hcd->self.controller, > >>> + "failed to %s vbus supply: %d\n", > >>> + enable ? "enable" : "disable", ret); > >>> + } > >>> + return ret; > >>> +} > >>> + > >>> static int ehci_platform_power_on(struct platform_device *dev) > >>> { > >>> struct usb_hcd *hcd = platform_get_drvdata(dev); > >>> @@ -134,6 +155,7 @@ static struct hc_driver __read_mostly ehci_platform_hc_driver; > >>> static const struct ehci_driver_overrides platform_overrides __initconst = { > >>> .reset = ehci_platform_reset, > >>> .extra_priv_size = sizeof(struct ehci_platform_priv), > >>> + .port_power = ehci_platform_port_power, > >>> }; > >>> > >>> static struct usb_ehci_pdata ehci_platform_defaults = { > >>> @@ -247,6 +269,15 @@ static int ehci_platform_probe(struct platform_device *dev) > >>> if (err) > >>> goto err_put_clks; > >>> > >>> + priv->vbus_supply = devm_regulator_get_optional(&dev->dev, "vbus"); > >>> + if (IS_ERR(priv->vbus_supply)) { > >>> + err = PTR_ERR(priv->vbus_supply); > >>> + if (err == -ENODEV) > >>> + priv->vbus_supply = NULL; > >>> + else > >>> + goto err_reset; > >>> + } > >>> + > >>> if (pdata->big_endian_desc) > >>> ehci->big_endian_desc = 1; > >>> if (pdata->big_endian_mmio) > >>> > >