Re: [linux-usb-devel] Re: Commit "[PATCH] USB: Always do usb-handoff" breaks my powerbook

From: Kyle Moffett
Date: Mon Oct 31 2005 - 23:07:33 EST


On Oct 31, 2005, at 22:09:32, David Brownell wrote:
Which logic? The fundamental thing those USB handoff functions do is make sure that BIOS code lets go of the host controllers. The main reason it'd be using a controller is because of USB keyboards, mice, or maybe boot disks. Secondarily, that code needs to make sure the controller is really quiesced before Linux starts using it.

So you rant about "ppc specific" whatever while the entire point of this code is to workaround x86 specific BIOS junk ...

Actually any "sophisticated" boot loader nowadays will know something about USB, to handle keyboards, mice, or maybe boot disks.

OpenFirmware is quite knowledgeable about USB devices, both disks, mice, keyboards, and IIRC there's even a USB<=>serial bridge useable as an OpenFirmware console.

On some platforms, u-Boot understands OHCI ... so that's not just x86 BIOS or other closed-source firmware.

On other platforms, OpenFirmware supports direct ELF loading without any extra code. If you want initrd support, you need a little Forth script (IE: yaboot) to load it into some RAM first.

The difference is, OpenFirmware is nice and clean and stops messing with hardware before handing off to the new kernel. If you ever try to boot from an invalid ELF file on an OpenFirmware machine, you'll see that's fairly obvious, because the screen flashes and changes state slightly during the failed boot attempt (after which it reconnects to the hardware again to display messages).

Why should x86-specific-BIOS-USB-handoff-specific-crap-PCI-quirks be even _compiled_ on PowerPC systems that have nothing remotely like the affected hardware (BIOS & PS/2 serio chip)?

Cheers,
Kyle Moffett

--
Simple things should be simple and complex things should be possible
-- Alan Kay



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/