[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1437511418.3214.233.camel@hp.com>
Date: Tue, 21 Jul 2015 14:43:38 -0600
From: Toshi Kani <toshi.kani@...com>
To: Ashutosh Dixit <ashutosh.dixit@...el.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Dutt, Sudeep" <sudeep.dutt@...el.com>,
"Rao, Nikhil" <nikhil.rao@...el.com>,
"Williams, Dan J" <dan.j.williams@...el.com>
Subject: Re: Regression in v4.2-rc1: vmalloc_to_page with ioremap
On Tue, 2015-07-21 at 14:39 -0600, Toshi Kani wrote:
> On Tue, 2015-07-21 at 08:17 -0700, Ashutosh Dixit wrote:
> > On Mon, Jul 20 2015 at 12:21:18 PM, Toshi Kani <toshi.kani@...com>
:
> > Yes, you are correct, the 'struct page' pointer returned by
> > vmalloc_to_page does not point to a "real" struct page entry. Neither
> > have we allocated a struct page for the range. However, because we pass
> > the returned pointer to streaming DMA mapping API's
> > (dma_map_ops->dma_map_sg or dma_map_ops->dma_map_page) and all those
> > functions do is call page_to_phys, they only care about the physical
> > address, it used to work.
> >
> > Would it be possible to have a different API which can do this or can
> > vmalloc_to_page be updated to handle huge ioremaps without crashing?
> > Or
> > would you have a suggestion for doing this differently?
>
> You can do the following instead. If you have the physical address
> already
> (i.e. the address you passed to ioremap), you can skip
> slow_virt_to_phys().
> pfn_to_page() is a hack for the time being so that you can use the same
> DMA mapping APIs.
>
> phys = slow_virt_to_phys(vaddr);
> page = pfn_to_page(phys >> PAGE_SHIFT);
Forgot to mention. slow_virt_to_phys() is only defined in x86, but I think
your driver is x86-only. Let me know if this is a problem.
Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists