Re: [PATCH 1/2] dma-mapping: truncate dma masks to what dma_addr_t can hold

2019-06-24 Thread Christoph Hellwig
On Fri, Jun 14, 2019 at 09:46:48AM +0200, Christoph Hellwig wrote: > If I don't hear anything back in the next days I will just merge > these patches, please comment. Applied to the dma-mapping for-next tree now.

Re: [PATCH 1/2] dma-mapping: truncate dma masks to what dma_addr_t can hold

2019-06-14 Thread Christoph Hellwig
If I don't hear anything back in the next days I will just merge these patches, please comment. On Wed, May 29, 2019 at 02:22:19PM +0200, Christoph Hellwig wrote: > Russell, > > any additional comments on this series? > > On Tue, May 21, 2019 at 03:15:03PM +0200, Christoph Hellwig wrote: > > On

Re: [PATCH 1/2] dma-mapping: truncate dma masks to what dma_addr_t can hold

2019-05-29 Thread Christoph Hellwig
Russell, any additional comments on this series? On Tue, May 21, 2019 at 03:15:03PM +0200, Christoph Hellwig wrote: > On Tue, May 21, 2019 at 02:04:37PM +0100, Russell King - ARM Linux admin > wrote: > > So how does the driver negotiation for >32bit addresses work if we don't > > fail for large

Re: [PATCH 1/2] dma-mapping: truncate dma masks to what dma_addr_t can hold

2019-05-21 Thread Christoph Hellwig
On Tue, May 21, 2019 at 02:04:37PM +0100, Russell King - ARM Linux admin wrote: > So how does the driver negotiation for >32bit addresses work if we don't > fail for large masks? > > I'm thinking about all those PCI drivers that need DAC cycles for >32bit > addresses, such as e1000, which

Re: [PATCH 1/2] dma-mapping: truncate dma masks to what dma_addr_t can hold

2019-05-21 Thread Russell King - ARM Linux admin
On Tue, May 21, 2019 at 02:47:28PM +0200, Christoph Hellwig wrote: > The dma masks in struct device are always 64-bits wide. But for builds > using a 32-bit dma_addr_t we need to ensure we don't store an > unsupportable value. Before Linux 5.0 this was handled at least by > the ARM dma mapping