From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932865AbcIBPwW (ORCPT ); Fri, 2 Sep 2016 11:52:22 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:61669 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932539AbcIBPwR (ORCPT ); Fri, 2 Sep 2016 11:52:17 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Alan Stern , Felipe Balbi , Grygorii Strashko , Stuart Yoder , Catalin Marinas , Yoshihiro Shimoda , "linux-usb@vger.kernel.org" , Sekhar Nori , Russell King - ARM Linux , lkml , Scott Wood , David Fisher , "Thang Q. Nguyen" , Leo Li , Greg Kroah-Hartman Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev Date: Fri, 02 Sep 2016 17:51:58 +0200 Message-ID: <5147808.apZTAZ3VPE@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:oC6TXzFrj3L/2hMGcEBaO7CfuDAYuQWrhNBZ+Kj5tA3qQysdj+B CB4FjmZZhVBiqrAYu9Gi/k2e1JMQTtKxXiJAvYU1GxTPkfhzl9jbTscmC5EzlNx1ELMPUL8 ePASOpLcoZtwi5HVtVvkPuAQlsXbvR2d+EIjbfiBiR8BaXKHblu7i+7eXvuzpHFEqkPjKCn tUq150gU2ZKWzevyOZ7nw== X-UI-Out-Filterresults: notjunk:1;V01:K0:VK0XkUewDN0=:+0Hm+e5RUAqOkN97QrfU3z BKec+KUuYP73U8aAK4jobJBHZL5ux5pG4j9MJJfXvHS653LO3diyXxAho8+Mh7wt4oAe62VhC WN2R59J5A/sWaVv6kwkIRuC3HVEgGakHLzkZde2aFuAya2ihWowPbca6AEu26NbklNdUd4z2z lToLVgWnIyoDNzp39X73HclXwPdDHziLv0VkaTKV9mF4zx+blzH5KAou9FowhhHwgdR0nvp5h JwOknOJRejucjDJVVPO9+5nBDs+nmHa9k96CLkzJxJqU7NTXsyCJrpndjg6TQArnTGemlKg49 Z8iaq39zdH22NWlJjeaPHyTNFcLnR/nZZMxXkzI7mPV2ZQ/dLrmJeIT3LjenYJM7W++1feCrZ kYF69OeWMZytceOBOHzHlk5JOCmOIjSiICFbEN4edLotpwDJYxSz3CsDOxHlp4mUGojpHpbWZ d+axevsQbfmfT3c42rRDH2m9X4mmMHUsZxAZ2Posx32jTOrIsDlMWXIfqlrxFIRoaxQNPa+u7 q8TDUHVshGns0BuDX3QhKc+vMQ88WnjuRHlzi2uFVPI1WmsNHZtZEwoHy7c9MNB5LcWMBwVef C629rxdm4/0eC4X/wULUZPy6Bt/CbNqVChWOQEmjiqR5YoWl6S6LTVxpx2j1vVvfhSc3S67tA 9yjd2xEN4Btd+lUNfq6BBzIhUd0u7Mn7snbmD52b39wjZ+kG1vXXqAzny354NlxJRn7WoocbQ BFnMyIrk5sofGS+F Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday, September 2, 2016 10:21:23 AM CEST Alan Stern wrote: > On Fri, 2 Sep 2016, Felipe Balbi wrote: > > > Hi, > > > > Russell King - ARM Linux writes: > > > On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote: > > >> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote: > > >> > > > >> > Hi Felipe and Arnd, > > >> > > > >> > It has been a while since the last response to this discussion, but we > > >> > haven't reached an agreement yet! Can we get to a conclusion on if it > > >> > is valid to create child platform device for abstraction purpose? If > > >> > yes, can this child device do DMA by itself? > > >> > > >> I'd say it's no problem for a driver to create child devices in order > > >> to represent different aspects of a device, but you should not rely on > > >> those devices working when used with the dma-mapping interfaces. > > > > > > That's absolutely right. Consider the USB model - only the USB host > > > controller can perform DMA, not the USB devices themselves. All DMA > > > mappings need to be mapped using the USB host controller device struct > > > not the USB device struct. > > > > > > The same _should_ be true everywhere else: the struct device representing > > > the device performing DMA must be the one used to map the transfer. > > > > How do we fix dwc3 in dual-role, then? > > > > Peripheral-side dwc3 is easy, we just require a glue-layer to be present > > and use dwc3.ko's parent device (which will be the PCI device or OF > > device). But for host side dwc3, the problem is slightly more complex > > because we're using xhci-plat.ko by just instantiating a xhci-platform > > device so xhci-plat can probe. > > > > xhci core has no means to know if its own device or the parent of its > > parent should be used for DMA. Any ideas? > > In theory, you can store a flag somewhere in the platform device, > something that would tell xhci-hcd that it has to use the parent's > parent for DMA purposes. > > I know it would be somewhat of a hack, but ought to work. Speaking of that flag, I suppose we need the same logic to know where to look for USB devices attached to a dwc3 host when we need to describe them in DT. By default we look for child device nodes under the node of the HCD device node, but that would be wrong here too. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Fri, 02 Sep 2016 17:51:58 +0200 Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: References: Message-ID: <5147808.apZTAZ3VPE@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Friday, September 2, 2016 10:21:23 AM CEST Alan Stern wrote: > On Fri, 2 Sep 2016, Felipe Balbi wrote: > > > Hi, > > > > Russell King - ARM Linux writes: > > > On Fri, Sep 02, 2016 at 12:43:39PM +0200, Arnd Bergmann wrote: > > >> On Thursday, September 1, 2016 5:14:28 PM CEST Leo Li wrote: > > >> > > > >> > Hi Felipe and Arnd, > > >> > > > >> > It has been a while since the last response to this discussion, but we > > >> > haven't reached an agreement yet! Can we get to a conclusion on if it > > >> > is valid to create child platform device for abstraction purpose? If > > >> > yes, can this child device do DMA by itself? > > >> > > >> I'd say it's no problem for a driver to create child devices in order > > >> to represent different aspects of a device, but you should not rely on > > >> those devices working when used with the dma-mapping interfaces. > > > > > > That's absolutely right. Consider the USB model - only the USB host > > > controller can perform DMA, not the USB devices themselves. All DMA > > > mappings need to be mapped using the USB host controller device struct > > > not the USB device struct. > > > > > > The same _should_ be true everywhere else: the struct device representing > > > the device performing DMA must be the one used to map the transfer. > > > > How do we fix dwc3 in dual-role, then? > > > > Peripheral-side dwc3 is easy, we just require a glue-layer to be present > > and use dwc3.ko's parent device (which will be the PCI device or OF > > device). But for host side dwc3, the problem is slightly more complex > > because we're using xhci-plat.ko by just instantiating a xhci-platform > > device so xhci-plat can probe. > > > > xhci core has no means to know if its own device or the parent of its > > parent should be used for DMA. Any ideas? > > In theory, you can store a flag somewhere in the platform device, > something that would tell xhci-hcd that it has to use the parent's > parent for DMA purposes. > > I know it would be somewhat of a hack, but ought to work. Speaking of that flag, I suppose we need the same logic to know where to look for USB devices attached to a dwc3 host when we need to describe them in DT. By default we look for child device nodes under the node of the HCD device node, but that would be wrong here too. Arnd