Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp4306657ybz; Tue, 28 Apr 2020 09:06:06 -0700 (PDT) X-Google-Smtp-Source: APiQypLpYlMmppC0XQ0W0FJRkA8wi5OAcF4dXL5JtEvWUPGdyXN+rF5EXlQyqA+cMxqXMZPvpgnE X-Received: by 2002:a17:906:48ce:: with SMTP id d14mr23793289ejt.113.1588089965932; Tue, 28 Apr 2020 09:06:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588089965; cv=none; d=google.com; s=arc-20160816; b=gzyuzE5ss6L6ihh4b+dyMe+LkCZdum+YEITA0rnRU9/PlOkUF52MAM+Cagpl1RpX32 MU4ZjCQwZx4xkZAtpA059lPwBJcIsAG7YxNIcUYwDXW9Qs40dSMe5YlyykDEuIeDV6AT wIuaRA3sYwVsJmAuZwFKQ8HiFzmoBnq2UQuhwRzunf17VoHSinSgsr87+0JZDP5I06g6 sWqRPXbB6oCtes2OwR51fiX6te8vx2uXe3xstAI9xlRJf8SJrDDbxX2oNtelhxRGzsYp kgErMFcM7nIk9IGHes0neYG+Ty3Ukz5QXWAzJ26OCSSUIJpW+QMgQ3jasiPBoYC+Zb7f UQeQ== 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:to:subject; bh=+NygYQ9Q9Juxr/Hcle9yPiL+5wuOjdB1VP0681DToG0=; b=ph7QTV+4VdRpP1mxC7ZOuOm6MZaIByuGLiSNiA+PxJgB8C5j96cOQLYMHgD7NS2t85 ZUa/+yF8vu2e6cb2Wg7YoxcMnBkfkKBVR5Nd5apzRHM94cZzTJlFx4vgWnSqAJF5o39N q1mnD2q5A28lS9NkEdTH8fMKpo2csfPz/XmBG/UH1IzalXNe1UlS2JxLgiNjq46x+Hyw ZgjfdCdIXbXVI97ceGvS2TQo4UWOE2t5sjmVzD8cfBuwI4KAD8J/xGHETd7wMzq6EblB 2lTafJHJ9IkmFITUd5OJrsGevHBq+iAmYqhmnVSzjvHXAWdoiZIGT79VoQLy4Vx4GVTB CYww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t9si2062069ejr.422.2020.04.28.09.05.10; Tue, 28 Apr 2020 09:06:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728296AbgD1QDC (ORCPT + 99 others); Tue, 28 Apr 2020 12:03:02 -0400 Received: from foss.arm.com ([217.140.110.172]:54716 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727920AbgD1QDC (ORCPT ); Tue, 28 Apr 2020 12:03:02 -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 11FB530E; Tue, 28 Apr 2020 09:03:02 -0700 (PDT) Received: from [10.57.33.170] (unknown [10.57.33.170]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0EE773F305; Tue, 28 Apr 2020 09:02:59 -0700 (PDT) Subject: Re: [RFC 00/17] DRM: fix struct sg_table nents vs. orig_nents misuse To: Christoph Hellwig , Marek Szyprowski , dri-devel@lists.freedesktop.org, iommu@lists.linux-foundation.org, linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org, Bartlomiej Zolnierkiewicz , Sumit Semwal , Benjamin Gaignard , intel-gfx@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, amd-gfx@lists.freedesktop.org, David Airlie References: <20200428132005.21424-1-m.szyprowski@samsung.com> <20200428140257.GA3433@lst.de> <20200428153202.GY3456981@phenom.ffwll.local> From: Robin Murphy Message-ID: Date: Tue, 28 Apr 2020 17:02:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200428153202.GY3456981@phenom.ffwll.local> 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 2020-04-28 4:32 pm, Daniel Vetter wrote: > On Tue, Apr 28, 2020 at 04:02:57PM +0200, Christoph Hellwig wrote: >> On Tue, Apr 28, 2020 at 03:19:48PM +0200, Marek Szyprowski wrote: >>> 1. introduce a dma_{map,sync,unmap}_sgtable() wrappers, which will use >>> a proper sg_table entries and call respective DMA-mapping functions >>> and adapt current code to it >> >> That sounds reasonable to me. Those could be pretty trivial wrappers. >> >>> >>> >>> 2. rename nents and orig_nents to nr_pages, nr_dmas to clearly state >>> which one refers to which part of the scatterlist; I'm open for >>> other names for those entries >> >> nr_cpu_ents and nr_dma_ents might be better names, but it still would be >> a whole lot of churn for little gain. I think just good wrappers like >> suggested above might be more helpful. > > I guess long-term we could aim for both? I.e. roll out better wrappers > first, once that's soaked through the tree, rename the last offenders. Yes, that's what I was thinking too - most of these uses are just passing them in and out of the DMA APIs, and thus would be subsumed into the wrappers anyway, then in the relatively few remaining places where the table is actually iterated for one reason or the other, renaming would stand to help review and maintenance in terms of making it far more obvious when the implementation and the intent don't match. Robin.