From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757040AbcIHMwr (ORCPT ); Thu, 8 Sep 2016 08:52:47 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:62741 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752110AbcIHMwq (ORCPT ); Thu, 8 Sep 2016 08:52:46 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Peter Chen , 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 Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Date: Thu, 08 Sep 2016 14:52:29 +0200 Message-ID: <6547614.50rx8ya9lj@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160908122810.GA14132@b29397-desktop> References: <4934737.egJZVdaLZs@wuerfel> <20160908122810.GA14132@b29397-desktop> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:U9P9ePyW+KYc5IOySjWC8GFuYRJg3sr2BCujUXSaMq4dcv4y9N7 EU3UymKz+Gj/aDPkZ4QrzqKowzXvuFllOs2eJwm0ISbqEEtEW/AQ1KmOrcXcTLI9ev1l3Zj vxJ6NrKGlyZRRetcG9cyOgQecZyIgyTMQnak4m61YtqScZ7YvmxUVfMsF+3+xwZAlOBvp+i v00mdLn284m2TIDUfa9Dw== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZnxfkXYqxPM=:e2BfTv/zmW7d2SUu5KZikV 56qr7SF8rNQ0ONMOwLaWvMlf7O68ahMT5BfHAbhkS+W1QIyah2FwpEGozgJGeugkikDfiq8/2 0HiCkAKHKJcWev51R3d0GOPpg3CLQa4KHe1htBKL/jNpTS4qH3lm48TjSa0BWTuVE1N+jfHpc 8S82ZFz1rwwJIjSOcjIidugGeWrQZCNLjr8mlCnIIeCIdwYDfnB0l2QFzpSXAVp4OIDGN37YE Jp4nbQsYsJpqRaWEnsY7VG0Shy4BMrAhSznaXd96wOoUl1pJAsVgU4U5TGpN0oO/kTMS68qSx ypw6aezkdZmfBjKsKsxdDw72dsHSRtnsYlfjL/pxhkrHl55m+AlYKDxPCF3JmpKpva8VZqdxs 6Ojmu4Od295WsNB5YUjTgXLMI/OqHoFhtW/TJ5d6/q8PGC72yObwG4F7Vy9zHiUnyVoL3i1WI viXeEX1+W3Rm0j2Ojw5fnZ3BEe+2NUAr/VXN0er+RFgCuj8/r90g4b1ML4TZGpwCi5aiYLSsw JjbhM/2JBX8FTGqOxUZUoEwhb6qEda8Qw1CPJ1+18XttcxnEF09wtcannKfdvaDRhIO5F0oKi rsvxxzDZwD1evtWjl6Y83bL2e4QzMVDIpr/tuV5dPqS51s949ptFzpw7ilraXFRV1o4Ddsc5w vsUXoGaB1gTZvkJ63YFzRcmxQTfDx9tl8ea9Fc/NTwqwCmN2zlTyIdX6kYKAigfyizsjYpwXD aUzYG1X5aNCCJhqj Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday, September 8, 2016 8:28:10 PM CEST Peter Chen wrote: > 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 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. Ok, thanks. That leaves the PCI glue, right? > 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); > > 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). Just to make sure I understand you right: in the qcom,dwc3 -> dwc3 -> xhci hierarchy, this would be the dwc3 device, not the qcom,dwc3 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). Here we have the pci-dwc3 -> dwc3 -> xhci hierarchy, and we want sysdev to point to pci-dwc3, not dwc3! The point is that the pci_dev is where we have the dma settings and (optionally) additional DT or ACPI data for that device. Arnd