[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190213.220238.72067832020194055.davem@davemloft.net>
Date: Wed, 13 Feb 2019 22:02:38 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: brouer@...hat.com
Cc: netdev@...r.kernel.org, linux-mm@...ck.org, toke@...e.dk,
ilias.apalodimas@...aro.org, willy@...radead.org,
saeedm@...lanox.com, alexander.duyck@...il.com,
akpm@...ux-foundation.org, mgorman@...hsingularity.net,
tariqt@...lanox.com
Subject: Re: [net-next PATCH V3 0/3] Fix page_pool API and dma address
storage
From: Jesper Dangaard Brouer <brouer@...hat.com>
Date: Wed, 13 Feb 2019 02:55:34 +0100
> As pointed out by David Miller in [1] the current page_pool implementation
> stores dma_addr_t in page->private. This won't work on 32-bit platforms with
> 64-bit DMA addresses since the page->private is an unsigned long and the
> dma_addr_t a u64.
>
> Since no driver is yet using the DMA mapping capabilities of the API let's
> fix this by storing the information in 'struct page' and use that to store
> and retrieve DMA addresses from network drivers.
>
> As long as the addresses returned from dma_map_page() are aligned the first
> bit, used by the compound pages code should not be set.
>
> Ilias tested the first two patches on Espressobin driver mvneta, for which
> we have patches for using the DMA API of page_pool.
>
> [1]: https://lore.kernel.org/netdev/20181207.230655.1261252486319967024.davem@davemloft.net/
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@...hat.com>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@...aro.org>
Series applied, thanks Jesper.
Powered by blists - more mailing lists