In few scenarios, where the register update ioctl is
missed, the handling of frame drop is not working
in such scenarios as the frame drop pattern is not
set correctly. Once the epoch handling is done,
we need to re-configure the buffer and pattern.
Change-Id: I87b2cecda7e7e1addc68511dad6a80498051f87a
Signed-off-by: Meera Gande <mgande@codeaurora.org>
In few scenarios, the request frame may get
delayed and current and request frame id may
become same. To handle such scenarios, made
changes to inform user to delay a frame and
process the request.
Change-Id: I31fa04c386922c48a043c511a163c76316e21987
Signed-off-by: Meera Gande <mgande@codeaurora.org>
Update the logging mask for both events and F3 masks to the latest
requests.
Change-Id: I9485f18eca2ee0f78b5086e0332359d997acf57a
Signed-off-by: Manoj Prabhu B <bmanoj@codeaurora.org>
For error conditions,this api returns negative value.
currently the return type is unsigned int, this should
be changed to integer type.
Signed-off-by: Rajasekaran Kalidoss <rkalidos@codeaurora.org>
Change-Id: Ifaeea4d76f5d2c2e8f0f67eab97df50dae09462c
qos_request object is used between two drivers (msm, camera)
there can be a scenario qos_request being updated before
initialize.
fix: make sure initialize is called before update.
Change-Id: I5e7e1639577f30b671598663d3dd2f8e7f5c3f36
Signed-off-by: Srikanth Uyyala <suyyala@codeaurora.org>
If video state set to DEINIT before processing all frame done
packets in the list may create video failures as explained below,
the client communication to video hardware will fail because of
DEINIT state and client will close the session upon failure which
will happen in parallel to response thread processing the response
packets in the list. It may happen that client already free'd the
buffer references and response thread might access the same buffer
reference and results in use-after-free memory fault. So In case
of sys error from video hardware, set video state to DEINIT after
processing all packets in the list to avoid use-after-free failure
Change-Id: I688c3ec3feb2b5621d75c4da93ee9870aa0e6dfe
Signed-off-by: Darshan Kumsi Srinivasa <darssr@codeaurora.org>
Original function pointer check is not correct, so use
the correct one.
Change-Id: I6e87eaef66339442b86e64ba0501eaca04b10d89
Signed-off-by: Guchun Chen <guchunc@codeaurora.org>
This sequence change is required to avoid dips in voltage
during boot-up.
Apparently, this dip is caused because in the original
sequence, the regulators are initialized in lpm mode.
And then when the load is set to high, and more current
is drawn, than is allowed in lpm, the dip is seen.
CRs-fixed: 2279027
Change-Id: Ie6cbc332cbee8227e16636219e375b18c796a12f
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
This sequence change is required to avoid dips in voltage
during boot-up.
Apparently, this dip is caused because in the original
sequence, the regulators are initialized in lpm mode.
And then when the load is set to high, and more current
is drawn, than is allowed in lpm, the dip is seen.
CRs-fixed: 2279027
Change-Id: Ic531a1e6788d6288071f93d5002613855c2667f5
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
To resolve the timing issue between usb-driver
and android framework, made the change on rndis
ipa to send the usb-connect msg when usb-driver
connect the IPA pipes.
Change-Id: I51de37bc7610cb0a94659c64146f10ed322210b2
Acked-by: Pooja Kumari <kumarip@qti.qualcomm.com>
Signed-off-by: Mohammed Javid <mjavid@codeaurora.org>
Signed-off-by: Skylar Chang <chiaweic@codeaurora.org>
The use-after-free issue can also occur with ION_IOC_IMPORT
just like in the commit 2c155709e4
("staging: android: ion: fix ION_IOC_{MAP,SHARE} use-after-free").
This is due to reacquiring client->lock in pass_to_user().
Change-Id: Ib5f3297504763c341b3ce343ef18538ce2c9c7d5
Signed-off-by: Srinivasarao P <spathi@codeaurora.org>
BMI160 will not power on if regulator does not enabled from
probe
Change-Id: I134687a7923416dd87c8753e980337f68f6862c4
Signed-off-by: puneet <puneet@codeaurora.org>
Attempting to avoid cloning the skb when broadcasting by inflating
the refcount with sock_hold/sock_put while under RCU lock is dangerous
and violates RCU principles. It leads to subtle race conditions when
attempting to free the SKB, as we may reference sockets that have
already been freed by the stack.
Unable to handle kernel paging request at virtual address 6b6b6b6b6b6c4b
[006b6b6b6b6b6c4b] address between user and kernel address ranges
Internal error: Oops: 96000004 [#1] PREEMPT SMP
task: fffffff78f65b380 task.stack: ffffff8049a88000
pc : sock_rfree+0x38/0x6c
lr : skb_release_head_state+0x6c/0xcc
Process repro (pid: 7117, stack limit = 0xffffff8049a88000)
Call trace:
sock_rfree+0x38/0x6c
skb_release_head_state+0x6c/0xcc
skb_release_all+0x1c/0x38
__kfree_skb+0x1c/0x30
kfree_skb+0xd0/0xf4
pfkey_broadcast+0x14c/0x18c
pfkey_sendmsg+0x1d8/0x408
sock_sendmsg+0x44/0x60
___sys_sendmsg+0x1d0/0x2a8
__sys_sendmsg+0x64/0xb4
SyS_sendmsg+0x34/0x4c
el0_svc_naked+0x34/0x38
Kernel panic - not syncing: Fatal exception
CRs-Fixed: 2251019
Change-Id: Ib3b01f941a34a7df61fe9445f746b7df33f4656a
Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>
Soft reset of the core before setting the run stop
bit of the core is not suggested.
So, remove the soft reset of the core as part of
the run_stop operation.
Change-Id: Ib87176d8036a27cc7e0a5790b293ee79811e4734
Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
For various reasons, user may want to specify lower bMaxPower
using following sysfs attribute for a configuration:
"configs/c.1/MaxPower"
Driver currently ignores that and selects 500mA or 900mA based
on the connection speed. Fix this by no overriding bMaxPower
if config->MaxPower is non-zero.
Change-Id: I10b499b327d5c4e332df2ce435211144637c48d0
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
GPS QDR feature has dependency on BMI160 and IAM20680
sensor driver which is enabled through GPIO 10 and 11 pins.
Change-Id: Ib9c257fc385233c733c24fa0f7175f739ce75a19
Signed-off-by: puneet <puneet@codeaurora.org>
Thus its been occasionally noted that users have seen
confusing warnings like:
Adjusting tsc more than 11% (5941981 vs 7759439)
We try to limit the maximum total adjustment to 11% (10% tick
adjustment + 0.5% frequency adjustment). But this is done by
bounding the requested adjustment values, and the internal
steering that is done by tracking the error from what was
requested and what was applied, does not have any such limits.
This is usually not problematic, but in some cases has a risk
that an adjustment could cause the clocksource mult value to
overflow, so its an indication things are outside of what is
expected.
It ends up most of the reports of this 11% warning are on systems
using chrony, which utilizes the adjtimex() ADJ_TICK interface
(which allows a +-10% adjustment). The original rational for
ADJ_TICK unclear to me but my assumption it was originally added
to allow broken systems to get a big constant correction at boot
(see adjtimex userspace package for an example) which would allow
the system to work w/ ntpd's 0.5% adjustment limit.
Chrony uses ADJ_TICK to make very aggressive short term corrections
(usually right at startup). Which push us close enough to the max
bound that a few late ticks can cause the internal steering to push
past the max adjust value (tripping the warning).
Thus this patch adds some extra logic to enforce the max adjustment
cap in the internal steering.
Note: This has the potential to slow corrections when the ADJ_TICK
value is furthest away from the default value. So it would be good to
get some testing from folks using chrony, to make sure we don't
cause any troubles there.
Change-Id: I31f2966d5134af18e3902cb0f1d9805f204a3e14
Cc: Miroslav Lichvar <mlichvar@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Tested-by: Miroslav Lichvar <mlichvar@redhat.com>
Reported-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Git-commit: ec02b076ceab63f99e5b3d80fd223d777266c236
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Signed-off-by: Gustavo Solaira <gustavos@codeaurora.org>
