From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932129AbcIBM5a (ORCPT ); Fri, 2 Sep 2016 08:57:30 -0400 Received: from mga14.intel.com ([192.55.52.115]:12951 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752964AbcIBM51 (ORCPT ); Fri, 2 Sep 2016 08:57:27 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,270,1470726000"; d="asc'?scan'208";a="4084129" From: Felipe Balbi To: Robin Murphy , Arnd Bergmann , Leo Li Cc: 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: <956cf653-973a-3bfd-9aaa-bdc922995ea6@arm.com> References: <87vb31kdvh.fsf@intel.com> <6414695.LEIYfGPUEg@wuerfel> <87eg528te7.fsf@linux.intel.com> <956cf653-973a-3bfd-9aaa-bdc922995ea6@arm.com> 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 15:56:53 +0300 Message-ID: <87wpiu794a.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, Robin Murphy writes: >>>> 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. >>=20 >> heh, that looks like an excuse to me :-) >>=20 >> 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? >>=20 >>> 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 >>=20 >> right, so we have a very old regression that just took a complex driver >> such as dwc3 to trigger ;-) >>=20 >>> firmware or bootloader to describe various aspects of how DMA is done, >>=20 >> 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. > > Huh? There's only no DMA description in DT if the device can be assumed > to be happy with the defaults. Anything else should be using > "dma-ranges", "dma-coherent", etc. to describe non-default integration heh, guilty as charged. I never noticed we had dma-ranges or dma-coherent. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXyXcVAAoJEMy+uJnhGpkGZn4P/RYuVF/1EJtmj+a0i14CnJIt 2Fd6LNMWIQF/MGAwux+G25r3+dS7a6oS4SokCgwR6FpIgYQxFfx3Yy+PVLyKNGkB k0Q9Qk7Co3fnG5w3BEmfm9t09LNl9mpxy4wYlDU0NxY3I/d97rdBXoFBKdRTWLSk in17lyIfEt2DfPj1DLh6WgI83KniRXrjogK2X2sc5oj9aO9KByCy3elyrImBx7F0 a9Ob0u1xZnpo0Al2yYv5a8Pju4QC6oMjxAJYHWd05k35DKWhL4oU9+yskTcTgdSu Uwlkz/PH388qBKoL6gMTs3z/o37mL6gcYiqdyec/iLjZ+ZWE5TDbDevJWqlRfK/z Yyj/FvHs9V5puG5hAKO/WFYfVirdRBNw1CZSwpd8v8W05lhGr/O6rM6nRGLUUBl8 DWzDS30fty9MUlm2bbJEdumWj4ZNh31WK/x00Gud5s6ZfwiU+PAnaWenwu9frVy6 FZ2q/0Dy27lzThQxfaPAeypPl9ueUP5yacIt7mq0sJATqNETHMDE3QsFcQW8I4NV wX9uz0JeA/UqcD4Py/whkFIQeNxIi2Xoh26WEZLIgu31VU3YemesYYRKA19nyLRi e1KwxBEreQjzN8kEj/MU/CLD5vQgYlSPnm3wF9kihz9fsIFjpc24kY0Ty7cGDtIm SG0RoB6wg8Utt5oypj/Z =C32k -----END PGP SIGNATURE----- --=-=-=--