linux-kernel - Re: PCI-Express root complex quirk in virtual P2P bridge

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1D49C522-F1EC-4708-800E-523C126C69D2@kernel.crashing.org>
Date:	Wed, 13 Jun 2007 08:11:07 -0500
From:	Kumar Gala <galak@...nel.crashing.org>
To:	David Miller <davem@...emloft.net>
Cc:	linux-pci@...ey.karlin.mff.cuni.cz, gregkh@...e.de,
	benh@...nel.crashing.org, linux-kernel@...r.kernel.org
Subject: Re: PCI-Express root complex quirk in virtual P2P bridge


On Jun 13, 2007, at 1:40 AM, David Miller wrote:

> From: Kumar Gala <galak@...nel.crashing.org>
> Date: Wed, 13 Jun 2007 01:26:33 -0500
>
>> I was hoping to get some guidance on how to handle a quirk in how the
>> virtual P2P bridge works on some embedded PowerPC PCI-Express root
>> complex controllers.  In the controllers I'm dealing with when we
>> change PCI_PRIMARY_BUS in pci_scan_bridge the ability to send config
>> cycles to the controller itself becomes effected.  The controller
>> only sends config cycles internally if the bus # in the config cycle
>> matches the PCI_PRIMARY_BUS.  We end up going from being 0 to 3 in
>> the particular setup and at the point we set PCI_PRIMARY_BUS to 3 we
>> are no longer able to send internal config cycles.
>>
>> What we need is that either a quirk or pcibios code needs to get call
>> right after we set PCI_PRIMARY_BUS so we can fixup the bus number
>> relationship.  I was wondering if anyone had suggestions on how best
>> to handle this.
>
> I would suggest building the PCI device tree using the OF device tree.
> 64-bit PowerPC does this already, perhaps you can use some of the
> existing code for your case too.

Unfortunately that isn't really an option, since on the embedded side  
we allow the device tree to be much simpler.  For example, we dont  
require the firmware to produce a full PCI device tree and populate  
the device tree with it.  A lot of embedded PPCs use linux as the pci  
bios.

> Sparc64 does as 64-bit PowerPC does.

Both of these platforms do it because their OF implementations are  
more complete than anything we'd see on the embedded side.

> I can't even program the PCI-E root controller in PCI config space on
> sparc64 Niagara systems, so I just virtualize it.

- k
-
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/