From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from kirsty.vergenet.net ([202.4.237.240]:38711 "EHLO kirsty.vergenet.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752227AbcB2Ag0 (ORCPT ); Sun, 28 Feb 2016 19:36:26 -0500 Date: Mon, 29 Feb 2016 09:36:18 +0900 From: Simon Horman To: Phil Edworthy Cc: Geert Uytterhoeven , Bjorn Helgaas , Magnus Damm , linux-pci , "linux-renesas-soc@vger.kernel.org" Subject: Re: [PATCH] PCI: rcar, rcar-gen2: Use ARCH_RENESAS Message-ID: <20160229003618.GA25079@verge.net.au> References: <1456361156-16798-1-git-send-email-horms+renesas@verge.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: Sender: linux-pci-owner@vger.kernel.org List-ID: On Fri, Feb 26, 2016 at 09:22:04AM +0000, Phil Edworthy wrote: > Hi Geert, > > On 25 February 2016 08:05, Geert Uytterhoeven wrote: > > On Thu, Feb 25, 2016 at 1:45 AM, Simon Horman > > wrote: > > > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE. > > > > > > This is part of an ongoing process to migrate from ARCH_SHMOBILE to > > > ARCH_RENESAS the motivation for which being that RENESAS seems to be a > > more > > > appropriate name than SHMOBILE for the majority of Renesas ARM based > > SoCs. > > > > > > Signed-off-by: Simon Horman > > > > Acked-by: Geert Uytterhoeven > > > > > --- a/drivers/pci/host/Kconfig > > > +++ b/drivers/pci/host/Kconfig > > > > > @@ -49,7 +49,7 @@ config PCI_RCAR_GEN2 > > > > > > config PCI_RCAR_GEN2_PCIE > > > bool "Renesas R-Car PCIe controller" > > > - depends on ARCH_SHMOBILE || (ARM && COMPILE_TEST) > > > + depends on ARCH_RENESAS || (ARM && COMPILE_TEST) > > > help > > > Say Y here if you want PCIe controller support on R-Car Gen2 SoCs. > > > > BTW, this looks like a misnomer: the driver supports a compatible value for > > R-Car H1, too ("renesas,pcie-r8a7779"), but it's not used in r8a7779.dtsi. > IIRC, H1 PCIe support was nobbled in some way that meant you could not > use it with any normal PCIe card. You could connect to another R-Car that > was acting as an endpoint though. It sounds like that might be worth documenting somewhere. In any case, I think we could s/Gen2 // in the text above.