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
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>
Enable MSM_TIMER_LEAP config flag in both msm-auto_defconfig
and msm-auto-perf_defconfig files. This option enables check
for architecture timer leaps, when all least significant 32bits
of CNTVCT or CNTPCT counter is set and rereads counters.
Change-Id: I1b37f9931793e21f5144e0afb9c689a228c03493
Signed-off-by: Gustavo Solaira <gustavos@codeaurora.org>
GPU should not be forced to SUSPEND state when it is in INIT
or NONE state as this transition is invalid.
Change-Id: Ia3d0fd131348508fe34c57f271c1f991a98afa19
Signed-off-by: Archana Sriram <apsrir@codeaurora.org>
Whenever a vchan is locally closed in hab_vchan_close or hab_free,
4 actions should be taken immediately, including,
- remove it from the local hab context
- mark its local closed flag
- notify remote side and unblock local blocking calls over it
- decrease the refcnt on the vchan
Change-Id: I3fbde9464f6405b6dadac248768a5fd857a29128
Signed-off-by: Yong Ding <yongding@codeaurora.org>
If the result of (min + max) is negative in functions
snd_soc_get_volsw_sx() or snd_soc_put_volsw_sx(), there
will be an overflow for the variable 'mask'.
UBSAN: Undefined behaviour in sound/soc/soc-ops.c:382:6
signed integer overflow:
-2147483648 - 1 cannot be represented in type 'int'
Fix this by updating the variable type of 'mask' to unsigned int.
Change-Id: Ia34f397fad5b93c0e2ffacae60e051ad20c20bdf
Signed-off-by: Banajit Goswami <bgoswami@codeaurora.org>
Add CPU ID to the socinfo table needed to support
APQ8096A Automotive SoC.
Change-Id: I621faa171c867b36fa541961772a841333917861
Signed-off-by: Arun KS <arunks@codeaurora.org>
