Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935867AbcCQPxp (ORCPT ); Thu, 17 Mar 2016 11:53:45 -0400 Received: from mout.kundenserver.de ([212.227.126.133]:59488 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934944AbcCQPxm (ORCPT ); Thu, 17 Mar 2016 11:53:42 -0400 From: Arnd Bergmann To: Peter Chen Cc: Li Yang , Bjorn Andersson , Peter Chen , Greg Kroah-Hartman , Rajesh Bhagat , "linux-usb@vger.kernel.org" , lkml , Srinivas Kandagatla , linux-arm-msm , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT Date: Thu, 17 Mar 2016 16:52:55 +0100 Message-ID: <3240370.XdEELlSA8f@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160314105108.GB2131@shlinux2.ap.freescale.net> References: <1456119133-16114-1-git-send-email-bjorn.andersson@linaro.org> <20160314105108.GB2131@shlinux2.ap.freescale.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:Yvq9zj6/OdEqqWkJcUeOvZ4O/HgI+qNjouuJigEQ8Dm5XkRroPF SGuVYnrHefrHxmiHF+a4p7jvHcLFZ26wp41/+ICLmoAwohnHFlwG5UFaTxTTpJ3d++IxciR uFtU6OrmDRDsyBPhqgFMei2bZC+AIQ3sQTDbDVOMDXVlGj3bRz11kNc6HYUswuasnYYrE6g KC6YAKVQoPbshY2tNcQHQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:13Bcz4CaQ8U=:PEl2/RoKBNBnyl67JnB0MZ Vf3JforCDhe+JRtqvOpSYYNy4lS4g3toI5giCS9Z1xsiYjuM1dgj4DCb+fYk3WKrSrLeppjDn 8eT5Hp5Aq97eAfuyjb1ME3iVlD2yCTrWMcxM5+KyXwTJ1Z7c39o28tYznYDUrhAF7WNjfn/nF J/Ql3WlDoOsNURyc2fjaZceHFLonVjukmgg9nLM89FuxOkb0ItnpaAfKiYioc7Z3ZyGCWmP77 x9W2vqV08wmmodb2bohOWQw6HTsHg0SBJPF3W8VIOjlAfo39TfigjA0/505ZjqbQ7MNFoiSp6 c7VuccNCW9q4mCQqhRFPmvrlIY89P10xLGbTa644MQuWbuUzC6Mlb75zvgOHkMmJTl9c+xRdF 8loDOzW7jOH4XJes7Zg060Y5iGQ226RTMkqgAze4n/ErFIvY+W3vTZ9SDbRn2v9eDlILKT5DU qLoAVLx2crM/FY4X2COEI6HZEyH7q0/wv5zpP+j77ic0mjfvAEFyTuxvNUNhIpEzYNdPi2ff0 /1EEnkeItuebygvs1PWVKVIrU3iw8YxhCX+XLP/Jy/PkL1nSZA2kObNZCVywvv0p3LTI4dXno MKgQGKhX3RuJFMF+CD8VN2+InVwP/yY7uLHpniFc+A0fAqztqG9EOKZSQk/IykU3lLeOgCzqx XywgBOc7aQ4EYWuvfXqEH5qTIIgv8FYol7f0+jIjgL+XwnWkbSq5N8EcG2moVlevqhF97RSaW QP+i2yuOeStBWrb7 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2409 Lines: 51 On Monday 14 March 2016 18:51:08 Peter Chen wrote: > On Wed, Mar 09, 2016 at 05:16:50PM -0600, Li Yang wrote: > > On Tue, Mar 8, 2016 at 9:40 PM, Bjorn Andersson > > wrote: > > > On Tue, Mar 8, 2016 at 11:52 AM, Li Yang wrote: > > >> On Wed, Mar 2, 2016 at 4:59 PM, Li Yang wrote: > > >>> On Mon, Feb 22, 2016 at 4:07 PM, Bjorn Andersson > > >>> wrote: > > >>>> On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote: > > > > > > I had the chance to go through this with Arnd and the verdict is that > > > devices not described in DT should not do DMA (or allocate buffers for > > > doing DMA). > > > > > > So I believe the solution is to fall back on Peter's description; the > > > chipidea driver is the core driver and the Qualcomm code should just > > > be a platform layer. > > > > > > My suggestion is that we turn the chipidea core into a set of APIs > > > that can called by the platform specific pieces. That way we will have > > > the chipidea core be the device described in the DT. > > > > But like I said, this problem is not just existing for chipidea > > driver. We already found that the dwc3 driver is also suffering from > > the same issue. I don't know how many other drivers are impacted by > > this change, but I suspect there will be some. A grep of > > platform_device_add() in driver/ directory returns many possible > > drivers to be impacted. As far as I know, the > > drivers/net/ethernet/freescale/fman/mac.c is registering child > > ethernet devices that definitely will do dma. If you want to do this > > kind of rework to all these drivers, it will be a really big effort. > > > > +1 > > Yes, I think this DMA things should be covered by driver core too. > I don't think it's a very widespread problem, there are only very few developers that intentionally use this method, and some use the platform_device_register_full() call to create a device with a known mask, which is generally ok for the limited case where the driver is only ever going to run on a single platform, but not in the more general case that of_dma_configure is designed to handle. I think we should fix the drivers to consistently use the device that was created by the platform (DT or ACPI or board file) to pass that into the DMA API, anything else will just cause more subtle bugs. Arnd