On devices with only one configuration, skip the code that attempts to
change the device's active configuration, since it must always be the
single available configuration.
This works around an issue observed with some USB devices (e.g. Servo
Micro) where the initial Get Configuration control request fails with
-EPIPE.
BUG=chromium:1061382
BUG=b:151408644
TEST=Attach servo micro, see /dev/ttyUSB[012], screen /dev/ttyUSB0
Change-Id: Ic3333e1d70a0c57b090de64e4d3b7932ce2cf81d
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2108871
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: George Engelbrecht <engeg@google.com>
Commit-Queue: George Engelbrecht <engeg@google.com>
Transfer TRBs have a flag that indicates that data is transferred within
the TRB itself instead of as a separate buffer. Add support for this
type of transfer in the ScatterGatherBuffer implementation.
This fixes USB support when using Linux 5.1+ as the guest kernel, since
it now uses immediate data transfers.
BUG=chromium:1046564
TEST=`adb root` to connected phone on Linux 5.4 guest kernel
Change-Id: I6c37db422ac8e65d10e1a91807b15e903ad614de
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2026262
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Don't store the BAR value, as it can potentially be updated by the
guest. (This is not supported by our PCI device model just yet, but this
is still the correct thing to do and matches other crosvm PCI devices.)
BUG=None
TEST=Add USB device on nami
Change-Id: Ie42d08429e7ff124178c818877b4cee83003d66f
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1924782
Reviewed-by: Zach Reizner <zachr@chromium.org>
rust 1.40 has a new warning when there are extra parens, soRemove them.
Change-Id: Ibb565cac41ba8d72879f4cb8b949f2be30e55167
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1978140
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Since unified allocator is used to allocate mmio, this patch remove the
device memory name, and rename device to mmio.
BUG=chromium:992270
TEST=this patch doesn't change function, run build_test
Change-Id: I234b0db4b3c5de8cfee372ace5212a980564d0c7
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1895234
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Current mmio and device two allocators exist, the purpose to define
two allocator is:
Accessing to gpa from mmio allocator cause vm exit, while gpa from
device allocator doesn't cause vm exit.
Whether vm exits exist or not, dependency on whether
vm->add_device_memory() is called with gpa from allocator or not.Even
if gpa is from mmio alloator, and vm->add_device_memory() is called
with this gpa, accessing this gpa won't cause vm exit. So mmio allocator
and device allocator couldn't guarantee the original purpose.
This patch unify mmio allocator and device allocator into one mmio
allocator.
BUG=chromium:992270
TEST=this patch doesn't change function, so just run build_test
Change-Id: If87d5c2838eb122ef627fa45c394b1b3ccfafeb0
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1895233
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This just removes a few extraneous blank lines that the new rustfmt
doesn't like.
BUG=None
TEST=bin/fmt --check
Change-Id: I4482f873bdfe19f2f73f86cfdd99d6cce873593c
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1863000
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Drop the dependency on libusb and reimplement the host USB backend using
usb_sys to wrap the Linux usbdevfs ioctls.
This allows sandboxing to work without any dependency on libusb patches,
and it gives us the flexibility to modify and update the USB backend
without depending on an external third-party library.
BUG=chromium:987833
TEST=`adb logcat` on nami with Nexus 5 attached
TEST=deploy app to phone with Android Studio
TEST=Run EdgeTPU USB accelerator demo (including DFU mode transition)
Cq-Depend: chromium:1773695
Change-Id: I4321c2b6142caac15f48f197795a37d59d268831
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1783601
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Make sure all devices join any threads they spawn before returning from
the drop() handler after signaling the exit event.
BUG=chromium:992494
TEST=crosvm exits without errors
Change-Id: I6bc91c32a08f568b041765044caa9aff6f7cf4a9
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1802156
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Rather than having a get_canceller() function on UsbTransfer, make the
submit function return the canceller. This makes it clear that the
transfer can't be cancelled before it is submitted.
BUG=None
TEST=None
Change-Id: Ice36c3096a1f8a5aafe93b5d5e27eb371183c19f
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1783599
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Fix the last instance of this clippy warning:
warning: passing a unit value to a function
... and remove this warning from the "To be resolved" list in
bin/clippy.
BUG=None
TEST=bin/clippy passes without warnings
Change-Id: Ic1d558e935366d80eeadb96bf1ff951ce50edd5b
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1766623
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
When USB device is detached from kernel driver there might be multiple
pending USB transfers enqued, each completing with TransferStatus::NoDevice.
Once backend device is detached from system it's ok to ignore subsequent
detach request errors in transfer completion handler.
BUG=chromium:987500
TEST=ADB USB device attach/detach cycles with active adb service.
Change-Id: I4026e68df860c483973f51f9787bf3d48d2716b3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1737471
Tested-by: Tomasz Jeznach <tjeznach@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Tomasz Jeznach <tjeznach@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Currently device impliments PciDevice trait, it will return config
register to bus trait at pci cfg r/w, then BusDevice trait on behave
of device to do actual pci config r/w.
But vfio device need to handle the pci config r/w by itself, as
vfio device need to transfer this request to kernel.
For pci config read, this patch delete PciDevice->config_registers(),
and add PciDevice->read_config_register(), then BusDevice->
config_register_read() call PciDevice->read_config_register(), finally
Device could trap the PciConfig Read.
For pci config write, it is similiar with pci config read. But the
common code is moved into PciConfiguration.
BUG=none
TEST=none
Change-Id: Ie6bd3a8c94f523d6fb1ef3d1e97d087bb0407d9f
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1580457
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Replace use of our custom, patched libusb APIs with the new
libusb_wrap_sys_device() function, which has been submitted to libusb
upstream. This allows us to drop the bindings for the custom APIs (and
will also allow us to drop the libusb patch that introduces them).
For now, keep this path behind the sandboxed-libusb feature to allow
crosvm to build against older libusb versions that do not have the new
API. This should be cleaned up eventually once we are comfortable with
raising the minimum libusb version required.
BUG=b:133773289
TEST=Attach Android device to Linux VM; deploy app via adb
Change-Id: Ie249c6f3f3b4c63210dd163ca7ad03e2de8a8872
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1676601
Tested-by: kokoro <noreply+kokoro@google.com>
Each PCI BAR must be aligned to at least its own size to allow the BAR
sizing mechanism to work. Change all BAR allocations to use
allocate_with_align(), specifying the size as the alignment.
In particular, this fixes the alignment of the XHCI BAR, whose size is
larger than a page (the default MMIO allocator alignment).
BUG=None
TEST=Boot vm_kernel in crosvm
Change-Id: Icba03771a896b9b4feae608efdb7685fe24f8b98
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1660202
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This enables the full firmware update/reset/use device in application
mode sequence for Edge TPU USB Accelerator.
There is a bit of a UI hiccup: once the firmware update and reset is
complete, the device re-enumerates with a different VID/PID, and the
"Connect to Linux" prompt shows up again. The user must re-affirm that
the device should be connected to Linux to proceed with using the Edge
TPU. This may be unavoidable - I'm not sure if we can tell the
difference between a newly-inserted device and a reset one.
Allowing USBDEVFS_DISCONNECT_CLAIM should be safe, since it can only
operate on file descriptors passed into the xhci device jail.
BUG=chromium:831850
TEST=Run Edge TPU Accelerator demo and verify that it can update FW
Change-Id: I3d61c7bd914830ce25448b1ae4d60e1c16f10aed
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1599881
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
We don't need schema anymore. Will use bool and custom enums.
BUG=None
TEST=local build and run crosvm
Change-Id: I1396916878f2903b17a75f375aee4eec1ced0583
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1564780
Tested-by: kokoro <noreply+kokoro@google.com>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Transfer requests have a flag called Interrupt on Short Packet (ISP)
that we have been totally ignoring. Now that the control request
execution phases have been rearranged in previous changes, we can
correctly trigger an event when a transfer fills fewer bytes than
requested.
This fixes firmware update on the Edge TPU USB Accelerator (Coral):
https://coral.withgoogle.com/docs/accelerator/get-started/
BUG=chromium:831850
TEST=Run Edge TPU test model from get-started page
Change-Id: I0d21e408a19c2e2eba562362bfe636c75dbb7160
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1593716
Tested-by: kokoro <noreply+kokoro@google.com>
Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
If a control request has a DataStage, execute the request during the
data stage so that we can get the actual length of the transferred data.
This will allow the ISP (Interrupt on Short Packets) bit to be
implemented correctly; we need to know the actual length during
processing of the DataStage TRB rather than at the StatusStage as we did
previously. (Note that ISP isn't implemented yet in this change; this
just passes the correct length to xhci_transfer.on_transfer_complete,
which doesn't do anything useful with the length yet in the short
transfer case.)
BUG=chromium:831850
TEST=Test adb on Crostini
Change-Id: I340424269aa139b0d9698f44ce9d3a457f3eb899
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1593715
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Certain control requests need to be intercepted for special handling
rather than being passed through directly to the device. Clean up the
implementation of these intercepted requests by getting rid of the
confusing intermediate analyze_request_setup function and merging it
with the actual handling of each intercepted request in the new
execute_control_transfer function. This keeps the custom handling all
in one place rather than scattered around the file and removes the need
for the extra HostToDeviceControlRequest enum.
Also add a check in get_standard_request to verify that the request is
indeed a standard control request so that the caller does not need to
check.
BUG=chromium:831850
TEST=Test adb on Crostini
Change-Id: I73b1db76941c39f124cfd0f51f14c15017ba9141
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1593714
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The get_type and get_direction helpers return Options, even though
they can only possibly return a non-None value; all bit patterns of the
fields they are interpreting are defined. Drop the Options and return
the enum values directly to simplify callers and remove dead code.
Fix up a typo ("recipienet" -> "recipient") while we're in the
neighborhood.
BUG=chromium:831850
TEST=Test adb in Crostini
Change-Id: Ie26a1ed1c15f5f17b5ae80be78ce5f8ff51fab28
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1593713
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The device to host and host to device branches of HostDevice's
handle_control_transfer function are basically identical, differing only
in whether to do a read or write and when to do it. Split this code out
into its own function, execute_control_transfer, to reduce code
duplication and prepare for future changes.
BUG=chromium:831850
TEST=Test adb in crostini
Change-Id: Ic659f18ca97e2c1c71f67f3543096fe69228969a
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1593712
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Rather than acquiring the lock twice, lock it once and hold it while
doing the check and potential follow-up call to interrupt(). This looks
like it could be a race to me, but I don't know if it can actually cause
problems in practice. In any case, it's better to only acquire the lock
once.
BUG=chromium:831850
TEST=Test adb in Crostini
Change-Id: Id7aa76e543cd5b858faf128f516e8d63e27cf3e7
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1592579
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Set the name of the thread created to run the Xhci controller event loop
so that it can be identified more easily in a debugger.
BUG=None
TEST=Attach to running crosvm with gdb and verify 'info threads' name
Change-Id: Id73a580b35231ec7fa7aec5bd51027d32e483bff
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1594192
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The UsbHub::try_detach function, which is only called from the libusb
hotplug callback when devices are removed, calls into
port.get_backend_device(), which acquires the backend_device lock, and
then calls port.detach(), which also tries to acquire the backend_device
lock, while still holding onto the backend_device. This clearly leads to
a deadlock.
Add an extra block in try_detach to keep the backend_device lock scoped
so that it is dropped before calling port.detach().
BUG=chromium:958117
TEST=Hot remove usb device from Crostini; verify it is gone in lsusb
Change-Id: Ibbbf68623390e3d25576f544b815c2a5607934fc
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1594158
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
1. Removed for device slot reset and evaluate context. The verification was
unnecessary and may cause some guest kernel operations to fail.
2. The context was updated after dequeue pointer set
3. Reset device when it's attached.
4. Add seccomp rules to allow the above reset.
The verification was copied from another implementation which works for
adb, but does not work with serial devices. The verification is also not
part of the spec, so we removed it here.
BUG=b:131336977
TEST=local build and test
Change-Id: Ifd7994ff5512346d1bab27654e60c97a602da8a6
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Signed-off-by: Zach Reizner <zachr@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1558934
Tested-by: kokoro <noreply+kokoro@google.com>
Originally, crosvm would list details about an attached usb device for a
given port. This change allows getting details about multiple ports at
once. This is intended to simplify command line usage and downstream
consumers like concierge.
TEST=various vmc commands
Chrome UI for handling USB devices
BUG=chromium:831850
Change-Id: I55681a7fea7425c897a22a579dcc15567683ef54
Reviewed-on: https://chromium-review.googlesource.com/1529765
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
AddressAllocator now maintains a HashMap<Alloc, (u64, u64, u64)>,
which uniquely maps a Allocation enum (e.g: PciBar(bus, dev, bar),
GpuRenderNode, etc...) to it's address, size, and human-readable tag
/ description.
The interface has also been modified to use Error instead of Option.
Aside from improving debugging, tracking allocations will have
numerous uses in the future. For example, when allocating guest memory
over VmControl sockets, it will be possible to restrict allocations to
pre-allocated slices of memory owned by the requesting device.
To plumb through PCI information to PCI devices, this CL necessitated
the addition of a PciDevice method called `assign_bus_dev`, which
notifies PCI devices of their uniquely assigned Bus and Device numbers.
BUG=chromium:936567
TEST=cargo test -p resources && cargo build --features="gpu gpu-forward"
Change-Id: I8b4b0e32c6f3168138739249ede53d03143ee5c3
Reviewed-on: https://chromium-review.googlesource.com/1536207
Commit-Ready: Daniel Prilik <prilik@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
As described in:
https://doc.rust-lang.org/edition-guide/rust-2018/ownership-and-lifetimes/default-match-bindings.html
which also covers the new mental model that the Rust Book will use for
teaching binding modes and has been found to be more friendly for both
beginners and experienced users.
Before:
match *opt {
Some(ref v) => ...,
None => ...,
}
After:
match opt {
Some(v) => ...,
None => ...,
}
TEST=cargo check --all-features
TEST=local kokoro
Change-Id: I3c5800a9be36aaf5d3290ae3bd3116f699cb00b7
Reviewed-on: https://chromium-review.googlesource.com/1566669
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Before the new borrow checker in the 2018 edition, we sometimes used to
have to manually insert curly braced blocks to limit the scope of
borrows. These are no longer needed.
Details in:
https://doc.rust-lang.org/edition-guide/rust-2018/ownership-and-lifetimes/non-lexical-lifetimes.html
TEST=cargo check --all-features
TEST=local kokoro
Change-Id: I59f9f98dcc03c8790c53e080a527ad9b68c8d6f3
Reviewed-on: https://chromium-review.googlesource.com/1568075
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
In Rust 2018 edition, `extern crate` is no longer required for importing
from other crates. Instead of writing:
extern crate dep;
use dep::Thing;
we write:
use dep::Thing;
In this approach, macros are imported individually from the declaring
crate rather than through #[macro_use]. Before:
#[macro_use]
extern crate sys_util;
After:
use sys_util::{debug, error};
The only place that `extern crate` continues to be required is in
importing the compiler's proc_macro API into a procedural macro crate.
This will hopefully be fixed in a future Rust release.
extern crate proc_macro;
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
TEST=local kokoro
Change-Id: I0b43768c0d81f2a250b1959fb97ba35cbac56293
Reviewed-on: https://chromium-review.googlesource.com/1565302
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Macros were previously imported through `#[macro_use] extern crate`,
which is basically a glob import of all macros from the crate. As of
2018 edition of Rust, `extern crate` is no longer required and macros
are imported individually like any other item from a dependency. This CL
fills in all the appropriate macro imports that will allow us to remove
our use of `extern crate` in a subsequent CL.
TEST=cargo check --all-features --tests
TEST=kokoro
Change-Id: If2ec08b06b743abf5f62677c6a9927c3d5d90a54
Reviewed-on: https://chromium-review.googlesource.com/1565546
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
The devices crate imports things from usb_util which is a separate
crate. Importing from a crate normally looks like:
use name_of_crate::path::to::ThingToImport;
In the case it would be e.g.:
use usb_util::hotplug::UsbHotplugHandler;
Importing these things through crate::usb::usb_util is unnecessary.
TEST=cargo check
Change-Id: I70554639a71b2423c1e13a30361d5f9d92e9d9a9
Reviewed-on: https://chromium-review.googlesource.com/1565725
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jingkui Wang <jkwang@google.com>
These are import paths in new code added since CL:1513054 that need to
be made compatible with 2018 edition's treatment of paths.
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
Change-Id: Icb3ecf2fb2015332e0c03cdc22bff2ecab2c40df
Reviewed-on: https://chromium-review.googlesource.com/1559264
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Found by running: `cargo rustc -- -D bare_trait_objects`
Bare trait objects like `&Trait` and `Box<Trait>` are soft-deprecated in
2018 edition and will start warning at some point.
As part of this, I replaced `Box<Trait + 'static>` with `Box<dyn Trait>`
because the 'static bound is implied for boxed trait objects.
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
TEST=local kokoro
Change-Id: I41c4f13530bece8a34a8ed1c1afd7035b8f86f19
Reviewed-on: https://chromium-review.googlesource.com/1513059
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
We were lucky that adb does not trigger this code path, but Arduino do.
BUG=None
TEST=local build, deploy and run
Change-Id: I0cf02c5de0a73af4e5cb6f5b668cef6606ed166b
Reviewed-on: https://chromium-review.googlesource.com/1542032
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
None of instances of EventHandler::on_event actually used the fd. The
PollfdChangeHandler::remove_poll_fd callback fabricated a potentially
valid fd (0), which went undetected because nobody used it.
Additionally, using RawFds almost always requires unsafe and should be
avoided.
CQ-DEPEND=CL:1522214
BUG=chromium:831850
TEST=cargo test
Change-Id: I095edbcad317e4832b1fb29fd08d602fbde4fd5d
Reviewed-on: https://chromium-review.googlesource.com/1525135
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Jingkui Wang <jkwang@google.com>
Device can be assigned to slot. Command ring handles usb commands,
transfer ring handles usb transfers.
CQ-DEPEND=CL:1510819
BUG=chromium:831850
TEST=cargo test
Change-Id: Ib0836ee518d1c7a3e902630c7ea04e29b9496c80
Reviewed-on: https://chromium-review.googlesource.com/1510820
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Those are bridges between xhci and backend.
CQ-DEPEND=CL:1510818
BUG=chromium:831850
TEST=cargo test
Change-Id: I04feab449d48b0c908aeebfda08d1869239cbe6f
Reviewed-on: https://chromium-review.googlesource.com/1510819
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
