From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965642AbcIHJnp (ORCPT ); Thu, 8 Sep 2016 05:43:45 -0400 Received: from mga09.intel.com ([134.134.136.24]:26069 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752804AbcIHJnn (ORCPT ); Thu, 8 Sep 2016 05:43:43 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,300,1470726000"; d="asc'?scan'208";a="5845447" 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: <2733202.7lpFC7RnDm@wuerfel> References: <6739240.VDAnDBppH0@wuerfel> <87y432iylr.fsf@linux.intel.com> <2733202.7lpFC7RnDm@wuerfel> User-Agent: Notmuch/0.22.1+63~g994277e (https://notmuchmail.org) Emacs/25.1.3 (x86_64-pc-linux-gnu) Date: Thu, 08 Sep 2016 12:43:06 +0300 Message-ID: <87lgz2iv6d.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, Arnd Bergmann writes: > On Thursday, September 8, 2016 11:29:04 AM CEST Felipe Balbi wrote: >> > If we do that, we have to put child devices of the dwc3 devices into >> > the platform glue, and it also breaks those dwc3 devices that don't >> > have a parent driver. >>=20 >> Well, this is easy to fix: >>=20 >> if (dwc->dev->parent) { >> dwc->sysdev =3D dwc->dev->parent; >> } else { >> dev_info(dwc->dev, "Please provide a glue layer!\n"); >> dwc->sysdev =3D dwc->dev; >> } > > I don't understand. Do you mean we should have an extra level of > stacking and splitting "static struct platform_driver dwc3_driver" > in two so instead of > > "qcom,dwc3" -> "snps,dwc3" (usb_bus.sysdev) -> "xhci" (usb_bus.dev) > > we do this? > > "qcom,dwc3" -> "snps,dwc3" (usb_bus.sysdev) -> "dwc3-glue" -> "xhci" (us= b_bus.dev) no :-) If we have a parent device, use that as sysdev, otherwise use self as sysdev. > That sounds a bit clumsy for the sake of consistency with PCI. > The advantage is that xhci can always use the grandparent device > as sysdev whenever it isn't probed through PCI or firmware > itself, but the purpose of the dwc3-glue is otherwise questionable. > > How about adding a 'compatible=3D"snps,dwc3-pci"' property for the dwc3 > device when that is created from the PCI driver and checking for that > with the device property interface instead? If it's "snps,dwc3" > we use the device itself while for "snps,dwc3-pci", we use the parent? Any reason why we wouldn't use e.g. dwc3-omap.dev as sysdev? =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJX0TKqAAoJEMy+uJnhGpkG86IP/RzRoFGHFhh/j6kP2moX10t7 dOsWPtZVkDUvWjcTUpDgmyN9or4mq9LvGwoDhSXpeRzkh+oH0oL6u+C0+KF/Tfmv cD6t03Ahv0ldjBuYj6ZSOrZBGf5+OTHXUNTxy5A65zd7rw7G7nSVWKMtUEore+8Y 4rrFRn+WnJsOId7xFm5uAHBKwWjnqJMVjXYm+nBArKFQ7qrumQ45y4nQwZrqd/e3 4uSsafDMTsf4KZ/EEk6xf82avnjL4l/gcWY3Xjf692dVxfOe+DF4279EAu6AiQGN lSFXiDHLVS5O3mzl30zoRdwNeP/a73Ayg1hQGGVWiPjVqDDueiMoZtT9cpVsuEgz +XIP6c8jwVa3E9avrOMOdJ9rWxWho/bEwGvWdf6L3Q3N6CcdB5AeWpPmkxEulEOV hLkI5XJTxKxO0/1PFKVzbtnteTBHGX3HhUJ3kcqZ+aBJVsA1oPoPqZ6QbxTOzrkd mLbUaaEkHkmUmf8ZLFg6bnd8UlpqYC9nl3LXQizMGX5kl74Xj0HBqI4fZyJ/1A6y sr+j79yW0ZNKjhRRJ7waDhIP8fq3JnQEt6nHoZFfQTNl3vcz1Q4SH825AGvvaYls HK3zIftw2t1/Yw/vdwgnBJxZ2i2naROVcycW2EDJeAPHd3hrmvYu8yFnu4r7vpqc RmiOUwkAA+XuY2qoS+tz =5e/w -----END PGP SIGNATURE----- --=-=-=-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@kernel.org (Felipe Balbi) Date: Thu, 08 Sep 2016 12:43:06 +0300 Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <2733202.7lpFC7RnDm@wuerfel> References: <6739240.VDAnDBppH0@wuerfel> <87y432iylr.fsf@linux.intel.com> <2733202.7lpFC7RnDm@wuerfel> Message-ID: <87lgz2iv6d.fsf@linux.intel.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, Arnd Bergmann writes: > On Thursday, September 8, 2016 11:29:04 AM CEST Felipe Balbi wrote: >> > If we do that, we have to put child devices of the dwc3 devices into >> > the platform glue, and it also breaks those dwc3 devices that don't >> > have a parent driver. >> >> Well, this is easy to fix: >> >> if (dwc->dev->parent) { >> dwc->sysdev = dwc->dev->parent; >> } else { >> dev_info(dwc->dev, "Please provide a glue layer!\n"); >> dwc->sysdev = dwc->dev; >> } > > I don't understand. Do you mean we should have an extra level of > stacking and splitting "static struct platform_driver dwc3_driver" > in two so instead of > > "qcom,dwc3" -> "snps,dwc3" (usb_bus.sysdev) -> "xhci" (usb_bus.dev) > > we do this? > > "qcom,dwc3" -> "snps,dwc3" (usb_bus.sysdev) -> "dwc3-glue" -> "xhci" (usb_bus.dev) no :-) If we have a parent device, use that as sysdev, otherwise use self as sysdev. > That sounds a bit clumsy for the sake of consistency with PCI. > The advantage is that xhci can always use the grandparent device > as sysdev whenever it isn't probed through PCI or firmware > itself, but the purpose of the dwc3-glue is otherwise questionable. > > How about adding a 'compatible="snps,dwc3-pci"' property for the dwc3 > device when that is created from the PCI driver and checking for that > with the device property interface instead? If it's "snps,dwc3" > we use the device itself while for "snps,dwc3-pci", we use the parent? Any reason why we wouldn't use e.g. dwc3-omap.dev as sysdev? -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: