The following deadlock has been observed on a test setup:
* All tags allocated.
* The SCSI error handler calls ufshcd_eh_host_reset_handler()
* ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler()
* ufshcd_err_handler() locks up as follows:
Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt
Call trace:
__switch_to+0x298/0x5d8
__schedule+0x6cc/0xa94
schedule+0x12c/0x298
blk_mq_get_tag+0x210/0x480
__blk_mq_alloc_request+0x1c8/0x284
blk_get_request+0x74/0x134
ufshcd_exec_dev_cmd+0x68/0x640
ufshcd_verify_dev_init+0x68/0x35c
ufshcd_probe_hba+0x12c/0x1cb8
ufshcd_host_reset_and_restore+0x88/0x254
ufshcd_reset_and_restore+0xd0/0x354
ufshcd_err_handler+0x408/0xc58
process_one_work+0x24c/0x66c
worker_thread+0x3e8/0xa4c
kthread+0x150/0x1b4
ret_from_fork+0x10/0x30
Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved
request.
This patch is closely related to the upstream patch with the same title.
Bug: 205080886
Link: https://lore.kernel.org/linux-scsi/700f0463-23a9-8465-f712-1188cb884dea@acm.org/T/#u
Change-Id: I9e9ba3f45ba23ecf576380aa19701d3437af6cdd
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Before reducing 'can_queue' from 32 to 31, make
ufshcd_change_queue_depth() restrict the queue depth to 'can_queue'
instead of hba->nutrs (32). This is a backport of a subset of the
following patch: "[PATCH 2/2] scsi: ufs: Fix a deadlock in the error
handler".
Bug: 205080886
Link: https://lore.kernel.org/linux-scsi/20211103000529.1549411-3-bvanassche@acm.org/
Change-Id: I6e694a9698f91293fc2987217e3f939726c397dd
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Commit 4c22227e39 ("cfg80211: fix management registrations locking")
in 5.10.77, which is commit 09b1d5dc6c ("cfg80211: fix management
registrations locking") upstream, moved the mgmt_registrations_lock out
of struct wireless_dev. This did not change the structure size, but
caused a CRC change in the structure pointer, which tripped the abi
checker.
So restore the variable, and comment that this is not used anymore. No
driver should ever be touching this so it is safe.
Note, using a __GENKSYMS__ hack would work, as the overall structure
size remains the same when this variable is removed, BUT the warning
that the field is gone is reported by libabigail correctly, which would
require a .xml update, so it's not worth it.
Bug: 161946584
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibcfe743833860e6f75611d7ebed1036a77be0a69
The management registrations locking was broken, the list was
locked for each wdev, but cfg80211_mgmt_registrations_update()
iterated it without holding all the correct spinlocks, causing
list corruption.
Rather than trying to fix it with fine-grained locking, just
move the lock to the wiphy/rdev (still need the list on each
wdev), we already need to hold the wdev lock to change it, so
there's no contention on the lock in any case. This trivially
fixes the bug since we hold one wdev's lock already, and now
will hold the lock that protects all lists.
Cc: stable@vger.kernel.org
Reported-by: Jouni Malinen <j@w1.fi>
Fixes: 6cd536fe62 ("cfg80211: change internal management frame registration API")
Link: https://lore.kernel.org/r/20211025133111.5cf733eab0f4.I7b0abb0494ab712f74e2efcd24bb31ac33f7eee9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Bug: 204384349
(cherry picked from commit 09b1d5dc6c)
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id1bca68277be3a5f7c7329a8195018946f686bdb
When receiving a disconnect event from the UDC, the mass storage
function driver currently runs the handle_exception() routine
asynchronously. For UDCs that support runtime PM, there is a
possibility the UDC is already suspended by the time the
do_set_interface() is executed. This can lead to HW register access
while the UDC is already suspended.
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Bug: 204343836
(cherry picked from commit 9fff139aebhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing)
Change-Id: I6c8011baddf02d6b0eadb5934416bc24b8a93f4a
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
The usb_ep_disable() and usb_ep_enable() routines are being widely
used in atomic/interrupt context by function drivers. Hence, the
statement about it being able to only run in process context may
not be true. Add an explicit comment mentioning that it can be used
in atomic context.
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Bug: 204343836
(cherry picked from commit b0d5d2a716https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing)
Change-Id: I1adb5d074fe2f9e33ebfdb30d335283c56bc7b39
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
If CONFIG_CFI_CLANG=y, attempting to read an event histogram will cause
the kernel to panic due to failed CFI check.
1. echo 'hist:keys=common_pid' >> events/sched/sched_switch/trigger
2. cat events/sched/sched_switch/hist
3. kernel panics on attempting to read hist
This happens because the sort() function expects a generic
int (*)(const void *, const void *) pointer for the compare function.
To prevent this CFI failure, change tracing map cmp_entries_* function
signatures to match this.
Also, fix the build error reported by the kernel test robot [1].
[1] https://lore.kernel.org/r/202110141140.zzi4dRh4-lkp@intel.com/
Link: https://lkml.kernel.org/r/20211014045217.3265162-1-kaleshsingh@google.com
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Bug: 204946901
(cherry picked from commit 7ce1bb83a1)
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Change-Id: I4a1a39b086b5e306ddecabd9a6076e2fb14c3f70
In host control mode, eviction is precieved as an extreme measure.
There are several conditions that both the entering and exiting regions
should meet, so that eviction will take place.
The common case however, is that those conditions are rarely met, so it
is normal that the act of eviction fails. Therefore, Do not report an
error in host control mode if eviction fails.
Link: https://lore.kernel.org/r/20210808090024.21721-5-avri.altman@wdc.com
Fixes: 6c59cb501b (scsi: ufs: ufshpb: Make eviction depend on region's reads)
(cherry picked from commit 10163cee1f
git: //git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: Id6aa444ea5e2efd15c507bbd586c421018c75998
num_inflight_map_req should not be negative. It is incremented and
decremented without any protection, allowing it theoretically to be
negative, should some weird unbalanced count occur.
Verify that the those calls are properly serielized.
Link: https://lore.kernel.org/r/20210808090024.21721-4-avri.altman@wdc.com
Fixes: 33845a2d84 (scsi: ufs: ufshpb: Limit the number of in-flight map requests)
(cherry picked from commit 22aede9f48
git: //git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: I8a8252c919e6678752b60bcd950cb08e765e6aed
In HPB2.0, if pre_req_min_tr_len < transfer_len < pre_req_max_tr_len
the driver is expected to send a HPB-WRITE-BUFFER companion to HPB-READ.
The upper bound should fit into a single byte, regardless of
bMAX_ DATA_SIZE_FOR_HPB_SINGLE_CMD which being an attribute (u32) can
be significantly larger.
To further illustrate the issue let us consider the following scenario:
- SCSI_DEFAULT_MAX_SECTORS is 1024 limiting the IO chunks to 512KB
- The OEM changes scsi_host_template .max_sectors to be 2048, which
allows a 1M requests: transfer_len = 256
- pre_req_max_tr_len = HPB_MULTI_CHUNK_HIGH = 256
- ufshpb_is_supported_chunk returns true (256 <= 256)
- WARN_ON_ONCE(transfer_len > HPB_MULTI_CHUNK_HIGH) doesn't warn
- ufshpb_set_hpb_read_to_upiu cast transfer_len to u8: transfer_len = 0
- the command is failing with illegal request
Link: https://lore.kernel.org/r/20210808090024.21721-3-avri.altman@wdc.com
Fixes: 41d8a9333c (scsi: ufs: ufshpb: Add HPB 2.0 support)
(cherry picked from commit 07106f86ae
git: //git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: I0dc568020a0fe6c4ddf6952f89ad5230770fd7f3
The "cold"-timer purpose is not to hang-on to active regions with no
reads. Therefore the read-timeout should be re-wind on every read, and
not just when the region is activated.
Link: https://lore.kernel.org/r/20210808090024.21721-2-avri.altman@wdc.com
Fixes: 13c044e916 (scsi: ufs: ufshpb: Add "cold" regions timer)
(cherry picked from commit 283e61c5a9
git: //git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Avri Altman <avri.altman@wdc.com>
Change-Id: If174a161028cf2382538d69e30181cda979a12de
Add vendor hooks to monitor more update load-avg point
where tasks on the run-queue will go through.
Bug: 204857484
Signed-off-by: JianMin Liu <jian-min.liu@mediatek.com>
Change-Id: I440d7b9686a37508bd7568454472ab014ba0d0c9
This is needed to meet a FIPS 140-3 requirement that modules provide a
service that retrieves their name and versioning information.
Bug: 188620248
Change-Id: I36049c839c4217e3616daab52ec536b46479c12a
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 2888f960d0)
To satisfy the FIPS 140-3 "service indicators" requirement, add a
function which checks whether the given algorithm is "approved" or not.
Note that this function is a bit different from the module's other APIs
in that it is an exported symbol rather than a registration-based API.
This avoids needing to make kernel/KMI changes, so I think we should do
it this way if possible, given that it's unlikely this function will be
used in practice outside of the lab test. Built-in code can still call
this function via symbol_get() if it really wants to.
Bug: 188620248
Change-Id: I26c976258fa9446b34eb189bba7154142d85da16
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit fe4b8d3c68)
SPF patchset introduced an mmu_notifier imbalance by adding a new exit
path that skips mmu_notifier_invalidate_range_only_end after calling
mmu_notifier_invalidate_range_start. This triggers a BUG in KVM driver
checking for mmu_notifier_count to remain balanced
Fixes: afeec97a8d ("FROMLIST: mm: prepare for FAULT_FLAG_SPECULATIVE")
Bug: 161210518
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: Ibe9d1f0903a23b48c9d733b81249b190e5321c2f
FIPS 140-3 requires this for some reason.
Bug: 188620248
Change-Id: I7c286532097e1d8971faf4d8be31b801f9007e3b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit c14d52059b)
The lab has confirmed that it is actually fine for users to keep using
non-FIPS code after the module has loaded if they were already using it
beforehand. So remove the code that tried to prevent this by updating
live algorithms in-place. Similarly, remove the call to
synchronize_rcu_tasks() which no longer has any purpose.
We still need to move the live algorithms to a private list, so keep
doing that. Keep appending "+orig" to cra_name as well, and start doing
the same for cra_driver_name too.
Bug: 188620248
Change-Id: I29c9faec7d7314484a03f9729924b2f892552c7c
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 54aecb72db)
As per the new guidance from the lab, the module must block crypto
operations until the tests have completed. It's unclear what this means
exactly (given that technically this is impossible), but let's make some
changes that should be enough to comply with the requirement's intent.
First, register the library functions and update the live algorithms
after the tests rather than before the tests. This is a trivial change.
Much more problematic is the fact that the algorithms are registered
with the kernel's crypto framework before the tests run, as the tests
depend on the framework. Unfortunately, the lab believes that the
kernel isn't allowed to enforce the ordering here; the module itself
must. Moreover, trying to solve this by copying the crypto API
framework into the module proved to be heavily problematic.
Thus, implement an alternate solution: make the module override the tfm
initialization function of every algorithm it registers, so that it can
wait for the tests to complete before allowing the use of any algorithm.
This is sufficient if the user makes a supported sequence of API calls.
Bug: 153614920
Bug: 188620248
Change-Id: I11ffba90c08114dda4e91c4be7ce8b608c4e14c1
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 02e48f383b)
Instead of having a special case in the core kernel's module loader that
treats a module called 'fips140.ko' in a special way, use a host tool to
tweak the ELF metadata of this module so that the RELA data is preserved
and accessible to the module init code.
This is done in the following way:
- each RELA section that we care about (the ones for .text and .rodata
at the moment) is copied into a new section called .init.rela.<name>
with the SHF_ALLOC attribute, so that the module loader will copy it
into __init memory at load time;
- for each such section, an offset/count tuple is added as a global
variable to the module;
- the count field of those tuples is populated directly by the host tool
based on the actual size of the RELA section in question;
- the offset field is decorated with a place-relative relocation against
the start of the copied RELA section via a weak symbol reference,
which causes an entry to be emitted into the ELF symbol table;
- these ELF symbol table entries are updated by the host tool and turned
into STT_SECTION type symbols with STB_GLOBAL linkage, carrying the
correct section index.
With these changes in place, the unmodified module loader will load all
required information into memory in a way that permits the module init
code to locate the relocations, and apply them in reverse.
Bug: 153614920
Bug: 188620248
Change-Id: I07d9704febdf913834502dd09c19aa4a04d983b1
Signed-off-by: Ard Biesheuvel <ardb@google.com>
(cherry picked from commit 502af6e349)
We currently only emit directives for handling the .text section into
the module linker script if both LTO and CFI are enabled, while for
other sections, we do this even if CFI is not enabled. This is
inconsistent at best, but as it also interferes with the assumption in
the fips140.ko module that the .text._start and .text._end input
sections are placed at the very start and end of the .text section,
which currently can only be relied upon if CFI is enabled.
So rearrange the #ifdef so that it only covers the .text.__cfi_check
input section. Note that aligning to page size is likely to be redundant
in any case, given that the .text section is laid out first, and module
allocations are page aligned to begin with, so making that part
unconditional is unlikely to make an observeable difference in the
output.
Bug: 153614920
Bug: 188620248
Fixes: 6be141eb36 ("ANDROID: crypto: fips140 - perform load time integrity check")
Change-Id: I3f9ed0ae8fa8fe5693c8d2964566cbb42c101aa7
Signed-off-by: Ard Biesheuvel <ardb@google.com>
(cherry picked from commit 6ae8277450)
These flags are supposed to be used when building all source files for
the module.
Bug: 188620248
Fixes: b7397e89db ("ANDROID: fips140: add power-up cryptographic self-tests")
Change-Id: I41cacff040c8a8a0065dd3cfc537303f1ff18335
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 422bc2feb7)
Unfortunately, the AES-GCM implementations won't actually be able to be
FIPS-approved. One consequence of this is that the "cmac" template will
need to be tested with all underlying "aes" implementations, as the
equivalent test with "gcm" won't count as fulfilling the requirement to
test all AES implementations in an authenticated mode when supported.
Update the self-tests and comments accordingly.
Bug: 153614920
Bug: 188620248
Change-Id: I874b0718a5ff9d4e2dea2353448266e87f3f0d0b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit a9765fb6dc)
Although jitterentropy doesn't necessarily need to be part of
fips140.ko, it does need to have the SP800-90B health tests enabled, and
that requires that it be compiled with the fips_enabled flag set. The
easiest way to do this is just to include a copy of it in fips140.ko.
Bug: 153614920
Bug: 188620248
Change-Id: I9dc0281e07e08e0650e3d340897c697722ad3b1a
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit cae2421105)
AES-CMAC is a FIPS allowed algorithm, and fips140.ko already has
arm64 implementations of it. Meanwhile, GKI includes both these arm64
implementations as well as the "cmac" template. Add the "cmac" template
to fips140.ko too and add a self-test for AES-CMAC, so that we can
include AES-CMAC in the set of algorithms which will be certified.
As with a number of the other algorithms, the criteria for which
algorithms need to be in the certified set are still not particularly
clear, but the latest guidance we've received is to error on the side of
including algorithms.
Bug: 153614920
Bug: 188620248
Change-Id: I6c1d9281fe848a7101d5ef94ab48e5a41bbcc6f8
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 038dc9f2cc)
AES-CBC-CTS is a FIPS allowed algorithm, and fips140.ko already has
arm64 implementations of it. Meanwhile, GKI includes both these arm64
implementations as well as the "cts" template. Add the "cts" template
to fips140.ko too and add a self-test for AES-CBC-CTS, so that we can
include AES-CBC-CTS in the set of algorithms which will be certified.
There appears to be no support for CBC-CTS mode in pycryptodome or
python-cryptography, so I manually added the test vector.
As with a number of the other algorithms, the criteria for which
algorithms need to be in the certified set are still not particularly
clear, but the latest guidance we've received is to error on the side of
including algorithms. Android uses AES-CBC-CTS for filenames
encryption, which may be relevant (though arguably this use case doesn't
actually require a FIPS approved algorithm).
Bug: 153614920
Bug: 188620248
Change-Id: I53ffbd1d38493592eeaf471bc0007978ec400878
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit e2cfdfbc51)
The lab has confirmed that this test is not required.
Bug: 153614920
Bug: 188620248
Change-Id: Ie55031beacd00f093db3a7ba30fe0844a2ce363b
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit ea902862ea)
By using the initial_value parameter when creating the pycryptodome
AES-CTR instance, we can use any 16-byte IV, like the other AES modes.
Therefore, there's no need for the last 4 bytes of the IV to be 0.
This doesn't really matter, but it seems nice to avoid this quirk.
Bug: 153614920
Bug: 188620248
Change-Id: If33de260b1119f2b3e004164199b08364781ab23
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit fa5a44b364)
Test all implementations of each algorithm rather than just the highest
priority implementation. This aligns with the revised guidance we have
received from the lab.
We can still skip some tests in some cases, as per the FIPS 140-2
Implementation Guidance document. See the comments for details.
To align with the new scope of the tests, the fips140.broken_alg module
parameter now must specify an implementation (e.g. "sha256-ce") rather
than an algorithm (e.g. "sha256").
No change to the DRBG tests is required, as it turns out the module only
includes HMAC_DRBG. However, clarify the comment about the DRBG tests.
On a Pixel device, this increases the running time of the fips140 tests
from 0.5ms to 3.1 ms (very roughly; there's a lot of variation). This
is still very fast, so it isn't expected to be a problem.
Bug: 153614920
Bug: 173104584
Bug: 188620248
Change-Id: I555b535dd45f0164b7744a2c9338c501bb88de86
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit abe0780696)
dpcm_end_walk_at_be() stops the graph walk when first BE is found for
the given FE component. In a component model we may want to connect
multiple DAIs from different components.
android_vh_snd_soc_card_get_comp_chain can be registered here
to allows DAI/component chaining.
Later PCM operations can be called for all these listed components for a
valid DAPM path.
ALSA machine driver can setup component_chaining like below code slice.
static void my_board_component_chaining_hook(void *data, bool *ret)
{
*ret = true;
}
static int my_board_dev_probe(struct platform_device *pdev)
{
register_trace_android_vh_snd_soc_card_get_comp_chain(
my_board_component_chaining_hook, NULL);
return 0;
}
static int my_board_dev_remove(struct platform_device *pdev)
{
unregister_trace_android_vh_snd_soc_card_get_comp_chain(
my_board_component_chaining_hook, NULL);
return 0;
}
static struct platform_driver my_board_driver = {
...
.probe = my_board_dev_probe,
.remove = my_board_dev_remove,
...
};
Bug: 198732156
Signed-off-by: Bicycle Tsai <bicycle.tsai@mediatek.com>
Change-Id: Ife5df291d40af9ec83d57462b6a08aba95d9119d
The ABI diff is essentially bogus, but included here for completeness.
Leaf changes summary: 1 artifact changed
Changed leaf types summary: 1 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 0 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
'struct xhci_hcd at xhci.h:1756:1' changed:
type size hasn't changed
1 data member deletion:
'union {xhci_vendor_ops* vendor_ops; struct {u64 android_kabi_reserved1;} __UNIQUE_ID_android_kabi_hide322; union {};}', at offset 59392 (in bits) at xhci.h:1935:1
18 impacted interfaces
Bug: 210255585
Change-Id: Ic646e0edd2ab19fcd9b7b88b6e6a604299fc4824
Signed-off-by: Giuliano Procida <gprocida@google.com>
The __UNIQUE_ID() macro causes problems as it turns out to not be
deterministic across different compiler runs as it relies on the
__COUNTER__ macro which could have been used on other .h files previous
to this .h file being included.
This shows up specifically when building with "LTO=thin" vs. "LTO=full"
as different build paths seem to be triggered.
As the structure name isn't really needed at all here, we were just
including it for older compilers that could not handle anonymous
structures in a union, just drop the whole thing which resolves the abi
naming issue.
Bug: 210255585
Reported-by: Giuliano Procida <gprocida@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6b9449fa9d26ffc5d66b2f0f3b41e2d5f3003f68
Commit f1a0a376ca ("sched/core: Initialize the idle task with
preemption disabled") removed the init_idle() call from
idle_thread_get(). This was the sole call-path on hotplug that resets
the Shadow Call Stack (scs) Stack Pointer (sp).
Not resetting the scs-sp leads to scs overflow after enough hotplug
cycles. Therefore add an explicit scs_task_reset() to the hotplug code
to make sure the scs-sp does get reset on hotplug.
Fixes: f1a0a376ca ("sched/core: Initialize the idle task with preemption disabled")
Signed-off-by: Woody Lin <woodylin@google.com>
[peterz: Changelog]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Link: https://lore.kernel.org/r/20211012083521.973587-1-woodylin@google.com
(cherry picked from commit 63acd42c0d)
Bug: 201047587
Bug: 201771367
Change-Id: I9e48270f8d4c698c140cc3f427cadae636acb6d7
Add define of cpuset_update_active_cpus_affine() for fix compile error
when not define CONFIG_CPUSETS.
Bug: 204347727
Fixes: 09bd9e940e ("ANDROID: cpuhp/pause: schedule cpu_hotplug_work on
resume cpu")
Change-Id: Icf79df5e22233d15e4e8257a5f54176efbcd975b
Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com>
Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
Enable the UVC function driver to allow USB gadgets
to connect as a standard video device to a host.
Bug: 200712777
Signed-off-by: Dan Vacura <w36195@motorola.com>
Change-Id: Ia037f8560664f9e98f28f3fede609764d5d5699d
