Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753709AbcD0UFy (ORCPT ); Wed, 27 Apr 2016 16:05:54 -0400 Received: from mail-lf0-f66.google.com ([209.85.215.66]:32897 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753495AbcD0UFt (ORCPT ); Wed, 27 Apr 2016 16:05:49 -0400 From: Felipe Balbi To: Arnd Bergmann , Alan Stern Cc: linux-arm-kernel@lists.infradead.org, Grygorii Strashko , Catalin Marinas , Yoshihiro Shimoda , linux-usb@vger.kernel.org, Sekhar Nori , linux-kernel@vger.kernel.org, David Fisher , "Thang Q. Nguyen" , Greg Kroah-Hartman Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <13248156.8VXoeOzRlg@wuerfel> References: <13248156.8VXoeOzRlg@wuerfel> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.0.92.2 (x86_64-pc-linux-gnu) Date: Wed, 27 Apr 2016 23:05:42 +0300 Message-ID: <8737q6stpl.fsf@ti.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-Length: 3092 Lines: 80 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Arnd Bergmann writes: > On Wednesday 27 April 2016 13:59:13 Alan Stern wrote: >> On Wed, 27 Apr 2016, Arnd Bergmann wrote: >>=20 >> > I've looked at the usb HCD code now and see this: >> >=20 >> > struct usb_hcd *usb_create_shared_hcd(const struct hc_driver *driver, >> > struct device *dev, const char *bus_name, >> > struct usb_hcd *primary_hcd) >> > { >> > ... >> > hcd->self.controller =3D dev; >> > hcd->self.uses_dma =3D (dev->dma_mask !=3D NULL); >> > ... >> > } >> >=20 >> > What I think we need to do here is ensure that the device that gets >> > passed here and assigned to hcd->self.controller is the actual DMA >> > master device, i.e. the pci_device or platform_device that was created >> > from outside of the xhci stack. This is after all the pointer that >> > gets passed into all the dma_map_*/dma_sync_*/dma_alloc_*/... >> > functions. >>=20 >> It would be better to add a new field, since self.controller is also >> used for lots of other purposes. Something like hcd->self.dma_dev. > > Ok, fair enough. I only took a brief look and all uses I found were > either for the DMA mapping API or some printk logging. I have a feeling you guys are not considering how the patch to implement this will look like. How are you expecting dwc3 to pass a pointer to the DMA device from dwc3.ko to xhci-plat ? platform_data ? That's gonna be horrible :-) Also, remember that the DMA device for dwc3 is not always dwc3->dev->parent. It might be dwc3->dev itself. How are you expecting us to figure that one out ? I still think dma_inherit() (or something along those lines) is necessary. Specially when you consider that, as I said previously, that's pretty much what of_dma_configure() does. Anyway, I'd really like to see a patch implementing this hcd->self.dma_dev logic. Consider all the duplication with this approach, btw. struct dwc3 will *also* need a dwc->dma_dev of its own. Will that be passed to dwc3 as platform_data from glue layer ? What about platforms which don't even use a glue layer ? =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXIRuWAAoJEIaOsuA1yqRE6mYQAJxND/JAtkvOVbBZAKyk5pe8 W82TS9S4xLdnpfw+tXYjp5nmF6YbAGN89kMpaYO57mifCh1DiVcu26Pt6DxDepzj 7bNVt4AsFafriNCLbZ/U3y4RnYq5Rf48BNGZuzbRX4HXQXIzw8Hirv9STp5JygEX KLqipUi1ZrOSyYtxRKCEczwCA8OmboBq1WOo4Bngsa1OmbGETX20r84HcSme9eIW Ovzx84SyBuQBhX85HqXItxvwb4tU2dORzEFTrBy5gCUOQlFsiw2LvqLUV9xqwMQJ 5LbexatRGNwrG0BpWczBu/9ab1wtqpwt7wjjWaCClK8hdKuaIy5HJXaz50c9D2w2 sbqxjTopO5Lnsa+FJ3iwxYPA7zTMpcPDVOF7gLW83nlrlVSPE5cDpCzihqL6jpS1 fjc80JZhYpvmTdKGYiawVQYs3QQFwvGQvMnGH9T/3JKehY7P7jl6G4Ru6s7Mevkr nli3zopOE//wcyFf0uOWAKShEUwD7bMCuiOl2ztgt+GmMGxt3JRdKLJEgDUAxSeA cj3bCJ7sBI9yFX/RsV/5jdbEM7zsdn7emnAcRRMfgVqp/FWGAW5h/AvFCGnS2srP KwMAi75sg6rBS+18qLm4X9yHeybMmcTcAvxtB+g/zLwu5qwXEiAMc19GhntFgU4w OXsP+hnCyHTbkcf+kDd7 =pBBL -----END PGP SIGNATURE----- --=-=-=--