Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-26 Thread Robin Murphy
On 2019-11-26 6:51 pm, Nicolas Saenz Julienne wrote: On Mon, 2019-11-25 at 16:33 +, Robin Murphy wrote: On 25/11/2019 7:44 am, Christoph Hellwig wrote: On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote: Just as an FYI, this introduces a warning on arm32 allyesconfig for

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-26 Thread Nicolas Saenz Julienne
On Mon, 2019-11-25 at 16:33 +, Robin Murphy wrote: > On 25/11/2019 7:44 am, Christoph Hellwig wrote: > > On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote: > > > Just as an FYI, this introduces a warning on arm32 allyesconfig for me: > > > > I think the dma_limit argument to

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-25 Thread Robin Murphy
On 25/11/2019 7:44 am, Christoph Hellwig wrote: On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote: Just as an FYI, this introduces a warning on arm32 allyesconfig for me: I think the dma_limit argument to iommu_dma_alloc_iova should be a u64 and/or we need to use min_t and

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-24 Thread Christoph Hellwig
On Sat, Nov 23, 2019 at 09:51:08AM -0700, Nathan Chancellor wrote: > Just as an FYI, this introduces a warning on arm32 allyesconfig for me: I think the dma_limit argument to iommu_dma_alloc_iova should be a u64 and/or we need to use min_t and open code the zero exception. Robin, Nicolas - any

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-23 Thread Nathan Chancellor
On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote: > Using a mask to represent bus DMA constraints has a set of limitations. > The biggest one being it can only hold a power of two (minus one). The > DMA mapping code is already aware of this and treats dev->bus_dma_mask > as a

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Christoph Hellwig
On Thu, Nov 21, 2019 at 05:07:54PM +, Robin Murphy wrote: > ^^ super-nit only because I can't not see my editor currently highlighting > the typo: "accessible" > > Regardless of that though, > > Reviewed-by: Robin Murphy Applied for real now with that typo fixed and on top of the pulled in

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Christoph Hellwig
On Thu, Nov 21, 2019 at 04:53:48PM +, Will Deacon wrote: > Please go ahead and pull in our for-next/zone-dma branch if you need it. > We're not going to rebase it, and I suspect we won't even be queueing > anything else there at this stage in the game. Ok. I've pulled it in and will wait

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Robin Murphy
On 21/11/2019 9:26 am, Nicolas Saenz Julienne wrote: Using a mask to represent bus DMA constraints has a set of limitations. The biggest one being it can only hold a power of two (minus one). The DMA mapping code is already aware of this and treats dev->bus_dma_mask as a limit. This quirk is

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Will Deacon
On Thu, Nov 21, 2019 at 05:02:17PM +0100, Christoph Hellwig wrote: > On Thu, Nov 21, 2019 at 03:55:39PM +, Robin Murphy wrote: > > Hmm, there's no functional dependency though, is there? AFAICS it's > > essentially just a context conflict. Is it worth simply dropping (or > > postponing) the

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Christoph Hellwig
On Thu, Nov 21, 2019 at 03:55:39PM +, Robin Murphy wrote: > Hmm, there's no functional dependency though, is there? AFAICS it's > essentially just a context conflict. Is it worth simply dropping (or > postponing) the local renaming in __dma_direct_optimal_gfp_mask(), or > perhaps even

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Robin Murphy
On 21/11/2019 3:26 pm, Christoph Hellwig wrote: On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote: On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote: Using a mask to represent bus DMA constraints has a set of limitations. The biggest one being it can only

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Christoph Hellwig
On Thu, Nov 21, 2019 at 04:24:57PM +0100, Christoph Hellwig wrote: > On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote: > > Using a mask to represent bus DMA constraints has a set of limitations. > > The biggest one being it can only hold a power of two (minus one). The > >

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Nicolas Saenz Julienne
On Thu, 2019-11-21 at 16:24 +0100, Christoph Hellwig wrote: > On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote: > > Using a mask to represent bus DMA constraints has a set of limitations. > > The biggest one being it can only hold a power of two (minus one). The > > DMA

Re: [PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Christoph Hellwig
On Thu, Nov 21, 2019 at 10:26:44AM +0100, Nicolas Saenz Julienne wrote: > Using a mask to represent bus DMA constraints has a set of limitations. > The biggest one being it can only hold a power of two (minus one). The > DMA mapping code is already aware of this and treats dev->bus_dma_mask > as a

[PATCH v2] dma-mapping: treat dev->bus_dma_mask as a DMA limit

2019-11-21 Thread Nicolas Saenz Julienne
Using a mask to represent bus DMA constraints has a set of limitations. The biggest one being it can only hold a power of two (minus one). The DMA mapping code is already aware of this and treats dev->bus_dma_mask as a limit. This quirk is already used by some architectures although still rare.