From: "Aleš Nesrsta" <starous@volny.cz>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH]: xHCI/EHCI - Windows - BIOS bug interaction.
Date: Fri, 20 Dec 2013 20:45:49 +0100 [thread overview]
Message-ID: <52B49E6D.4010105@volny.cz> (raw)
In-Reply-To: <BBCDB0B9B472124D9EED8CB900AA04CA1F9688A1@corpappl747.corp.saab.se>
[-- 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 --]
next prev parent reply other threads:[~2013-12-21 20:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-19 10:01 [PATCH]: xHCI/EHCI - Windows - BIOS bug interaction Melki Christian (consultant)
2013-12-19 11:33 ` Melki Christian (consultant)
2013-12-19 20:50 ` Aleš Nesrsta
2013-12-20 7:38 ` Melki Christian (consultant)
2013-12-20 19:45 ` Aleš Nesrsta [this message]
2014-01-03 8:44 ` Melki Christian (consultant)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52B49E6D.4010105@volny.cz \
--to=starous@volny.cz \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.