From: ddaney@caviumnetworks•com (David Daney)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs.
Date: Fri, 18 Sep 2015 18:00:28 -0700 [thread overview]
Message-ID: <55FCB3AC.8080709@caviumnetworks.com> (raw)
In-Reply-To: <2512701.zkjk3n3AQS@wuerfel>
On 09/18/2015 12:45 PM, 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 <david.daney@cavium•com>
>>>>
>>>> The on-chip devices all have fixed bars. So, fix them up.
>>>>
>>>> Signed-off-by: David Daney <david.daney@cavium•com>
>>>>
>>>
>>> You should be able to just mark the BARs as fixed in DT
I think we can switch to PCI_PROBE_ONLY, and have all non-fixed BAR
devices configured by firmware. This may significantly simplify any
quirks required in the kernel.
>>
>> 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
>
next prev parent reply other threads:[~2015-09-19 1:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 22:41 [PATCH 0/3] PCI: Add support for Cavium ThunderX RC and on-SoC devices David Daney
2015-09-17 22:41 ` [PATCH 1/3] PCI: Allow quirks to override SRIOV BARs David Daney
2015-09-17 22:41 ` [PATCH 2/3] PCI: Add quirks for devices found on Cavium ThunderX SoCs David Daney
2015-09-18 7:19 ` Arnd Bergmann
2015-09-18 17:00 ` David Daney
2015-09-18 19:45 ` Arnd Bergmann
2015-09-19 1:00 ` David Daney [this message]
2015-09-22 13:19 ` Bjorn Helgaas
2015-09-23 16:24 ` David Daney
2015-09-22 15:39 ` Lorenzo Pieralisi
2015-09-22 19:33 ` Arnd Bergmann
2015-09-17 22:41 ` [PATCH 3/3] PCI: generic: Add support for Cavium ThunderX PCIe root complexes David Daney
2015-09-22 16:05 ` Lorenzo Pieralisi
2015-09-22 16:13 ` David Daney
2015-09-22 16:40 ` Lorenzo Pieralisi
2015-09-22 16:56 ` David Daney
2015-09-22 18:52 ` Will Deacon
2015-09-22 19:02 ` David Daney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55FCB3AC.8080709@caviumnetworks.com \
--to=ddaney@caviumnetworks$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox