Re: powerpc : dma-mapping : Check null condition for dev->archdata.dma_ops

[Scott Wood <scottwood@freescale.com>]

On Fri, Jul 18, 2014 at 03:34:52PM +0530, Nikhil Badola wrote:
> Modifies get_dma_ops() implementation on ppc arch to check null condition
> for dev->archdata.dma_ops; returns common dma_direct_ops structure in
> case its NULL
> 
> Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
> ---
>  arch/powerpc/include/asm/dma-mapping.h | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)

I'm not sure why this was delegated to me in patchwork, as it doesn't
appear to be FSL-specific...  I wish patchwork showed the history of
changes to a patch.

> The use case in which ops are null is while running USB in Gadget and
> Otg mode.
> 
> For PPC architecture, whenever a platform device is registered,
> pdev->dev is assigned dma_ops.  In USB, one single chipidea platform
> device is registered for any mode (host, gadget or otg) whose dev, as
> explained above, has dma_ops set and this dev is assigned to
> ci->dev(dev of chipidea struct) which is used by host controller
> device.  That is why we don't need the above null case checking in host
> mode.  But when we run usb in gadget/otg mode, the device structure
> used is ci->gadget.dev which does not have dma_ops set and it crashes
> when dma transaction starts when it calls get_dma_ops() which returns
> NULL.
>
> A similar approach is used in ARM architecture which checks for null
> condition and returns common dma_ops

The above doesn't make it clear to me why dma_ops is NULL in non-host
modes, or why "direct" is necessarily the right ops -- what if swiotlb or
an iommu is needed?

If the problem is that you're using a "struct device" other than the
platform device, shouldn't that be fixed?  Or make sure that this other
"struct device" has been properly set up by arch code for doing DMA.

>  }
>  
> +
>  static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)

Don't add this newline

-Scott