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 me:
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 io
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 open
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 op
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
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
a
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 with
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 alre
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 l
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 cross-
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 ho
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
> > DMA
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 mappin
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
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.
Wi
15 matches
Mail list logo