From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67422C7618F for ; Tue, 16 Jul 2019 15:10:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 398B82173E for ; Tue, 16 Jul 2019 15:10:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563289819; bh=qsVYG/AAKfZqvM/AL48HHkboJVYj6AAMTA3FfuN1840=; h=Subject:To:Cc:References:From:Date:In-Reply-To:List-ID:From; b=0Zc2EH0y1JDGfEGuaqaDxAsp7YrxTxphemZ7wQefG0a+VQ3qh1ljntiYTsZ2R/FYQ 6NV9Pj7uZt4iTdpEWYrHfuJF9S8RthkZ3gVKEduqxI1RgszwyEE7t/YsKGg6mOTguF NYFOYA/u2M2smWV+BI1iUAewH8nQesCDPRP/oRKk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728817AbfGPPKT (ORCPT ); Tue, 16 Jul 2019 11:10:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:38654 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728384AbfGPPKS (ORCPT ); Tue, 16 Jul 2019 11:10:18 -0400 Received: from [10.84.150.84] (unknown [167.220.148.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D79052173B; Tue, 16 Jul 2019 15:10:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563289817; bh=qsVYG/AAKfZqvM/AL48HHkboJVYj6AAMTA3FfuN1840=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cA0qN5tFZBu+I0MkNLY1rdU6KqOdCmjmgBZqfB3AYRCy+6Cx+1bm4YhjQvkbyzmvD HunhvZyLo8l2aLhfLvSgNC/rgeU95ST08kkJkAJB5nUfQk3aTdvW70dMweVgXFYDcf TC4WiUmbxp4t1zcUxnICgEl+WIfag5taN+tPq2p8= Subject: Re: [PATCH v3 04/24] dmaengine: qcom_hidma: Remove call to memset after dmam_alloc_coherent To: Robin Murphy , 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> <9ea5f97f-5963-5836-6ab2-dc30628c6820@arm.com> From: Sinan Kaya Openpgp: preference=signencrypt Autocrypt: addr=okaya@kernel.org; keydata= mQENBFrnOrUBCADGOL0kF21B6ogpOkuYvz6bUjO7NU99PKhXx1MfK/AzK+SFgxJF7dMluoF6 uT47bU7zb7HqACH6itTgSSiJeSoq86jYoq5s4JOyaj0/18Hf3/YBah7AOuwk6LtV3EftQIhw 9vXqCnBwP/nID6PQ685zl3vH68yzF6FVNwbDagxUz/gMiQh7scHvVCjiqkJ+qu/36JgtTYYw 8lGWRcto6gr0eTF8Wd8f81wspmUHGsFdN/xPsZPKMw6/on9oOj3AidcR3P9EdLY4qQyjvcNC V9cL9b5I/Ud9ghPwW4QkM7uhYqQDyh3SwgEFudc+/RsDuxjVlg9CFnGhS0nPXR89SaQZABEB AAG0HVNpbmFuIEtheWEgPG9rYXlhQGtlcm5lbC5vcmc+iQFOBBMBCAA4FiEEYdOlMSE+a7/c ckrQvGF4I+4LAFcFAlztcAoCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQvGF4I+4L AFfidAf/VKHInxep0Z96iYkIq42432HTZUrxNzG9IWk4HN7c3vTJKv2W+b9pgvBF1SmkyQSy 8SJ3Zd98CO6FOHA1FigFyZahVsme+T0GsS3/OF1kjrtMktoREr8t0rK0yKpCTYVdlkHadxmR Qs5xLzW1RqKlrNigKHI2yhgpMwrpzS+67F1biT41227sqFzW9urEl/jqGJXaB6GV+SRKSHN+ ubWXgE1NkmfAMeyJPKojNT7ReL6eh3BNB/Xh1vQJew+AE50EP7o36UXghoUktnx6cTkge0ZS qgxuhN33cCOU36pWQhPqVSlLTZQJVxuCmlaHbYWvye7bBOhmiuNKhOzb3FcgT7kBDQRa5zq1 AQgAyRq/7JZKOyB8wRx6fHE0nb31P75kCnL3oE+smKW/sOcIQDV3C7mZKLf472MWB1xdr4Tm eXeL/wT0QHapLn5M5wWghC80YvjjdolHnlq9QlYVtvl1ocAC28y43tKJfklhHiwMNDJfdZbw 9lQ2h+7nccFWASNUu9cqZOABLvJcgLnfdDpnSzOye09VVlKr3NHgRyRZa7me/oFJCxrJlKAl 2hllRLt0yV08o7i14+qmvxI2EKLX9zJfJ2rGWLTVe3EJBnCsQPDzAUVYSnTtqELu2AGzvDiM gatRaosnzhvvEK+kCuXuCuZlRWP7pWSHqFFuYq596RRG5hNGLbmVFZrCxQARAQABiQEfBBgB CAAJBQJa5zq1AhsMAAoJELxheCPuCwBX2UYH/2kkMC4mImvoClrmcMsNGijcZHdDlz8NFfCI gSb3NHkarnA7uAg8KJuaHUwBMk3kBhv2BGPLcmAknzBIehbZ284W7u3DT9o1Y5g+LDyx8RIi e7pnMcC+bE2IJExCVf2p3PB1tDBBdLEYJoyFz/XpdDjZ8aVls/pIyrq+mqo5LuuhWfZzPPec 9EiM2eXpJw+Rz+vKjSt1YIhg46YbdZrDM2FGrt9ve3YaM5H0lzJgq/JQPKFdbd5MB0X37Qc+ 2m/A9u9SFnOovA42DgXUyC2cSbIJdPWOK9PnzfXqF3sX9Aol2eLUmQuLpThJtq5EHu6FzJ7Y L+s0nPaNMKwv/Xhhm6Y= Message-ID: Date: Tue, 16 Jul 2019 11:10:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <9ea5f97f-5963-5836-6ab2-dc30628c6820@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org On 7/16/2019 7:35 AM, Robin Murphy wrote: > 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. Thanks for confirming the behavior for arm64 arch. Acked-by: Sinan Kaya From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D86AFC7618F for ; Tue, 16 Jul 2019 15:10:23 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B20D42173C for ; Tue, 16 Jul 2019 15:10:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="BlyBlStA"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="cA0qN5tF" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B20D42173C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=rrRRD7BGg9M4rWD58g96LTHL2PNnphaDOsi3aFlwu8A=; b=BlyBlStAREnotU tIbFVPsEwNTDyUg1VJvJZvTOTsdJ8AaWapwSdykk12hqokVKESPCjMmA7LH4H4RMXcZSsx0Jakw/h A/ATkZMF49LhJdOPBh4ZJXWUxc5ZUwX39nUhbqgQqO3OKVHP9EzLQ+iRO1RlP0F8BFaDHzXUjMe3i STlu5TxUxXFtjTwTqd/glmBhMWbMyhXam6zBd9Es3EuBo/STg5yI2jDRbjw9606y08mol1Z/zYiE3 iofBT1MIm1/MXkCnQG0sRmk3zijF9rx4F1ALNx1mqcLe3aOQG6CF/roiLpEWe+Esm3o/7AsTRt0H4 TydmBkYP4if5RkPtYe3A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hnP5w-0001O0-QX; Tue, 16 Jul 2019 15:10:20 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hnP5u-0001Nd-9u for linux-arm-kernel@lists.infradead.org; Tue, 16 Jul 2019 15:10:19 +0000 Received: from [10.84.150.84] (unknown [167.220.148.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D79052173B; Tue, 16 Jul 2019 15:10:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563289817; bh=qsVYG/AAKfZqvM/AL48HHkboJVYj6AAMTA3FfuN1840=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cA0qN5tFZBu+I0MkNLY1rdU6KqOdCmjmgBZqfB3AYRCy+6Cx+1bm4YhjQvkbyzmvD HunhvZyLo8l2aLhfLvSgNC/rgeU95ST08kkJkAJB5nUfQk3aTdvW70dMweVgXFYDcf TC4WiUmbxp4t1zcUxnICgEl+WIfag5taN+tPq2p8= Subject: Re: [PATCH v3 04/24] dmaengine: qcom_hidma: Remove call to memset after dmam_alloc_coherent To: Robin Murphy , Fuqian Huang References: <20190715031723.6375-1-huangfq.daxian@gmail.com> <72c45b14-f0c0-9d1c-0953-eea70ce513a0@kernel.org> <245ffd79-316c-e985-d1da-2ccea6d29636@kernel.org> <9ea5f97f-5963-5836-6ab2-dc30628c6820@arm.com> From: Sinan Kaya Openpgp: preference=signencrypt Autocrypt: addr=okaya@kernel.org; keydata= mQENBFrnOrUBCADGOL0kF21B6ogpOkuYvz6bUjO7NU99PKhXx1MfK/AzK+SFgxJF7dMluoF6 uT47bU7zb7HqACH6itTgSSiJeSoq86jYoq5s4JOyaj0/18Hf3/YBah7AOuwk6LtV3EftQIhw 9vXqCnBwP/nID6PQ685zl3vH68yzF6FVNwbDagxUz/gMiQh7scHvVCjiqkJ+qu/36JgtTYYw 8lGWRcto6gr0eTF8Wd8f81wspmUHGsFdN/xPsZPKMw6/on9oOj3AidcR3P9EdLY4qQyjvcNC V9cL9b5I/Ud9ghPwW4QkM7uhYqQDyh3SwgEFudc+/RsDuxjVlg9CFnGhS0nPXR89SaQZABEB AAG0HVNpbmFuIEtheWEgPG9rYXlhQGtlcm5lbC5vcmc+iQFOBBMBCAA4FiEEYdOlMSE+a7/c ckrQvGF4I+4LAFcFAlztcAoCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQvGF4I+4L AFfidAf/VKHInxep0Z96iYkIq42432HTZUrxNzG9IWk4HN7c3vTJKv2W+b9pgvBF1SmkyQSy 8SJ3Zd98CO6FOHA1FigFyZahVsme+T0GsS3/OF1kjrtMktoREr8t0rK0yKpCTYVdlkHadxmR Qs5xLzW1RqKlrNigKHI2yhgpMwrpzS+67F1biT41227sqFzW9urEl/jqGJXaB6GV+SRKSHN+ ubWXgE1NkmfAMeyJPKojNT7ReL6eh3BNB/Xh1vQJew+AE50EP7o36UXghoUktnx6cTkge0ZS qgxuhN33cCOU36pWQhPqVSlLTZQJVxuCmlaHbYWvye7bBOhmiuNKhOzb3FcgT7kBDQRa5zq1 AQgAyRq/7JZKOyB8wRx6fHE0nb31P75kCnL3oE+smKW/sOcIQDV3C7mZKLf472MWB1xdr4Tm eXeL/wT0QHapLn5M5wWghC80YvjjdolHnlq9QlYVtvl1ocAC28y43tKJfklhHiwMNDJfdZbw 9lQ2h+7nccFWASNUu9cqZOABLvJcgLnfdDpnSzOye09VVlKr3NHgRyRZa7me/oFJCxrJlKAl 2hllRLt0yV08o7i14+qmvxI2EKLX9zJfJ2rGWLTVe3EJBnCsQPDzAUVYSnTtqELu2AGzvDiM gatRaosnzhvvEK+kCuXuCuZlRWP7pWSHqFFuYq596RRG5hNGLbmVFZrCxQARAQABiQEfBBgB CAAJBQJa5zq1AhsMAAoJELxheCPuCwBX2UYH/2kkMC4mImvoClrmcMsNGijcZHdDlz8NFfCI gSb3NHkarnA7uAg8KJuaHUwBMk3kBhv2BGPLcmAknzBIehbZ284W7u3DT9o1Y5g+LDyx8RIi e7pnMcC+bE2IJExCVf2p3PB1tDBBdLEYJoyFz/XpdDjZ8aVls/pIyrq+mqo5LuuhWfZzPPec 9EiM2eXpJw+Rz+vKjSt1YIhg46YbdZrDM2FGrt9ve3YaM5H0lzJgq/JQPKFdbd5MB0X37Qc+ 2m/A9u9SFnOovA42DgXUyC2cSbIJdPWOK9PnzfXqF3sX9Aol2eLUmQuLpThJtq5EHu6FzJ7Y L+s0nPaNMKwv/Xhhm6Y= Message-ID: Date: Tue, 16 Jul 2019 11:10:15 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <9ea5f97f-5963-5836-6ab2-dc30628c6820@arm.com> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190716_081018_381342_B29C88AE X-CRM114-Status: GOOD ( 12.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arm-msm@vger.kernel.org, Linux Kernel Mailing List , Christoph Hellwig , David Brown , Vinod Koul , Andy Gross , dmaengine@vger.kernel.org, linux-arm Mailing List Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 7/16/2019 7:35 AM, Robin Murphy wrote: > 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. Thanks for confirming the behavior for arm64 arch. Acked-by: Sinan Kaya _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel