[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200925041425.GA9419@lst.de>
Date: Fri, 25 Sep 2020 06:14:25 +0200
From: 'Christoph Hellwig' <hch@....de>
To: David Laight <David.Laight@...LAB.COM>
Cc: 'Christoph Hellwig' <hch@....de>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
Dominik Brodowski <linux@...inikbrodowski.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] dma-mapping: better document dma_addr_t and
DMA_MAPPING_ERROR
On Tue, Sep 22, 2020 at 01:56:46PM +0000, David Laight wrote:
> > +/*
> > + * A dma_addr_t can hold any valid DMA or bus address for the platform. It can
> > + * be given to a device to use as a DMA source or target. A CPU cannot
> > + * reference a dma_addr_t directly because there may be translation between its
> > + * physical address space and the bus address space.
>
> It can't access it 'directly' because it isn't a virtual address....
>
> > + *
> > + * DMA_MAPPING_ERROR is the magic error code if a mapping failed. It should not
> > + * be used directly in drivers, but checked for using dma_mapping_error()
> > + * instead.
> > + */
>
> I think it might be worth adding:
>
> A dma_addr_t value may be device dependant and differ from the
> 'physical address' of the memory.
This is what I've committed:
* A dma_addr_t can hold any valid DMA or bus address for the platform. It can
* be given to a device to use as a DMA source or target. It is specific to a
* given device and there may be a translation between the CPU physical address
* space and the bus address space.
Powered by blists - more mailing lists