[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160425142619.GJ28777@bigcity.dyn.berto.se>
Date: Mon, 25 Apr 2016 16:26:19 +0200
From: Niklas Söderlund <niso@....se>
To: Christoph Hellwig <hch@...radead.org>
Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Dan Williams <dan.j.williams@...el.com>,
Vinod Koul <vinod.koul@...el.com>,
linux-renesas-soc@...r.kernel.org,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
iommu@...ts.linux-foundation.org, robin.murphy@....com,
geert+renesas@...der.be, Linus Walleij <linus.walleij@...aro.org>,
Arnd Bergmann <arnd@...db.de>, linux-arch@...r.kernel.org
Subject: Re: [PATCH v5 3/9] dma-mapping: add dma_{map,unmap}_resource
Hi Christoph,
On 2016-04-21 06:49:42 -0700, Christoph Hellwig wrote:
> On Wed, Apr 13, 2016 at 03:29:17PM +0200, Niklas S?derlund wrote:
> > > Yes, it would be good to do an audit of all the ARM dma_ops as well
> > > as generic code like drivers/base/dma-*.c, lib/dma-debug.c and
> > > include/linux/dma-*.h
>
> What about things like the phys_addr() helper in lib/dma-debug.c? That
> was in fact what prompted my question for an audit, and it seems
> to not even feature on your list. What patterns / symbols did you look
> for?
I have followed the call path from the usage in
drivers/dma/sh/rcar-dmac.c and made sure the dma_addr_t is not used in a
bad way.
I also looked at the dma-mapping API and ruled out that the only
function that make sens to use with a dma_addr_t from dma_map_resource()
are dma_unmap_resource() and dma_mapping_error(). With that I can't see
how a dma_addr_t would end up in lib/dma-debug.c. But I might be missing
something?
In the big picture do you feel the approach I have is the correct way to
solve my problem? Provided we can work out this issues ofc?
--
Regards,
Niklas Söderlund
Powered by blists - more mailing lists