[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CY1PR0401MB1536C1FF3C069BC88D1DB14581000@CY1PR0401MB1536.namprd04.prod.outlook.com>
Date: Tue, 11 Apr 2017 01:14:29 +0000
From: Bart Van Assche <Bart.VanAssche@...disk.com>
To: Stefano Stabellini <sstabellini@...nel.org>
CC: "boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
"jgross@...e.com" <jgross@...e.com>,
"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"hpa@...or.com" <hpa@...or.com>,
"mingo@...hat.com" <mingo@...hat.com>,
"linux@...linux.org.uk" <linux@...linux.org.uk>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"julien.grall@....com" <julien.grall@....com>
Subject: Re: "Consolidate get_dma_ops" breaks Xen on ARM
On 04/10/17 17:31, Stefano Stabellini wrote:
> I think the reason is that, as you can see, if (dev && dev->dma_ops),
> dev->dma_ops is returned, while before this changes, xen_dma_ops was
> returned on Xen on ARM.
>
> Unfortunately DMA cannot work properly without using the appropriate
> xen_dma_ops. See drivers/xen/swiotlb-xen.c and arch/arm/xen/mm.c for
> more details. (The problem is easy to spot, but I wasn't CC'ed on the
> patch.)
>
> I don't know how to solve this problem without introducing some sort of
> if (xen()) in include/linux/dma-mapping.h.
Sorry but I don't have access to an ARM development system. Does your
comment apply to dev == NULL only, dev != NULL only or perhaps to both?
If your comment applies to dev != NULL only, can you check whether
adding something like set_dma_ops(dev, get_arch_dma_ops(NULL)) to the
appropriate ARM arch_setup_dma_ops() function is sufficient?
Thanks,
Bart.
Powered by blists - more mailing lists