On sandboxed will be invoked when the device is sandboxed. Device
implementation could do initialization here. It does not need to return
fd opened here to keep fds.
BUG=None
TEST=local build and run
Change-Id: I42c2b3cae3a87dd54f02e77b8cd10766309a0770
Reviewed-on: https://chromium-review.googlesource.com/1327513
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
In order to properly send dmabufs over the wayland protocol, accurate
buffer metadata is needed in the guest. This change plumbs information
from minigbm allocations to the guest using a virtio-gpu response.
BUG=875998
TEST=wayland-simple-egl
Change-Id: I5c80d539bc7757c302ad7adf56f5d3b011304617
Reviewed-on: https://chromium-review.googlesource.com/1227054
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: David Riley <davidriley@chromium.org>
We updated the production toolchain from 1.30 to 1.31 in CL:1366446.
This CL does the same upgrade for the local developer toolchain and
Kokoro.
The relevant changes are in rust-toolchain and kokoro/Dockerfile.
The rest are from rustfmt.
TEST=cargo fmt --all -- --check
TEST=as described in kokoro/README.md
Change-Id: I3b4913f3e237baa36c664b4953be360c09efffd4
Reviewed-on: https://chromium-review.googlesource.com/1374376
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This change uses the resource bridge between virtio-gpu and virtio-cpu
to send resources over the host wayland connection that originated from
the virtio-gpu device. This will help support gpu accelerated wayland
surfaces.
BUG=chromium:875998
TEST=wayland-simple-egl
Change-Id: I3340ecef438779be5cb3643b2de8bb8c33097d75
Reviewed-on: https://chromium-review.googlesource.com/1182793
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This CL adds a crate `sync` containing a type sync::Mutex which wraps
the standard library Mutex and mirrors the same methods, except that
they panic where the standard library would return a PoisonError. This
API codifies our error handling strategy around poisoned mutexes in
crosvm.
- Crosvm releases are built with panic=abort so poisoning never occurs.
A panic while a mutex is held (or ever) takes down the entire process.
Thus we would like for code not to have to consider the possibility of
poison.
- We could ask developers to always write `.lock().unwrap()` on a
standard library mutex. However, we would like to stigmatize the use
of unwrap. It is confusing to permit unwrap but only on mutex lock
results. During code review it may not always be obvious whether a
particular unwrap is unwrapping a mutex lock result or a different
error that should be handled in a more principled way.
Developers should feel free to use sync::Mutex anywhere in crosvm that
they would otherwise be using std::sync::Mutex.
TEST=boot linux
Change-Id: I9727b6f8fee439edb4a8d52cf19d59acf04d990f
Reviewed-on: https://chromium-review.googlesource.com/1359923
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Hopefully the changes are self-explanatory and uncontroversial. This
eliminates much of the noise from `cargo clippy` and, for my purposes,
gives me a reasonable way to use it as a tool when writing and reviewing
code.
Here is the Clippy invocation I was using:
cargo +nightly clippy -- -W clippy::correctness -A renamed_and_removed_lints -Aclippy::{blacklisted_name,borrowed_box,cast_lossless,cast_ptr_alignment,enum_variant_names,identity_op,if_same_then_else,mut_from_ref,needless_pass_by_value,new_without_default,new_without_default_derive,or_fun_call,ptr_arg,should_implement_trait,single_match,too_many_arguments,trivially_copy_pass_by_ref,unreadable_literal,unsafe_vector_initialization,useless_transmute}
TEST=cargo check --features wl-dmabuf,gpu,usb-emulation
TEST=boot linux
Change-Id: I55eb1b4a72beb2f762480e3333a921909314a0a2
Reviewed-on: https://chromium-review.googlesource.com/1356911
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
These duplicate the doc comments found in `trait PciDevice`. I am
removing them because a sensible reader would already assume that they
have fallen out of sync with the doc comments in the trait, and thus
refer to the trait definition anyway.
TEST=none
Change-Id: Id86936a6f2a1b6c78a000b107bb4fc8ed78e40f9
Reviewed-on: https://chromium-review.googlesource.com/1355350
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Our virtio devices are all "modern" (no legacy/transitional support).
Add VIRTIO_F_VERSION_1 to the features() handler for all virtio devices
that didn't already have it.
This lets us remove the hack that forced VIRTIO_F_VERSION_1 on for all
devices.
BUG=None
TEST=build_test; boot crosvm on kevin
Change-Id: I008926a9075679aae46069aa37a14504f10e8584
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1313013
Reviewed-by: Zach Reizner <zachr@chromium.org>
When wl-dmabuf is not enabled, rustc complains about unused imports and
enum values. Add compiler directives to silence the warnings.
BUG=None
TEST='cargo build', 'emerge-nami crosvm'
Change-Id: Ib39735d329f8aa835c0b5842b10bfe78d0e578d9
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1327827
The virtio specification only defines feature bits in the 0-63 range
currently, so we can represent the features as a u64. The Linux kernel
makes the same simplifying assumption, and very few features have been
defined beyond the first 32 bits, so this is probably safe for a while.
This allows the device models to be simplified, since they no longer
need to deal with the features paging mechanism (it is handled by the
generic virtio transport code).
BUG=None
TEST=build_test; boot termina on kevin
Change-Id: I6fd86907b2bdf494466c205e85072ebfeb7f5b73
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1313012
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Refactor existing code to use msg_socket.
BUG=None
TEST=local build and run
Change-Id: Iee72326b330e035303f679e1aedd6e5d18ad4f8a
Reviewed-on: https://chromium-review.googlesource.com/1260260
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This matches the definitions from the virtio specification and makes
balloon consistent with the other virtio devices in crosvm.
BUG=None
TEST=build_test.py
Change-Id: I9dd6b6ec981944e28eaf6bc92332db5ec326433b
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1313011
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
All devices have been converted to PCI, so we don't need MmioDevice.
BUG=chromium:854766
TEST=Boot crosvm on kevin and verify virtio devices still work
Change-Id: Ib6400e15bdb2153d14795de3cb0bfbf1845a8891
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1281832
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Rust 1.30.0 ships a new rustfmt that causes a few more formatting
changes.
BUG=None
TEST=Run kokoro tests with updated Rust version
Change-Id: I803765ec0f3d2447f627b1e990bce438512367f7
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1307816
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Register the irqfd with resample support so that we can correctly
emulate level-triggered interrupts. This requires each PciDevice to
listen for interrupt_resample events and re-assert the IRQ eventfd if it
should still be active.
BUG=None
TEST=Boot crosvm on x86-64 and arm devices
Change-Id: I5cf8d1d1705cf675b453962c00d2d606801fee91
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1298654
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
File exposes sync_all() and sync_data() functions, which map to fsync()
and fdatasync(), but these functions are not in a trait (they are just
implemented directly on File), so they can't be implemented and used in
a generic way for QcowFile.
Add a new trait, FileSync, that exposes a fsync() function that may be
used in the virtio block model. Previously, we were translating a block
flush request into a call to File's flush() function, but this just
flushes internal Rust library buffers to the file descriptor; it didn't
actually result in a fsync() call. Using the new trait, we can cause an
actual fsync() to occur for raw files, as intended. QcowFile was
already safe, since its flush() function actually calls sync_all() under
the hood.
BUG=None
TEST=sync with raw disk and verify fsync() in strace output
Change-Id: I9bee2c0d2df3747aac1e7d9ec7d9b46a7862dc48
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1297839
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
If a BackBuffer has some gpu_renderer_resource, attach the backing
through to virgl to allow resources to be transfered in the future.
BUG=chromium:892261
TEST=eglgears_x11, xterm, xeyes
Change-Id: I9c4310da8eba73ec69dbaeba340b362c22fb21a0
Reviewed-on: https://chromium-review.googlesource.com/1288960
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Make the Minijail part of the PCI device tuple optional so that an empty
jail is not created for --disable-sandbox.
BUG=None
TEST=Boot crosvm in both --multiprocess and --disable-sandbox modes
Change-Id: Ibb3f2dbf33ca19910ee7448ea823b2772e09ecc5
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1290289
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Our branch of the 3.18 kernel has FALLOC_FL_PUNCH_HOLE disabled for the
ext4 filesystem, which means that systems running that kernel always
take the fallback path of writing buffers full of zeroes. This is not
necessary for the Discard command, since it is just a hint and is not
required to actually zero the blocks.
Split the WriteZeroes trait up into a new PunchHole trait, which
corresponds to fallocate() with FALLOC_FL_PUNCH_HOLE, and use the new
trait to implement the virtio block Discard command.
BUG=chromium:896314
TEST=`mkfs.btrfs /dev/vdb` and verify the desired fallocate() is used
and no write() calls are issued when inducing a failure
Change-Id: I67fd9a132758d8d766531ccca8358c7fe67b0460
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1286224
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The virtio PCI spec (4.1.4.5.1 Device Requirements: ISR status
capability) says:
"The device MUST reset ISR status to 0 on driver read."
BUG=chromium:854766
TEST=None
Change-Id: I92a1ddccfc8e44bed7f4a16e3cfd11b946629e22
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1260252
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The virtio PCI spec (4.1.5.2 Notifying The Device) says:
"The driver notifies the device by writing the 16-bit virtqueue index
of this virtqueue to the Queue Notify address."
We were previously registering the notify address specifying
NoDatamatch; switch this to a 16-bit match of the queue index to follow
the specification.
BUG=chromium:854766
TEST=Boot crosvm with virtio devices converted to PCI
Change-Id: Ic950a8c7751268f7fcc21d5c37b0afc859f1e6d0
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1265861
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Now that cargo fmt has landed, run it over everything at once to bring
rust source to the standard formatting.
TEST=cargo test
BUG=None
Change-Id: Ic95a48725e5a40dcbd33ba6d5aef2bd01e91865b
Reviewed-on: https://chromium-review.googlesource.com/1259287
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
capset2 has many new features. We currently hardcode num_capsets
to 1, however our Mesa/guest kernel/virglrenderer are new enough
to support caps v2.
We could attempt to do negotiation (see virtio_gpu_virgl_get_num_capset
in QEMU), but virtio::gpu::Gpu::get_config actually comes before
virtio::gpu::Gpu::activate. To support older Mesa/guest kernel/virglrenderer
configurations, this must be refactored.
BUG=none
TEST=get a gles31 context on tatl
Change-Id: I8d9ed54774a63da2ec5a4ba86187330521785566
Reviewed-on: https://chromium-review.googlesource.com/1258323
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
The virtio PCI transport requires that the queue_size configuration
value returns the maximum supported queue size on reset; it uses 0 to
indicate an unavailable queue.
Queue::size is write-only via the existing MmioDevice (the driver must
always write a queue size during initialization), so there should be no
difference in behavior when using MMIO virtio devices.
Change-Id: I5b77e0d84f0bc7b854e33aaeb34ff011af226103
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1237363
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This will be used on ARM.
Change-Id: I61206b761f49f963f0cce706268379ceae1a0239
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1241540
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The current PciRoot is only workable for the legacy I/O port 0xCF8
access mechanism; factor out the config access mechanism part of PciRoot
into PciConfigIo so that we can add a MMIO-based access mechanism for
ARM.
Change-Id: I87756b0ab31070d8717c76d419957bf5ea5d75ad
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1241539
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Most of PCI configuration space should be read only; initialize the
writable_bits field accordingly.
Change-Id: I67f93d81cfbac6000db51663bdf76e54aeac08f3
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1240659
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The add_capability() function was using the normal PCI configuration
write_byte() function, which enforces read-only regions. This won't
work once the appropriate regions of config space are marked as read
only in the following commit, so add an internal-only helper function to
access bytes without applying writable_bits.
Change-Id: If61f79cd80950bf517d69c18aaf98c2e76841a56
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1240658
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Return the BAR number rather than the register offset within PCI config
space.
Change-Id: I6e965c5fe7218abe6986b461731f18abb34894c1
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1240653
Reviewed-by: Dylan Reid <dgreid@chromium.org>
VirtioDevices and potentially others need to register ioeventfds that
will be triggered when guests write to certain addresses. Allow
PciDevices to return an array of ioeventfds that the VM can install.
Change-Id: I2524c4e8c04f75a8d7868cac998304aecbb29c40
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1237360
Commit-Ready: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
PciDevice implementations will have file descriptors that need to be
preserved across the minijail fork.
Change-Id: I0b1f5b827b55c4d8960ffa95331b82f9c692f304
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1237359
Reviewed-by: Dylan Reid <dgreid@chromium.org>
PCI class codes are made up of three fields: class, subclass, and
programming interface. Some class/subclass combinations do not define
any programming interfaces, so add an optional parameter to specify the
value and use 0 if it is not provided.
Change-Id: Ib4000eafe2d7d003ed5753d7b0ea05e16fd06130
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1237358
Reviewed-by: Dylan Reid <dgreid@chromium.org>
passing everything in to the pci code is getting annoying. Instead build
it up in arch which already has access to all the needed resources.
Change-Id: If42f994443c4f11152fca8da16f27fa4cd80580d
Reviewed-on: https://chromium-review.googlesource.com/1237357
Commit-Ready: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Rather than querying the flush timerfd state repeatedly on every write,
just track the state in a variable. This avoids an extra
timerfd_gettime() syscall on every write.
BUG=None
TEST=Verify that the flush timer still fires via strace
Change-Id: I5437d26570de466f05b496d3e0dce08a521c4fde
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1247443
Reviewed-by: Dylan Reid <dgreid@chromium.org>
To fully meet the requirements laid out by the virtio specification, we
need to fail write commands for devices that expose VIRTIO_BLK_F_RO with
a specific error code of VIRTIO_BLK_S_IOERR. Pipe the read_only status
down into the worker and the request execute function so that it can be
checked and return the correct error code.
BUG=chromium:872973
TEST=Attempt to write to read-only /dev/vda in termina
Change-Id: I98c8ad17fde497e5a529d9e65096fb4ef022fd65
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1211062
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Otherwise, the flush timer case of the PollContext continues to fire
repeatedly, since the timerfd remains readable.
BUG=None
TEST=Verify that crosvm virtio_blk thread no longer pins the CPU after
writes are done
Change-Id: I693346c078e07b97e30083f34d00be75fa93841d
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1232295
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The Scm object was made to reduce the number of heap allocations in
the hot paths of poll loops, at the cost of some code complexity. As it
turns out, the number of file descriptors being sent or received is
usually just one or limited to a fixed amount that can easily be covered
with a fixed size stack allocated buffer.
This change implements that solution, with heap allocation as a backup
in the rare case that many file descriptors must be sent or received.
This change also moves the msg and cmsg manipulation code out of C and
into pure Rust. The move was necessary to allocate the correct amount
of buffer space at compile time. It also improves safety by reducing the
scope of unsafe code. Deleting the code for building the C library is
also a nice bonus.
Finally, the removal of the commonly used Scm struct required
transitioning existing usage to the ScmSocket trait based methods. This
includes all those changes.
TEST=cargo test
BUG=None
Change-Id: If27ba297f5416dd9b8bc686ce740866912fa0aa0
Reviewed-on: https://chromium-review.googlesource.com/1186146
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
If the guest doesn't issue a flush command after a write, insert one.
This will mainly help qcow backed files. However, it is a good idea for
block devices as well, it narrows the window for data loss.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I1d6eaeda6fd5038ec994ed882e870ae025e3c151
Reviewed-on: https://chromium-review.googlesource.com/1211126
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Sandboxing only works when started as chronos via concierge client. If
started directly via crosvm as root, the jail will not have proper group
permissions to access the Wayland socket.
BUG=chromium:837073
TEST=build with --features=gpu; null_platform_test without --disable-sandbox
CQ-DEPEND=CL:1213779
Change-Id: I6331f7ae1f5b99d31ad44cf158f72337294771f0
Reviewed-on: https://chromium-review.googlesource.com/1181168
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The virtio PCI specification places requirements on the PCI subsystem
IDs, so allow PCI devices to specify them in PciConfiguration.
Change-Id: I70bc6ad4333ba3601db2831fef03483bcaea70ff
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1208156
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
The status register is actually the high 16 bits of register index
STATUS_REG (1). Adjust the STATUS_REG_CAPABILITIES_USED_MASK value
accordingly so it is bit 4 within the high 16 bits.
Change-Id: I3fb695a577bae754eda5640224ef335c44b119eb
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1208152
Reviewed-by: Dylan Reid <dgreid@chromium.org>
