Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp405670ima; Fri, 1 Feb 2019 05:16:34 -0800 (PST) X-Google-Smtp-Source: ALg8bN74lXM4NGin0bw90pjmM1MRpPjdDK1OwJKfWcmSYyZfiiXk8p21TgtwLeX5rBHuiPiO6zRD X-Received: by 2002:a62:4641:: with SMTP id t62mr38900606pfa.141.1549026994263; Fri, 01 Feb 2019 05:16:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549026994; cv=none; d=google.com; s=arc-20160816; b=YjvgBBoDeDv1t/qG/7gVW+hi6jfQlceM+uErSnFIGKqMfeJiFyjrBWLDcfyS1euFtj Obt+zx2SiTNw11j/Z38Y7ApjxdAUFGKlHOcCSzlOd0mGrqInHLupJ4xYDV1FpC8xpDij CdfNepgh0ooqGo0F8o9KQhcQE93ICsXn/nNBp8BSeyQvpRcV3av1aSgftz3lm8FIQmoo 0mSY5Hv/fWSl0bu/D+BGryFqGC97xeJhituSUGjF06zTiPR/j5dZ3Qk+wTioZNojDlHj F1nBeImcYnC5FjxY1BAcaF9A9jNM23hwvdXIyjPFci+5VNJiskMNQ8o9+gqC3/rlFp20 IyCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:subject:cc:to:from:message-id:date; bh=PTWIVE6V4C6ryPTepQl/apO2vp2K45kBkzv1Ivtg6As=; b=fmUYRe4Y21Iy1uMt8IhO2VQ8mByDJ2hTAHe0Ia06yQWpEy6WO1MiqYsUaopMhfV/g2 WbWoDJLiCHYkpe+uGV8KcclDPS62n8DJqMJvNfs7aTzcAf6MzFU734Nw2cuK0WXQZWNo YecTcqYyCFu2gVUH9T/lv7QkE2AfCCzlIJ2rynxCLIKWJX8oj9FNBjfp702dW+Xs5Beu g8rHceFpTBeUKxWIZ5Qsj/CZ6X1K8TSRRgHI2PvJ/3HSVKFcD0Yj73ePuSVvhdlusy82 Ao6wzJg66XFmUMt9VTAQF7adaWcBNPSH6qK1wxOW6SnNv7vKXuWawhy2aLhzlajIvN+b Rd6w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a13si1608971pgb.412.2019.02.01.05.16.19; Fri, 01 Feb 2019 05:16:34 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730140AbfBANNG (ORCPT + 99 others); Fri, 1 Feb 2019 08:13:06 -0500 Received: from mx2.suse.de ([195.135.220.15]:37672 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726734AbfBANNG (ORCPT ); Fri, 1 Feb 2019 08:13:06 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 5EC4FACA9; Fri, 1 Feb 2019 13:13:04 +0000 (UTC) Date: Fri, 01 Feb 2019 14:13:04 +0100 Message-ID: From: Takashi Iwai 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 Subject: Re: [alsa-devel] [PATCH 18/18] ALSA: pass struct device to DMA API functions In-Reply-To: <20190201084801.10983-19-hch@lst.de> References: <20190201084801.10983-1-hch@lst.de> <20190201084801.10983-19-hch@lst.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 01 Feb 2019 09:48:01 +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. > > Also use GFP_KERNEL instead of GFP_USER as the gfp_t for the memory > allocation, as we should treat this allocation as a normal kernel one. > > Signed-off-by: Christoph Hellwig Reviewed-by: Takashi Iwai thanks, Takashi