VIDIOC_ENUM_FRAMESIZES ioctl enumerate all frame sizes
that the device supports for the given pixel format. It
also provides the type of frame sizes the device supports.
The frame type supported is stepwise and it is continuous
i.e. the step size is 1. Keeping it as stepwise.
Change-Id: I9c801bd3dface3b1d1d824aea124e9c0666e09e1
Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
Request runtime PM resume in platform driver as soon as shutdown
happens. This can make sure device is resumed while shutdown is
proceeding.
Change-Id: I0aa15b9713347288f4954bd767ec9243d22153ed
CRs-fixed: 2124999
Signed-off-by: Yue Ma <yuem@codeaurora.org>
LLVM bug 30792 causes clang's AArch64 backend to crash compiling
arch/arm64/crypto/aes-ce-cipher.c. Replacing -mgeneral-regs-only with
-mno-implicit-float is the suggested workaround.
Drop this patch once the clang bug has been fixed.
Change-Id: I7c7bb9315a281970698120a6d2a9fcd126aad65e
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Task->on_rq has three states:
0 - Task is not on runqueue (rq)
1 (TASK_ON_RQ_QUEUED) - Task is on rq
2 (TASK_ON_RQ_MIGRATING) - Task is on rq but in the
process of being migrated to another rq
When a task is moving between rqs task->on_rq state should be
TASK_ON_RQ_MIGRATING in order for WALT to account rq's cumulative
runnable average correctly. Without such state marking for all the
classes, WALT's update_history() would try to fixup task's demand
which was never contributed to any of CPUs during migration.
Change-Id: Iced3428f3924fe8ab5d0075698273ead04f12d5b
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[joonwoop: Reinforced changelog to explain why this is needed by WALT.
Fixed conflicts in deadline.c]
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
Unserialized access to diag_dbgfs_dci_data_index can lead to
heap overflow. Add mutex protection while updating the
diag_dbgfs_dci_data_index.
Change-Id: Iee9d0447494e3576e6293afcd4d7611bc429aa8a
Signed-off-by: Sreelakshmi Gownipalli <sgownipa@codeaurora.org>
RX intent no timeout value when waiting for response. This can result
in calling function to wait indefinitely.
Set max waiting time to 500 ms.
CRs-Fixed: 2127311
Change-Id: I30475ca49f107e62bed41d3d26287562574d988c
Signed-off-by: Dhoat Harpal <hdhoat@codeaurora.org>
In function ufs_qcom_dbg_testbus_cfg_write(), the global
variable ufs_qcom_host (host) is not protected by lock.
In function ufs_qcom_testbug_config(), we are checking this
variable in switch case and there is possibility of race
condition while accessing host variable in both of these
functions. This change fixes the possible race scenario
using spin_lock on host_lock.
Change-Id: I4e3fa1c3b80b92a648965371e12e52352cf80ce5
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Create new function ext4_issue_zeroout() to zeroout contiguous (both
logically and physically) part of inode data. We will need to issue
zeroout when extent structure is not readily available and this function
will allow us to do it without making up fake extent structures.
Change-Id: I5deb04b49d3ebdd1ac12f8bb950faf46d08f5d80
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Git-commit: 53085fac02d12fcd29a9cb074ec480ff0f77ae5c
Git-repo: https://source.codeaurora.org/quic/la/kernel/msm-4.4
[srkupp@codeaurora.org: Resolved minor conflict]
Signed-off-by: Srinivasa Rao Kuppala <srkupp@codeaurora.org>
(from https://patchwork.kernel.org/patch/10005409/)
If there's some data written through inline data or dentry, we need to shouw
st_blocks. This fixes reporting zero blocks even though there is small written
data.
Bug: 67651285
Bug: 67600404
Change-Id: I9ad5cb137eb627b9fd22740d2ab98e0221433c95
Cc: stable@vger.kernel.org
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
qcedev_sha_req_cb() is only called by _sha_complete() during sha
operation, and will copy byte_count value from authdata array.
This array size is two, and only contains two byte_count value
that are used for sha operation. So make change to only copy the
first two elements from this array.
Change-Id: I535f2ec0e358870a9a2163b3c0bf154b2c8d003f
Signed-off-by: Zhen Kong <zkong@codeaurora.org>
Currently, there is a possibility of nested sleep
during handling of data ready notification to diag
clients. The patch fixes the issue by properly
handling data ready notifications.
Change-Id: Ib30455b41d1b05bff33cc0a627c1fc7e9a1b7568
Signed-off-by: Mohit Aggarwal <maggarwa@codeaurora.org>
In mmc_wr_pack_stats_read(), userspace buffer is directly accessed
which is violating PAN (Privilege Access Never).
So to prevent this, data which needs to be copied to user buffer is
gathered into a local buffer and at the end, this local buffer
contents are copied back to buffer supplied from user space using
copy_to_user().
Change-Id: Id772613fe54c47d64906c18d3d0249eee2f6ac26
Signed-off-by: Siba Prasad <sibap@codeaurora.org>
Set fixed rate in of_dummy_get since dummy_clk_dt_parser
is not called.
Change-Id: Id33be0a00a0a29100618f5fd25a917983f654025
Signed-off-by: Zhiqiang Tu <ztu@codeaurora.org>
Currently, charge_counter is based off CC_SOC_SW which is based
off coulomb counter. However, there could be some accumulation
of error due to inaccuracy in ADC over time. This can potentially
affect the accuracy of charge_counter. To overcome this, prime
CC_SOC_SW during discharging based off battery SOC and to a full
value during charge termination.
While at it, expose the charge_counter_shadow property based off
battery SOC for comparison.
CRs-Fixed: 2109421
Change-Id: I50de44afbdbd747db95946416a09062df205fd6c
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
When SOC is held @ 100% after charge termination, charge_full
flag is cleared only when the monotonic SOC drops below recharge
SOC threshold. This can cause the flag to be held for a long time
when the charger is removed. Fix this by clearing charge_full
flag when charging status had changed from FULL.
Change-Id: I35b52ddc45f314347f0e4d8433d5fb550663267c
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Add null terminator at the end of string
extend_ioctl_data.u.rmnet_mux_val.vchannel_name
to avoid potential security issue.
Change-Id: I57fe3a9f7e3ad6a499b62a9cfc49bc6b2f3b42e0
Acked-by: Shihuan Liu <shihuanl@qti.qualcomm.com>
Signed-off-by: Skylar Chang <chiaweic@codeaurora.org>
If wlan driver probe returns error of defer, platform driver will
try to recover by calling probe again. The maximun probe count
is 2.
CRs-Fixed: 2124152
Change-Id: Ic973d0f1d76fc59ce5950397d42a9e778cacaa5a
Signed-off-by: Yuanyuan Liu <yuanliu@codeaurora.org>
commit d41519a69b35b10af7fda867fb9100df24fdf403 upstream.
On sparc, if we have an alloca() like situation, as is the case with
SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack
memory. The result can be that the value is clobbered if a trap
or interrupt arrives at just the right instruction.
It only occurs if the function ends returning a value from that
alloca() area and that value can be placed into the return value
register using a single instruction.
For example, in lib/libcrc32c.c:crc32c() we end up with a return
sequence like:
return %i7+8
lduw [%o5+16], %o0 ! MEM[(u32 *)__shash_desc.1_10 + 16B],
%o5 holds the base of the on-stack area allocated for the shash
descriptor. But the return released the stack frame and the
register window.
So if an intererupt arrives between 'return' and 'lduw', then
the value read at %o5+16 can be corrupted.
Add a data compiler barrier to work around this problem. This is
exactly what the gcc fix will end up doing as well, and it absolutely
should not change the code generated for other cpus (unless gcc
on them has the same bug :-)
With crucial insight from Eric Sandeen.
Reported-by: Anatoly Pugachev <matorola@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As Ju Hyung Park reported:
"When 'fstrim' is called for manual trim, a BUG() can be triggered
randomly with this patch.
I'm seeing this issue on both x86 Desktop and arm64 Android phone.
On x86 Desktop, this was caused during Ubuntu boot-up. I have a
cronjob installed which calls 'fstrim -v /' during boot. On arm64
Android, this was caused during GC looping with 1ms gc_min_sleep_time
& gc_max_sleep_time."
Root cause of this issue is that f2fs_wait_discard_bios can only be
used by f2fs_put_super, because during put_super there must be no
other referrers, so it can ignore discard entry's reference count
when removing the entry, otherwise in other caller we will hit bug_on
in __remove_discard_cmd as there may be other issuer added reference
count in discard entry.
Thread A Thread B
- issue_discard_thread
- f2fs_ioc_fitrim
- f2fs_trim_fs
- f2fs_wait_discard_bios
- __issue_discard_cmd
- __submit_discard_cmd
- __wait_discard_cmd
- dc->ref++
- __wait_one_discard_bio
- __wait_discard_cmd
- __remove_discard_cmd
- f2fs_bug_on(sbi, dc->ref)
Change-Id: I8fb5c8215e6222ae853e7781218d5084e1f11166
Fixes: 969d1b180d987c2be02de890d0fff0f66a0e80de
Reported-by: Ju Hyung Park <qkrwngud825@gmail.com>
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 638164a2718f337ea224b747cf5977ef143166a4)
This patch removes fscrypto.h which was missed to remove when porting the
latest fs/crypto stuffs.
Change-Id: Ib17cba17d48535b0d754ae52537053098248a036
Fixes: 13f002354d ("f2fs: catch up to v4.14-rc1")
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
We should use FLAT_BINDER_FLAG_SCHED_POLICY_MASK as
the mask to calculate sched policy.
Change-Id: Ic252fd7c68495830690130d792802c02f99fc8fc
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Add verify flag in fs_mgr of vendor label to enable
verity on vendor partition for sdm630, sdm660 & msm8998.
Change-Id: I172b3f8da55059658bb0caff5c8b2cab905a21ad
Signed-off-by: Sachin Grover <sgrover@codeaurora.org>
