post-2.6.14 USB change breaks sparc64 boot

["David S. Miller" <davem@davemloft.net>]

This change:

diff-tree 478a3bab8c87a9ba4a4ba338314e32bb0c378e62 (from 46f116eab81b21c6ae8c4f169498c632b1f94bf1)
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Oct 19 12:52:02 2005 -0400

    [PATCH] USB: Always do usb-handoff
    
    This revised patch (as586b) makes usb-handoff permanently true and no
    longer a kernel boot parameter.  It also removes the piix3_usb quirk code;
    that was nothing more than an early version of the USB handoff code
    (written at a time when Intel's PIIX3 was about the only motherboard with
    USB support).  And it adds identifiers for the three PCI USB controller
    classes to pci_ids.h.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

breaks sparc64 bootup badly on machines with USB host controllers.

The reason is that this fixup is run as a PCI header fixup, but at
that time it is not yet legal to do ioremap() on the PCI device's
resources.  This USB fixup does ioremap() calls so that it can program
a few of the host controller registers during bootup.  It fails
spectacularly since the PCI device resource values haven't been been
adjusted by the sparc64 PCI layer yet.

The platform layer first needs a chance to fixup the pdev->resource[]
values to the format the ioremap() expects, and this is done after the
PCI header fixups are executed.  On platforms where this matters, such
adjustments are made immediately after the pci_scan_bus() invocation.

So ioremap() calls during pci_scan_bus() are pretty much not allowed.

Perhaps pci_fixup_final would be a more appropriate time to run this
USB host controller fixup?  One downside to this is that such calls
would not be invoked for hot-plugged USB host controller devices.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/