Re: [PATCH] net: mvpp2: avoid bouncing buffers

[Brian Brooks]

On 08/19 23:23:26, Christoph Hellwig wrote:
> On Sun, Aug 19, 2018 at 07:55:05PM -0700, David Miller wrote:
> > From: Brian Brooks <brian.brooks@xxxxxxxxxx>
> > Date: Sun, 19 Aug 2018 21:47:30 -0500
> > 
> > > @@ -5126,6 +5126,12 @@ static int mvpp2_probe(struct platform_device *pdev)
> > >  	}
> > >  
> > >  	if (priv->hw_version == MVPP22) {
> > > +		/* Platform code may have set dev->dma_mask to point
> > > +		 * to dev->coherent_dma_mask, but we want to ensure
> > > +		 * they take different values due to comment below.
> > > +		 */
> > > +		pdev->dev.dma_mask = &priv->dma_mask;
> > 
> > The platform code might be doing this exactly because it cannot support
> > different coherent and streaming DMA masks.
> > 
> > Well, in any case, the platform code is doing it for a reason and
> > overriding this in a "driver" of all places seems totally
> > inappropriate and at best a layering violation.
> > 
> > I would rather you fix this in a way that involves well defined APIs
> > that set the DMA masks or whatever to the values that you need, rather
> > than going behind the platform code's back and changing the DMA mask
> > pointer like this.
> 
> Agreed.  What platform do you see this issue on?

This is Armada 8040 SoC with PPv2 net device on chip. MACCHIATObin board.

Both DT and ACPI have the following snippet:

	/*
	 * Set default coherent_dma_mask to 32 bit.  Drivers are expected to
	 * setup the correct supported mask.
	 */
	if (!dev->coherent_dma_mask)
		dev->coherent_dma_mask = DMA_BIT_MASK(32);

	/*
	 * Set it to coherent_dma_mask by default if the architecture
	 * code has not set it.
	 */
	if (!dev->dma_mask)
		dev->dma_mask = &dev->coherent_dma_mask;

Some architectures code setup DMA masks, but it does not seem appropriate
to add mvpp2 specific code in arch/arm64. The mvpp2 driver appeared to be
the least invasive place to resolve the limitation of this net device.

Another DMA API could be added to allocate storage for the streaming
mask to ensure masks can take on separate values when the existing DMA
APIs are used by the driver to set those values. But, this would be the
only driver using such API. Would that be how to handle this?