[patch 21/28] PCI: lets kill the PCI hidden behind bridge message

[patch 21/28] PCI: lets kill the PCI hidden behind bridge message

Post by Greg K » Sat, 25 Aug 2007 07:40:09


stable review patch. If anyone has any objections, please let us know.

------------------

From: Bernhard Kaindl < XXXX@XXXXX.COM >

Adrian Bunk wrote:

Ok, lets kill the message. As Alois Nepor also saw, that's fixed up by Yenta,
so PCI does not have to warn about it. PCI could still warn about it if
is_cardbus is 0 in that instance of pci_scan_bridge(), but so far I have
not seen a report where this would have been the case so I think we can
spare the kernel of that check (removes ~300 lines of asm) unless debugging
is done.

History: The whole check was added in the days before we had the fixup
for this in Yenta and pci=assign-busses was the only way to get CardBus
cards detected on many (not all) of the machines which give this warning.

In theory, there could be cases when this warning would be triggered and
it's not cardbus, then the warning should still apply, but I think this
should only be the case when working on a completely broken PCI setup,
but one may have already enabled the debug code in drivers/pci and the
patched check would then trigger.

I do not sign this off yet because it's completely untested so far, but
everyone is free to test it (with the #ifdef DEBUG replaced by #if 1 and
pr_debug( changed to printk(.

We may also dump the whole check (remove everything within the #ifdef from
the source) if that's perferred.

On Alois Nepor's machine this would then (only when debugging) this message:

"PCI: Bus #0b (-#0e) is partially hidden behind transparent bridge #0a (-#0b)"

"partially" should be in the message on his machine because #0b of #0b-#0e
is reachable behind #0a-#0b, but not #0c-#0e.

But that differentiation is now moot anyway because the fixup in Yenta takes
care of it as far as I could see so far, which means that unless somebody
is debugging a totally broken PCI setup, this message is not needed anymore,
not even for debugging PCI.


Ok, here the patch with the following changes:

* Refined to say that the bus is only partially hidden when the parent
bus numbers are not totally way off (outside of) the child bus range
* remove the reference to pci=assign-busses and the plea to report it

We could add a pure source code-only comment to keep a reference to
pci=assign-busses the in case when this is triggered by someone who
is debugging the cause of this message and looking the way to solve it.

From: Bernhard Kaindl < XXXX@XXXXX.COM >
Signed-off-by: Greg Kroah-Hartman < XXXX@XXXXX.COM >

---
drivers/pci/probe.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)

--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -643,20 +643,20 @@ int pci_scan_bridge(struct pci_bus *bus,

sprintf(child->name, (is_cardbus ? "PCI CardBus #%02x" : "PCI Bus #%02x"), child->number);

+ /* Has only triggered on CardBus, fixup is in yenta_socket */
while (bus->parent) {
if ((child->subordinate > bus->subordinate) ||
(child->number > bus->subordinate) ||
(child->number < bus->number) ||
(child->subordinate < bus->number)) {
- printk(KERN_WARNING "PCI: Bus #%02x (-#%02x) is "
- "hidden behind%s bridge #%02x (-#%02x)%s\n",
- child->number, child->subordinate,
- bus->self->transparent ? " transparent" : " ",
- bus->number, bus->subordinate,
- pcibios_assign_all_busses()
 
 
 

1. [v1 PATCH 1/1] PCI: Add AMD8111 PCI Bridge PCI Device ID

2. Updating PCI/PCI Express configuration values for PCI/PCI Express bridge

Hi

I wrote message couple days before but i didn't receive any answer.
I'll try to get more details for the problem.

I'm writing application and driver for PCI/PCI Express extender (like
this one: http://www.yqcomputer.com/ ;http://
www.amfeltec.com/index.php?id=1&subid=6>). The extender is used for
testing/debugging PCI/PCI Express cards.
The application is execute IOCTL call to my driver that reads PCI/PCI
express configuration registers (PCI_COMMON_CONFIG structure) of
tested card (there is no connection between my driver and driver of
tested card). Than, the user can switch off the extender and remove
the tested card from the extender. After this, the user can put back
tested card and restore PCI/PCI Express configuration register using
my application by executing call into my driver. At this point, the
user can use the tested card as before.

I have version of my application/driver under Windows 2000 that uses
Halsetbusdata/Halgetbusdata function in order to read and write
configuration register from/into pci devices. These functions are
required only bus/slot number as a parameters.
The problem is happened under Windows XP. These functions are not
available for PCI/PCI Express bridge devices (i.e. when i have PCI/PCI
express bridge on my tested card). I found that i need to use
IRP_MN_QUERY_INTERFACE and IRP_MN_WRITE_CONFIG requests instead. But,
i don't have device objects for the tested driver so i can send IRP
request.

Can you suggest some solution for this problem under Windows XP.

If you need more information, please let me know.

Thank you.
Alex

3. [PATCH] PCI: handle subtractive decode pci-pci bridge better

4. [PATCH 1/2] PCI-PCI transparent bridge handling improvements (pci core)

5. [PATCH 21/42]: PCI: cleanup/simplify ppc64 PCI hotplug code

6. ASUS K8N-DL Beta BIOS AKA PROBLEM: Devices behind PCI Express-to-PCI bridge not mapped

7. ASUS K8N-DL Beta BIOS AKA PROBLEM: Devices behind PCI Express-to-PCI bridge not mapped

8. ASUS K8N-DL Beta BIOS AKA PROBLEM: Devices behind PCI Express-to-PCI bridge not mapped

9. FW: PROBLEM: Devices behind PCI Express-to-PCI bridge not mapped

10. ASUS K8N-DL Beta BIOS AKA PROBLEM: Devices behind PCI Express-to-PCI bridge not mapped

11. PROBLEM: Devices behind PCI Express-to-PCI bridge not mapped

12. FW: PROBLEM: Devices behind PCI Express-to-PCI bridge not mapped

13. FW: PROBLEM: Devices behind PCI Express-to-PCI bridge not mapped

14. FW: PROBLEM: Devices behind PCI Express-to-PCI bridge not mapped

15. PCI Standard PCI-to-PCI Bridge