From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752929AbcIBKyH (ORCPT ); Fri, 2 Sep 2016 06:54:07 -0400 Received: from mga11.intel.com ([192.55.52.93]:17239 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752748AbcIBKyF (ORCPT ); Fri, 2 Sep 2016 06:54:05 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,270,1470726000"; d="asc'?scan'208";a="3842343" From: Felipe Balbi To: Arnd Bergmann , Leo Li Cc: Russell King - ARM Linux , 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: <6414695.LEIYfGPUEg@wuerfel> References: <87vb31kdvh.fsf@intel.com> <6414695.LEIYfGPUEg@wuerfel> 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 13:53:36 +0300 Message-ID: <87eg528te7.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 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? > > 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. heh, that looks like an excuse to me :-) This will always be a problem for e.g. MFD, for example. Are you saying MFD child-devices shouldn't be allowed to do DMA? It becomes silly when you read it that way, right? > This used to be simpler back when we could configure the kernel for > only one SoC platform at a time, and the platforms could provide their > own overrides for the dma-mapping interfaces. These days, we rely on right, so we have a very old regression that just took a complex driver such as dwc3 to trigger ;-) > firmware or bootloader to describe various aspects of how DMA is done, there's no DMA description in DT. Every OF device gets the same 32-bit DMA mask and that is, itself, wrong for several devices. > so you can't assume that passing a device without an of_node pointer > or ACPI data into those functions will do the right thing. That's not the problem, however. We can very easily pass along ACPI_COMPANION() to any platform_device we want, but that's not enough because DMA-related bits are passed along with archdata; but archdata isn't generic in any way. Some arches (like x86) _do_ use it for DMA, but some don't. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXyVowAAoJEMy+uJnhGpkGdNwQAN2zlQv0BaG8SjnQ8q3lk/H+ AutMr+YMJN04/BKfyBKssNXBaT2qC6DVc/0b04A/AzxJDOvsmV6HpfJnIbgyS9e4 YRTvI4vwr9bVNV5p4WALxfDx5FZVNmbwoGfv1nZKj9R1TFWaWxnaoXqlb6QRNIlj wOXMB//Rn5vneIf8RZsfjeopeaNEK43gTEBFxvFlZt8r/mgvMXXkhdVyTYo/Embx 3a7SL3YEH5W4cskCf6mhCGQH9lKIOQ+cv8iqHVUoN8ke51qogtbKv8V+wopXBFje LBica/dNjFva/W+oU0ldJP8zjRTm7CB4gFkHFAD62lvveU6KQkoeovIP7JCvkBD5 IzY7u6tMJs1DFTIEKY3GcXTotc8BAiM523Vet1YjOJwVlgBwqThLmw8AWmnz1kp0 wFqtRivl77ZT+4I+YrVZ3Hk2fd8CtQZfHGPt8653mfxdzy0ySBhQwdgtsaB9dKP0 qVBEMoyd8FAAA3mSyPd6pd5DBXdgrlyrsjVYZY0NxsbeMn513mLFP7MbQQGzcGP8 qnNzFU8oDHygQ173XxmrAB2NuqujgJLDu6yxRFBCZbzlKQV6lCux5tsiF80NqWE3 jXplU5tv9lUm9q2gcg58UZvKFzwX170hrJCPqUa2uUI9fGJW+LUVilvBYaTO40aN CUfoayF3hGUDTWa+GOoK =ob01 -----END PGP SIGNATURE----- --=-=-=-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: balbi@kernel.org (Felipe Balbi) Date: Fri, 02 Sep 2016 13:53:36 +0300 Subject: [PATCH] usb: dwc3: host: inherit dma configuration from parent dev In-Reply-To: <6414695.LEIYfGPUEg@wuerfel> References: <87vb31kdvh.fsf@intel.com> <6414695.LEIYfGPUEg@wuerfel> Message-ID: <87eg528te7.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 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. heh, that looks like an excuse to me :-) This will always be a problem for e.g. MFD, for example. Are you saying MFD child-devices shouldn't be allowed to do DMA? It becomes silly when you read it that way, right? > This used to be simpler back when we could configure the kernel for > only one SoC platform at a time, and the platforms could provide their > own overrides for the dma-mapping interfaces. These days, we rely on right, so we have a very old regression that just took a complex driver such as dwc3 to trigger ;-) > firmware or bootloader to describe various aspects of how DMA is done, there's no DMA description in DT. Every OF device gets the same 32-bit DMA mask and that is, itself, wrong for several devices. > so you can't assume that passing a device without an of_node pointer > or ACPI data into those functions will do the right thing. That's not the problem, however. We can very easily pass along ACPI_COMPANION() to any platform_device we want, but that's not enough because DMA-related bits are passed along with archdata; but archdata isn't generic in any way. Some arches (like x86) _do_ use it for DMA, but some don't. -- balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: