Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp740626ybi; Tue, 16 Jul 2019 04:36:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqwi3G9JymDG4eKYxzCpm3UlFWJMhufd1nMhkPopHHlnTDTaC2QCOH3OKJiAi9Lxha48NE9w X-Received: by 2002:a17:902:a612:: with SMTP id u18mr33597807plq.181.1563276988853; Tue, 16 Jul 2019 04:36:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563276988; cv=none; d=google.com; s=arc-20160816; b=jYYd4aE7UdHF3cQqGEBTExdu+oWT7Ki/5c+y4+Y+hAA/I8bCEI2mlmsQ7VfY1MGo3A Dg7OBNWPqLBic5vQDBI+L1nSWBz0B+hckibZnSo5w0Ax9CJfrn675XBMI6YnSOZc5LpI i4OJkn7CtNS23Pqqwn+z3fCkBBlnTMrvfoTto5+E2fyFlrR05r7xShgxK/nJKiuY1l4G gDUfjdC2jsb+EujWs1UDjb6DKRpphlxlSmYUVCtB+HlgWf7zLrmtXSzZ2hPA1MpMbUGr mnUShcE/oKFzm+psKdeVDmfXCI7W0hiow3ltEL06b5/7sCpRe7N3veCSM8DdlxRbJ9tJ tDKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=CP7OiTouUM0ynfsqDfyd02heKob30iRxf8HdphzMZjA=; b=b0TaXg6H7gzv1UrxPcws1JA0RigHnhVa4hVaf6uslge5XXVd4CTQThqRHga8GxXXFz Q8PfUEyaJLpqSd8fUodgE+5wbuJzZaiq4kTMQdoVfFloKAXw0XIRXfIpwN3lVLBJOzn4 TgmSbsqptezisNS6FllZowIABkb9rCgbBUIit5Zs2dIWvS5dyadytZDl2jjFFRhCku62 qxcRpoKLz44mxgnERLeEVP72YbBQ/W7xEUEpcImF2rkm/LtWv498BCNAxiiDkPGTA5OJ /tggDVKeRZzDg2gtvktbDZDC+tzZD99LgmcNezoWX+8xyNBfCzTG/rYi2ua4joupmJPS bNIQ== 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 cu6si18005659pjb.102.2019.07.16.04.36.11; Tue, 16 Jul 2019 04:36:28 -0700 (PDT) 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 S2387686AbfGPLfI (ORCPT + 99 others); Tue, 16 Jul 2019 07:35:08 -0400 Received: from foss.arm.com ([217.140.110.172]:33286 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733067AbfGPLfI (ORCPT ); Tue, 16 Jul 2019 07:35:08 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EC6AC2B; Tue, 16 Jul 2019 04:35:07 -0700 (PDT) Received: from [10.1.197.57] (e110467-lin.cambridge.arm.com [10.1.197.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id AD30B3F71A; Tue, 16 Jul 2019 04:35:06 -0700 (PDT) Subject: Re: [PATCH v3 04/24] dmaengine: qcom_hidma: Remove call to memset after dmam_alloc_coherent To: Sinan Kaya , Fuqian Huang Cc: Andy Gross , David Brown , Vinod Koul , linux-arm Mailing List , linux-arm-msm@vger.kernel.org, dmaengine@vger.kernel.org, Linux Kernel Mailing List , Christoph Hellwig References: <20190715031723.6375-1-huangfq.daxian@gmail.com> <72c45b14-f0c0-9d1c-0953-eea70ce513a0@kernel.org> <245ffd79-316c-e985-d1da-2ccea6d29636@kernel.org> From: Robin Murphy Message-ID: <9ea5f97f-5963-5836-6ab2-dc30628c6820@arm.com> Date: Tue, 16 Jul 2019 12:35:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <245ffd79-316c-e985-d1da-2ccea6d29636@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/07/2019 16:17, Sinan Kaya wrote: > On 7/15/2019 1:43 AM, Fuqian Huang wrote: >> Should I rewrite the commit log? Just mention that dma_alloc_coherent >> has already >> zeroed the memory and not to reference the commit? > > I'd like to hear from Robin Murphy that arm smmu driver follows this as > well. I'd be lying if I said it did. ...but only because that's never been part of the SMMU driver's responsibility either way. The iommu-dma layer however, and thus the respective arm64 iommu_dma_ops, has always zeroed allocations right from its inception. 518a2f1925c3 was just cleaning up the last of the stragglers which *weren't* already clearing buffers anyway, such that we could formalise that behaviour into the API. Robin.