GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/payloads/libpayload/drivers/usb/xhci_devconf.c

473 lines
13 KiB
C
Raw Normal View History

libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
/*
* This file is part of the libpayload project.
*
* Copyright (C) 2013 secunet Security Networks AG
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
//#define XHCI_SPEW_DEBUG
#include <arch/virtual.h>
libpayload: usb: Unify USB speed between XHCI stack and USB core This patch removes the confusing concept of a special "xhci_speed" with a different numeric value from the usual speed used throughout the USB core (except for the places directly interacting with the xHC, which are explicitly marked). It also moves the MPS0 decoding function into the core and moves some definitions around in preparation of later changes that will make the stack SuperSpeed-ready. It makes both set_address implementations share a constant for the specification-defined SetAddress() recovery delay and removes pointless additional delays from the non-XHCI version. Change-Id: I422379d05d4a502b12dae183504e5231add5466a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170664 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit f160d4439c0d7cea1d2e6b97207935d61dcbb2f2) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6776 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-25 05:03:54 +02:00
#include <usb/usb.h>
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
#include "xhci_private.h"
static u32
xhci_gen_route(xhci_t *const xhci, const int hubport, const int hubaddr)
{
if (!hubaddr)
return 0;
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
u32 route_string = SC_GET(ROUTE, xhci->dev[hubaddr].ctx.slot);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
int i;
for (i = 0; i < 20; i += 4) {
if (!(route_string & (0xf << i))) {
route_string |= (hubport & 0xf) << i;
break;
}
}
return route_string;
}
static int
xhci_get_rh_port(xhci_t *const xhci, const int hubport, const int hubaddr)
{
if (!hubaddr)
return hubport;
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
return SC_GET(RHPORT, xhci->dev[hubaddr].ctx.slot);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
}
static int
libpayload: usb: Unify USB speed between XHCI stack and USB core This patch removes the confusing concept of a special "xhci_speed" with a different numeric value from the usual speed used throughout the USB core (except for the places directly interacting with the xHC, which are explicitly marked). It also moves the MPS0 decoding function into the core and moves some definitions around in preparation of later changes that will make the stack SuperSpeed-ready. It makes both set_address implementations share a constant for the specification-defined SetAddress() recovery delay and removes pointless additional delays from the non-XHCI version. Change-Id: I422379d05d4a502b12dae183504e5231add5466a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170664 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit f160d4439c0d7cea1d2e6b97207935d61dcbb2f2) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6776 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-25 05:03:54 +02:00
xhci_get_tt(xhci_t *const xhci, const usb_speed speed,
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
const int hubport, const int hubaddr,
int *const tt, int *const tt_port)
{
if (!hubaddr)
return 0;
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
const slotctx_t *const slot = xhci->dev[hubaddr].ctx.slot;
if ((*tt = SC_GET(TTID, slot))) {
*tt_port = SC_GET(TTPORT, slot);
libpayload: usb: Unify USB speed between XHCI stack and USB core This patch removes the confusing concept of a special "xhci_speed" with a different numeric value from the usual speed used throughout the USB core (except for the places directly interacting with the xHC, which are explicitly marked). It also moves the MPS0 decoding function into the core and moves some definitions around in preparation of later changes that will make the stack SuperSpeed-ready. It makes both set_address implementations share a constant for the specification-defined SetAddress() recovery delay and removes pointless additional delays from the non-XHCI version. Change-Id: I422379d05d4a502b12dae183504e5231add5466a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170664 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit f160d4439c0d7cea1d2e6b97207935d61dcbb2f2) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6776 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-25 05:03:54 +02:00
} else if (speed < HIGH_SPEED &&
SC_GET(SPEED1, slot) - 1 == HIGH_SPEED) {
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
*tt = hubaddr;
*tt_port = hubport;
}
return *tt != 0;
}
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
static void
xhci_reap_slots(xhci_t *const xhci, int skip_slot)
{
int i;
xhci_debug("xHC resource shortage, trying to reap old slots...\n");
for (i = 1; i <= xhci->max_slots_en; i++) {
if (i == skip_slot)
continue; /* don't reap slot we were working on */
if (xhci->dev[i].transfer_rings[1])
continue; /* slot still in use */
if (!xhci->dev[i].ctx.raw)
continue; /* slot already disabled */
const int cc = xhci_cmd_disable_slot(xhci, i);
if (cc != CC_SUCCESS)
xhci_debug("Failed to disable slot %d: %d\n", i, cc);
else
xhci_spew("Successfully reaped slot %d\n", i);
xhci->dcbaa[i] = 0;
free(xhci->dev[i].ctx.raw);
xhci->dev[i].ctx.raw = NULL;
}
}
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
static inputctx_t *
xhci_make_inputctx(const size_t ctxsize)
{
int i;
const size_t size = (1 + NUM_EPS) * ctxsize;
inputctx_t *const ic = malloc(sizeof(*ic));
void *dma_buffer = dma_memalign(64, size);
if (!ic || !dma_buffer) {
free(ic);
free(dma_buffer);
return NULL;
}
memset(dma_buffer, 0, size);
ic->drop = dma_buffer + 0;
ic->add = dma_buffer + 4;
dma_buffer += ctxsize;
for (i = 0; i < NUM_EPS; i++, dma_buffer += ctxsize)
ic->dev.ep[i] = dma_buffer;
return ic;
}
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
usbdev_t *
libpayload: usb: Unify USB speed between XHCI stack and USB core This patch removes the confusing concept of a special "xhci_speed" with a different numeric value from the usual speed used throughout the USB core (except for the places directly interacting with the xHC, which are explicitly marked). It also moves the MPS0 decoding function into the core and moves some definitions around in preparation of later changes that will make the stack SuperSpeed-ready. It makes both set_address implementations share a constant for the specification-defined SetAddress() recovery delay and removes pointless additional delays from the non-XHCI version. Change-Id: I422379d05d4a502b12dae183504e5231add5466a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170664 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit f160d4439c0d7cea1d2e6b97207935d61dcbb2f2) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6776 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-25 05:03:54 +02:00
xhci_set_address (hci_t *controller, usb_speed speed, int hubport, int hubaddr)
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
{
xhci_t *const xhci = XHCI_INST(controller);
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
const size_t ctxsize = CTXSIZE(xhci);
devinfo_t *di = NULL;
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
usbdev_t *dev = NULL;
int i;
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
inputctx_t *const ic = xhci_make_inputctx(ctxsize);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
transfer_ring_t *const tr = malloc(sizeof(*tr));
if (tr)
tr->ring = xhci_align(16, TRANSFER_RING_SIZE * sizeof(trb_t));
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
if (!ic || !tr || !tr->ring) {
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
xhci_debug("Out of memory\n");
goto _free_return;
}
int slot_id;
int cc = xhci_cmd_enable_slot(xhci, &slot_id);
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
if (cc == CC_NO_SLOTS_AVAILABLE) {
xhci_reap_slots(xhci, 0);
cc = xhci_cmd_enable_slot(xhci, &slot_id);
}
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
if (cc != CC_SUCCESS) {
xhci_debug("Enable slot failed: %d\n", cc);
goto _free_return;
} else {
xhci_debug("Enabled slot %d\n", slot_id);
}
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
di = &xhci->dev[slot_id];
void *dma_buffer = dma_memalign(64, NUM_EPS * ctxsize);
if (!dma_buffer)
libpayload: usb: Fix several minor USB stack bugs This patch fixes the following minor bugs in the USB stack: 1. Ensure that all dynamically allocated device structures are cleaned on detachment, and that the device address is correctly released again. 2. Make sure MSC and HID drivers notice missing endpoints and actually detach the device in that case (to prevent it from being used). 3. Make sure XHCI-specific set_address() cleans up all data structures on failure. 4. Fix broken Slot ID range check that prevented XHCI devices from being correctly cleaned up. Change-Id: I7b2b9c8cd6c5e93cb19abcf01425bcd85d2e1f22 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170665 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Ronald Minnich <rminnich@chromium.org> Tested-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 9671472263ddd0c30400ae3b6da780a18cd21ded) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6701 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-09-25 21:30:07 +02:00
goto _disable_return;
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
memset(dma_buffer, 0, NUM_EPS * ctxsize);
for (i = 0; i < NUM_EPS; i++, dma_buffer += ctxsize)
di->ctx.ep[i] = dma_buffer;
*ic->add = (1 << 0) /* Slot Context */ | (1 << 1) /* EP0 Context */ ;
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
SC_SET(ROUTE, ic->dev.slot, xhci_gen_route(xhci, hubport, hubaddr));
libpayload: usb: Unify USB speed between XHCI stack and USB core This patch removes the confusing concept of a special "xhci_speed" with a different numeric value from the usual speed used throughout the USB core (except for the places directly interacting with the xHC, which are explicitly marked). It also moves the MPS0 decoding function into the core and moves some definitions around in preparation of later changes that will make the stack SuperSpeed-ready. It makes both set_address implementations share a constant for the specification-defined SetAddress() recovery delay and removes pointless additional delays from the non-XHCI version. Change-Id: I422379d05d4a502b12dae183504e5231add5466a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170664 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit f160d4439c0d7cea1d2e6b97207935d61dcbb2f2) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6776 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-25 05:03:54 +02:00
SC_SET(SPEED1, ic->dev.slot, speed + 1);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
SC_SET(CTXENT, ic->dev.slot, 1); /* the endpoint 0 context */
SC_SET(RHPORT, ic->dev.slot, xhci_get_rh_port(xhci, hubport, hubaddr));
int tt, tt_port;
libpayload: usb: Unify USB speed between XHCI stack and USB core This patch removes the confusing concept of a special "xhci_speed" with a different numeric value from the usual speed used throughout the USB core (except for the places directly interacting with the xHC, which are explicitly marked). It also moves the MPS0 decoding function into the core and moves some definitions around in preparation of later changes that will make the stack SuperSpeed-ready. It makes both set_address implementations share a constant for the specification-defined SetAddress() recovery delay and removes pointless additional delays from the non-XHCI version. Change-Id: I422379d05d4a502b12dae183504e5231add5466a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170664 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit f160d4439c0d7cea1d2e6b97207935d61dcbb2f2) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6776 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-25 05:03:54 +02:00
if (xhci_get_tt(xhci, speed, hubport, hubaddr, &tt, &tt_port)) {
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
xhci_debug("TT for %d: %d[%d]\n", slot_id, tt, tt_port);
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
SC_SET(MTT, ic->dev.slot, SC_GET(MTT, xhci->dev[tt].ctx.slot));
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
SC_SET(TTID, ic->dev.slot, tt);
SC_SET(TTPORT, ic->dev.slot, tt_port);
}
di->transfer_rings[1] = tr;
xhci_init_cycle_ring(tr, TRANSFER_RING_SIZE);
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
ic->dev.ep0->tr_dq_low = virt_to_phys(tr->ring);
ic->dev.ep0->tr_dq_high = 0;
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
EC_SET(TYPE, ic->dev.ep0, EP_CONTROL);
EC_SET(AVRTRB, ic->dev.ep0, 8);
libpayload: xhci: Set MPS based on speed BUG=chrome-os-partner:49249 TEST=Compiles and boots and detect USB storage BRANCH=none Change-Id: I9007399e1f785e6f1d2258225e3f7cc602053aed Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 1db43f53973d2124e41186777caa829aa346ace3 Original-Change-Id: I943d19a3a7d785bd075073b57ba6388662d7df90 Original-Signed-off-by: Varadarajan Narayanan <varada@codeaurora.org> Original-Reviewed-on: https://chromium-review.googlesource.com/333311 Original-Commit-Ready: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14659 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-03-17 10:13:35 +01:00
EC_SET(MPS, ic->dev.ep0, speed_to_default_mps(speed));
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
EC_SET(CERR, ic->dev.ep0, 3);
EC_SET(DCS, ic->dev.ep0, 1);
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
xhci->dcbaa[slot_id] = virt_to_phys(di->ctx.raw);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
cc = xhci_cmd_address_device(xhci, slot_id, ic);
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
if (cc == CC_RESOURCE_ERROR) {
xhci_reap_slots(xhci, slot_id);
cc = xhci_cmd_address_device(xhci, slot_id, ic);
}
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
if (cc != CC_SUCCESS) {
xhci_debug("Address device failed: %d\n", cc);
goto _disable_return;
} else {
xhci_debug("Addressed device %d (USB: %d)\n",
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
slot_id, SC_GET(UADDR, di->ctx.slot));
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
}
libpayload: usb: Unify USB speed between XHCI stack and USB core This patch removes the confusing concept of a special "xhci_speed" with a different numeric value from the usual speed used throughout the USB core (except for the places directly interacting with the xHC, which are explicitly marked). It also moves the MPS0 decoding function into the core and moves some definitions around in preparation of later changes that will make the stack SuperSpeed-ready. It makes both set_address implementations share a constant for the specification-defined SetAddress() recovery delay and removes pointless additional delays from the non-XHCI version. Change-Id: I422379d05d4a502b12dae183504e5231add5466a Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170664 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit f160d4439c0d7cea1d2e6b97207935d61dcbb2f2) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6776 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-25 05:03:54 +02:00
mdelay(SET_ADDRESS_MDELAY);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
dev = init_device_entry(controller, slot_id);
if (!dev)
goto _disable_return;
dev->address = slot_id;
dev->hub = hubaddr;
dev->port = hubport;
dev->speed = speed;
dev->endpoints[0].dev = dev;
dev->endpoints[0].endpoint = 0;
dev->endpoints[0].toggle = 0;
dev->endpoints[0].direction = SETUP;
dev->endpoints[0].type = CONTROL;
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
u8 buf[8];
if (get_descriptor(dev, gen_bmRequestType(device_to_host, standard_type,
dev_recp), DT_DEV, 0, buf, sizeof(buf)) != sizeof(buf)) {
usb_debug("first get_descriptor(DT_DEV) failed\n");
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
goto _disable_return;
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
}
dev->endpoints[0].maxpacketsize = usb_decode_mps0(speed, buf[7]);
if (dev->endpoints[0].maxpacketsize != 8) {
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
memset((void *)ic->dev.ep0, 0x00, ctxsize);
*ic->add = (1 << 1); /* EP0 Context */
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
EC_SET(MPS, ic->dev.ep0, dev->endpoints[0].maxpacketsize);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
cc = xhci_cmd_evaluate_context(xhci, slot_id, ic);
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
if (cc == CC_RESOURCE_ERROR) {
xhci_reap_slots(xhci, slot_id);
cc = xhci_cmd_evaluate_context(xhci, slot_id, ic);
}
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
if (cc != CC_SUCCESS) {
xhci_debug("Context evaluation failed: %d\n", cc);
goto _disable_return;
}
}
goto _free_ic_return;
_disable_return:
xhci_cmd_disable_slot(xhci, slot_id);
xhci->dcbaa[slot_id] = 0;
libpayload: usb: Fix several minor USB stack bugs This patch fixes the following minor bugs in the USB stack: 1. Ensure that all dynamically allocated device structures are cleaned on detachment, and that the device address is correctly released again. 2. Make sure MSC and HID drivers notice missing endpoints and actually detach the device in that case (to prevent it from being used). 3. Make sure XHCI-specific set_address() cleans up all data structures on failure. 4. Fix broken Slot ID range check that prevented XHCI devices from being correctly cleaned up. Change-Id: I7b2b9c8cd6c5e93cb19abcf01425bcd85d2e1f22 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170665 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Ronald Minnich <rminnich@chromium.org> Tested-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 9671472263ddd0c30400ae3b6da780a18cd21ded) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6701 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-09-25 21:30:07 +02:00
usb_detach_device(controller, slot_id);
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
dev = NULL;
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
_free_return:
if (tr)
free((void *)tr->ring);
free(tr);
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
if (di) {
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
free(di->ctx.raw);
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
di->ctx.raw = 0;
}
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
_free_ic_return:
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
if (ic)
free(ic->raw);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
free(ic);
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
return dev;
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
}
static int
xhci_finish_hub_config(usbdev_t *const dev, inputctx_t *const ic)
{
libpayload: usb: Add support for SuperSpeed hubs This patch adds support for the SuperSpeed half of USB 3.0 hubs, which previously prevented SuperSpeed devices behind those hubs from working. BRANCH=None BUG=chrome-os-partner:39877 TEST=Played around with multiple hubs and devices on Oak and Falco, can no longer find a combination that doesn't work. Change-Id: I20815be95769e33d399b7ad91c3020687234e059 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3db96ece20d2304e7f6f6aa333cf114037c48a3e Original-Change-Id: I2dd6c9c3607a24a7d78c308911e3d254d5f8d91d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284577 Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Original-Tested-by: chunfeng yun <chunfeng.yun@mediatek.com> Reviewed-on: http://review.coreboot.org/10958 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-10 01:29:10 +02:00
int type = dev->speed == SUPER_SPEED ? 0x2a : 0x29; /* similar enough */
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
hub_descriptor_t desc;
if (get_descriptor(dev, gen_bmRequestType(device_to_host, class_type,
libpayload: usb: Add support for SuperSpeed hubs This patch adds support for the SuperSpeed half of USB 3.0 hubs, which previously prevented SuperSpeed devices behind those hubs from working. BRANCH=None BUG=chrome-os-partner:39877 TEST=Played around with multiple hubs and devices on Oak and Falco, can no longer find a combination that doesn't work. Change-Id: I20815be95769e33d399b7ad91c3020687234e059 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3db96ece20d2304e7f6f6aa333cf114037c48a3e Original-Change-Id: I2dd6c9c3607a24a7d78c308911e3d254d5f8d91d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284577 Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Original-Tested-by: chunfeng yun <chunfeng.yun@mediatek.com> Reviewed-on: http://review.coreboot.org/10958 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-10 01:29:10 +02:00
dev_recp), type, 0, &desc, sizeof(desc)) != sizeof(desc)) {
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
xhci_debug("Failed to fetch hub descriptor\n");
return COMMUNICATION_ERROR;
}
SC_SET(HUB, ic->dev.slot, 1);
SC_SET(MTT, ic->dev.slot, 0); /* No support for Multi-TT */
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
SC_SET(NPORTS, ic->dev.slot, desc.bNbrPorts);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
if (dev->speed == HIGH_SPEED)
SC_SET(TTT, ic->dev.slot,
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
(desc.wHubCharacteristics >> 5) & 0x0003);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
return 0;
}
static size_t
xhci_bound_interval(const endpoint_t *const ep)
{
if ( (ep->dev->speed == LOW_SPEED &&
(ep->type == ISOCHRONOUS ||
ep->type == INTERRUPT)) ||
(ep->dev->speed == FULL_SPEED &&
ep->type == INTERRUPT))
{
if (ep->interval < 3)
return 3;
else if (ep->interval > 11)
return 11;
else
return ep->interval;
} else {
if (ep->interval < 0)
return 0;
else if (ep->interval > 15)
return 15;
else
return ep->interval;
}
}
static int
xhci_finish_ep_config(const endpoint_t *const ep, inputctx_t *const ic)
{
xhci_t *const xhci = XHCI_INST(ep->dev->controller);
const int ep_id = xhci_ep_id(ep);
xhci_debug("ep_id: %d\n", ep_id);
if (ep_id <= 1 || 32 <= ep_id)
return DRIVER_ERROR;
transfer_ring_t *const tr = malloc(sizeof(*tr));
if (tr)
tr->ring = xhci_align(16, TRANSFER_RING_SIZE * sizeof(trb_t));
if (!tr || !tr->ring) {
free(tr);
xhci_debug("Out of memory\n");
return OUT_OF_MEMORY;
}
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
xhci->dev[ep->dev->address].transfer_rings[ep_id] = tr;
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
xhci_init_cycle_ring(tr, TRANSFER_RING_SIZE);
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
*ic->add |= (1 << ep_id);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
if (SC_GET(CTXENT, ic->dev.slot) < ep_id)
SC_SET(CTXENT, ic->dev.slot, ep_id);
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
epctx_t *const epctx = ic->dev.ep[ep_id];
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
xhci_debug("Filling epctx (@%p)\n", epctx);
epctx->tr_dq_low = virt_to_phys(tr->ring);
epctx->tr_dq_high = 0;
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
EC_SET(INTVAL, epctx, xhci_bound_interval(ep));
EC_SET(CERR, epctx, 3);
EC_SET(TYPE, epctx, ep->type | ((ep->direction != OUT) << 2));
EC_SET(MPS, epctx, ep->maxpacketsize);
EC_SET(DCS, epctx, 1);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
size_t avrtrb;
switch (ep->type) {
case BULK: case ISOCHRONOUS: avrtrb = 3 * 1024; break;
case INTERRUPT: avrtrb = 1024; break;
default: avrtrb = 8; break;
}
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
EC_SET(AVRTRB, epctx, avrtrb);
EC_SET(MXESIT, epctx, EC_GET(MPS, epctx) * EC_GET(MBS, epctx));
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
libpayload: usb: Support MTK xHCI host controller 1. There is a mis-understanding to calculate the value of TD Size in Normal TRB. For MTK's xHCI controller it defines a number of packets that remain to be transferred for a TD after processing all Max packets in all previous TRBs, that means don't include the current TRB's. 2. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK architecture defines some extra SW scheduling parameters for HW. According to these parameters provided by SW, the xHC can easily decide whether a synchronous endpoint should be scheduled in a specific uFrame. The extra SW scheduling parameters are put into reserved DWs in Slot and Endpoint Context. But in coreboot synchronous transfer can be ignored, so only two fields are set to a default value 1 to support bulk and interrupt transfers, and others are set to zero. 3. For control transfer, it is better to read back doorbell register or add a memory barrier after ringing the doorbell to flush posted write. Otherwise the first command will be aborted on MTK's xHCI controller. 4. Before send commands to a port, the Port Power in PORTSC register should be set to 1 on MTK's xHCI so a hook function of enable_port in generic_hub_ops_t struct is provided. Change-Id: Ie8878b50c048907ebf939b3f6657535a54877fde Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 738609c11f16264c6e6429d478b2040cb391fe41 Original-Change-Id: Id9156892699e2e42a166c77fbf6690049abe953b Original-Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/265362 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com> Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Reviewed-on: http://review.coreboot.org/10389 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
2015-05-07 09:36:04 +02:00
if (IS_ENABLED(CONFIG_LP_USB_XHCI_MTK_QUIRK)) {
/* The MTK xHCI defines some extra SW parameters which are
* put into reserved DWs in Slot and Endpoint Contexts for
* synchronous endpoints. But for non-isochronous transfers,
* it is enough to set the following two fields to 1, and others
* are set to 0.
*/
EC_SET(BPKTS, epctx, 1);
EC_SET(BBM, epctx, 1);
}
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
return 0;
}
int
xhci_finish_device_config(usbdev_t *const dev)
{
xhci_t *const xhci = XHCI_INST(dev->controller);
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
int slot_id = dev->address;
devinfo_t *const di = &xhci->dev[slot_id];
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
int i, ret = 0;
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
inputctx_t *const ic = xhci_make_inputctx(CTXSIZE(xhci));
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
if (!ic) {
xhci_debug("Out of memory\n");
return OUT_OF_MEMORY;
}
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
*ic->add = (1 << 0); /* Slot Context */
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
xhci_dump_slotctx(di->ctx.slot);
ic->dev.slot->f1 = di->ctx.slot->f1;
ic->dev.slot->f2 = di->ctx.slot->f2;
ic->dev.slot->f3 = di->ctx.slot->f3;
libpayload: usb: Add support for SuperSpeed hubs This patch adds support for the SuperSpeed half of USB 3.0 hubs, which previously prevented SuperSpeed devices behind those hubs from working. BRANCH=None BUG=chrome-os-partner:39877 TEST=Played around with multiple hubs and devices on Oak and Falco, can no longer find a combination that doesn't work. Change-Id: I20815be95769e33d399b7ad91c3020687234e059 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3db96ece20d2304e7f6f6aa333cf114037c48a3e Original-Change-Id: I2dd6c9c3607a24a7d78c308911e3d254d5f8d91d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284577 Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Original-Tested-by: chunfeng yun <chunfeng.yun@mediatek.com> Reviewed-on: http://review.coreboot.org/10958 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-10 01:29:10 +02:00
/* f4 *must* be 0 in the Input Context... yeah, it's weird, I know. */
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
libpayload: usb: Add support for SuperSpeed hubs This patch adds support for the SuperSpeed half of USB 3.0 hubs, which previously prevented SuperSpeed devices behind those hubs from working. BRANCH=None BUG=chrome-os-partner:39877 TEST=Played around with multiple hubs and devices on Oak and Falco, can no longer find a combination that doesn't work. Change-Id: I20815be95769e33d399b7ad91c3020687234e059 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 3db96ece20d2304e7f6f6aa333cf114037c48a3e Original-Change-Id: I2dd6c9c3607a24a7d78c308911e3d254d5f8d91d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284577 Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Original-Tested-by: chunfeng yun <chunfeng.yun@mediatek.com> Reviewed-on: http://review.coreboot.org/10958 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-10 01:29:10 +02:00
if (dev->descriptor->bDeviceClass == 0x09) {
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
ret = xhci_finish_hub_config(dev, ic);
if (ret)
goto _free_return;
}
for (i = 1; i < dev->num_endp; ++i) {
ret = xhci_finish_ep_config(&dev->endpoints[i], ic);
if (ret)
goto _free_ep_ctx_return;
}
xhci_dump_inputctx(ic);
libpayload: usb: Refactor USB enumeration to fix SuperSpeed devices This patch represents a major overhaul of the USB enumeration code in order to make it cleaner and much more robust to weird or malicious devices. The main improvement is that it correctly parses the USB descriptors even if there are unknown descriptors interspersed within, which is perfectly legal and in particular present on all SuperSpeed devices (due to the SuperSpeed Endpoint Companion Descriptor). In addition, it gets rid of the really whacky and special cased get_descriptor() function, which would read every descriptor twice whether it made sense or not. The new code makes the callers allocate descriptor memory and only read stuff twice when it's really necessary (i.e. the device and configuration descriptors). Finally, it also moves some more responsibilities into the controller-specific set_address() function in order to make sure things are initialized at the same stage for all controllers. In the new model it initializes the device entry (which zeroes the endpoint array), sets up endpoint 0 (including MPS), sets the device address and finally returns the whole usbdev_t structure with that address correctly set. Note that this should make SuperSpeed devices work, but SuperSpeed hubs are a wholly different story and would require a custom hub driver (since the hub descriptor and port status formats are different for USB 3.0 ports, and the whole issue about the same hub showing up as two different devices on two different ports might present additional challenges). The stack currently just issues a warning and refuses to initialize this part of the hub, which means that 3.0 devices connected through a 3.0 hub may not work correctly. Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170666 Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6780 Tested-by: build bot (Jenkins)
2013-09-18 07:16:04 +02:00
const int config_id = dev->configuration->bConfigurationValue;
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
xhci_debug("config_id: %d\n", config_id);
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
int cc = xhci_cmd_configure_endpoint(xhci, slot_id, config_id, ic);
if (cc == CC_RESOURCE_ERROR || cc == CC_BANDWIDTH_ERROR) {
xhci_reap_slots(xhci, slot_id);
cc = xhci_cmd_configure_endpoint(xhci, slot_id, config_id, ic);
}
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
if (cc != CC_SUCCESS) {
xhci_debug("Configure endpoint failed: %d\n", cc);
ret = CONTROLLER_ERROR;
goto _free_ep_ctx_return;
} else {
xhci_debug("Endpoints configured\n");
}
goto _free_return;
_free_ep_ctx_return:
for (i = 2; i < 31; ++i) {
if (di->transfer_rings[i])
free((void *)di->transfer_rings[i]->ring);
free(di->transfer_rings[i]);
di->transfer_rings[i] = NULL;
}
_free_return:
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
free(ic->raw);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
free(ic);
return ret;
}
void
xhci_destroy_dev(hci_t *const controller, const int slot_id)
{
xhci_t *const xhci = XHCI_INST(controller);
libpayload: usb: Fix several minor USB stack bugs This patch fixes the following minor bugs in the USB stack: 1. Ensure that all dynamically allocated device structures are cleaned on detachment, and that the device address is correctly released again. 2. Make sure MSC and HID drivers notice missing endpoints and actually detach the device in that case (to prevent it from being used). 3. Make sure XHCI-specific set_address() cleans up all data structures on failure. 4. Fix broken Slot ID range check that prevented XHCI devices from being correctly cleaned up. Change-Id: I7b2b9c8cd6c5e93cb19abcf01425bcd85d2e1f22 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170665 Reviewed-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Ronald Minnich <rminnich@chromium.org> Tested-by: Ronald Minnich <rminnich@chromium.org> (cherry picked from commit 9671472263ddd0c30400ae3b6da780a18cd21ded) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6701 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-09-25 21:30:07 +02:00
if (slot_id <= 0 || slot_id > xhci->max_slots_en)
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
return;
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
inputctx_t *const ic = xhci_make_inputctx(CTXSIZE(xhci));
if (!ic) {
xhci_debug("Out of memory, leaking resources!\n");
return;
}
const int num_eps = controller->devices[slot_id]->num_endp;
*ic->add = 0; /* Leave Slot/EP0 state as it is for now. */
*ic->drop = (1 << num_eps) - 1; /* Drop all endpoints we can. */
*ic->drop &= ~(1 << 1 | 1 << 0); /* Not allowed to drop EP0 or Slot. */
int cc = xhci_cmd_evaluate_context(xhci, slot_id, ic);
libpayload: xhci: plug leak Change-Id: Ia163872846906c6c78144a984a405812f856f626 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Found-by: Coverity Scan #1325835 Reviewed-on: https://review.coreboot.org/18035 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2017-01-04 22:08:10 +01:00
free(ic);
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
if (cc != CC_SUCCESS)
xhci_debug("Failed to quiesce slot %d: %d\n", slot_id, cc);
cc = xhci_cmd_stop_endpoint(xhci, slot_id, 1);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
if (cc != CC_SUCCESS)
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
xhci_debug("Failed to stop EP0 on slot %d: %d\n", slot_id, cc);
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
int i;
libpayload: xhci: Make XHCI stack usable on ARM This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-09-04 02:15:31 +02:00
devinfo_t *const di = &xhci->dev[slot_id];
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
for (i = 1; i < num_eps; ++i) {
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
if (di->transfer_rings[i])
free((void *)di->transfer_rings[i]->ring);
free(di->transfer_rings[i]);
free(di->interrupt_queues[i]);
}
libpayload: usb: xhci: Prevent address reuse We have been trying to avoid reassigning previously used USB addresses to different devices since CL:197420, because some devices seem to take issue with that. Unfortunately, that patch doesn't affect XHCI: those controllers insist on chosing addresses on their own. The only way to prevent them from reusing a previously assigned address is to not disable that slot at all. This patch implements address reuse avoidance on XHCI by not disabling slots when a device is detatched (which may occur both on physical detachment or if we simply couldn't find a driver for that device). Instead, we just release as many resources as we can for detached devices (by dropping all endpoint contexts) and defer the final cleanup until the point where the controller actually runs out of resources (a point that we probably don't often reach in most firmware scenarios). BRANCH=none BUG=chrome-os-partner:42181 TEST=Booted an Oak plugged into a Servo without having a driver for the SMSC network chip, observed that it could still enumerate the next device afterwards. Kept unplugging/replugging stuff until the cleanup triggered and made sure the controller still worked after that. Also played around a bit on a Falco without issues. Change-Id: Idfbab39abbc5bc5eff822bedf9c8d5bd4cad8cd2 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 88c6bcbc41156729c3c38937c8a4adebc66f1ccb Original-Change-Id: I0653a4f6a02c02498210a70ffdda9d986592813b Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/284175 Original-Tested-by: Nicolas Boichat <drinkcat@chromium.org> Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10957 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-07-09 07:36:00 +02:00
xhci_spew("Stopped slot %d, but not disabling it yet.\n", slot_id);
di->transfer_rings[1] = NULL;
libpayload: Fill gaps in the xHCI driver Well, it turned out to be more as some gaps ;) but we finally have xHCI running. It's well tested against a QM77 Ivy Bridge board. We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not advertised and USB 3 devices will just work at HighSpeed. There are still some bit fields in xhci_private.h, so this might need little more work to run on ARM. Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c Signed-off-by: Nico Huber <nico.huber@secunet.com> Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3452 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-13 14:37:15 +02:00
}