iommu.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Christoph Hellwig <hch@lst.de>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	dri-devel@lists.freedesktop.org,
	iommu@lists.linux-foundation.org, linaro-mm-sig@lists.linaro.org,
	linux-kernel@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	intel-gfx@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	amd-gfx@lists.freedesktop.org, David Airlie <airlied@linux.ie>
Subject: Re: [RFC 00/17] DRM: fix struct sg_table nents vs. orig_nents misuse
Date: Tue, 28 Apr 2020 17:02:58 +0100	[thread overview]
Message-ID: <c01c9766-9778-fd1f-f36e-2dc7bd376ba4@arm.com> (raw)
In-Reply-To: <20200428153202.GY3456981@phenom.ffwll.local>

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.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

      reply	other threads:[~2020-04-28 16:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200428132022eucas1p2aa4716cbaca61c432ee8028be15fef7a@eucas1p2.samsung.com>
2020-04-28 13:19 ` [RFC 00/17] DRM: fix struct sg_table nents vs. orig_nents misuse Marek Szyprowski
     [not found]   ` <CGME20200428132022eucas1p22f64f56bb61cf6ee73892a9fc9ce7e09@eucas1p2.samsung.com>
2020-04-28 13:19     ` [RFC 01/17] drm: core: fix " Marek Szyprowski
     [not found]   ` <CGME20200428132023eucas1p2a1993145eef91506698aa8c9750a7e43@eucas1p2.samsung.com>
2020-04-28 13:19     ` [RFC 02/17] drm: amdgpu: " Marek Szyprowski
2020-04-28 15:14       ` Christian König
     [not found]   ` <CGME20200428132023eucas1p1a894986ab95ac3208c19878c6a04c0e1@eucas1p1.samsung.com>
2020-04-28 13:19     ` [RFC 03/17] drm: armada: " Marek Szyprowski
     [not found]   ` <CGME20200428132024eucas1p1c51178774db6fb4cab748522c86646cd@eucas1p1.samsung.com>
2020-04-28 13:19     ` [RFC 04/17] drm: etnaviv: " Marek Szyprowski
     [not found]   ` <CGME20200428132025eucas1p15cf78bdedef6eebc477c7e8429a6f971@eucas1p1.samsung.com>
2020-04-28 13:19     ` [RFC 05/17] drm: exynos: " Marek Szyprowski
     [not found]   ` <CGME20200428132025eucas1p21580e634500a3e85564551cddf168b4a@eucas1p2.samsung.com>
2020-04-28 13:19     ` [RFC 06/17] drm: i915: " Marek Szyprowski
2020-04-28 14:27       ` [Intel-gfx] " Tvrtko Ursulin
2020-04-30 14:17         ` Marek Szyprowski
     [not found]   ` <CGME20200428132026eucas1p27c64540e53f328d0bb7bf9dae2ccb98d@eucas1p2.samsung.com>
2020-04-28 13:19     ` [RFC 07/17] drm: lima: " Marek Szyprowski
     [not found]   ` <CGME20200428132027eucas1p2fed88e94fecf1ef12b312ba80a78bc00@eucas1p2.samsung.com>
2020-04-28 13:19     ` [RFC 08/17] drm: msm: " Marek Szyprowski
     [not found]   ` <CGME20200428132027eucas1p1a045e89a0058ccff3ea94d1da2236af7@eucas1p1.samsung.com>
2020-04-28 13:19     ` [RFC 09/17] drm: panfrost: " Marek Szyprowski
     [not found]   ` <CGME20200428132028eucas1p155a84ab14c6a6820b4c8240f01e98905@eucas1p1.samsung.com>
2020-04-28 13:19     ` [RFC 10/17] drm: radeon: " Marek Szyprowski
2020-04-28 15:15       ` Christian König
     [not found]   ` <CGME20200428132028eucas1p2310cd19b879962d5241604dd13909255@eucas1p2.samsung.com>
2020-04-28 13:19     ` [RFC 11/17] drm: rockchip: " Marek Szyprowski
     [not found]   ` <CGME20200428132029eucas1p2433959853ef384ef783cbe9a1e45fde3@eucas1p2.samsung.com>
2020-04-28 13:20     ` [RFC 12/17] drm: tegra: " Marek Szyprowski
     [not found]   ` <CGME20200428132030eucas1p17d907110da4cf2a12651cc52ba7eaad6@eucas1p1.samsung.com>
2020-04-28 13:20     ` [RFC 13/17] drm: virtio: " Marek Szyprowski
     [not found]   ` <CGME20200428132030eucas1p11f977e77050b5e76f580255096bb94bf@eucas1p1.samsung.com>
2020-04-28 13:20     ` [RFC 14/17] drm: vmwgfx: " Marek Szyprowski
     [not found]   ` <CGME20200428132031eucas1p1e7a72bf0de5acea2af652cd8337a8ed5@eucas1p1.samsung.com>
2020-04-28 13:20     ` [RFC 15/17] drm: xen: " Marek Szyprowski
     [not found]   ` <CGME20200428132031eucas1p25bf6d0d1f24a69cc3692b2001ac0ebd1@eucas1p2.samsung.com>
2020-04-28 13:20     ` [RFC 16/17] drm: host1x: " Marek Szyprowski
     [not found]   ` <CGME20200428132032eucas1p17c2b93daf91c95c41650e75b251d525c@eucas1p1.samsung.com>
2020-04-28 13:20     ` [RFC 17/17] dmabuf: " Marek Szyprowski
2020-04-28 14:02   ` [RFC 00/17] DRM: fix struct " Christoph Hellwig
2020-04-28 15:32     ` Daniel Vetter
2020-04-28 16:02       ` Robin Murphy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c01c9766-9778-fd1f-f36e-2dc7bd376ba4@arm.com \
    --to=robin.murphy@arm.com \
    --cc=airlied@linux.ie \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=b.zolnierkie@samsung.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@lst.de \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).