[PATCH]: xHCI/EHCI - Windows - BIOS bug interaction.

[PATCH]: xHCI/EHCI - Windows - BIOS bug interaction.

[Melki Christian (consultant)]

[-- Attachment #1: Type: text/plain, Size: 2298 bytes --]

Hi.

Request for comments (patch is a local repository patch) so far:

I noticed on some Dell 7010 machines the following behaviour with GRUB.

Machine is cold-booted. - > USB keyboard works in GRUB -> Windows boots -> Windows does warm reboot -> USB keyboard does not work in GRUB.
This only happens in the ports marked superspeed on the machine.
A quick dig into the subject revealed something of interest that Sarah Sharp added to Linux a while ago.
The problem is that Windows seems to leave the the SS ports in SS mode when rebooting and a BIOS bug(?) on warm boot leads to not setting the SS ports in 2.0 mode.
So in the ehci driver I identified the xHCI controller, disabled it and set all ports in 2.0 mode in the port routing register, much like Linux does.
This is a little odd, but I think GRUB needs this because it does not properly handle xHCI yet. GRUB needs to make sure that all ports are available as 2.0 mode ports.
It seems to fix my problems atleast.

Index: grub-core/bus/usb/ehci.c
===================================================================
--- grub-core/bus/usb/ehci.c    (revision 6009)
+++ grub-core/bus/usb/ehci.c    (working copy)
@@ -41,6 +41,8 @@
  */

 #define GRUB_EHCI_PCI_SBRN_REG  0x60
+#define GRUB_XHCI_PCI_XUSB2PR   0xD0
+#define GRUB_XHCI_PCI_USB3_PSSEN 0xD8

 /* Capability registers offsets */
 enum
@@ -507,6 +509,21 @@
       subclass = (class_code >> 8) & 0xFF;
       class = class_code >> 16;

+      /* This is an xHCI controller.
+       * Since GRUB does not currently handle xHCI we need
+       * to make sure it is disabled and the ports put in 2.0 mode.
+       * To be removed when xHCI is properly introduced.
+       */
+      if (class == 0x0c && subclass == 0x03 && interf == 0x30)
+        {
+          addr = grub_pci_make_address (dev, GRUB_XHCI_PCI_USB3_PSSEN);
+          grub_pci_write_word (addr, 0x0);
+          grub_pci_read_word(addr);
+          addr = grub_pci_make_address (dev, GRUB_XHCI_PCI_XUSB2PR);
+          grub_pci_write_word (addr, 0x0);
+          grub_pci_read_word(addr);
+        }
+
       /* If this is not an EHCI controller, just return.  */
       if (class != 0x0c || subclass != 0x03 || interf != 0x20)
        return 0;

Regards,
Christian



[-- Attachment #2: xhcifix.patch --]
[-- Type: application/octet-stream, Size: 2681 bytes --]

Index: grub-core/Makefile.core.def
===================================================================
--- grub-core/Makefile.core.def	(revision 6009)
+++ grub-core/Makefile.core.def	(working copy)
@@ -756,6 +756,17 @@
 };
 
 module = {
+  name = usbtest;
+  common = commands/usbtest.c;
+  enable = usb;
+};
+
+module = {
+  name = videoinfo;
+  common = commands/videoinfo.c;
+};
+
+module = {
   name = scsi;
   common = disk/scsi.c;
 };
Index: grub-core/soe/ee.c
===================================================================
--- grub-core/soe/ee.c	(revision 6009)
+++ grub-core/soe/ee.c	(working copy)
@@ -131,7 +131,7 @@
 static grub_err_t
 ee_test_ee(grub_disk_t disk)
 {
-    char buf[GRUB_DISK_SECTOR_SIZE];
+    char buf[GRUB_DISK_SECTOR_SIZE * 256];
     grub_uint16_t *idw;
     grub_uint16_t security;
 
Index: grub-core/normal/main.c
===================================================================
--- grub-core/normal/main.c	(revision 6009)
+++ grub-core/normal/main.c	(working copy)
@@ -354,15 +354,12 @@
 
 /* This starts the normal mode.  */
 void
-__attribute__((noreturn)) grub_enter_normal_mode (const char *config)
+grub_enter_normal_mode (const char *config)
 {
   grub_boot_time ("Entering normal mode");
   nested_level++;
   grub_normal_execute (config, 0, 0);
 
-  /* We dont want no stinkin' shell */
-  grub_reboot();
-
   grub_boot_time ("Entering shell");
   grub_cmdline_run (0);
   nested_level--;
Index: grub-core/bus/usb/ehci.c
===================================================================
--- grub-core/bus/usb/ehci.c	(revision 6009)
+++ grub-core/bus/usb/ehci.c	(working copy)
@@ -41,6 +41,8 @@
  */
 
 #define GRUB_EHCI_PCI_SBRN_REG  0x60
+#define GRUB_XHCI_PCI_XUSB2PR   0xD0
+#define GRUB_XHCI_PCI_USB3_PSSEN 0xD8
 
 /* Capability registers offsets */
 enum
@@ -507,6 +509,21 @@
       subclass = (class_code >> 8) & 0xFF;
       class = class_code >> 16;
 
+      /* This is an xHCI controller.
+       * Since GRUB does not currently handle xHCI we need
+       * to make sure it is disabled and the ports put in 2.0 mode.
+       * To be removed when xHCI is properly introduced.
+       */
+      if (class == 0x0c && subclass == 0x03 && interf == 0x30) 
+        {
+          addr = grub_pci_make_address (dev, GRUB_XHCI_PCI_USB3_PSSEN);
+          grub_pci_write_word (addr, 0x0);
+          grub_pci_read_word(addr);
+          addr = grub_pci_make_address (dev, GRUB_XHCI_PCI_XUSB2PR);
+          grub_pci_write_word (addr, 0x0);
+          grub_pci_read_word(addr);
+        }
+
       /* If this is not an EHCI controller, just return.  */
       if (class != 0x0c || subclass != 0x03 || interf != 0x20)
 	return 0;

RE: [PATCH]: xHCI/EHCI - Windows - BIOS bug interaction.

[Melki Christian (consultant)]

Addition:

Seems to be intel pantherpoint chipset specific.
So the issue is likely far smaller than I initially thought.
Code should probably be enclosed with vendor/product id test.
I'm not an USB expert. :)

Regards,
Christian

> -----Original Message-----
> From: grub-devel-bounces+christian.melki=saabgroup.com@gnu.org
> [mailto:grub-devel-bounces+christian.melki=saabgroup.com@gnu.org] On
> Behalf Of Melki Christian (consultant)
> Sent: den 19 december 2013 11:01
> To: grub-devel@gnu.org
> Subject: [PATCH]: xHCI/EHCI - Windows - BIOS bug interaction.
> 
> Hi.
> 
> Request for comments (patch is a local repository patch) so far:
> 
> I noticed on some Dell 7010 machines the following behaviour with GRUB.
> 
> Machine is cold-booted. - > USB keyboard works in GRUB -> Windows boots -
> > Windows does warm reboot -> USB keyboard does not work in GRUB.
> This only happens in the ports marked superspeed on the machine.
> A quick dig into the subject revealed something of interest that Sarah Sharp
> added to Linux a while ago.
> The problem is that Windows seems to leave the the SS ports in SS mode
> when rebooting and a BIOS bug(?) on warm boot leads to not setting the SS
> ports in 2.0 mode.
> So in the ehci driver I identified the xHCI controller, disabled it and set all
> ports in 2.0 mode in the port routing register, much like Linux does.
> This is a little odd, but I think GRUB needs this because it does not properly
> handle xHCI yet. GRUB needs to make sure that all ports are available as 2.0
> mode ports.
> It seems to fix my problems atleast.
> 
> Index: grub-core/bus/usb/ehci.c
> ==========================================================
> =========
> --- grub-core/bus/usb/ehci.c    (revision 6009)
> +++ grub-core/bus/usb/ehci.c    (working copy)
> @@ -41,6 +41,8 @@
>   */
> 
>  #define GRUB_EHCI_PCI_SBRN_REG  0x60
> +#define GRUB_XHCI_PCI_XUSB2PR   0xD0
> +#define GRUB_XHCI_PCI_USB3_PSSEN 0xD8
> 
>  /* Capability registers offsets */
>  enum
> @@ -507,6 +509,21 @@
>        subclass = (class_code >> 8) & 0xFF;
>        class = class_code >> 16;
> 
> +      /* This is an xHCI controller.
> +       * Since GRUB does not currently handle xHCI we need
> +       * to make sure it is disabled and the ports put in 2.0 mode.
> +       * To be removed when xHCI is properly introduced.
> +       */
> +      if (class == 0x0c && subclass == 0x03 && interf == 0x30)
> +        {
> +          addr = grub_pci_make_address (dev, GRUB_XHCI_PCI_USB3_PSSEN);
> +          grub_pci_write_word (addr, 0x0);
> +          grub_pci_read_word(addr);
> +          addr = grub_pci_make_address (dev, GRUB_XHCI_PCI_XUSB2PR);
> +          grub_pci_write_word (addr, 0x0);
> +          grub_pci_read_word(addr);
> +        }
> +
>        /* If this is not an EHCI controller, just return.  */
>        if (class != 0x0c || subclass != 0x03 || interf != 0x20)
>         return 0;
> 
> Regards,
> Christian
> 

Re: [PATCH]: xHCI/EHCI - Windows - BIOS bug interaction.

[Aleš Nesrsta]

[-- Attachment #1.1: Type: text/plain, Size: 898 bytes --]

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: xhci.c --]
[-- Type: text/x-csrc; name="xhci.c", Size: 4828 bytes --]

/* xhci.c - xHCI dummy driver.  */
/*
 *  GRUB  --  GRand Unified Bootloader
 *  Copyright (C) 2011  Free Software Foundation, Inc.
 *
 *  GRUB is free software: you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation, either version 3 of the License, or
 *  (at your option) any later version.
 *
 *  GRUB is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
 */

#include <grub/dl.h>
#include <grub/mm.h>
#include <grub/usb.h>
#include <grub/usbtrans.h>
#include <grub/misc.h>
#include <grub/pci.h>
#include <grub/cpu/pci.h>
#include <grub/cpu/io.h>
#include <grub/time.h>
#include <grub/loader.h>
#include <grub/list.h>

GRUB_MOD_LICENSE ("GPLv3+");

/* This module solves only xHCI problem:
 * Machine is cold-booted. - > USB keyboard works in GRUB -> Windows boots ->
 * Windows does warm reboot -> USB keyboard does not work in GRUB.
 * This only happens in the ports marked superspeed on the machine.
 * The problem is that Windows seems to leave the the SS ports in SS mode
 * when rebooting and a BIOS bug(?) on warm boot leads to not setting
 * the SS ports in 2.0 mode.
 */

/* Identification values */
#define GRUB_XHCI_CLASS_CODE 0x0c0330
#define GRUB_XHCI_SBRN_VALUE 0x30

#define GRUB_XHCI_PCI_XUSB2PR    0xD0
#define GRUB_XHCI_PCI_USB3_PSSEN 0xD8

/* PCI iteration function... */
static int
grub_xhci_pci_iter (grub_pci_device_t dev,
  grub_pci_id_t pciid __attribute__ ((unused)),
  void __attribute__ ((unused)) *data)
{
  grub_pci_address_t addr;
  grub_uint32_t class_code;
  grub_uint8_t release;
  
  addr = grub_pci_make_address (dev, GRUB_PCI_REG_CLASS);
  class_code = grub_pci_read (addr) >> 8;

  /* If this is not an XHCI controller, just return.  */
  if (class_code != GRUB_XHCI_CLASS_CODE)
    return 0;

  /* Check Serial Bus Release Number */
  addr = grub_pci_make_address (dev, GRUB_XHCI_PCI_SBRN_REG);
  release = grub_pci_read_byte (addr);
  if (release != GRUB_XHCI_SBRN_VALUE)
    return 0;

  /* Since GRUB does not currently handle xHCI we need
   * to make sure it is disabled and the ports put in 2.0 mode.
   * To be removed when xHCI is properly introduced.
   */
  addr = grub_pci_make_address (dev, GRUB_XHCI_PCI_USB3_PSSEN);
  grub_pci_write_word (addr, 0x0);
  grub_pci_read_word(addr);
  addr = grub_pci_make_address (dev, GRUB_XHCI_PCI_XUSB2PR);
  grub_pci_write_word (addr, 0x0);
  grub_pci_read_word(addr);

  return 0;
}


static int
grub_xhci_iterate (grub_usb_controller_iterate_hook_t hook, void *hook_data)
{
  return 0;
}


static grub_usb_err_t
grub_xhci_setup_transfer (grub_usb_controller_t dev,
  grub_usb_transfer_t transfer)
{
  if (dev && transfer) {}
  
  return GRUB_USB_ERR_NONE;
}


static grub_usb_err_t
grub_xhci_check_transfer (grub_usb_controller_t dev,
			  grub_usb_transfer_t transfer, grub_size_t * actual)
{
  if (dev && transfer && actual) {}

  return GRUB_USB_ERR_NONE;
}


static grub_usb_err_t
grub_xhci_cancel_transfer (grub_usb_controller_t dev,
			   grub_usb_transfer_t transfer)
{
  if (dev && transfer) {}

  return GRUB_USB_ERR_NONE;
}


static int
grub_xhci_hubports (grub_usb_controller_t dev)
{
  if (dev) {}

  return 0;
}


static grub_usb_err_t
grub_xhci_portstatus (grub_usb_controller_t dev,
		      unsigned int port, unsigned int enable)
{
  if (dev && port && enable) {}

  return GRUB_USB_ERR_NONE;
}


static grub_usb_speed_t
grub_xhci_detect_dev (grub_usb_controller_t dev, int port, int *changed)
{
  if (dev &&changed) {}

  return GRUB_USB_SPEED_NONE;
}


static grub_err_t
grub_xhci_fini_hw (int noreturn __attribute__ ((unused)))
{
  return GRUB_USB_ERR_NONE;
}


static grub_err_t
grub_xhci_restore_hw (void)
{
  return GRUB_USB_ERR_NONE;
}


static void
grub_xhci_inithw (void)
{
  grub_pci_iterate (grub_xhci_pci_iter, NULL);
}


static struct grub_usb_controller_dev usb_controller = {
  .name = "xhci",
  .iterate = grub_xhci_iterate,
  .setup_transfer = grub_xhci_setup_transfer,
  .check_transfer = grub_xhci_check_transfer,
  .cancel_transfer = grub_xhci_cancel_transfer,
  .hubports = grub_xhci_hubports,
  .portstatus = grub_xhci_portstatus,
  .detect_dev = grub_xhci_detect_dev,
  .max_bulk_tds = 0
};


GRUB_MOD_INIT (xhci)
{
  grub_xhci_inithw ();
}

GRUB_MOD_FINI (xhci)
{
  grub_xhci_fini_hw (0);
}


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

RE: [PATCH]: xHCI/EHCI - Windows - BIOS bug interaction.

[Melki Christian (consultant)]

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.com@gnu.org
> [mailto:grub-devel-bounces+christian.melki=saabgroup.com@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

Re: [PATCH]: xHCI/EHCI - Windows - BIOS bug interaction.

[Aleš Nesrsta]

[-- Attachment #1: Type: text/plain, Size: 2443 bytes --]

Hi Christian,

I think - generally, if OS is able to work with this Intel chipset, then
it should handle change of XUSB2PR and USB3_PSSEN registers state during
reboot (or sleep/resume).
In opposite case, when OS is not able to work with this chipset, then OS
will not touch these registers - and routing to EHCI is the default
state, so no problem should happen.


But I am little bit confused:

I searched XUSB2PR and USB3_PSSEN PCI registers in official xHCI
specification "eXtensible Host Controller Interafce for Universal Serial
Bus (xHCI)", Revision 1.0, 5/21/10 (downloaded from www.intel.com) - and
I didn't find them.
Additionally, as far as I understood xHCI specification, xHCI concept is
to avoid such port switching (similar to EHCI ports switching to
companion OHCI/UHCI controllers).

Then I tried to find datasheet of Intel pantherpoint chipset - and I
found document "Intel 7 Series / C216 Chipset Family Platform Controller
Hub (PCH)", June 2012. And this document includes description of XUSB2PR
and USB3_PSSEN PCI registers.

So:
Are these PCI registers some only Intel-specific special "non-official"
extension? (It looks like that - according to comments in Linux kernel
source.)
Or are them some new "official" xHCI add-on mentioned in some newer
version of xHCI specification, unknown for us yet?
How can I distinguish if xHCI contains these (possibly non-official -
but very important) special PCI registers or not? Only by Vendor/Device
IDs? Or is there some system, e.g. similar to PCI Capabilities etc?

Answers of these questions will be important in case when we will try to
support xHCI in GRUB.

BR,
Ales


Dne 20.12.2013 08:38, Melki Christian (consultant) napsal(a):
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

RE: [PATCH]: xHCI/EHCI - Windows - BIOS bug interaction.

[Melki Christian (consultant)]

Aleš,

Sorry for the late reply. Holliday vaccation. :)

> Hi Christian,
> 
> I think - generally, if OS is able to work with this Intel chipset, then
> it should handle change of XUSB2PR and USB3_PSSEN registers state during
> reboot (or sleep/resume).
> In opposite case, when OS is not able to work with this chipset, then OS
> will not touch these registers - and routing to EHCI is the default
> state, so no problem should happen.

Yes. I think this is the case with Windows if Intel drivers are used.
Otherwise I think generic Microsoft xHCI drivers are used, and they don't know anything about Intel specific bugs.

> 
> But I am little bit confused:
> 
> I searched XUSB2PR and USB3_PSSEN PCI registers in official xHCI
> specification "eXtensible Host Controller Interafce for Universal Serial
> Bus (xHCI)", Revision 1.0, 5/21/10 (downloaded from www.intel.com) - and
> I didn't find them.
> Additionally, as far as I understood xHCI specification, xHCI concept is
> to avoid such port switching (similar to EHCI ports switching to
> companion OHCI/UHCI controllers).

Maybe I did not clarify my late findings properly.
This is not a xHCI spec problem, but rather an Intel PantherPoint chipset problem.

 > Then I tried to find datasheet of Intel pantherpoint chipset - and I
> found document "Intel 7 Series / C216 Chipset Family Platform Controller
> Hub (PCH)", June 2012. And this document includes description of XUSB2PR
> and USB3_PSSEN PCI registers.

Ah, yes. Correct. :)

> So:
> Are these PCI registers some only Intel-specific special "non-official"
> extension? (It looks like that - according to comments in Linux kernel
> source.)
> Or are them some new "official" xHCI add-on mentioned in some newer
> version of xHCI specification, unknown for us yet?
> How can I distinguish if xHCI contains these (possibly non-official -
> but very important) special PCI registers or not? Only by Vendor/Device
> IDs? Or is there some system, e.g. similar to PCI Capabilities etc?

These registers are Intel Pantherpoint specific as far as I understand. By deviceid only.

I did this before you sent your patch last time. It includes the Panterpoint chipset id.
(local changes only). They still fit better in a separate quirk or xhci-driver module as you suggested.

Index: grub-core/bus/usb/ehci.c
===================================================================
--- grub-core/bus/usb/ehci.c    (revision 6012)
+++ grub-core/bus/usb/ehci.c    (revision 6013)
@@ -41,6 +41,9 @@
  */

 #define GRUB_EHCI_PCI_SBRN_REG  0x60
+#define GRUB_XHCI_PCI_XUSB2PR   0xD0
+#define GRUB_XHCI_PCI_USB3_PSSEN 0xD8
+#define GRUB_XHCI_INTEL_PPT_PCIID 0x1e318086

 /* Capability registers offsets */
 enum
@@ -458,6 +461,41 @@
   return GRUB_USB_ERR_NONE;
 }

+static int
+grub_xhci_quirk_fix (grub_pci_device_t dev, grub_pci_id_t pciid,
+                     void *data __attribute__ ((unused)))
+{
+  grub_uint32_t class_code;
+  grub_uint32_t interf;
+  grub_uint32_t subclass;
+  grub_uint32_t class;
+  grub_pci_address_t addr;
+
+  addr = grub_pci_make_address (dev, GRUB_PCI_REG_CLASS);
+  class_code = grub_pci_read (addr) >> 8;
+  interf = class_code & 0xFF;
+  subclass = (class_code >> 8) & 0xFF;
+  class = class_code >> 16;
+
+  /* This is an Intel Pantherpoint xHCI controller.
+   * Quirk fix to put all ports in 2.0 mode.
+   * To be removed when xHCI is properly introduced.
+   */
+  if (class == 0x0c && subclass == 0x03 && interf == 0x30 &&
+      pciid == GRUB_XHCI_INTEL_PPT_PCIID)
+    {
+      grub_dprintf("ehci", "Intel PPT, applying quirk fix.\n");
+      addr = grub_pci_make_address (dev, GRUB_XHCI_PCI_USB3_PSSEN);
+      grub_pci_write_word (addr, 0x0);
+      grub_pci_read_word(addr);
+      addr = grub_pci_make_address (dev, GRUB_XHCI_PCI_XUSB2PR);
+      grub_pci_write_word (addr, 0x0);
+      grub_pci_read_word(addr);
+    }
+
+  return 0;
+}
+
 /* PCI iteration function... */
 static int
 grub_ehci_pci_iter (grub_pci_device_t dev, grub_pci_id_t pciid,
@@ -1844,6 +1882,12 @@
   grub_pci_iterate (grub_ehci_pci_iter, NULL);
 }

+static void
+grub_xhci_quirk (void)
+{
+  grub_pci_iterate (grub_xhci_quirk_fix, NULL);
+}
+
 static grub_err_t
 grub_ehci_restore_hw (void)
 {
@@ -1967,6 +2011,7 @@
   COMPILE_TIME_ASSERT (sizeof (struct grub_ehci_qh) == 96);

   grub_boot_time ("Initing EHCI hardware");
+  grub_xhci_quirk ();
   grub_ehci_inithw ();
   grub_boot_time ("Registering EHCI driver");
   grub_usb_controller_dev_register (&usb_controller);

> Answers of these questions will be important in case when we will try to
> support xHCI in GRUB.

At first I too thought that these vere more xHCI specific than they were.
I have reduced this problem to "nice to have" from by behalf rather than
"must have bugfix".
I think this will only appear on this Intel chipset, possibly BIOS bug(?) selected OS (Win7+) without Intel specific xHCI driver...
Not so many users are likely to get bitten by this.

regards && late season greetings. :)
Christian

> BR,
> Ales
> 
> 
> Dne 20.12.2013 08:38, Melki Christian (consultant) napsal(a):
> > 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