On 1 March 2017 at 07:57, Andrei Borzenkov <[email protected]> wrote: > Yes, Bjørn Forsman intended to work on implementation.
So now is apparently a good time to tell you about the status of that implementation :-) The good: I ported the xHCI driver from Coreboot / libpayload to GRUB. In basic tests, it works. (I tested a Lenovo G50-80 laptop with Intel Wildcat Point-LP USB xHCI controller [8086:9cb1].) The bad: The code doesn't support HUBs and completely hangs on one xHCI controller I tested (Intel NUC6i5SYH Skylake with Sunrise Point-LP xHCI USB controller [8086:9d2f]). The HUB problem is due to GRUB using a different code path for HUBs than normal devices. I implemented hooks for "control_transfer" and "bulk_transfer" in GRUB USB stack, because that required little changes and it made it easy to hook it up with the xHCI driver. But when GRUB sees a HUB, it uses the "old" setup_transfer code path which isn't implemented in the xHCI driver. I'm thinking the "hanging" issue (the controller never responds to a basic "NOP" command) is a problem with the Coreboot driver itself, or more specifically, the lack of a "quirk" handling for this controller. But blaming that driver doesn't fix it. About the implementation. I tried to change as little code as possible, both in GRUB and the Coreboot driver, thinking that it'd make maintenance easier. My reasoning was (perhaps wrongly?) that there is little help to get in the community, and if I reuse enough of the Coreboot driver, I can easiliy re-import the driver if/when they fix some bugs. This "change as little as possible" policy means that now the xHCI driver initializes and tracks some state that also GRUB USB stack does. It works but it's not something I think is good enough to integrate in mainline GRUB. (That's one of the reasons why I didn't tell you about the status earlier. I don't see how to make it "clean" enough for mainline. Also, the above issues are sort of blockers in themselves.) The ugly :-) https://github.com/bjornfor/grub/tree/add-coreboot-xhci-driver-2nd-attempt-v2 (I just cleaned up history and rebased on master, so it's less ugly than it was a few hours ago.) Best regards, Bjørn Forsman _______________________________________________ Grub-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/grub-devel
