From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753858AbbIRTqa (ORCPT ); Fri, 18 Sep 2015 15:46:30 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:52508 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752962AbbIRTq2 (ORCPT ); Fri, 18 Sep 2015 15:46:28 -0400 From: Arnd Bergmann To: David Daney Cc: 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: Fri, 18 Sep 2015 21:45:50 +0200 Message-ID: <2512701.zkjk3n3AQS@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <55FC4330.10302@caviumnetworks.com> References: <1442529694-1792-1-git-send-email-ddaney.cavm@gmail.com> <3066583.BWDZlYWxXU@wuerfel> <55FC4330.10302@caviumnetworks.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:goY4mh5nvmCSgbr6QxB+DxBHtMLp5jzqO7yNywYABEwWORKW3eV ZPSlyMxOqdjXyhIBhlocdfXQOlzxBKxdQcXrVyaOxy2Y4QI2WNSEC9B6S2EZVkcCiRzypjG JuwB3Mnyyb869PX6bbbwpJwh972GBVTlfrJM3Y8W1ftUlfI+fbS57rT7C6Klss07FbnxkqC 2KkP8QyBgKbPxNqP2oTKw== X-UI-Out-Filterresults: notjunk:1;V01:K0:tAB9OD0mscc=:Fvznae/XDRD0SITUAtOtvN g4kGgYXTZ+7QdIQHBiufWyVcIW/wg4eZO1LvfJ48NfSYqvfQkhSagmrkdPOGOspP76YYoz0Pb CPTJxGbqAc+jBUM3vrkS0hVwTCgDPi2k++zxkjHMWIX3dqdlzSru0aYTDfdi1SiOy1Kh6FRIO 09shtYGp+N2fJlDwL1B0QYCdqASYmkclNwakgf6O8LS9+nSud5IcEnFJOmrtBoiYV/kA/8r+E GAkcx19MaZlYfE1YVR4LMfoFL5bRfJ2uuIvZGU+bbTeHTiIRNsvGpwJmt3ggritmpEsgxUulh x4HVMDOONpvZ0Qs6VHfapeqSSgZdGy2y6Erk2UTECExMvfkRufzM6sbn/7l8zmDAXQoqRTycp 4K91nq+nZJIXAEZmcfKVwpbe4FYn83OUwJmi29IYp6p5tgyiErlPFtQuEyDsoCdhPtG7+W+dJ NDe2bYTZ4S+M8qSBu8kf4DVCIIPGCSK68dI+iegEo4nSG+TkR9ILYsh5hYIiICag0np3xv2zh hn9njqfZ1R/1SEdtBT46GcFn/3VlDCau8ENv20XBl+dvqAINzBLobRuMJnbgde4RK3WmU4G9y 8jq0hUV78sWAvCOg1PFmX9/RTefdql82eL6BxEJToiGusRxx++ikBLE/OyQmy3kqP7Gb1GKa5 4wgzewvlpTETk79l8Y/BGvEWBGH8UOSoFTPU7R4ncgMoX8O6NdVfop4lat7sGHVAITlqaYwMl LjMQTs8yLBCwFFku Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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. The PCI binding traditionally requires you to list all PCI devices in DT, Linux as an extension (for the flattened DT format) allows leaving out the devices, but in this case you probably need to list every device that has a fixed BAR. > Yes, it is a bit of a hack. That is why I put it in its own file, and > only try to hack up PCI devices that exactly match the vendor and device > ids that need fixing. > > IMHO, putting infrastructure into drivers/pci/probe.c, et al. to handle > this would be much more intrusive. My guess is that it's already there, but even if it's not, this is a generic well-defined case that has a standardized binding, and we should implement that. > For the record: The PCI Enhanced Allocation (EA) capability (approved > by PCI SIG on 23 October 2014) is the proper way to handle this going > forward. However, this is not yet implemented in the SoCs that this > patch addresses. Our plan is to implement the EA capability in the core > PCI code, so that we do not need to keep adding devices to this fixup code. Good, but still this should only be required for the embedded case where you don't have a firmware to probe the bus. Arnd