The size of the settings copied from userspace, is directly checked
in msm_cci_data_queue with CCI_I2C_MAX_WRITE. This might cause
out of bound access in function msm_cci_data_queue as the max size is
MAX_I2C_REG_SET. Hence adding check on the size in flash driver itself.
Change-Id: Ifac358be9f4b4ff60d14c20e02886c2d044e7f52
Signed-off-by: Samyukta Mogily <smogily@codeaurora.org>
put_buf and buf_done are not unlocking rwlock in error case.
Change-Id: Ie10afa15f332cf7bd38be69ea8b99b163b125e66
Signed-off-by: Trishansh Bhardwaj <tbhardwa@codeaurora.org>
It's not necessary to reprogram PWM period setting if only
changing PWM duty cycle.
Change-Id: I366e17a5e2f18c09ab0850d00ec08a35e0f1cb9f
Signed-off-by: Fenglin Wu <fenglinw@codeaurora.org>
This is a debug enhance feature. It shows rejuvenation
info in ICNSS stats report, which makes it easier to
track the reason for every rejuvenation.
CRs-Fixed: 2072253
Change-Id: I6d133b4b182943ed745d7587bd1ec23858c29750
Signed-off-by: Yuanyuan Liu <yuanliu@codeaurora.org>
A race condition between queueing and processing the disable_work
instances results in having a work instance in the queue and the
deferred_disables variable of regulator device structure having a
value '0'. If no new regulator_disable_deferred() call later from
clients, the deferred_disables variable value remains '0' and hits
BUG() in regulator_disable_work() when the queued instance scheduled
for processing the work.
The race occurs as below:
Core-0 Core-1
..... /* deferred_disables = 2 */ .....
..... /* disable_work is queued */ .....
..... .....
regulator_disable_deferred: regulator_disable_work:
mutex_lock(&rdev->mutex); .....
rdev->deferred_disables++; mutex_lock(&rdev->mutex);
mutex_unlock(&rdev->mutex); .....
queue_delayed_work(...) count =rdev->deferred_disables;
..... rdev->deferred_disables = 0;
..... .....
..... mutex_unlock(&rdev->mutex);
..... .....
..... return;
..... .....
/* No new regulator_disable_deferred() calls from clients */
/* The newly queued instance is scheduled for processing */
..... .....
regulator_disable_work:
.....
mutex_lock(&rdev->mutex);
BUG_ON(!rdev->deferred_disables); /* deferred_disables = 0 */
The race is fixed by removing the work instance that is queued while
processing the previous queued instance. Cancel the newly queued instance
from disable_work() handler just after reset the deferred_disables variable
to value '0'. Also move the work queueing step before mutex_unlock in
regulator_disable_deferred().
Also use mod_delayed_work() in the pace of queue_delayed_work() as
queue_delayed_work() always uses the delay requested in the first call
when multiple consumers call regulator_disable_deferred() close in time
and does not guarantee the semantics of regulator_disable_deferred().
CRs-Fixed: 2064610
Change-Id: Iacaddc5e2f5c9998c4d038bdc10c4587cbf4812e
Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
Zero out cnss_utils priv structure during initalization to make
sure it starts cleanly.
CRs-Fixed: 2072421
Change-Id: I72caa5fb7e1df16b018165d277cd3a404b81c304
Signed-off-by: Yuanyuan Liu <yuanliu@codeaurora.org>
The spcom allows only one owner per channel, so only one app can open()
a channel char device at a time.
However, the channel owner process might share the channel file
descriptor (fd) with other threads, that might write() concurrently
a command to spcom, that can cause a race.
Add a mutex to "serialize" handling of the commands.
Change-Id: Ief9c6c48a862444dfff66d14d2317568cd6e81e6
Signed-off-by: Amir Samuelov <amirs@codeaurora.org>
Access to dma shared buffer is set at device probe, avoid making
multiple hypervisor assign calls for the same buffer.
Change-Id: I91f7dd0bca109fa774af49159bdec57b8acd65b2
Signed-off-by: Sathish Ambley <sathishambley@codeaurora.org>
Acked-by: Viswanatham Paduchuri <vpaduchu@qti.qualcomm.com>
Set FDE encryption key size to 256bit for sdm660_64
target.
Change-Id: Ib90068dc1a4a7c1caa1a65753c1b91827b1eb798
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
This reverts commit 2bb686dccd ("defconfig: arm64: msm: Enable
virtual platform"). The configs added in this change are not in
proper state and have build failures.
Change-Id: I30922e76761a1c436b54fb07f376ad9a5f5718f8
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
There is a dead loop in kgsl_devfreq_target(), while governor request
to change GPU frequency. In governor 'userspace' mode, If the requested
frequency (set_freq) is more than the configured frequency and max_freq
is also set to more than the configured frequency, then there is a dead
loop while changing target frequency.
Dead loop occurs due to comparing signed integer with unsigned integer.
So, type casting unsigned integer to signed integer will terminate the
loop when loop variable is less than zero.
Change-Id: Ic82b7477d50d1abcd348b011f64246066887922c
Signed-off-by: Venkateswara Rao Tadikonda <vtadik@codeaurora.org>
Currently, there is a possibility of out-of-bound access while
processing data received from user space. The patch adds proper
checks for valid address.
CRs-Fixed: 2048536
Change-Id: I1e0fc7a9d69e69f3326429d5d9540dd3bb1a59b0
Signed-off-by: Hardik Arya <harya@codeaurora.org>
