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

Michael Zoran mzoran at crowfest.net
Wed Jan 25 05:35:17 PST 2017


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 at crowfest.net
> > > 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.





More information about the linux-rpi-kernel mailing list