linux-kernel - clean up and modularize arch dma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20170608132609.32662-1-hch@lst.de>
Date:   Thu,  8 Jun 2017 15:25:25 +0200
From:   Christoph Hellwig <hch@....de>
To:     x86@...nel.org, linux-arm-kernel@...ts.infradead.org,
        xen-devel@...ts.xenproject.org, linux-c6x-dev@...ux-c6x.org,
        linux-hexagon@...r.kernel.org, linux-ia64@...r.kernel.org,
        linux-mips@...ux-mips.org, openrisc@...ts.librecores.org,
        linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
        linux-sh@...r.kernel.org, sparclinux@...r.kernel.org,
        linux-xtensa@...ux-xtensa.org, dmaengine@...r.kernel.org,
        linux-tegra@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-samsung-soc@...r.kernel.org,
        iommu@...ts.linux-foundation.org, netdev@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org
Subject: clean up and modularize arch dma_mapping interface

Hi all,

for a while we have a generic implementation of the dma mapping routines
that call into per-arch or per-device operations.  But right now there
still are various bits in the interfaces where don't clearly operate
on these ops.  This series tries to clean up a lot of those (but not all
yet, but the series is big enough).  It gets rid of the DMA_ERROR_CODE
way of signaling failures of the mapping routines from the
implementations to the generic code (and cleans up various drivers that
were incorrectly using it), and gets rid of the ->set_dma_mask routine
in favor of relying on the ->dma_capable method that can be used in
the same way, but which requires less code duplication.

Btw, we don't seem to have a tree every-growing amount of common dma
mapping code, and given that I have a fair amount of all over the tree
work in that area in my plate I'd like to start one.  Any good reason
to that?  Anyone willing to volunteer as co maintainer?

The whole series is also available in git:

    git://git.infradead.org/users/hch/misc.git dma-map

Gitweb:

    http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-map