From patchwork Thu Sep 8 12:28:10 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Chen X-Patchwork-Id: 9321261 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 299556077F for ; Thu, 8 Sep 2016 12:30:22 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1619D297F0 for ; Thu, 8 Sep 2016 12:30:22 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 0A7B429812; Thu, 8 Sep 2016 12:30:22 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 5488F297F0 for ; Thu, 8 Sep 2016 12:30:18 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1bhyRk-00022V-Pz; Thu, 08 Sep 2016 12:28:48 +0000 Received: from mail-pa0-x241.google.com ([2607:f8b0:400e:c03::241]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1bhyRa-0001uw-Vb for linux-arm-kernel@lists.infradead.org; Thu, 08 Sep 2016 12:28:43 +0000 Received: by mail-pa0-x241.google.com with SMTP id gi6so2363455pac.1 for ; Thu, 08 Sep 2016 05:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=y/x+WvZDOJJB2FXqsD2RvSXqmEomSsSyqt6kCfX7vA8=; b=XDmaOvNDR3Mbk9pwdjoj+3d7KNRO1Z7H0iy/272+Hy1bXsZ0ID29qZnlrjdEakh80e DtQDEdq0vEbawfOHIWmNDdHcxhRchuXMSUfTQQlisaVwW5ZPluLTtHJFfTXQ/+UEtUZW jbCE9rmYw1uBA+Y55O8ANmNCdew7Dwwm9krkrOkhDrnM88MN0IPb/lt/lxG/KfokCbRh 1EKEWZ57VuzhldLgepb5NH99MngayzMMLBO1bgQa0Jo4HnGt8ybQQTD6iyKwFv9yac3d 9awiAuTpHeqrV2bb5jxQeeMHQhCJDcFz6s0UDQMtBMAy3ICcDSQDsgudyki1pphip4zs rwjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=y/x+WvZDOJJB2FXqsD2RvSXqmEomSsSyqt6kCfX7vA8=; b=BsZ1qYu32HOd3/fvM0fxDUDDtNbyfX2SjxXQrnsyuMBJNypfu+4x5510b6J7swaJYk s3IGZNKX74I4D24u1opT1dIwCDhHc5HnLQ5CcpcCKx6aD/35ShUjeB02yY4RcH8nEq1r YoYpERxMSZsx/2x9a4j54jXeNHcys9wWph+IlpPm285kNsOoTm5st6y0nE2Va0jiFOyH TExtL0pL8gJgT6qnRERdcGNnuA1SxaaPSiXvVNrZnnyUmvPKQZ7dmw/ixtpVgrL+zB15 34CIUAer1VwDCbeWHex/O9WOyt5OVlqaKZ2K97bJh72IASewExGTrEUM/937pIj7bMt9 WH7w== X-Gm-Message-State: AE9vXwM7TYoOcIhi98HJxxKoy0hz1vCYV6vmzBZr7paoG5S0kPvcpjnxe4lfOBZrb/MJIw== X-Received: by 10.66.170.135 with SMTP id am7mr1635090pac.6.1473337697465; Thu, 08 Sep 2016 05:28:17 -0700 (PDT) Received: from b29397-desktop (gate-zmy3.freescale.com. [192.88.167.1]) by smtp.gmail.com with ESMTPSA id r19sm46058368pfb.31.2016.09.08.05.28.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Sep 2016 05:28:16 -0700 (PDT) Date: Thu, 8 Sep 2016 20:28:10 +0800 From: Peter Chen To: Arnd Bergmann Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Message-ID: <20160908122810.GA14132@b29397-desktop> References: <2733202.7lpFC7RnDm@wuerfel> <87lgz2iv6d.fsf@linux.intel.com> <4934737.egJZVdaLZs@wuerfel> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4934737.egJZVdaLZs@wuerfel> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160908_052839_093249_5BF38E36 X-CRM114-Status: GOOD ( 35.53 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Felipe Balbi , Grygorii Strashko , Russell King - ARM Linux , Catalin Marinas , Yoshihiro Shimoda , "linux-usb@vger.kernel.org" , Sekhar Nori , lkml , Stuart Yoder , Scott Wood , David Fisher , "Thang Q. Nguyen" , Leo Li , Greg Kroah-Hartman , Alan Stern , "linux-arm-kernel@lists.infradead.org" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Sep 08, 2016 at 12:17:21PM +0200, Arnd Bergmann wrote: > On Thursday, September 8, 2016 12:43:06 PM CEST Felipe Balbi wrote: > > Arnd Bergmann writes: > > > On Thursday, September 8, 2016 11:29:04 AM CEST Felipe Balbi wrote: > > >> > If we do that, we have to put child devices of the dwc3 devices into > > >> > the platform glue, and it also breaks those dwc3 devices that don't > > >> > have a parent driver. > > >> > > >> Well, this is easy to fix: > > >> > > >> if (dwc->dev->parent) { > > >> dwc->sysdev = dwc->dev->parent; > > >> } else { > > >> dev_info(dwc->dev, "Please provide a glue layer!\n"); > > >> dwc->sysdev = dwc->dev; > > >> } > > > > > > I don't understand. Do you mean we should have an extra level of > > > stacking and splitting "static struct platform_driver dwc3_driver" > > > in two so instead of > > > > > > "qcom,dwc3" -> "snps,dwc3" (usb_bus.sysdev) -> "xhci" (usb_bus.dev) > > > > > > we do this? > > > > > > "qcom,dwc3" -> "snps,dwc3" (usb_bus.sysdev) -> "dwc3-glue" -> "xhci" (usb_bus.dev) > > > > no > > > > If we have a parent device, use that as sysdev, otherwise use self as > > sysdev. > > But there is often a parent device in DT, as the xhci device is > attached to some internal bus that gets turned into a platform_device > as well, so checking whether there is a parent will get the wrong > device node. From my point, all platform and firmware information at dwc3 are correct, so we don't need to change dwc3/core.c, only changing for xhci-plat.c is ok. At above changes, the root hub's of_node equals to xhci-hcd sysdev's of_node, which is from firmware or from its parent (it is dwc3 core device). > > > > That sounds a bit clumsy for the sake of consistency with PCI. > > > The advantage is that xhci can always use the grandparent device > > > as sysdev whenever it isn't probed through PCI or firmware > > > itself, but the purpose of the dwc3-glue is otherwise questionable. > > > > > > How about adding a 'compatible="snps,dwc3-pci"' property for the dwc3 > > > device when that is created from the PCI driver and checking for that > > > with the device property interface instead? If it's "snps,dwc3" > > > we use the device itself while for "snps,dwc3-pci", we use the parent? > > For pci glue device, it is always the parent for dwc3 core device. In your patch, you may not need to split pci or non-pci, just using if (dev->parent). > > Any reason why we wouldn't use e.g. dwc3-omap.dev as sysdev? > > That would be incompatible with the USB binding, as the sysdev > is assumed to be a USB host controller with #address-cells=<1> > and #size-cells=<0> in order to hold the child devices, for > example: > > / { > omap_dwc3_1: omap_dwc3_1@48880000 { > compatible = "ti,dwc3"; > #address-cells = <1>; > #size-cells = <1>; > ranges; > usb1: usb@48890000 { > compatible = "snps,dwc3"; > reg = <0x48890000 0x17000>; > #address-cells = <1>; > #size-cells = <0>; > interrupts = , > , > ; > interrupt-names = "peripheral", > "host", > "otg"; > phys = <&usb2_phy1>, <&usb3_phy1>; > phy-names = "usb2-phy", "usb3-phy"; > > hub@1 { > compatible = "usb5e3,608"; > reg = <1>; > #address-cells = <1>; > #size-cells = <0>; > > ethernet@1 { > compatible = "usb424,ec00"; > mac-address = [00 11 22 33 44 55]; > reg = <1>; > }; > }; > }; > }; > With my above changes, the hub of_node should be found since it is child of root hub's of_node which is the dwc3's of_node. > It's also the node that contains the "phys" properties and > presumably other properties like "otg-rev", "maximum-speed" > etc. > This information is described at dwc3 core device of_node, and be handled at dwc3/core.c diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index ed56bf9..fd57c0d 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c @@ -145,6 +145,7 @@ static int xhci_plat_probe(struct platform_device *pdev) struct clk *clk; int ret; int irq; + struct device *dev = &pdev->dev, *sysdev; if (usb_disabled()) return -ENODEV; @@ -155,6 +156,12 @@ static int xhci_plat_probe(struct platform_device *pdev) if (irq < 0) return -ENODEV; + if (dev->parent) { + sysdev = dev->parent; + } else { + sysdev = dev; + } + /* Try to set 64-bit DMA first */ if (WARN_ON(!pdev->dev.dma_mask)) /* Platform did not initialize dma_mask */ @@ -170,7 +177,8 @@ static int xhci_plat_probe(struct platform_device *pdev) return ret; } - hcd = usb_create_hcd(driver, &pdev->dev, dev_name(&pdev->dev)); + hcd = __usb_create_hcd(driver, sysdev, &pdev->dev, + dev_name(&pdev->dev), NULL); if (!hcd) return -ENOMEM; diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index d2e3f65..563600b 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1118,7 +1118,7 @@ static int register_root_hub(struct usb_hcd *hcd) /* Did the HC die before the root hub was registered? */ if (HCD_DEAD(hcd)) usb_hc_died (hcd); /* This time clean up */ - usb_dev->dev.of_node = parent_dev->of_node; + usb_dev->dev.of_node = parent_dev->sysdev->of_node; } mutex_unlock(&usb_bus_idr_lock);