From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1cj1dd-0008Is-SX for mharc-grub-devel@gnu.org; Wed, 01 Mar 2017 05:37:41 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cj1db-0008G3-Aa for grub-devel@gnu.org; Wed, 01 Mar 2017 05:37:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cj1da-0004R9-Dm for grub-devel@gnu.org; Wed, 01 Mar 2017 05:37:39 -0500 Received: from mail-wm0-x234.google.com ([2a00:1450:400c:c09::234]:35402) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cj1da-0004QY-6y for grub-devel@gnu.org; Wed, 01 Mar 2017 05:37:38 -0500 Received: by mail-wm0-x234.google.com with SMTP id v186so106519486wmd.0 for ; Wed, 01 Mar 2017 02:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+fyoF9weu4EnVbSIdIi4MbesLC2v3UlHfMdTzVEq0xE=; b=lR7JK+zl4qtWOEyf2E+96KOdDBCAjJxksZZ+z0uMajCWjGZiCYmdXtGs6vELpB8ial +Mo37zrN16GZ7o9A7KPWQotyUR77882YRin9JOzRPkYuGWipLXN2mUfJf0/s6dSrfI1e rUBWRIiPp8qCc65LdITVkrBZfW0357pKgDOcKAFAsWpBlkluvlWAPVtCUKKS2bau1U0z SfCouxLPTGZiugOMGD5Ybwfc3oUA6f+dULz+YYDS8bqG1Q/Midms5nesWv3vdRlfP/UR U4uzBdnEf7LdcKK/tCkrmT0I7PCynSOEWbXbPxN8kzqC3pVUncAqfeh/tcjv0qMzbkah 5mmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+fyoF9weu4EnVbSIdIi4MbesLC2v3UlHfMdTzVEq0xE=; b=Us9atYHP1mLXjJb+RBTC3qk4sBMhyDf/ZyOuZz9mJm6akVoDR1crTEJE/6dOFH8Ofn WlHqVqqxMy3DFZPqtNnPM5Ltu0lxF+ySaQrLYR2FXU5Koi+VJL8knwIWGSRlpvdG09xP sG0ivzi84bprcBs0xpQX86dxnt4qevxHwesuClL5qHjukW8d4BVCqwDJYEDWZS0lIH3M rW5hmMQKPOuBeY2kyOGR0KRcqUkRdfajRKwfgEu4Y+LGBWckjO/I4fOS+nXX9kg6vZ3W 0vYMt+tlrEAoMWQPNAPO7KAO6u8J/IgWkMHqlka5DPtM5F9f04SCmP1SJhVQpcVRnlG0 ai1w== X-Gm-Message-State: AMke39liFGyd0ZH+Hk3tLI4Z02z1C75mUbLyHbeQRrw+oLNwV5vLW1pjOvyhCbY9xv19F4UWhkRsHVs0wH3TFA== X-Received: by 10.28.26.196 with SMTP id a187mr2621738wma.33.1488364655353; Wed, 01 Mar 2017 02:37:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.138.158 with HTTP; Wed, 1 Mar 2017 02:37:34 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Bj=C3=B8rn_Forsman?= Date: Wed, 1 Mar 2017 11:37:34 +0100 Message-ID: Subject: Re: USB3.0 XHCI support on GRUB2 To: Andrei Borzenkov Cc: The development of GNU GRUB , gailu96@gmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::234 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 10:37:40 -0000 On 1 March 2017 at 07:57, Andrei Borzenkov wrote: > Yes, Bj=C3=B8rn Forsman intended to work on implementation. So now is apparently a good time to tell you about the status of that implementation :-) The good: I ported the xHCI driver from Coreboot / libpayload to GRUB. In basic tests, it works. (I tested a Lenovo G50-80 laptop with Intel Wildcat Point-LP USB xHCI controller [8086:9cb1].) The bad: The code doesn't support HUBs and completely hangs on one xHCI controller I tested (Intel NUC6i5SYH Skylake with Sunrise Point-LP xHCI USB controller [8086:9d2f]). The HUB problem is due to GRUB using a different code path for HUBs than normal devices. I implemented hooks for "control_transfer" and "bulk_transfer" in GRUB USB stack, because that required little changes and it made it easy to hook it up with the xHCI driver. But when GRUB sees a HUB, it uses the "old" setup_transfer code path which isn't implemented in the xHCI driver. I'm thinking the "hanging" issue (the controller never responds to a basic "NOP" command) is a problem with the Coreboot driver itself, or more specifically, the lack of a "quirk" handling for this controller. But blaming that driver doesn't fix it. About the implementation. I tried to change as little code as possible, both in GRUB and the Coreboot driver, thinking that it'd make maintenance easier. My reasoning was (perhaps wrongly?) that there is little help to get in the community, and if I reuse enough of the Coreboot driver, I can easiliy re-import the driver if/when they fix some bugs. This "change as little as possible" policy means that now the xHCI driver initializes and tracks some state that also GRUB USB stack does. It works but it's not something I think is good enough to integrate in mainline GRUB. (That's one of the reasons why I didn't tell you about the status earlier. I don't see how to make it "clean" enough for mainline. Also, the above issues are sort of blockers in themselves.) The ugly :-) https://github.com/bjornfor/grub/tree/add-coreboot-xhci-driver-2nd-attempt-= v2 (I just cleaned up history and rebased on master, so it's less ugly than it was a few hours ago.) Best regards, Bj=C3=B8rn Forsman