From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934303AbbIVTeN (ORCPT ); Tue, 22 Sep 2015 15:34:13 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:54592 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934060AbbIVTeL (ORCPT ); Tue, 22 Sep 2015 15:34:11 -0400 From: Arnd Bergmann To: Lorenzo Pieralisi Cc: David Daney , "linux-arm-kernel@lists.infradead.org" , David Daney , "linux-kernel@vger.kernel.org" , Bjorn Helgaas , "linux-pci@vger.kernel.org" , Will Deacon , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , "devicetree@vger.kernel.org" , Marc Zyngier , David Daney Subject: Re: [PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs. Date: Tue, 22 Sep 2015 21:33:25 +0200 Message-ID: <1763517.VsvPY9OlHW@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20150922153931.GD17444@red-moon> References: <1442529694-1792-1-git-send-email-ddaney.cavm@gmail.com> <2512701.zkjk3n3AQS@wuerfel> <20150922153931.GD17444@red-moon> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:aVwMKDaEhTddqzaUO2B2U4ArM/F0D0x6SgpjoyN2XyTm2+VaqZt WYUCB63KqPB6qdIFvMP3nrWNF+JCH0WxQ3nhmCE1LRpLOaf0rouhWx7VwZvYUmDKk1L8Wfd ssNVEAjvEo4Cq08h9P3vpjlbRO5JBgjIZDjquQndtPgaGzTzUBy1Ef2jb1LHmcf1/14weVn IwbmkN5PCBzDsgdyF5WVw== X-UI-Out-Filterresults: notjunk:1;V01:K0:wWcsNOpcSgw=:FdzGjctdl8RbPaw40kIyab RK4p7ha5R+N8vUMOr3Fcwxnaj7ftW1UufVCuuukL5Wvz3KCbHcwweEHOSY/bN4t3mVzsB27/+ 0JzyGLNH/Xbw0y69m9twUkUhr9ObciAMp9B4VCsmMLxvAunYO7z4t8jIVRGdOgZyQkzfRd82t zz0LuBlKhq0rC4Ee/fywpkmwvXTrpstuuIfDf5uVrld0SgARxWL8g2fSJAfvyscR3sn+KHdaB 9Wv7ug5EGoALsIu+eJu7m1Co6oXw8HxiAjc6trQXHG/t9QxyY0Dvm4FJuFN98s11SfsQyZpMc r2hUipacGVXZ2wUziaz5aLp2TObTGwudt6vjRv8T2C5EQ1FRGgyCnO5xkZZmz1/VFMolAk4rC H2TFmGaRsjg+8fCfs8sRCOvDQhLMh8YsGW9i6/jmx+M/3bUjTT+u4+CjVI2KKCJI3DQahn5+e o+XzF12Qg/0nxu1GZTGiZkmaqMmY55iT84MT9abovTxbtm4IzuZBG2pKqvy20A19xOs0NCm1S 7os6jxt2iuSMSZwz0DfHzXR5E3YynxnjRzk6lOTJ2pd7mmyg4dmH8mJxVXjNEixB+/QB+O/EQ MNYGdTZMvTbB0pglIDQxndETo+r1wlBy6aNdeSJPaYUFQ5VRpIkaGizAlmfYJs3xuGYLLcxAL q7zmRcRmU4M7/ge70+ftMN7EAu7hHo9CgXJ1jBV3G6nY0V3aKK+Apf/DvC4aA0FPp/iaPm3oP L4XQJ0g2YI6MT7R/ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 22 September 2015 16:39:31 Lorenzo Pieralisi wrote: > On Fri, Sep 18, 2015 at 08:45:50PM +0100, Arnd Bergmann wrote: > > On Friday 18 September 2015 10:00:32 David Daney wrote: > > > On 09/18/2015 12:19 AM, Arnd Bergmann wrote: > > > > On Thursday 17 September 2015 15:41:33 David Daney wrote: > > > >> From: David Daney > > > >> > > > >> The on-chip devices all have fixed bars. So, fix them up. > > > >> > > > >> Signed-off-by: David Daney > > > >> > > > > > > > > You should be able to just mark the BARs as fixed in DT > > > > > > In the case of ACPI, there is no DT. So we would need a different > > > solution for ACPI. What would you recommend for ACPI? > > > > I would expect that this does not matter at all on ACPI, because > > the devices that need it are not hot-plugged, and all boot-time > > devices are probed by the firmware: the ACPI PCI implementation > > does not reassign any BARs, except for the hotplug case. > > What do you mean by "the ACPI PCI implementation does not reassign > any BARs" ? Do you mean on x86 ? The resource assignment is part > of the resource survey on x86, where all resources that can be claimed > are claimed, but still, some of them may be still reassigned IIUC. The ACPI PCI implementation should be completely architecture independent and do the same thing everywhere. The code is spread over drivers/acpi/pci*, with small parts currently residing in arch/{x86,ia64} that need to be moved to drivers/acpi/ > On arm64 we do not carry out any resource survey at present, but > if we do (and we should), it will have to work for both DT and ACPI > systems. This is not a difference between DT and ACPI, but a difference between embedded and server. Server platforms that have a proper firmware to scan the PCI bus should not set PCI_REASSIGN_ALL_RSRC and PCI_REASSIGN_ALL_BUS, while embedded systems that don't set up the PCI bus before boot have to set those. On ACPI, reassigning the resources would actually be dangerous because the firmware may rely on devices to be at a certain location (both bus number and mmio address), or may play tricks here to hide stuff from the OS. > > > Also, can you point me to the OF device tree specification where it > > > tells how to specify PCI BAR addresses, I would especially be interested > > > in knowing how to specify fixed SRIOV BAR addresses in the device tree. > > > > This is the 'n' bit mentioned sections 2.1.3 and 2.2.1.1 of the > > PCI binding. When it is set, the OS is not supposed to try to > > reassign the BAR even on machines that otherwise do a complete > > rescan. > > I do not see any code in the kernel taking care of that bit and > if I am not mistaken the code that allows creating pci devices > exists in PowerPC arch code (arch/powerpc/kernel/pci_of_scan.c) and > should be moved out of there for the other arches to use it. > > Or maybe we can use DT just to fix-up the resource flags (ie > every PCI device will have its own of_node set if it is present > in the DT, we can use it to fixup its resources and related flags, > pcibios_add_device() ?). I haven't looked at the code in detail now, but I'm pretty sure that a device node that refers to a PCI device is connected to the dev->of_node pointer already on all architectures. It's quite possible that we never implemented the fixed BAR logic though, but it can be done based on those pointers. Arnd