The carved out or allocated memory may not be configured to be
accessible by both the owner and consumer vms. Add support to share
memory through hyp_assign_phy() and assign a label to the resultant
memparcel through hh_rm_mem_qcom_lookup_sgl().
This sharing sequence should only be done by the owner of the reserved
memory region. Currently we indicate this with the qcom,master tag in
device tree.
Change-Id: Iff9539f00dc3591b79352d87c1fd6fc91cbc0c6a
Signed-off-by: Chris Lew <clew@codeaurora.org>
Add support for the primary vm to read the vm peer name from device
tree. This information is needed to share memory to the peer vm.
Change-Id: Ied71d254975e08dcf6c1c51f49687aceced141a9
Signed-off-by: Chris Lew <clew@codeaurora.org>
Store the haven label so it can be used for other haven resources such
as attaching the label to memparcels that the qrtr haven driver
creates.
Change-Id: I78c8bea71666c35db393191131389867d39f7566
Signed-off-by: Chris Lew <clew@codeaurora.org>
Dump PA_VS_STATUS_REG1 when full reset is needed in eh, which is helpful
for error debugging.
Change-Id: Iad3c2fc09c88598428762b5da09e13b46493fc7d
Signed-off-by: Can Guo <cang@codeaurora.org>
Right now only anonymous pages are speculatively faulted, thus
leaving out a large percentage of faults still requiring to
take mmap_sem. These were left out since there can be fault
handlers mainly in the fs layer which may use vma in unknown
ways. This patch covers filemap_fault and shmem_fault and
enables speculative fault for all those vmas with vm_ops.
None of the other common fault handlers is seen to use or
modify vma.
Change-Id: I4f87909002f7ac64945f048ba0169a4cac7a15ab
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Enable support to limit the allocations which can be made from the
Movable zone in order to help reduce the likelihood of a page in the
movable zone being pinned because that would prevent memory from
being offlined.
Change-Id: I6503c9c23ad4b54838992a72f0cf79f3f545d703
Signed-off-by: Liam Mark <lmark@codeaurora.org>
There are a lot of readahead Movable allocations.
These allocations don't appear to get 'pinned' so allow them to be
satisfied from the CMA region in order to better utilize CMA memory.
Change-Id: I87387a748e67a6963b9a526b729e6e273c1cc519
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Ensure we continue to direct __GFP_CMA allocations to offlinable memory now
that __GFP_OFFLINABLE has been introduced.
Change-Id: Ibdd71e45f4e47110f3ec4d308d26ffae58beb300
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Ensure that only allocations which include __GFP_OFFLINABLE can be
satisfied from zone Movable. This restriction helps reduces the
likelihood of a page in the movable zone being pinned which would prevent
memory from being offlined.
In the past we allowed all __GFP_CMA allocations to be satisfied from
Movable zone but now add support to differentiate between __GFP_CMA
allocations and __GFP_OFFLINABLE allocations so that we can target certain
allocations at CMA regions and certain allocations at the Movable zone.
Change-Id: If2a9381b6d677f825ad53af9cd64f206d41da211
Signed-off-by: Liam Mark <lmark@codeaurora.org>
Device is still possible to enter low power state with current
unsync force wake method, and it may cause later failure when
accessing SoC register.
Introduce sync force wake API and expose it to WLAN host driver,
which will ensure device won't enter low power state after
device_wake is asserted.
Change-Id: Iaa7a7bdac910c162600bbf03ac97af83b2f68f3f
Signed-off-by: Lin Bai <lbai@codeaurora.org>
Add support to a new scm call to read LMH data.
Change-Id: Ifb8161292363bd18fb63a389692e67c547ac8bb6
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Add support for wireless charger firmware update in battery charger
driver through "wireless_fw_update" and "wireless_fw_force_update"
properties under "/sys/class/qcom-battery". Support firmware update
for wireless charger (IDT9412) for which firmware is split into
multiple chunks (128 bytes each) and sent over PMIC Glink. Charger
firmware running on the remote subsystem does the FW update by
communicating with IDT9412.
Wireless charger firmware name should be specified via a device tree
property "qcom,wireless-fw-name".
To update wireless firmware, user has to push the FW binary to a
firmware partition (e.g. /vendor/firmware) and then do one of the
following.
Normal update for which FW version check is made:
# echo 1 > /sys/class/qcom-battery/wireless_fw_update
Forced update for which FW version check is skipped:
# echo 1 > /sys/class/qcom-battery/wireless_fw_force_update
To read back FW version:
# cat /sys/class/qcom-battery/wireless_fw_version
Change-Id: Id565e7d5a73041d6e0340edc66eb8b1615396435
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Enable SDPM clock monitor driver for lahaina to monitor clocks and write
the clock rate in SDPm CSR register.
Change-Id: Ia643c5b412362518c9c6c08d47e5af17ff859f69
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Enable Policy Engine sensor driver for lahaina to get the CX/MX
mitigation recommendation as sensor.
Change-Id: I481552649909c32d229186a62e8b9240ca2ec88b
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Add SDPM clock notifier driver, which will register for clock rate
change notification and write the clock rate into SDPM CSR register. The
SDPM hardware will monitor the frequency changes and recommend
mitigation using policy engine.
Change-Id: I56b2941b3c3e47bdb49bf805a2fc9acd4356470f
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Add Policy Engine(PE) sensor recommendation as a sensor with thermal
framework. PE will recommend a mitigation level based on the operating
level of CX/MX clients. Registering this recommendations as sensor enables
the user to provide thermal zone configuration to mitigate cooling devices
for different policy engine recommendations.
Change-Id: I65e1a8baad62957482daca493987d6cd51eee3ef
Signed-off-by: Ram Chandrasekar <rkumbako@codeaurora.org>
Remove the unnecessary 'extern' keywords from function declarations.
This makes it so that we don't have a mix of both styles, so it won't be
ambiguous what to use in new fs-verity patches. This also makes the
code shorter and matches the 'checkpatch --strict' expectation.
Link: https://lore.kernel.org/r/20200511192118.71427-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Fix all kerneldoc warnings in fs/verity/ and include/linux/fsverity.h.
Most of these were due to missing documentation for function parameters.
Detected with:
scripts/kernel-doc -v -none fs/verity/*.{c,h} include/linux/fsverity.h
This cleanup makes it possible to check new patches for kerneldoc
warnings without having to filter out all the existing ones.
Link: https://lore.kernel.org/r/20200511192118.71427-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
The eMMC inline crypto standard will only specify 32 DUN bits (a.k.a. IV
bits), unlike UFS's 64. IV_INO_LBLK_64 is therefore not applicable, but
an encryption format which uses one key per policy and permits the
moving of encrypted file contents (as f2fs's garbage collector requires)
is still desirable.
To support such hardware, add a new encryption format IV_INO_LBLK_32
that makes the best use of the 32 bits: the IV is set to
'SipHash-2-4(inode_number) + file_logical_block_number mod 2^32', where
the SipHash key is derived from the fscrypt master key. We hash only
the inode number and not also the block number, because we need to
maintain contiguity of DUNs to merge bios.
Unlike with IV_INO_LBLK_64, with this format IV reuse is possible; this
is unavoidable given the size of the DUN. This means this format should
only be used where the requirements of the first paragraph apply.
However, the hash spreads out the IVs in the whole usable range, and the
use of a keyed hash makes it difficult for an attacker to determine
which files use which IVs.
Besides the above differences, this flag works like IV_INO_LBLK_64 in
that on ext4 it is only allowed if the stable_inodes feature has been
enabled to prevent inode numbers and the filesystem UUID from changing.
Link: https://lore.kernel.org/r/20200515204141.251098-1-ebiggers@kernel.org
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Paul Crowley <paulcrowley@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Since v1 encryption policies are deprecated, make test_dummy_encryption
test v2 policies by default.
Note that this causes ext4/023 and ext4/028 to start failing due to
known bugs in those tests (see previous commit).
Link: https://lore.kernel.org/r/20200512233251.118314-5-ebiggers@kernel.org
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
v1 encryption policies are deprecated in favor of v2, and some new
features (e.g. encryption+casefolding) are only being added for v2.
Therefore, the "test_dummy_encryption" mount option (which is used for
encryption I/O testing with xfstests) needs to support v2 policies.
To do this, extend its syntax to be "test_dummy_encryption=v1" or
"test_dummy_encryption=v2". The existing "test_dummy_encryption" (no
argument) also continues to be accepted, to specify the default setting
-- currently v1, but the next patch changes it to v2.
To cleanly support both v1 and v2 while also making it easy to support
specifying other encryption settings in the future (say, accepting
"$contents_mode:$filenames_mode:v2"), make ext4 and f2fs maintain a
pointer to the dummy fscrypt_context rather than using mount flags.
To avoid concurrency issues, don't allow test_dummy_encryption to be set
or changed during a remount. (The former restriction is new, but
xfstests doesn't run into it, so no one should notice.)
Tested with 'gce-xfstests -c {ext4,f2fs}/encrypt -g auto'. On ext4,
there are two regressions, both of which are test bugs: ext4/023 and
ext4/028 fail because they set an xattr and expect it to be stored
inline, but the increase in size of the fscrypt_context from
24 to 40 bytes causes this xattr to be spilled into an external block.
Link: https://lore.kernel.org/r/20200512233251.118314-4-ebiggers@kernel.org
Acked-by: Jaegeuk Kim <jaegeuk@kernel.org>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Enable UAPI_HEADER_TEST in the Lahaina GKI defconfig for UAPI sanity
checks.
Change-Id: Ic0dedbad7cd0782018c8e6f32d4337c6e211a809
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
By printing enqueue/dequeue pointers, we can make sure that our TRB
handling is correct. We've had a recent situation where we were not
always dequeueing all TRBs in an SG list and this helped figure out
what the problem was.
Change-Id: Ied1c5d57b4f324c40dd219153b49a1e244b6773c
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Git-commit: 30ad6273adad76017ddad737d45f8931cac554ad
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
If dwc3 fails to issue START_TRANSFER/UPDATE_TRANSFER command, then we
should properly end an active transfer and give back all the started
requests. However if it's for an isoc endpoint, the failure maybe due to
bus-expiry status. In this case, don't give back the requests and wait
for the next retry.
Change-Id: I64ff69a663a9ad7701f877a0cf3bcd87b93c792a
Fixes: 72246da40f ("usb: Introduce DesignWare USB3 DRD Driver")
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Git-commit: 8d99087c2db863c5fa3a4a1f3cb82b3a493705ca
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
A request may not be completed because not all the TRBs are prepared for
it. This happens when we run out of available TRBs. When some TRBs are
completed, the driver needs to prepare the rest of the TRBs for the
request. The check dwc3_gadget_ep_request_completed() shouldn't be
checking the amount of data received but rather the number of pending
TRBs. Revise this request completion check.
Change-Id: If806e69c32a84caa0c839286a33ee0b092cd372a
Cc: stable@vger.kernel.org
Fixes: e0c42ce590 ("usb: dwc3: gadget: simplify IOC handling")
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Git-commit: 49e0590e3a60e75b493e5df879e216e5073c7663
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
The flow from function dwc3_gadget_ep_dequeue() is not easy to follow.
Refactor it for easier read. No functional change in this commit.
Change-Id: I254081abaf3ff7c6a7a598bf859804ecf3454a15
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Git-commit: fcd2def6639293c2bde2dc4f5dab63641a60b5b3
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[mrana@codeaurora.org: resolve merge conflict related to debug log]
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Currently, the test_dummy_encryption mount option (which is used for
encryption I/O testing with xfstests) uses v1 encryption policies, and
it relies on userspace inserting a test key into the session keyring.
We need test_dummy_encryption to support v2 encryption policies too.
Requiring userspace to add the test key doesn't work well with v2
policies, since v2 policies only support the filesystem keyring (not the
session keyring), and keys in the filesystem keyring are lost when the
filesystem is unmounted. Hooking all test code that unmounts and
re-mounts the filesystem would be difficult.
Instead, let's make the filesystem automatically add the test key to its
keyring when test_dummy_encryption is enabled.
That puts the responsibility for choosing the test key on the kernel.
We could just hard-code a key. But out of paranoia, let's first try
using a per-boot random key, to prevent this code from being misused.
A per-boot key will work as long as no one expects dummy-encrypted files
to remain accessible after a reboot. (gce-xfstests doesn't.)
Therefore, this patch adds a function fscrypt_add_test_dummy_key() which
implements the above. The next patch will use it.
Link: https://lore.kernel.org/r/20200512233251.118314-3-ebiggers@kernel.org
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
<linux/parser.h> is missing include guards. Add them.
This is needed to allow declaring a function in <linux/fscrypt.h> that
takes a substring_t parameter.
Link: https://lore.kernel.org/r/20200512233251.118314-2-ebiggers@kernel.org
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Remove the unnecessary 'extern' keywords from function declarations.
This makes it so that we don't have a mix of both styles, so it won't be
ambiguous what to use in new fscrypt patches. This also makes the code
shorter and matches the 'checkpatch --strict' expectation.
Link: https://lore.kernel.org/r/20200511191358.53096-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Name all the function parameters. This makes it so that we don't have a
mix of both styles, so it won't be ambiguous what to use in new fscrypt
patches. This also matches the checkpatch expectation.
Link: https://lore.kernel.org/r/20200511191358.53096-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Fix all kerneldoc warnings in fs/crypto/ and include/linux/fscrypt.h.
Most of these were due to missing documentation for function parameters.
Detected with:
scripts/kernel-doc -v -none fs/crypto/*.{c,h} include/linux/fscrypt.h
This cleanup makes it possible to check new patches for kerneldoc
warnings without having to filter out all the existing ones.
For consistency, also adjust some function "brief descriptions" to
include the parentheses and to wrap at 80 characters. (The latter
matches the checkpatch expectation.)
Link: https://lore.kernel.org/r/20200511191358.53096-2-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Lucid PLL 5LPE reduced Nominal FMax from 2000 to 1750MHz and SVS_L1 FMax
from 1600 to 1500Mhz.
Change-Id: I1d6a162aa6a268efb146ea19499e29caa6cbcfaa
Signed-off-by: Vivek Aknurwar <viveka@codeaurora.org>
When unmapping memory in S1, treat zero-sized sg-lists as invalid
inputs.
Change-Id: I477cd0808eea1200873c50470c8b73d9162428e4
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
Add support for KPROBE for debugging various issues on
lahaina/shima/holi.
Change-Id: Iede9d2d29f5053b1024097db4640bbec996a441d
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
This change removes not informative prints.
Change-Id: Ic4c4e6fef752c72082b260b2e34873bd994bc62d
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Avoid passing tail pages to isolate_lru_page. In the case
process reclaim, since only lru pages are considered, this
is just to avoid a warning from isolate_lru_page.
Change-Id: I1f54dcec15f8c2d5ba16738657e79d2793d36c77
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Correct condition for SW USB mode when setup sysfs buf to fix the issue
that the allocated buffer size is always 32M for memory mode with sw_usb
is enabled.
Change-Id: Id545ecfa21378f49ddeac4c3c3f4fe51f744e69b
Signed-off-by: Mao Jinlong <jinlmao@codeaurora.org>
Remove 2 unnecessary checks:
1) A request in the started_list must have its trb field set. So
checking for req->trb is unnecessary.
2) An endpoint must have started (and have not ended) for the request to
still be in the started_list. There's no point to check if the endpoint
is started. We had this check because previously the driver didn't
handle the endpoint's started/ended flags for END_TRANSFER command
properly. See commit 9f45581f5e ("usb: dwc3: gadget: early giveback
if End Transfer already completed").
Change-Id: I5d55f02d25abe06d5601730f1d1d88ee24809d2c
Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Git-commit: 8411993e79df8e54da67613025d620a8a23a24fe
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
The secondary vm device tree will have a different format than the
primary vm. Try parsing the node as a secondary vm node if the
shared-buffer region does not exist.
Change-Id: Id794a1b21507329f4e16f1335a17a2262ecabd5a
Signed-off-by: Chris Lew <clew@codeaurora.org>
The carved out or allocated memory may not be configured to be
accessible by both the owner and consumer vms. Add support to share
memory through hyp_assign_phy() and assign a label to the resultant
memparcel through hh_rm_mem_qcom_lookup_sgl().
This sharing sequence should only be done by the owner of the reserved
memory region. Currently we indicate this with the qcom,primary tag in
device tree.
Change-Id: Idf5658ab4cf0d1c022f6b919914a8e782318c8d7
Signed-off-by: Chris Lew <clew@codeaurora.org>
Store the haven label so it can be used for other haven resources such
as attaching it to memparcels that are shared.
Change-Id: I90717bc7d158fb73ecb4442ede3c5d476f3d2045
Signed-off-by: Chris Lew <clew@codeaurora.org>
Add support for the primary vm to read the vm peer name from device
tree. This information is needed to share memory to the peer vm.
Change-Id: I9a38370c8b80480bcdd0988c515adf64b36f99c1
Signed-off-by: Chris Lew <clew@codeaurora.org>
The ready state gives clients in the primary vm a chance to share
resources before the vm is started and set to running state. This
window is currently missing because guestvm_loader starts the vm
directly after subsystem_get().
Make the guestvm boot code wait for the HH_RM_VM_STATUS_READY callback
before starting the vm. This allows drivers that need to share
resources a chance to do so instead of racing with guestvm_loader.
Drivers can register with the rm notifier chain at a higher priority
than 0 to be called first.
This change can eventually be replaced by a separate driver or notifier
chain managed by guestvm_loader to provide better synchronization
methods compared to notifier chain priority.
Change-Id: I0fb3c5c41957381b31fa652deec0d6d51a41e6ef
Signed-off-by: Chris Lew <clew@codeaurora.org>
The current code sets per-cpu variable sd_asym_cpucapacity while
building sched domains even when there are no asymmetric CPUs.
This is done to make sure that EAS remains enabled on a b.L system
after hotplugging out all big/LITTLE CPUs. However it is causing
the below warning during CPU hotplug.
[13988.932604] pc : static_key_slow_dec_cpuslocked+0xe8/0x150
[13988.932608] lr : static_key_slow_dec_cpuslocked+0xe8/0x150
[13988.932610] sp : ffffffc010333c00
[13988.932612] x29: ffffffc010333c00 x28: ffffff8138d88088
[13988.932615] x27: 0000000000000000 x26: 0000000000000081
[13988.932618] x25: ffffff80917efc80 x24: ffffffc010333c60
[13988.932621] x23: ffffffd32bf09c58 x22: 0000000000000000
[13988.932623] x21: 0000000000000000 x20: ffffff80917efc80
[13988.932626] x19: ffffffd32bf0a3e0 x18: ffffff8138039c38
[13988.932628] x17: ffffffd32bf2b000 x16: 0000000000000050
[13988.932631] x15: 0000000000000050 x14: 0000000000040000
[13988.932633] x13: 0000000000000178 x12: 0000000000000001
[13988.932636] x11: 16a9ca5426841300 x10: 16a9ca5426841300
[13988.932639] x9 : 16a9ca5426841300 x8 : 16a9ca5426841300
[13988.932641] x7 : 0000000000000000 x6 : ffffff813f4edadb
[13988.932643] x5 : 0000000000000000 x4 : 0000000000000004
[13988.932646] x3 : ffffffc010333880 x2 : ffffffd32a683a2c
[13988.932648] x1 : ffffffd329355498 x0 : 000000000000001b
[13988.932651] Call trace:
[13988.932656] static_key_slow_dec_cpuslocked+0xe8/0x150
[13988.932660] partition_sched_domains_locked+0x1f8/0x80c
[13988.932666] sched_cpu_deactivate+0x9c/0x13c
[13988.932670] cpuhp_invoke_callback+0x6ac/0xa8c
[13988.932675] cpuhp_thread_fun+0x158/0x1ac
[13988.932678] smpboot_thread_fn+0x244/0x3e4
[13988.932681] kthread+0x168/0x178
[13988.932685] ret_from_fork+0x10/0x18
The mismatch between increment/decrement of sched_asym_cpucapacity
static key is resulting in the above warning. It is due to
the fact that the increment happens only when the system really
has asymmetric capacity CPUs. This check is done by going through
each CPU capacity. So when system becomes SMP during hotplug,
the increment never happens. However the decrement of this static
key is done when any of the currently online CPU has per-cpu variable
sd_asym_cpucapacity value as non-NULL. Since we always set this
variable, we run into this issue.
Our goal was to enable EAS on SMP. To achieve that enable EAS and
build perf domains (required for compute energy) irrespective
of per-cpu variable sd_asym_cpucapacity value. In this way we
no longer have to enable sched_asym_cpucapacity feature on SMP
to enable EAS.
Change-Id: Id46f2b80350b742c75195ad6939b814d4695eb07
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
We have made the new idle CPU selection for load balance energy
aware. For example, if a silver CPU does not have any misfit
tasks but is overloaded, we have to select a silver CPU not
gold CPU. However, this extra checks are needed only when the
system has asymmetric capacity CPUs. So we should depend on
sched_asym_cpucapacity feature instead of sched_energy_present.
Later patches enable sched_energy_present for SMP systems also.
Change-Id: Ie4fae9d1c17511f15b48b92dd61395d1689e1612
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Update the ABI snapshot to use the latest version of libabigail(67d4c4cf).
This is required for the checker docker image to be updated.
Change-Id: I1b875122a1d71478723158b8334ad03a97a9c32a
Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
fix potential issue that idx of prop_array could be out of range
Change-Id: Ia2d6a7332f66f518b2f8d96ed999e3963f1b9284
Signed-off-by: Yu SI <ysi@codeaurora.org>
When reprogram_all_keys is called from keyslot manager, it is
done as part of the ufs resume context. This will cause a hang
when keyslot program tries to do a resume again. Avoid doing a
resume if keyslot program is called from resume context.
Change-Id: I336fd580885d8e26ec9bf3fafe13e30404ba3ac5
Signed-off-by: Gaurav Kashyap <gaurkash@codeaurora.org>
