From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Burton Subject: Re: [PATCH 01/18] MIPS: lantiq: pass struct device to DMA API functions Date: Thu, 7 Feb 2019 23:29:14 +0000 Message-ID: <20190207232912.wfgejc5c6d6lk5so@pburton-laptop> References: <20190201084801.10983-1-hch@lst.de> <20190201084801.10983-2-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20190201084801.10983-2-hch@lst.de> Content-Language: en-US Content-ID: Sender: linux-kernel-owner@vger.kernel.org To: Christoph Hellwig Cc: John Crispin , Vinod Koul , Dmitry Tarnyagin , Nicolas Ferre , Sudip Mukherjee , Felipe Balbi , "linux-mips@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dmaengine@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-usb@vger.kernel.org" , "linux-fbdev@vger.kernel.org" , "alsa-devel@alsa-project.org" , "iommu@lists.linux-foundation.org" List-Id: iommu@lists.linux-foundation.org Hi Christoph, On Fri, Feb 01, 2019 at 09:47:44AM +0100, Christoph Hellwig wrote: > The DMA API generally relies on a struct device to work properly, and > only barely works without one for legacy reasons. Pass the easily > available struct device from the platform_device to remedy this. >=20 > Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory > allocation, as we aren't in interrupt context or under a lock. >=20 > Note that this whole function looks somewhat bogus given that we never > even look at the returned dma address, and the CPHYSADDR magic on > a returned noncached mapping looks "interesting". But I'll leave > that to people more familiar with the code to sort out. >=20 > Signed-off-by: Christoph Hellwig > --- > arch/mips/lantiq/xway/vmmc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Would you like this to go through the MIPS tree or elsewhere? If the latter: Acked-by: Paul Burton Thanks, Paul