Messages in this thread | | | Date | Thu, 03 Nov 2005 09:33:28 -0800 (PST) | Subject | post-2.6.14 USB change breaks sparc64 boot | From | "David S. Miller" <> |
| |
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/
| |