From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753956AbcIBLLz (ORCPT ); Fri, 2 Sep 2016 07:11:55 -0400 Received: from mga09.intel.com ([134.134.136.24]:43470 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752230AbcIBLLv (ORCPT ); Fri, 2 Sep 2016 07:11:51 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,270,1470726000"; d="asc'?scan'208";a="4364262" From: Felipe Balbi To: Russell King - ARM Linux , Arnd Bergmann Cc: Leo Li , Grygorii Strashko , Catalin Marinas , Yoshihiro Shimoda , "linux-usb\@vger.kernel.org" , Sekhar Nori , lkml , David Fisher , "Thang Q. Nguyen" , Alan Stern , 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: <20160902104707.GC1041@n2100.armlinux.org.uk> References: <87vb31kdvh.fsf@intel.com> <6414695.LEIYfGPUEg@wuerfel> <20160902104707.GC1041@n2100.armlinux.org.uk> User-Agent: Notmuch/0.22.1+63~g994277e (https://notmuchmail.org) Emacs/25.1.1 (x86_64-pc-linux-gnu) Date: Fri, 02 Sep 2016 14:08:13 +0300 Message-ID: <87a8fq8spu.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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: >> >=20 >> > Hi Felipe and Arnd, >> >=20 >> > 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? >>=20 >> 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? =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXyV2dAAoJEMy+uJnhGpkGAM8P/08pz51AFuPfyjxJ6UkljAUL 07lcDGLmeCiJoqazCd/UdqRarhpH6JQ+vEDZtgqXOwx1lE1m1rzunZ1OeZMswxqK BTRQiPK+O6dZYKxkq+bln6rcZlKZumZtfJzRzpIyhl2y8zjS4cAlUs4Fc9E24X3l 1q6QtjvX5F4/ZI92i+1bJstdYTIF0zf6iX4kdL4WqXrE43pxZZJo404tQe6f7nzs YaKx9pEhRpI0R386qNxhfjjfJVItcSlv/7ilcQxfqixydOJtT80z5V8mfeNQvwSj YFOXrymZPEImUX+G2Efz0b2pGFyuFmzqw7BsU2fOdah5vbOz+52zjAQgcDSn1jl5 dil7D/+onrruqyUXUzPZLdJLnquewwMVz/jkR/lrX6clMjS8RGsrEXfipDrV4pz6 R99Z/MA79mAqtCho/A7ZbnmQILu3C4eta3yY05hSmZui77KSVlLTiExhkQGWdPgi ZpDut24C6zqcykyyqDF+t9Xkm9KdZbIVXNCW1LQFg1J+siZMhuVzBJDuk8vNZyqW ZCuJ3f5YwGdhIUp8dbd8j7CD7cy+7Yvp7dtWsyeVSvBRRQHfnXtQZidlO3625fcI t1RJlFp/TsSMESG0N5dgDLInG1qPfnvidStMa7ynj2FD6NHKh7Mzm7exVQa8G93I 1L7mBOl0E5RLClpO0wiH =dK1L -----END PGP SIGNATURE----- --=-=-=-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@kernel.org (Felipe Balbi) Date: Fri, 02 Sep 2016 14:08:13 +0300 Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <20160902104707.GC1041@n2100.armlinux.org.uk> References: <87vb31kdvh.fsf@intel.com> <6414695.LEIYfGPUEg@wuerfel> <20160902104707.GC1041@n2100.armlinux.org.uk> Message-ID: <87a8fq8spu.fsf@linux.intel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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? -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: