Aleš, You're right. The code was not meant to be final commit or anything. Just a base for discussion. I have added a filter for the chipset in question in my code, but I'm more curious about odd cases. What happens if BIOS intentionally sets ports to USB 3.0 in the port routing registers of said chipset? Will all OS drivers handle that I have routed the ports to the EHCI controller? Or will stuff break, but the other way around? Linux does this on _shutdown_ which means that it assumes, that whatever BIOS does it will be beneficial for the OS booting. We do this on boot, after BIOS, which means we could be breaking stuff instead.
Regards, Christian > -----Original Message----- > From: grub-devel-bounces+christian.melki=saabgroup....@gnu.org > [mailto:grub-devel-bounces+christian.melki=saabgroup....@gnu.org] On > Behalf Of Aleš Nesrsta > Sent: den 19 december 2013 21:51 > To: The development of GNU GRUB > Subject: Re: [PATCH]: xHCI/EHCI - Windows - BIOS bug interaction. > > Dne 19.12.2013 12:33, Melki Christian (consultant) napsal(a): > >... > > I'm not an USB expert. :) > In this case we are two... :) > > > According to your patch: > Even if this patch looks good for me, I am afraid it is not good way to > handle xHCI from EHCI module. > > From my point of view it is maybe little bit better to prepare some > "empty" skeleton of xHCI module and include it in GRUB. > Such "driver": > - will do the thing of your patch only > - will be loaded manually only if necessary (or automatically by some > hardcoded dependency on EHCI module - ? In such case it probably should > include also some Product/Vendor filter or whatever else...) > - could be more easily substituted by real xHCI driver module > > My initial simple proposal of "empty" xHCI module, based on your e-mail > and patch, is included. > Note: This is proposal code only, I didn't compile it nor tested... > > BR, > Ales _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
