From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932327AbcIBOV1 (ORCPT ); Fri, 2 Sep 2016 10:21:27 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:59992 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S932194AbcIBOVY (ORCPT ); Fri, 2 Sep 2016 10:21:24 -0400 Date: Fri, 2 Sep 2016 10:21:23 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Felipe Balbi cc: Russell King - ARM Linux , Arnd Bergmann , Leo Li , Grygorii Strashko , Catalin Marinas , Yoshihiro Shimoda , "linux-usb@vger.kernel.org" , Sekhar Nori , lkml , David Fisher , "Thang Q. Nguyen" , Greg Kroah-Hartman , "linux-arm-kernel@lists.infradead.org" , Stuart Yoder , Scott Wood Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <87a8fq8spu.fsf@linux.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Alan Stern From mboxrd@z Thu Jan 1 00:00:00 1970 From: stern@rowland.harvard.edu (Alan Stern) Date: Fri, 2 Sep 2016 10:21:23 -0400 (EDT) Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <87a8fq8spu.fsf@linux.intel.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. Alan Stern