[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190521103214.GB1973@lst.de>
Date: Tue, 21 May 2019 12:32:14 +0200
From: "hch@....de" <hch@....de>
To: Fredrik Noring <noring@...rew.org>
Cc: Laurentiu Tudor <laurentiu.tudor@....com>,
Robin Murphy <robin.murphy@....com>, "hch@....de" <hch@....de>,
"stern@...land.harvard.edu" <stern@...land.harvard.edu>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"marex@...x.de" <marex@...x.de>,
"JuergenUrban@....de" <JuergenUrban@....de>,
Leo Li <leoyang.li@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 0/3] prerequisites for device reserved local mem
rework
On Mon, May 20, 2019 at 05:41:56PM +0200, Fredrik Noring wrote:
> 2. A device address is supplied as phys_addr_t phys to gen_pool_add_virt().
> This seems to work in this particular DMA application, but there will be
> problems if someone does phys_to_virt() or suchlike. Can this be improved
> or clearly explained? gen_pool_virt_to_phys() searches in address ranges,
> for example, so it appears the implementation uses phys quite carefully.
Well, it is a physical address, but not one that has a kernel mapping.
So phys_addr_t seems right here, but an additional comment explaining it
is not in the kernel mapping never hurts.
Powered by blists - more mailing lists