[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170608.102136.2294569179855411095.davem@davemloft.net>
Date: Thu, 08 Jun 2017 10:21:36 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: hch@....de
Cc: 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,
linux-kernel@...r.kernel.org
Subject: Re: clean up and modularize arch dma_mapping interface
From: Christoph Hellwig <hch@....de>
Date: Thu, 8 Jun 2017 15:25:25 +0200
> 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.
There is unlikely to be conflicts for the sparc and net changes, so I
will simply ACK them.
Thanks Christoph.
Powered by blists - more mailing lists