Attachment 82866 Details for Bug 146438

detailed description of the patch for understanding and veriflying it

yenta_fixup_parent_subordinate.txt (text/plain), 5.37 KB, created by Bernhard Kaindl on 2006-05-10 18:06:30 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Bernhard Kaindl

Created: 2006-05-10 18:06:30 UTC

Size: 5.37 KB

patch

obsolete

>Description of the patch:
>=========================
>
>Intro:
>------
>
>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 needs to do in order to make the hidden devices work:
>--------------------------------------------------------------------
>The patch needs to ensure that the parent PCI-PCI bridge of the Cardbus
>Controller is configured so that Type 1 PCI configuration cycles reach
>the devices in the CardBus slots so that they are found and initialized
>
>The only cases where it has been found that a parent bridge of
>one or more cardbus bridges was not configured in this way were
>numerous laptops where the parent bridge of the cardbus bridge
>is a PCI-PCI bridge and it's subordinate bus number is lower
>than the subordinate bus number of the cardbus bridge.
>
>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.
>
>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, see the patch itself for reference, this is written from
>reading and checking the patch, not from memory. It also contains
>comments to help you to match this description with the source,
>but this description was not written from reading the comments,
>only from checking the source, it's excatly what it really does
>and since the patch was developed, it was tested on many machines,
>and there are no error reports.

Actions: View

Attachments on bug 146438: 67478 | 67479 | 67480 | 67481 | 67482 | 67483 | 67588 | 76677 | 76844 | 77254 | 78078 | 78105 | 79337 | 82866