Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3445239ybg; Mon, 28 Oct 2019 12:58:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqyVPNVtpyFe8BIQtSN+wjkqoqQQ60AouDZ1HfrpMCdrS9pvEzPDkJ9+HNa3nYpQb9HavSb/ X-Received: by 2002:a50:a9e3:: with SMTP id n90mr3831353edc.52.1572292696973; Mon, 28 Oct 2019 12:58:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572292696; cv=none; d=google.com; s=arc-20160816; b=aX1LLAgRqyZG0x6jHWA6bJjs962J9YTyoMVj5PWqru5tIuf118tOg+qBcu+rGHPZId 4hGHcveDc87CikTT8Y88kQWHBEOSUioAn1/fOncpnd2KKJVNuOAi1JHDjDXNI8LvGTKd ggfKfaNlfbWewg3ClCR9hMmF9+PmDnhqHxob4f9O0dYh9sNRPfD+YBzfTrJxvoVGQWBg Wu1N008HkJJV5EEkl2XvS5zAdtlUSYevu3Ah1CLARqN33WHWl/RCrPm9PZd4vijOS9Sm eYDhIMPsNzMWX+YBbBW7Hr05RCT7LQVjfuQCZqEK/jYAUWKoAGqVeYwFNRoleG9J9Dka +Ehw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=t+L/+hZtFDkbEchunYet4Shz1r5PLYeHXScDyub4pus=; b=MEDf0mIWu4/GEGZ7Lzf/4722Yc2UQiQb9J/mJs4L2LSQzRrNaN/lci7+ntuG90h1mU YP5nvXNZUCo5tKF1tl7a6vPiHJFAiHEYpgLt5g8H2wLaDAliFFMefMD/v2dlhMORZBdF 5A+iKWP9tzNCvYmtMP+sBiymJzTUp/vaQoHr6j+w2n+TOgTnx/LsNeEXdelytZkM3m25 /FahpC/FUDCuBnvNfTMFYVy0ywOe+/HsCsXN/SvjeFuhuRnFNqnQJ8JmNJP4x/81nG4U tUCHT/4sT3xZ63k53801uVc4vqEJyEftxoq6Df7cUbgczGm720eNK9EsroGITlDRD08x JJzA== 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 s10si6911316ejq.255.2019.10.28.12.57.53; Mon, 28 Oct 2019 12:58:16 -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 S2388518AbfJ1LiT (ORCPT + 99 others); Mon, 28 Oct 2019 07:38:19 -0400 Received: from verein.lst.de ([213.95.11.211]:34037 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726463AbfJ1LiS (ORCPT ); Mon, 28 Oct 2019 07:38:18 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id C917068BE1; Mon, 28 Oct 2019 12:38:16 +0100 (CET) Date: Mon, 28 Oct 2019 12:38:16 +0100 From: "hch@lst.de" To: Laurentiu Tudor Cc: Jonathan Lemon , "hch@lst.de" , "joro@8bytes.org" , Ioana Ciocoi Radulescu , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "netdev@vger.kernel.org" , Ioana Ciornei , Leo Li , "robin.murphy@arm.com" , Diana Madalina Craciun , "davem@davemloft.net" , Madalin Bucur Subject: Re: [PATCH v2 3/3] dpaa2_eth: use new unmap and sync dma api variants Message-ID: <20191028113816.GB24055@lst.de> References: <20191024124130.16871-1-laurentiu.tudor@nxp.com> <20191024124130.16871-4-laurentiu.tudor@nxp.com> <00a138f0-3651-5441-7241-5f02956b6c2c@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <00a138f0-3651-5441-7241-5f02956b6c2c@nxp.com> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 28, 2019 at 10:55:05AM +0000, Laurentiu Tudor wrote: > >> @@ -85,9 +75,10 @@ static void free_rx_fd(struct dpaa2_eth_priv *priv, > >> ???? sgt = vaddr + dpaa2_fd_get_offset(fd); > >> ???? for (i = 1; i < DPAA2_ETH_MAX_SG_ENTRIES; i++) { > >> ???????? addr = dpaa2_sg_get_addr(&sgt[i]); > >> -??????? sg_vaddr = dpaa2_iova_to_virt(priv->iommu_domain, addr); > >> -??????? dma_unmap_page(dev, addr, DPAA2_ETH_RX_BUF_SIZE, > >> -?????????????????? DMA_BIDIRECTIONAL); > >> +??????? sg_vaddr = page_to_virt > >> +??????????????? (dma_unmap_page_desc(dev, addr, > >> +??????????????????????????? DPAA2_ETH_RX_BUF_SIZE, > >> +??????????????????????????? DMA_BIDIRECTIONAL)); > > > > This is doing virt -> page -> virt.? Why not just have the new > > function return the VA corresponding to the addr, which would > > match the other functions? > > I'd really like that as it would get rid of the page_to_virt() calls but > it will break the symmetry with the dma_map_page() API. I'll let the > maintainers decide. It would be symmetric with dma_map_single, though. Maybe we need both variants?