Fix code analysis issues related to seemp, such as, variables might
be used uninitialized, and array may use index values larger than its
size.
Change-Id: Ic537ece4d00ac3d72d679359b60999df473f8710
Signed-off-by: Yida Wang <yidaw@codeaurora.org>
SPI core has a characterstic that it always sends data in FIFO word size
when we compress the data and fill the FIFO. This helps to improve the
overall througput but sometimes for the data transfers which is not
aligned to FIFO Word [i.e 4] it pads extra bytes and sends out which can
mislead spi slave device.
Do not enable packing if it's a FIFO mode transfer and data size is not
aligned to FIFO word size.
Change-Id: I28f4e3e38db4b882f229c00aa54aabdc72d2c139
Signed-off-by: Mukesh Kumar Savaliya <msavaliy@codeaurora.org>
Sampling work can be accessed by do_sampling kthread
before init. Fix this by initializing sampling work before
using.
Change-Id: I790ce50fcddbcd08861e31fea9bde839d6fbb7cc
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
GPS driver which makes use of PPS timestamp expects time
with respect to boot time. Existing pps_get_ts function
doesn't return time from the boot so replaced this function
with get_monotonic_boottime function which returns elapsed time
from the boot.
Change-Id: I8f656a1c4ef43f6314d4ab295a177125bcc8195e
CRs-Fixed: 1012438
Signed-off-by: Naresh Munagala <nareshm@codeaurora.org>
These changes will merge back the enhancemnts done to improve the medium
side transfers. This was reverted temporarily till the fix identified.
Change-Id: Ib7ac92ecefe7ca3ff9f03716c51dc31b8322ee33
Signed-off-by: Mukesh Kumar Savaliya <msavaliy@codeaurora.org>
This reverts 'commit 9814eb7549 ("sd: Fix rw_max for devices
that report an optimal xfer size")'.
Max sectors limit for request queue(q->limits.max_sectors) is reduced
from 1024 to 16 sectors by above commit and causing performance impact
(reduced by upto 50%). Hence revert the change to fix the performance
issue observed on 8998.
Change-Id: I9abd2be6c90922ea9de818912f405e0d292a62b8
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
The binder allocator assumes that the thread that
called binder_open will never die for the lifetime of
that proc. That thread is normally the group_leader,
however it may not be. Use the group_leader instead
of current.
Bug: 35707103
Test: Created test case to open with temporary thread
Change-Id: Id693f74b3591f3524a8c6e9508e70f3e5a80c588
Signed-off-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Martijn Coenen <maco@android.com>
Git-commit: 359795138d
Git-repo: https://android.googlesource.com/kernel/common/
Signed-off-by: Runmin Wang <runminw@codeaurora.org>
Adjust the PLL disable sequence as per the latest HW
programming guidelines to ensure there will not be any
stray clock glitches when PLL is turned OFF abruptly.
Change-Id: I6df35bbe18b0c42b43f38b9dd85c3502b2038928
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
When the supply to PLL digital domain is turned off,
it can result in certain PLL registers to get corrupted.
Make sure to re-program the PLL registers to the
power-on-reset value before starting to program the PLL again
to ensure that it locks reliably.
Change-Id: I63cac884cf11eae60b187f83654f5922a3342d66
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
During clock gating (ufshcd_gate_work()), we first put the link hibern8 by
calling ufshcd_uic_hibern8_enter() and if ufshcd_uic_hibern8_enter()
returns success (0) then we gate all the clocks.
Now let’s zoom in to what ufshcd_uic_hibern8_enter() does internally:
It calls __ufshcd_uic_hibern8_enter() which on detecting the LINERESET,
initiates the full recovery and puts the link back to highest HS gear and
returns success (0) to ufshcd_uic_hibern8_enter() which is the issue as
link is still in active state due to recovery!
Now ufshcd_uic_hibern8_enter() returns success to ufshcd_gate_work() and
hence it goes ahead with gating the UFS clock while link is still in active
state hence I believe controller would raise UIC error interrupts. But when
we service the interrupt, clocks might have already been disabled!
This change fixes for this by returning failure from
__ufshcd_uic_hibern8_enter() if recovery succeeds as link is still not in
hibern8, upon receiving the error ufshcd_hibern8_enter() would initiate
retry to put the link state back into hibern8.
Change-Id: Ib550fb791fa4c582b8f2d317a7f5f7594acb0872
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
CPU hotplug operations take place in preemptible context. This leaves
the hotplugging thread at the mercy of overall system load and CPU
availability. If the hotplugging thread does not get an opportunity
to execute after it has already begun a hotplug operation, CPUs can
end up being stuck in a quasi online state. In the worst case a CPU
can be stuck in a state where the migration thread is parked while
another task is executing and changing affinity in a loop. This
combination can result in unbounded execution time for the running
task until the hotplugging thread gets the chance to run to complete
the hotplug operation.
Fix the said problem by ensuring that hotplug can only occur from
threads belonging to the RT sched class. This allows the hotplugging
thread priority on the CPU no matter what the system load or the
number of available CPUs are. If a SCHED_NORMAL task attempts to
hotplug a CPU, we temporarily elevate it's scheduling policy to RT.
Furthermore, we disallow hotplugging operations to begin if the
calling task belongs to the idle and deadline classes or those that
use the SCHED_BATCH policy.
Change-Id: Idbb1384626e6ddff46c0d2ce752eee68396c78af
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
Add support to handle system error and shutdown notification
from MHI host.
CRs-Fixed: 2022936
Change-Id: Id36097dffd7571490d7d53d2e496bfe024702a42
Signed-off-by: Sujeev Dias <sdias@codeaurora.org>
Two notify requests are being queued for one available modem
response. So for the first GET_ENCAPSULATED_RESPONSE we provide
the host with the available response. Now for the next
GET_ENCAPSULATED_COMMAND we notify the host that the response is
available even before the modem is ready with a response because
of the extra notify request queued on the interrupt endpoint.
This causes a STALL for the next GET_ENCAPSULATED_RESPONSE request.
This is caused because we are queueing a notify request from the
completion handler of the interrupt endpoint request when the
response queue is not empty.
Fix this by queuing a notify request when a new response is
available only after the current resposne is send to the Host.
Change-Id: If84bc315f2be910503328cc6b0e21be342c6eb37
Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
