Re: [PATCH] arm64: dma-mapping: Fix dma_mapping_error() when bypassing SWIOTLB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2017-01-25 at 12:54 +0000, Robin Murphy wrote:
> On 25/01/17 12:51, Arnd Bergmann wrote:
> > On Wed, Jan 25, 2017 at 1:37 PM, Michael Zoran <mzoran@xxxxxxxxxxxx
> > > wrote:
> > > On Wed, 2017-01-25 at 12:03 +0000, Robin Murphy wrote:
> > > > hen bypassing SWIOTLB on small-memory systems, we need to avoid
> > > > calling
> > > > into swiotlb_dma_mapping_error() in exactly the same way as we
> > > > avoid
> > > > swiotlb_dma_supported(), because the former also relies on
> > > > SWIOTLB
> > > > state
> > > > being initialised.
> > > 
> > > I didn't submit the initial ARM64 port of the RPI 3, so I don't
> > > know
> > > much about this.  But from a third personal point of view, this
> > > seems
> > > to side step the main issue here.
> > 
> > I think Robin's approach is fixing exactly the right part of the
> > code.
> > 
> > > From an ARM64 subsystem point of view, what exactly is the
> > > correct/recommended method for ensuring the mm subsystem is
> > > initialized
> > > correctly?
> > 
> > It is initialized correctly, the bug was calling the wrong helper
> > when swiotlb
> > is not used because we determined that we don't need it.
> > 
> > One concern from inspection:
> > 
> > > +static int __swiotlb_dma_mapping_error(struct device *hwdev,
> > > dma_addr_t addr)
> > > +{
> > > +       if (swiotlb)
> > > +               return swiotlb_dma_mapping_error(hwdev, addr);
> > > +       return 1;
> > > +}
> > 
> > Shouldn't that be
> > 
> >      return addr == DMA_ERROR_CODE;
> > 
> > in the last line? Otherwise any addr is interpreted as an error,
> > which
> > seems wrong. Maybe I'm missing something obvious here.
> 
> Aw crap, copy/paste/brain error - thanks.
> 
> I'll have a nice strong cup of tea, actually engage thinking mode,
> and
> respin...
> 
> Robin.
> 
> > 
> >     Arnd
> > 

I have an RPI 3 that I run in ARM64 mode all the time for personal use.
 If/when you have a patch ready, I'm more then willing to try it out
locally.

Just tell me the path of the git tree and branch that it's based on.

Thanks.


--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]