linux-kernel - Re: [PATCH] arm64/pci: Add quirks for Cavium Thunder PCI bridges.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 24 Nov 2015 14:26:42 -0800
From:	David Daney <ddaney@...iumnetworks.com>
To:	Bjorn Helgaas <helgaas@...nel.org>
CC:	David Daney <ddaney.cavm@...il.com>,
	<linux-kernel@...r.kernel.org>, Will Deacon <will.deacon@....com>,
	<linux-arm-kernel@...ts.infradead.org>,
	Marc Zyngier <marc.zyngier@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	<linux-pci@...r.kernel.org>, David Daney <david.daney@...ium.com>
Subject: Re: [PATCH] arm64/pci: Add quirks for Cavium Thunder PCI bridges.

On 11/24/2015 01:52 PM, Bjorn Helgaas wrote:
> Hi David,
>
> On Tue, Sep 22, 2015 at 05:09:56PM -0700, David Daney wrote:
>> From: David Daney <david.daney@...ium.com>
>>
>> The Cavium ThunderX SoC needs a PCI quirk for its on-chip bridges.
>> Since it is arm64, create a new quirks.c file there to contain arm64
>> related quirks.  Add the ThunderX bridge quirk, gated by a new config
>> variable, so that it can be disabled for kernels that aren't expected
>> to be used on ThunderX.
>
> Is this still needed?

No.

The EA patch set that you merged to 4.4 supersedes this.

> I've seen some follow-up Cavium stuff, but
> nothing further on this one.  If we still need it, we should figure
> out who should take it.  It's all under arch/arm64, so ordinarily I
> would leave it up to the arm64 guys.
>
>> Signed-off-by: David Daney <david.daney@...ium.com>
>> ---
>>   arch/arm64/Kconfig         | 11 +++++++++++
>>   arch/arm64/kernel/Makefile |  2 +-
>>   arch/arm64/kernel/quirks.c | 36 ++++++++++++++++++++++++++++++++++++
>>   3 files changed, 48 insertions(+), 1 deletion(-)
>>   create mode 100644 arch/arm64/kernel/quirks.c
>
>> +#ifdef CONFIG_CAVIUM_THUNDER_PCI_QUIRKS
>> +static void thunder_bridge_fixup(struct pci_dev *dev)
>> +{
>> +	/*
>> +	 * This bridge is broken in that it doesn't have correct
>> +	 * resource ranges for the buses behind it.
>> +	 *
>> +	 * The upstream bus resources are a close enough approximation
>> +	 * to what is needed, that they can be used instead.  Copy
>> +	 * upstream root bus resources so that resource claiming for
>> +	 * downstream devices can be done.
>> +	 */
>> +	int resno;
>> +	struct pci_bus *bus = dev->subordinate;
>> +
>> +	for (resno = 0; resno < PCI_BRIDGE_RESOURCE_NUM; resno++) {
>> +		bus->resource[resno] =
>> +			pci_bus_resource_n(bus->parent,
>> +					   PCI_BRIDGE_RESOURCE_NUM + resno);
>
> I am curious about this.  Is this a standard PCI-PCI bridge,

Yes it is PCI-PCI

> or is it
> a host bridge.  If the former, I guess it must be broken in some way
> that keeps the usual bridge window reading code from working?
>
> Copying the upstream bus resources to the downstream bus might sort of
> work sometimes, but seems fragile in general.  If the bridge has any
> peers, it seems like we're headed for a conflict between the peer's
> resources and anything downstream of the bridge.

The problem is that all the downstream devices require 64-bit 
non-prefetchable addressing, which cannot be satisfied with the bridge 
provisioning code.  EA allows this to be described.

In any event the patch is not needed now that the EA code is in place.

>
>> +	}
>> +}
>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, 0xa002, thunder_bridge_fixup);
>> +#endif /* CONFIG_CAVIUM_THUNDER_PCI_QUIRKS */
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/