[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Aleš Nesrsta
Subject: Re: [PATCH]: xHCI/EHCI - Windows - BIOS bug interaction.
Date: Fri, 20 Dec 2013 20:45:49 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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 - 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.

Are these PCI registers some only Intel-specific special "non-official"
extension? (It looks like that - according to comments in Linux kernel
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.


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: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]