Mailinglist Archive: opensuse-bugs (8080 mails)

< Previous Next >
[Bug 146438] cardbus cards not seen by kernel (parent bridge misconfigured)
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Thu, 1 Feb 2007 06:43:26 -0700 (MST)
  • Message-id: <20070201134326.CADA1FBF@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=146438


bk@xxxxxxxxxx changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED




------- Comment #45 from bk@xxxxxxxxxx 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.

< Previous Next >
This Thread
  • No further messages