From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from kirsty.vergenet.net ([202.4.237.240]:34043 "EHLO kirsty.vergenet.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750959AbaKCX0i (ORCPT ); Mon, 3 Nov 2014 18:26:38 -0500 Date: Tue, 4 Nov 2014 08:26:25 +0900 From: Simon Horman To: Phil Edworthy Cc: Bjorn Helgaas , Lorenzo Pieralisi , "linux-arm-kernel@lists.infradead.org" , "linux-pci@vger.kernel.org" , "liviu.dudau@arm.com" , Arnd Bergmann , Jason Gunthorpe , Jingoo Han , Russell King , Mohit Kumar Subject: Re: [RFC PATCH 2/2] arm: pcibios: move to generic PCI domains Message-ID: <20141103232625.GA22642@verge.net.au> References: <1414669490-1217-1-git-send-email-lorenzo.pieralisi@arm.com> <1414669490-1217-3-git-send-email-lorenzo.pieralisi@arm.com> <08260858dd004e4881e7fbd4b23ea795@SIXPR06MB0639.apcprd06.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 In-Reply-To: <08260858dd004e4881e7fbd4b23ea795@SIXPR06MB0639.apcprd06.prod.outlook.com> Sender: linux-pci-owner@vger.kernel.org List-ID: On Fri, Oct 31, 2014 at 05:04:49PM +0000, Phil Edworthy wrote: > Hi Bjorn, > > On 31 October 2014 16:37, Bjorn wrote: > > On Fri, Oct 31, 2014 at 7:43 AM, Phil Edworthy > > wrote: > > > Hi Lorenzo, > > > > > > On 30 October 2014 11:45, Lorenzo wrote: > > >> Most if not all ARM PCI host controller device drivers either ignore the > > >> domain field in the pci_sys_data structure or just increment it every > > >> time a host controller is probed, using it as a domain counter. > > >> > > >> Therefore, instead of relying on pci_sys_data to stash the domain number > > >> in a standard location, ARM pcibios code can be moved to the newly > > >> introduced generic PCI domains code, implemented in commits: > > >> > > >> commit 41e5c0f81d3e676d671d96a0a1fafb27abfbd9 > > >> ("of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr()") > > >> > > >> commit 670ba0c8883b576d0aec28bd7a838358a4be1 > > >> ("PCI: Add generic domain handling") > > >> > > >> In order to assign a domain number dynamically, the ARM pcibios defines > > >> the function, called by core PCI code: > > >> > > >> void pci_bus_assign_domain_nr(...) > > >> > > >> that relies on a DT property to define the domain number or falls back to > > >> a counter; its usage replaces the current domain assignment code in PCI > > >> host controllers present in the kernel. > > >> > > >> Cc: Arnd Bergmann > > >> Cc: Phil Edworthy > > >> Cc: Jason Gunthorpe > > >> Cc: Jingoo Han > > >> Cc: Bjorn Helgaas > > >> Cc: Russell King > > >> Cc: Mohit Kumar > > >> Signed-off-by: Lorenzo Pieralisi > > > > > > This patch fixes a current problem with R-Car devices where there is an > > > internal PCI bridge and an external PCIe bridge on the devices. Both drivers > > > work independently but need to be on different domains. Just needed to > > enable > > > PCI_DOMAINS along with this. > > > I've done basic testing that the internal PCI and external PCIe work at the > > > same time. > > > > Hi Phil, > > > > Thanks for testing this. Can you give me some more guidance on where > > you'd like to see this merged? Until your comment about this fixing a > > current problem on R-Car, I probably would have considered this to be > > a cleanup and enhancement and hence material for v3.19. But if R-Car > > is actually broken and this fixes it, maybe this should go in for > > v3.18 instead. > I don’t think its urgent as most of our customers use LTSI kernels, e.g. v3.10. > Renesas typically provide out-of-tree BSPs with upstream code back ported, along > with other patches. Simon Horman (Renesas maintainer, cc'd) generally handles > the back ports, so I'll defer to his opinion. Hi Phil, from my point of view it would be best if this went into -stable if it is a fix. However, as you point out, from a customer point of view it shouldn't be a big deal as they should get backports via our LTSI kernel regardless of if the patch goes through stable or not. > > If it is currently broken, is there a point where it broke? I assume > > it used to work at one time. If there's a commit that broke it, it > > would be nice to reference that in the changelog and explain exactly > > what was broken and how this fixes it. > Both the internal PCI and external PCIe drivers work on their own, but have > never worked at the same time. I think it was just unfortunate timing when I > added the PCIe driver. At that time, the internal PCI driver didn’t have the > relevant DT nodes for the board I was using so I didn't see any conflicts. > > Thanks > Phil