https://bugzilla.novell.com/show_bug.cgi?id=146438 bk@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Comment #45 from bk@novell.com 2007-02-01 06:43 MST ------- The patch was submitted by the resplonsible maintainer to mainline http://lists.infradead.org/pipermail/linux-pcmcia/2006-June/003703.html and is in mainline since 2.6.18, so it did become part of 10.2 and this bug is fixed in all distributions which use a kernel based on 2.6.18 or newer. I wrote a detailed description of the patch which isn't found anywhere else so far, so I paste it here and close it: Short description: ------------------ This patch fixes detection of the CardBus cards in many notebooks due to a too low subordinate number of the parent PCI-PCI bridge It fixes the subordinate number of the parent PCI-PCI bridge of CardBus bridges when one is probed, before registering the CardBus bridge with the kernel and scanning its slot for devices. Longer description: ------------------- On a number of Laptops, the PCI scans do not find any CardBus cards because the parent bridge of the CardBus bridge is not configured so that Type 1 PCI configuration cycles can reach the CardBus cards. On one of the affected Laptops, a Samsung X20, Windows XP does a full pci bus renumbering, so the problem is not seen with Windows. Booting with pci=assign-busses does the same but since ACPI may contain references to PCI busses and we do not translate them yet, it may break things. The generic solution used in 2.6.13 was to only increase the subordinate number, but since this was done during PCI bus discovery, it was not safe to it at this point and taken out with the next release. This patch does the same but takes care that it can never cause create a PCI bus configuration with overlapping bus numbers which was the reason why the solution of 2.6.13 was moved to pci=assign-busses. Description of the fix: ======================= Principles: ----------- Reference: PCI-PCI Bridges: PCI Configuration Cycles and PCI Bus Numbering: http://www.science.unitn.it/~fiorella/guidelinux/tlk/node72.html --------------------------------------------------------------------------- It is up to each individual operating system to allocate bus numbers during PCI configuration but whatever the numbering scheme used the following statement must be true for all of the PCI-PCI bridges in the system: ``All PCI busses located behind a PCI-PCI bridge must reside between the seondary bus number and the subordinate bus number (inclusive).'' If this rule is broken then the PCI-PCI Bridges will not pass and translate Type 1 PCI configuration cycles correctly and the system will fail to find and initialise the PCI devices in the system. --------------------------------------------------------------------------- What the patch may not do: -------------------------- The patch may not raise the subordinate number of any PCI-PCI bridge so that it overlaps with the bus ranges of other PCI-PCI bridges. It has the checks neccesary to ensure that this does not happen. What the patch does: -------------------- Called from Cardbus controller probe function, before the controller is registered, so before the devices on it can be scanned, a new function call is inserted. This function works the following way:
If the parent of the cardbus parent is a root bridge, do nothing. (The root bridge does not hide Cardbus devices, it was always ok)
The parent of the cardbus bridge has been identified as the PCI-PCI bridge who's subordinate bus number may be raised to pass and translate Type 1 PCI configuration cycles so that they can reach the devices behind the CardBus brodge, it's called bridge_to_fix.
The subordinate number the parent of the bridge_to_fix is used as the initial upper limit to which we could theoretically raise the subordinate number of the bridge_to_fix. (there is no point in exceeding the range of the parent, childs will got get Type 1 PCI configuration cycles for those anyway)
For each child bridge of the parent bridge (equal to: for each silbling and the bridge_to_fix itself), do:
-> If the silbling's secondary bus number is higher than the subordinate of the bridge_to_fix (thus, it is a bridge which we have to care for when raising the subordinate of the bridge_to_fix to prevent overlapping) *and* if this silbling's secondary bus number is smaller than the upper limit, then update the upper limit to the secondary bus number of the silbling minus 1. This is repeated for all silbling bridges of the bridge_to_fix (and for the bridge_to_fix itself too, but for this to have any effect, it's secondary must be higher than it's subordinate which should never be the case but even if it is [then, the PCI config of it is totally broken and won't work anyway] is that the subordinate of it will only be raised to it's secondary minus one, so it won't have any effect) -> The upper_limit is then left at the last free bus number to which the subordinate of the cardbus parent bridge could be raised without reaching a bus number which is allocated for a different silbling bridge on the same bus and without leaving the bus range of the parent. I tested these checks to work by modifying the relevant data structures and verifying the results, so I certify that with all these tests, the upper limit was always right. If this upper limit is lower than the subordinate number of the cardbus bridge, a warning message which says which shows this constraint for raising the subordinate of the bridge_to_fix is logged. If the upper limit is higher than the subordinate of the bridge_to_fix (this means it could be raised to this limit, it is never reduced, so nothing can break), the following is done: The subordnate bus number to assign is set to the upper_limit or to the subordinate bus number of the cardbus bridge (this is the number which we want to have), whatever value is smaller. A message which logs that we raise the subordinate number of bridge_to fix to its new value is logged. The subordinate field of the PCI struct of the bridge_to_fix is set to the new subordnate bus number and the PCI config byte PCI_SUBORDINATE_BUS is set to the new number. That's it all. There are related follow-up bugs which are concerned with the kernel boot message which warns of hidden PCI busses, which is made obsolete by this patch for the cases which this patch fixes: * bug 237229 has the best initial comments * bug 225672 also tracks it (may be come a duplicate of 237229) * bug 191194 mentions it, but is about a different issue -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.