From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VuSmu-0000wL-0m for mharc-grub-devel@gnu.org; Sat, 21 Dec 2013 15:04:40 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuSmm-0000w1-1e for grub-devel@gnu.org; Sat, 21 Dec 2013 15:04:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuSmg-0000VG-5o for grub-devel@gnu.org; Sat, 21 Dec 2013 15:04:31 -0500 Received: from gmmr5.centrum.cz ([2a00:da80:0:502::4]:51071) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuSmf-0000Us-RQ for grub-devel@gnu.org; Sat, 21 Dec 2013 15:04:26 -0500 Received: from gm-as2.cent (unknown [10.32.3.100]) by gmmr5.centrum.cz (Postfix) with ESMTP id BB115728 for ; Sat, 21 Dec 2013 21:04:21 +0100 (CET) Received: by gm-as2.cent (Postfix, from userid 0) id B16F529BBAF81; Sat, 21 Dec 2013 21:02:13 +0100 (CET) X-Original-From: starous@volny.cz X-Envelope-To: grub-devel@gnu.org X-Original-IP: 193.86.90.90 Received: from [192.168.6.11] (unknown [193.86.90.90]) by gm-smtp1.centrum.cz (Postfix) with ESMTPX id 5309360049965 for ; Fri, 20 Dec 2013 20:45:50 +0100 (CET) Message-ID: <52B49E6D.4010105@volny.cz> Date: Fri, 20 Dec 2013 20:45:49 +0100 From: =?ISO-8859-2?Q?Ale=B9_Nesrsta?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: The development of GNU GRUB Subject: Re: [PATCH]: xHCI/EHCI - Windows - BIOS bug interaction. References: <52B35C26.3020009@volny.cz> In-Reply-To: X-Enigmail-Version: 1.6 OpenPGP: id=9AEF08D1 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9MRa9kVeGibsqM29CcoR3mD81KGLc2WBx" X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:da80:0:502::4 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2013 20:04:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9MRa9kVeGibsqM29CcoR3mD81KGLc2WBx Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable 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=B9, >=20 > 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 m= ore curious about odd cases. > What happens if BIOS intentionally sets ports to USB 3.0 in the port ro= uting registers of said chipset? > Will all OS drivers handle that I have routed the ports to the EHCI con= troller? Or will stuff break, but the other way around? > Linux does this on _shutdown_ which means that it assumes, that whateve= r 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. >=20 > Regards, > Christian --9MRa9kVeGibsqM29CcoR3mD81KGLc2WBx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlK0nm4ACgkQT72HYprvCNHcxQD9EO0rcgENxy0f7YhyfTiqJ9Zy g3qVbt5R1EzyEz86LcIA/jawvgdgrO0HUkKYt4suYPnHEEyFAs9TpJLsGpdGJcm2 =XxzD -----END PGP SIGNATURE----- --9MRa9kVeGibsqM29CcoR3mD81KGLc2WBx--