On Tue, Feb 05, 2019 at 10:20:32PM +1100, Michael Ellerman wrote:
> get_dma_ops() falls into arch-dependant get_arch_dma_ops(), which
> historically returns NULL on PowerPC. Therefore dma_set_mask() fails.
> This affects Switchtec (and probably other) NTB devices, that they fail
> to initialize.
>
ase, not for all devices.
>
> Can you provide the context? E.g. the patch and the rest of the commit
> log. This all looks rather odd to me.
Sorry, here it is.
Or on lore:
https://lore.kernel.org/linuxppc-dev/20190128133203.mon4a3nkrzijn43g@alfbook-pro.local/
Subject: [RFC PATCH] powe
On Wed, Jan 30, 2019 at 11:58:40PM +1100, Michael Ellerman wrote:
> Alexander Fomichev writes:
>
> > get_dma_ops() falls into arch-dependant get_arch_dma_ops(), which
> > historically returns NULL on PowerPC. Therefore dma_set_mask() fails.
> > This affects Switchtec (and probably other) NTB devi
Alexander Fomichev writes:
> get_dma_ops() falls into arch-dependant get_arch_dma_ops(), which
> historically returns NULL on PowerPC. Therefore dma_set_mask() fails.
> This affects Switchtec (and probably other) NTB devices, that they fail
> to initialize.
What's an NTB device?
drivers/ntb I a
get_dma_ops() falls into arch-dependant get_arch_dma_ops(), which
historically returns NULL on PowerPC. Therefore dma_set_mask() fails.
This affects Switchtec (and probably other) NTB devices, that they fail
to initialize.
The proposed patch should fix the issue.
---
arch/powerpc/include/asm/dma-