The USBHID driver zero-initializes some but not all of the fields in its
usbhid_inst_t structure. This is a problem because under some
circumstances, some of the uninitialized fields may be read and lead to
incorrect behavior. Some (broken) USB keyboards keep sending reports
that contain all zeroes even when they have no new keys... these usually
get silently ignored, but if the usbhid_inst_t structure is in an
inconsistent state where 'previous' is zeroed out but 'lastkeypress'
is non-zero because it wasn't properly initialized, these reports will
be interpreted as keyrepeats of the bogus 'lastkeypress'. This patch
changes the code to just xzalloc() the whole structure so we won't have
to worry about initialization issues anymore.
Change-Id: Ic987de2daaceaad2ae401a1e12b1bee397f802ee
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/23766
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
This will make the code work with the different styles
of Kconfig (emit unset bools vs don't emit unset bools)
Roughly, the patch does this, and a little bit of fixing up:
perl -pi -e 's,ifdef (CONFIG_LP_.+?)\b,if IS_ENABLED\($1\),g' `find . -name *.[ch]`
perl -pi -e 's,ifndef (CONFIG_LP_.+?)\b,if !IS_ENABLED\($1\),g' `find . -name *.[ch]`
Change-Id: Ib8a839b056a1f806a8597052e1b571ea3d18a79f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10711
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Forgot an asterisk and everything goes to hell. Sorry about that.
Change-Id: I6b2503ca3ea0f80d4e4e5d8b8c0e986fec5db2c9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173587
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: David James <davidjames@chromium.org>
(cherry picked from commit 2a357560a697b56cc6022a4dd3dda47b33568d83)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6854
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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)
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>
When libpayload header files are included in the payload itself, it's possible
that the payloads config settings will conflict with the ones in libpayload.
It's also possible for the libpayload config settings to conflict with the
payloads. To avoid that, the libpayload config settings have _LP_ (for
libpayload) added to them. The symbols themselves as defined in the Config.in files
are still the same, but the prefix added to them is now CONFIG_LP_ instead of just
CONFIG_.
Change-Id: Ib8a46d202e7880afdeac7924d69a949bfbcc5f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65303
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 23e866da20862cace0ed2a67d6fb74056bc9ea9a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6427
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This change makes it possible for vboot to avoid an
exploit that could cause involuntary switch to dev mode.
It gives depthcharge/vboot some information on the
type of input device that generated a key.
BUG=chrome-os-partner:21729
TEST=manually tested for panther
BRANCH=none
CQ-DEPEND=CL:182420,CL:182241,CL:182946
Change-Id: I87bdac34bfc50f3adb0b35a2c57a8f95f4fbc35b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/182357
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: http://review.coreboot.org/6003
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
And include the new, split out version in drivers/keyboard.c and
drivers/usb/usbhid.c. Those files were including curses.h just for those
definitions, but the include path was only fixed up to to point to the
libpayload versions of those files if one of the variants of curses was
compiled in. If neither was, gcc would fall back to the system version of that
header which is wrong.
Change-Id: I8c2ee0baf5f0702bd8c713c8dd4613a4bb269ce5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2762
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Previously printf()'s were used to show USB messages
which results in lots of USB information being shown
when it isn't needed. This will now use the usb_debug()
printing funtion that already exists in usb.h.
Change-Id: I2199814de3327417417eb2e26a660f4a5557cb9f
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2044
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Slightly more complete keymap
Change-Id: I4fef6b8f75ab07cb20a3a8ccd7eaad81c9fe719f
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1922
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The USB HID driver had some static variables with keyboard state. This
moves them to the driver's instance, so multiple attached keyboards
don't effect each other.
Change-Id: I3f1ccfdea95062b443cebe510abf2f72fdeb1916
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1907
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
The "debug" macro used internally in the libpayload USB subsystem was very
generically named and would leak into consumers of the library that included
usb.h directly or indirectly. This change turns that #define from a macro into
a static inline function to move away from the preprocessor, and also renames
it to usb_debug so it's less likely to collide with something unrelated.
Change-Id: I18717df111aa9671495f8a2a5bdb2c6311fa7acf
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/1738
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
The call to destroy_intr_queue was missing in usb_hid_destroy.
Change-Id: I51ccc6a79bc005819317263be24a56c51acd5f55
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1082
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have fatal(), which is just as good.
Coccinelle script:
@@
expression E;
@@
-usb_fatal(E)
+fatal(E)
Change-Id: Iabecbcc7d068cc0f82687bf51d89c2626642cd86
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/395
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The USB stack is pretty noisy. Reduce the output to a sane level.
Change-Id: I250949e5cf74a8c6d43822b2e7487143b2ae1c65
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
Reviewed-on: http://review.coreboot.org/393
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The new build system uses quite a few more -W flags for the compiler by
default than the old one. And that's for the better.
Change-Id: Ia8e3d28fb35c56760c2bd0983046c7067e8c5dd6
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/72
Tested-by: build bot (Jenkins)
Reviewed-by: Uwe Hermann <uwe@hermann-uwe.de>
while others dislike them being extra commits, let's clean them up once and
for all for the existing code. If it's ugly, let it only be ugly once :-)
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5507 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- support MMC2 devices
- make usb stack more solid
- drop some unused functions
- fix lowspeed/speed naming
- add support for "quirks"
- improve usbhid driver
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Joseph Smith <joe@settoplinux.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5299 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
- fix minor bug in serial driver.
- latest USB stack fixes
- fix dead store in options.c
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@4239 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
replaces it with two queues (input, output) where drivers (serial,
keyboard, video, usb) can attach.
The only things left with #ifdefs are initialization (at some point
the drivers must get a chance to register)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3679 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
560bytes/controller)
- no need for the client of libpayload to implement
usbdisk_{create,remove}, just because USB was compiled in.
- usb hub support compiles, and works for some trivial cases (no device
detach, trivial power management)
- usb keyboard support works in qemu, though there are reports that it
doesn't work on real hardware yet.
- usb keyboard is integrated in both libc-getchar() and curses, if
CONFIG_USB_HID is enabled
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3662 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
memalign implementation (eg. the one I sent yesterday).
Features:
- UHCI controller driver
- UHCI root hub driver
- USB MSC (Mass Storage Class) driver
- skeleton of a USB HID driver
(requires better interrupt transfer handling, which is TODO)
- skeleton of a USB hub driver
(needs several blank spots filled in, eg. power management.
Again: TODO)
OHCI and EHCI are not supported, though OHCI support should be rather
easy as the stack provides reasonable abstractions (or so I hope). EHCI
will probably be more complicated.
Isochronous transfers (eg. webcams, audio stuff, ...) are not supported.
They can be, but I doubt we'll have a reason for that in the boot
environment.
The MSC driver was tested against a couple of USB flash drives, and
should be reasonably tolerant by now. But I probably underestimate
the amount of bugs present in USB flash drives, so feedback is welcome.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Jordan Crouse <jordan.crouse@amd.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3560 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Julius Werner