From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v2 1/3] xen/arm: Add ThunderX platform support Date: Tue, 3 Mar 2015 10:18:41 +0000 Message-ID: <1425377921.24959.66.camel@citrix.com> References: <1424261984-28324-1-git-send-email-vijay.kilari@gmail.com> <1424261984-28324-2-git-send-email-vijay.kilari@gmail.com> <54E487AB.6060703@linaro.org> <1424713864.27930.253.camel@citrix.com> <1425373384.12103.47.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Vijay Kilari Cc: Stefano Stabellini , Prasun Kapoor , Vijaya Kumar K , Julien Grall , Tim Deegan , "xen-devel@lists.xen.org" , Stefano Stabellini , manish.jaggi@caviumnetworks.com List-Id: xen-devel@lists.xenproject.org On Tue, 2015-03-03 at 14:59 +0530, Vijay Kilari wrote: > On Tue, Mar 3, 2015 at 2:33 PM, Ian Campbell wrote: > > On Tue, 2015-03-03 at 10:39 +0530, Vijay Kilari wrote: > >> On Mon, Feb 23, 2015 at 11:21 PM, Ian Campbell wrote: > >> > On Wed, 2015-02-18 at 12:38 +0000, Julien Grall wrote: > >> >> > + uint64_t addr, size; > >> > > >> > Please use paddr_t and PRIpaddr etc. > >> > > >> >> > + res = map_mmio_regions(d, > >> >> > + paddr_to_pfn(addr & PAGE_MASK), > >> >> > + DIV_ROUND_UP(size, PAGE_SIZE), > >> >> > + paddr_to_pfn(addr & PAGE_MASK)); > >> >> > >> >> OOI, why this region is not described in the DT? Is it a PCI device? > >> > > >> > >> It is not PCI device. it is Global SerDes configuration region. It is not > >> mentioned in DT. > > > > Why not? Should it be? > > There is no specific driver in dom0 for this. > It is only used by thunder pci driver in dom0 to configure serdes. A DT is supposed to describe the hardware, so the presence or absence of a driver in the kernel doesn't really come in to it. > In future we plan to get rid of this. But for now we can have this > mapping. The problem is that removing this mapping in the future may, depending on how it is all done, break compatibility with older kernels. Could you describe how you plan to get rid of it please so I can see if we need to worry about that sort of thing here? To avoid blocking the rest of the series it might be a good idea to factor out this specific mapping into a separate patch, then the rest can go in, plus you can then use the commit message to explain what the plan is etc.