From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752657AbcD1O33 (ORCPT ); Thu, 28 Apr 2016 10:29:29 -0400 Received: from mga03.intel.com ([134.134.136.65]:51091 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752147AbcD1O32 (ORCPT ); Thu, 28 Apr 2016 10:29:28 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,547,1455004800"; d="asc'?scan'208";a="794289756" From: Felipe Balbi To: Arnd Bergmann , Russell King - ARM Linux 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" , Alan Stern , Greg Kroah-Hartman Subject: Re: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <2806018.GHhm6tEuKR@wuerfel> References: <87y47ykzmz.fsf@intel.com> <20160428141611.GK19428@n2100.arm.linux.org.uk> <2806018.GHhm6tEuKR@wuerfel> User-Agent: Notmuch/0.21+96~g9bbc54b (http://notmuchmail.org) Emacs/25.0.90.3 (x86_64-pc-linux-gnu) Date: Thu, 28 Apr 2016 17:27:14 +0300 Message-ID: <87vb31kdvh.fsf@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; 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, Arnd Bergmann writes: > On Thursday 28 April 2016 15:16:12 Russell King - ARM Linux wrote: >> On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote: >> >=20 >> > Hi, >> >=20 >> > Arnd Bergmann writes: >> > > pointer and pass that in platform_data. This is really easy, it's >> >=20 >> > Sorry but passing a struct device pointer in platform_data is >> > ridiculous. Not to mention that, as I said before, we can't assume whi= ch >> > device to pass to xhci_plat in the first place. It might be dwc->dev a= nd >> > it might be dwc->dev->parent. >>=20 >> +1. Passing an unref-counted struct device through platform data is >> totally mad, Arnd you're off your rocker if you think that's a good >> idea. What's more is that there's no way to properly refcount the >> thing. > > It's the parent device (or NULL), there is no way it can ever go away as > it's already refcounted through the device subsystem by the creation > of the child device. you're assuming that based on what we have today. We could get into a situation where we need to use a completely unrelated device and the problem exists again. > I do realize that it's a hack, but the idea is to get rid of that > as soon as possibly by fixing the way the xhci device is probe so > we no longer need to fake a platform_device as the child here and > can just use the device itself. okay, let me try to be extra clear here: We will *not* remove the extra platform_device because it actually *does* exist and helps me hide/abstract a bunch of details and make assumptions about order of certain events. We have already gone through that in the past when I explained why I wrote dwc3 the way it is; if you need a refresher, there are mailing list archives for that. Moreover, this same problem exists for anything under drivers/mfd. It just so happens that they're usually some i2c or spi device which don't do DMA by themselves. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJXIh3DAAoJEIaOsuA1yqRE2CUQAI5DsNeo/cAj9NEhJ23TdaAO jrtkaSp79V2bw7WMkKAv5CU+R/ZUtCgan7GPih4xp2l/etDLpJZ/yOzo1wb27Mje LJRAuO9/cCDcAN77fBAbk/ZX/sOZ20WeU7AoKqizRcUW96THllZH+gWftqKkxY2B DHo3NBVpbGtO2+hs48lLYgD2Rh/URzHIOxXoyD2yPO9hdUWbNSjury1fZfXfyxmY 2bRpvQcypfXmGJ0XrsZBFNwCDrlQUb7e1Mc+cwM8CBuKWkvO7KOhcf9JVZXBmZmZ zdIZSAMNkxcf6YECEOpYJklpxtYvUh/iijU6Q+Whn0U4BozXLMpgyWEYNPPIavuC DG5G13F18EmRhTtxzs87dkpwJytpFZVguxRmRQUOM4cbyHSlUtgXDxfZzVyzJxXU Obe3vvUHZhI1TdAgTwXZY7EWGTP8sO0yeO5t1WCG2yOxPMl/VZneTGGrCqRaM6HI 8+ouV8Yr9T7b5JWrDsaup+4tQudK+4iU5nYaAxg1KEeVs0ZGMEoE+RHbs4wLottv eK9lZ+03csvbOySdHPZWZpMcWbYdJMcTXTpHo8R8jnQe4ZkN4gLLEHOPIBKovU1o hKtOpkzzNHDj8qpekiiVhtzm1y4qIcVR+DafAXjY6jDCaksYCyRogsTUAIXFE/Yg /E4s8Jm1GrEDf6GcxOSZ =6Ulr -----END PGP SIGNATURE----- --=-=-=-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@kernel.org (Felipe Balbi) Date: Thu, 28 Apr 2016 17:27:14 +0300 Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <2806018.GHhm6tEuKR@wuerfel> References: <87y47ykzmz.fsf@intel.com> <20160428141611.GK19428@n2100.arm.linux.org.uk> <2806018.GHhm6tEuKR@wuerfel> Message-ID: <87vb31kdvh.fsf@intel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Arnd Bergmann writes: > On Thursday 28 April 2016 15:16:12 Russell King - ARM Linux wrote: >> On Thu, Apr 28, 2016 at 09:37:08AM +0300, Felipe Balbi wrote: >> > >> > Hi, >> > >> > Arnd Bergmann writes: >> > > pointer and pass that in platform_data. This is really easy, it's >> > >> > Sorry but passing a struct device pointer in platform_data is >> > ridiculous. Not to mention that, as I said before, we can't assume which >> > device to pass to xhci_plat in the first place. It might be dwc->dev and >> > it might be dwc->dev->parent. >> >> +1. Passing an unref-counted struct device through platform data is >> totally mad, Arnd you're off your rocker if you think that's a good >> idea. What's more is that there's no way to properly refcount the >> thing. > > It's the parent device (or NULL), there is no way it can ever go away as > it's already refcounted through the device subsystem by the creation > of the child device. you're assuming that based on what we have today. We could get into a situation where we need to use a completely unrelated device and the problem exists again. > I do realize that it's a hack, but the idea is to get rid of that > as soon as possibly by fixing the way the xhci device is probe so > we no longer need to fake a platform_device as the child here and > can just use the device itself. okay, let me try to be extra clear here: We will *not* remove the extra platform_device because it actually *does* exist and helps me hide/abstract a bunch of details and make assumptions about order of certain events. We have already gone through that in the past when I explained why I wrote dwc3 the way it is; if you need a refresher, there are mailing list archives for that. Moreover, this same problem exists for anything under drivers/mfd. It just so happens that they're usually some i2c or spi device which don't do DMA by themselves. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: