e44a4e8787
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> |
||
---|---|---|
.. | ||
arch | ||
bin | ||
configs | ||
crypto | ||
curses | ||
drivers | ||
gdb | ||
include | ||
libc | ||
libcbfs | ||
liblz4 | ||
liblzma | ||
libpci | ||
sample | ||
tests | ||
Doxyfile | ||
Kconfig | ||
LICENSES | ||
LICENSE_GPL | ||
Makefile | ||
Makefile.inc | ||
README |
README
------------------------------------------------------------------------------- libpayload README ------------------------------------------------------------------------------- libpayload is a minimal library to support standalone payloads that can be booted with firmware like coreboot. It handles the setup code, and provides common C library symbols such as malloc() and printf(). Note: This is _not_ a standard library for use with an operating system, rather it's only useful for coreboot payload development! See http://coreboot.org for details on coreboot. Installation ------------ $ git clone http://review.coreboot.org/p/coreboot.git $ cd coreboot/payloads/libpayload $ make menuconfig $ make $ sudo make install (optional, will install into /opt per default) As libpayload is for 32bit x86 systems only, you might have to install the 32bit libgcc version, otherwise your payloads will fail to compile. On Debian systems you'd do 'apt-get install gcc-multilib' for example. Usage ----- Here's an example of a very simple payload (hello.c) and how to build it: #include <libpayload.h> int main(void) { printf("Hello, world!\n"); return 0; } Building the payload using the 'lpgcc' compiler wrapper: $ lpgcc -o hello.elf hello.c Please see the sample/ directory for details. Website and Mailing List ------------------------ The main website is http://www.coreboot.org/Libpayload. For additional information, patches, and discussions, please join the coreboot mailing list at http://coreboot.org/Mailinglist, where most libpayload developers are subscribed. Copyright and License --------------------- See LICENSES.