Previous iterations of the llcc driver did not account for caches with
no llcc broadcast hardware. This fixes this issue.
Change-Id: I221d0d65d17c34645cd1a4070737fe9bebfa4b16
Signed-off-by: Melody Olvera <molvera@codeaurora.org>
Add support for gcc hw reset for sdcc. This feature would
help recover emmc host controller and card cleanly in case
software recovery fails.
This would also help reset hwkm key during probe for crypto
when called during probe.
Change-Id: I32c7fbfb1a97bb69924e1a0c6ea90a400dd35c43
Signed-off-by: Ram Prakash Gupta <rampraka@codeaurora.org>
First problem is we hit BUG_ON() in f2fs_get_sum_page given EIO on
f2fs_get_meta_page_nofail().
Quick fix was not to give any error with infinite loop, but syzbot caught
a case where it goes to that loop from fuzzed image. In turned out we abused
f2fs_get_meta_page_nofail() like in the below call stack.
- f2fs_fill_super
- f2fs_build_segment_manager
- build_sit_entries
- get_current_sit_page
INFO: task syz-executor178:6870 can't die for more than 143 seconds.
task:syz-executor178 state:R
stack:26960 pid: 6870 ppid: 6869 flags:0x00004006
Call Trace:
Showing all locks held in the system:
1 lock held by khungtaskd/1179:
#0: ffffffff8a554da0 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6242
1 lock held by systemd-journal/3920:
1 lock held by in:imklog/6769:
#0: ffff88809eebc130 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 fs/file.c:930
1 lock held by syz-executor178/6870:
#0: ffff8880925120e0 (&type->s_umount_key#47/1){+.+.}-{3:3}, at: alloc_super+0x201/0xaf0 fs/super.c:229
Actually, we didn't have to use _nofail in this case, since we could return
error to mount(2) already with the error handler.
As a result, this patch tries to 1) remove _nofail callers as much as possible,
2) deal with error case in last remaining caller, f2fs_get_sum_page().
Change-Id: I886e51597190332553b6a6bbd9fa474f4995bac6
Reported-by: syzbot+ee250ac8137be41d7b13@syzkaller.appspotmail.com
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Git-commit: 86f33603f8c51537265ff7ac0320638fd2cbdb1b
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux.git/
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
If a channel is being rapidly restarting and the kobj release worker
is busy, there is a chance the the rpdev_release function will run
after the channel struct itself has been released.
There should not be a need to decouple the channel from rpdev in the
rpdev release since that should only happen from the close commands.
Change-Id: Ia4131151b7efb014716c5a0666f940384975ea42
Signed-off-by: Chris Lew <clew@codeaurora.org>
Surround vendor extensions with #ifdef directive to make them
available only for QGKI builds.
Change-Id: Ibea4847739e97e4ffd9ea97223c20f14aa53a967
Signed-off-by: Santosh Mardi <gsantosh@codeaurora.org>
If frequency update is not honored in cases where it matches to the
previous update, the previous policy update may be revoked any time
and desired performance may drop before the usecase completeion of
the current frequency update.
Change-Id: Ib626f04ecdd343b767c3e0609863a9b8d30f5187
Signed-off-by: Kishore Sri venkata Ganesh Bolisetty <bsrivenk@codeaurora.org>
Enable PCI_QTI config flag to add QTI specific code to upstream
PCI driver for sdxlemur.
Change-Id: Ic17441714ac67c7965af43c59ff24cfef432ae6b
Signed-off-by: Tony Truong <truong@codeaurora.org>
Documentation/networking/ip-sysctl.txt:46 says:
ip_forward_use_pmtu - BOOLEAN
By default we don't trust protocol path MTUs while forwarding
because they could be easily forged and can lead to unwanted
fragmentation by the router.
You only need to enable this if you have user-space software
which tries to discover path mtus by itself and depends on the
kernel honoring this information. This is normally not the case.
Default: 0 (disabled)
Possible values:
0 - disabled
1 - enabled
Which makes it pretty clear that setting it to 1 is a potential
security/safety/DoS issue, and yet it is entirely reasonable to want
forwarded traffic to honour explicitly administrator configured
route mtus (instead of defaulting to device mtu).
Indeed, I can't think of a single reason why you wouldn't want to.
Since you configured a route mtu you probably know better...
It is pretty common to have a higher device mtu to allow receiving
large (jumbo) frames, while having some routes via that interface
(potentially including the default route to the internet) specify
a lower mtu.
Note that ipv6 forwarding uses device mtu unless the route is locked
(in which case it will use the route mtu).
This approach is not usable for IPv4 where an 'mtu lock' on a route
also has the side effect of disabling TCP path mtu discovery via
disabling the IPv4 DF (don't frag) bit on all outgoing frames.
I'm not aware of a way to lock a route from an IPv6 RA, so that also
potentially seems wrong.
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: Sunmeet Gill (Sunny) <sgill@qti.qualcomm.com>
Cc: Vinay Paradkar <vparadka@qti.qualcomm.com>
Cc: Tyler Wear <twear@qti.qualcomm.com>
Cc: David Ahern <dsahern@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
(Backported from commit 02a1b175b0e92d9e0fa5df3957ade8d733ceb6a0).
Change-Id: I26f336f891711f0149b2835d2c4a78fc8407b5ba
Git-Commit: 02a1b175b0e92d9e0fa5df3957ade8d733ceb6a0
Git-repo: https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux
Signed-off-by: Sauvik Saha <ssaha@codeaurora.org>
Add 5nm Combo and Uni phy macro definition file for
broader use across all 5nm QMP Phy device tree nodes.
Change-Id: I5791723981b3b7015e69d2dbc07e0cdd2d2a25c6
Signed-off-by: Elson Roy Serrao <eserrao@codeaurora.org>
Before copying dump to userspace, memory is mapped and then the
content get copied to userspace and later that memory should be
unmapped.
Let's unmap the memory after the content get copied to
userspace.
Change-Id: I03d53ebd1cdb743e1820f226a49d46136eca4874
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org>
Send Calibration mode to FW only at the time of cold
boot. At the time of SSR Calibration mode will not be
sent.
Change-Id: Idf7016384937433480f62d0912e5e3dcf76f4e44
Signed-off-by: Naman Padhiar <npadhiar@codeaurora.org>
Normally clk_vote_vdd_level() and clk_unvote_vdd_level() are called
while holding the clock framework's prepare_lock since they are called
in the prepare paths. However, we're also calling clk_unvote_vdd_level()
from qcom_cc_sync_state() when removing proxy votes. This happens
outside of the clock framework, so the prepare_lock isn't protecting
this case. If the sync_state callback fires while another thread is
voting/unvoting voltage from a normal clock call, then there's a race
condition that can result in regulators being set to the incorrect
voltage or being pre-maturely disabled.
Add a mutex to protect this case.
Change-Id: Ib979e2edaaa5824dc80f7d4f065d72ca0b1a4444
Signed-off-by: Mike Tipton <mdtipton@codeaurora.org>
The target platforms use PM_SUSPEND_TO_IDLE as its default
suspend target. Since syscore_ops's suspend/resume callbacks
are not called in this path, the IPCC driver will never be
able to log the client's details that caused the wakeup in
it's resume handler. Hence, move the suspend/resume handlers
to dev_pm_ops for better visibility.
Change-Id: I095f02217aeea5ed7c5036017a7e960e2b98757a
Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
According to the comment in arch/arm/include/asm/delay.h,
__bad_udelay is specifically designed on ARM to produce a
build failure when udelay is called with a value > 2000.
Fix the issue by using mdelay for value > 2000.
Change-Id: Ia5ee988eeef68ce60b637232e0dd3989b8cbfe64
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Driver is directly performing a 64 bit read on time sync
register. In order to avoid compilation error on a 32 bit
platform perform two 32 bit reads instead of 64 bit read.
Change-Id: I477647c88a0bb2b4302ce2564bdc58fc4d68e806
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
