From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933194AbcIGGws (ORCPT ); Wed, 7 Sep 2016 02:52:48 -0400 Received: from mga02.intel.com ([134.134.136.20]:39400 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932462AbcIGGwr (ORCPT ); Wed, 7 Sep 2016 02:52:47 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,295,1470726000"; d="asc'?scan'208";a="875884101" From: Felipe Balbi To: Arnd Bergmann Cc: Peter Chen , Leo Li , 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" , Alan Stern , Greg Kroah-Hartman , "linux-arm-kernel\@lists.infradead.org" Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <20562703.Glp77l1PBf@wuerfel> References: <4416687.vUjZzKWZG6@wuerfel> <87d1khmhdj.fsf@linux.intel.com> <20562703.Glp77l1PBf@wuerfel> User-Agent: Notmuch/0.22.1+63~g994277e (https://notmuchmail.org) Emacs/25.1.3 (x86_64-pc-linux-gnu) Date: Wed, 07 Sep 2016 09:51:55 +0300 Message-ID: <87y434kxro.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 Arnd Bergmann writes: > On Tuesday, September 6, 2016 1:50:48 PM CEST Felipe Balbi wrote: >> Hi, >>=20 >> Arnd Bergmann writes: >> > On Tuesday, September 6, 2016 9:40:19 AM CEST Felipe Balbi wrote: >> >>=20 >> >> this only solves the problem for DT devices. Legacy devices and >> >> PCI-based systems will still suffer from the same problem. At least f= or >> >> dwc3, I will only be taking patches that solve the problem for all >> >> users, not a subset of them. >> > >> > I don't think legacy devices are a worry, because they wouldn't >> > have this problem. For the PCI case, you are right that it cannot >> > work, in particular for machines that have complex IOMMU setup. >> > >> > Some architectures (at least arm64 and sparc) check the bus_type of >> > a device in order to find the correct set of dma_map_ops for that >> > device, so there is no real way to handle this as long as you >> > pass a platform_device into an API that expects a pci_device. >>=20 >> Then I guess we're left with adding a "struct device *dma_dev" to struct >> dwc3 and trying to figure out if we should use parent or self. Does >> anybody see any problems with that? > > I think we actually need the device pointer in the usb_hcd structure, > so it can be passed in these API calls from the USB core that's for host side. I'm concerned about peripheral side > as these are all called on behalf of the host controller node. > Looking for more instances of hcd->self.controller, I find this > instance: > > drivers/usb/core/hcd.c: struct usb_phy *phy =3D usb_get_phy_dev(h= cd->self.controller, 0); > drivers/usb/core/hcd.c: struct phy *phy =3D phy_get(hcd->self.con= troller, "usb"); > > I'm unsure which device pointer we want here, but I suspect this also > needs to be the one that has the device node in order to make the lookup > of the phy structure by device node work right. Can you clarify how > this works today? sounds correct to me. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXz7kLAAoJEMy+uJnhGpkG5RIP/ixd1LZk5U9NKKqmPOY5FXoV gmtzIk6i498Ai6EdQQ/QorIiNGH4sKfUW856hbG9rL4hT6vDxNtzZrHirDoftdfx +N1u9BdQ1W6sfRyy0odB6kuUWIavddWtuhJChQEwGJ/W08RHuFjPpfsnL4G8SGzy nsFPiLP15lSUQnpC2ZYejg0EN0gzwV6mqw3p7vXVzN1W/xQUwdi8N9QtlqyVDDri OJIFqWRWp8YFmPhYLQbbtfN8QUoZcJY1hwTR7bLuj0546NPTSj35TBuuGohpgBuv vC4PG1UJIRHVvMxqTncbpnb3GcLQkwxnzgKC6D283sPksISo8DHY1141D6c0ik/w K4qWpDn75s10uCzAYLBjBkhebkrz+jpBNFY+FbabVzG3hBkNe99yL1IMaKL+zY5v 14N6v+DLAyspp5Ru9yk+gj66cwVavCvMp9swK0BDUpNqyAy+ImwbhTjzqjGzpflE uw+bzb81piReqB4ldJewht45i9QlaxSo3+71HVliCSpApEXJyhmexDRq4+b509tP bclZL7CJOBffdVKIM4V7CcGidKw/xCdq41Qxt3aTI5qKJFTFv0NXsBDXQ5Zocd9q wmk2uVJOaH6inSa3kIgFtXy5/+W185GviGVUVtD6rvL0+yQ7w2MD5leg+ZQKocN1 BliixcLv6DoiYOe6/FEy =b7SJ -----END PGP SIGNATURE----- --=-=-=-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@kernel.org (Felipe Balbi) Date: Wed, 07 Sep 2016 09:51:55 +0300 Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <20562703.Glp77l1PBf@wuerfel> References: <4416687.vUjZzKWZG6@wuerfel> <87d1khmhdj.fsf@linux.intel.com> <20562703.Glp77l1PBf@wuerfel> Message-ID: <87y434kxro.fsf@linux.intel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Arnd Bergmann writes: > On Tuesday, September 6, 2016 1:50:48 PM CEST Felipe Balbi wrote: >> Hi, >> >> Arnd Bergmann writes: >> > On Tuesday, September 6, 2016 9:40:19 AM CEST Felipe Balbi wrote: >> >> >> >> this only solves the problem for DT devices. Legacy devices and >> >> PCI-based systems will still suffer from the same problem. At least for >> >> dwc3, I will only be taking patches that solve the problem for all >> >> users, not a subset of them. >> > >> > I don't think legacy devices are a worry, because they wouldn't >> > have this problem. For the PCI case, you are right that it cannot >> > work, in particular for machines that have complex IOMMU setup. >> > >> > Some architectures (at least arm64 and sparc) check the bus_type of >> > a device in order to find the correct set of dma_map_ops for that >> > device, so there is no real way to handle this as long as you >> > pass a platform_device into an API that expects a pci_device. >> >> Then I guess we're left with adding a "struct device *dma_dev" to struct >> dwc3 and trying to figure out if we should use parent or self. Does >> anybody see any problems with that? > > I think we actually need the device pointer in the usb_hcd structure, > so it can be passed in these API calls from the USB core that's for host side. I'm concerned about peripheral side > as these are all called on behalf of the host controller node. > Looking for more instances of hcd->self.controller, I find this > instance: > > drivers/usb/core/hcd.c: struct usb_phy *phy = usb_get_phy_dev(hcd->self.controller, 0); > drivers/usb/core/hcd.c: struct phy *phy = phy_get(hcd->self.controller, "usb"); > > I'm unsure which device pointer we want here, but I suspect this also > needs to be the one that has the device node in order to make the lookup > of the phy structure by device node work right. Can you clarify how > this works today? sounds correct to me. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: