On Mon, Jul 10, 2017 at 04:31:54PM +0100, Robin Murphy wrote:
> On 10/07/17 15:56, Christoph Hellwig wrote:
> > This looks reasonable to me, I'd be happy to pick it up. Can you send
> > it as a series with the reverts?
>
> The fact remains that the FSL driver is still doing the wrong thing
> thou
On 10/07/17 15:56, Christoph Hellwig wrote:
> This looks reasonable to me, I'd be happy to pick it up. Can you send
> it as a series with the reverts?
The fact remains that the FSL driver is still doing the wrong thing
though - set_dma_ops(dev1, get_dma_ops(dev2)) is just a hack which
happens to
This looks reasonable to me, I'd be happy to pick it up. Can you send
it as a series with the reverts?
On Sun, Jul 9, 2017 at 9:33 PM, Geert Uytterhoeven wrote:
> Adding a dummy for set_dma_ops() allows to compile (sub)drivers that
> don't actually use the DMA API, but propagate DMA ops configuration to a
> second driver that may or may not use the DMA API. Of course the second
> driver does have
Adding a dummy for set_dma_ops() allows to compile (sub)drivers that
don't actually use the DMA API, but propagate DMA ops configuration to a
second driver that may or may not use the DMA API. Of course the second
driver does have to depend on HAS_DMA if it uses the DMA API.
An example is commit
