Conflicts:
	arch/arm64/boot/dts/qcom/qcs605-lc.dtsi

Change-Id: If28a4dff2dea200b58b3648f9e09a0fd07b1e7e8
Signed-off-by: Ashok Kundurthi <askund@codeaurora.org>

skb maybe freed in hns_nic_net_xmit_hw() and return NETDEV_TX_OK,
which cause hns_nic_net_xmit to use a freed skb.

BUG: KASAN: use-after-free in hns_nic_net_xmit_hw+0x62c/0x940...
	[17659.112635]      alloc_debug_processing+0x18c/0x1a0
	[17659.117208]      __slab_alloc+0x52c/0x560
	[17659.120909]      kmem_cache_alloc_node+0xac/0x2c0
	[17659.125309]      __alloc_skb+0x6c/0x260
	[17659.128837]      tcp_send_ack+0x8c/0x280
	[17659.132449]      __tcp_ack_snd_check+0x9c/0xf0
	[17659.136587]      tcp_rcv_established+0x5a4/0xa70
	[17659.140899]      tcp_v4_do_rcv+0x27c/0x620
	[17659.144687]      tcp_prequeue_process+0x108/0x170
	[17659.149085]      tcp_recvmsg+0x940/0x1020
	[17659.152787]      inet_recvmsg+0x124/0x180
	[17659.156488]      sock_recvmsg+0x64/0x80
	[17659.160012]      SyS_recvfrom+0xd8/0x180
	[17659.163626]      __sys_trace_return+0x0/0x4
	[17659.167506] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=23 cpu=1 pid=13
	[17659.174000]      free_debug_processing+0x1d4/0x2c0
	[17659.178486]      __slab_free+0x240/0x390
	[17659.182100]      kmem_cache_free+0x24c/0x270
	[17659.186062]      kfree_skbmem+0xa0/0xb0
	[17659.189587]      __kfree_skb+0x28/0x40
	[17659.193025]      napi_gro_receive+0x168/0x1c0
	[17659.197074]      hns_nic_rx_up_pro+0x58/0x90
	[17659.201038]      hns_nic_rx_poll_one+0x518/0xbc0
	[17659.205352]      hns_nic_common_poll+0x94/0x140
	[17659.209576]      net_rx_action+0x458/0x5e0
	[17659.213363]      __do_softirq+0x1b8/0x480
	[17659.217062]      run_ksoftirqd+0x64/0x80
	[17659.220679]      smpboot_thread_fn+0x224/0x310
	[17659.224821]      kthread+0x150/0x170
	[17659.228084]      ret_from_fork+0x10/0x40

	BUG: KASAN: use-after-free in hns_nic_net_xmit+0x8c/0xc0...
	[17751.080490]      __slab_alloc+0x52c/0x560
	[17751.084188]      kmem_cache_alloc+0x244/0x280
	[17751.088238]      __build_skb+0x40/0x150
	[17751.091764]      build_skb+0x28/0x100
	[17751.095115]      __alloc_rx_skb+0x94/0x150
	[17751.098900]      __napi_alloc_skb+0x34/0x90
	[17751.102776]      hns_nic_rx_poll_one+0x180/0xbc0
	[17751.107097]      hns_nic_common_poll+0x94/0x140
	[17751.111333]      net_rx_action+0x458/0x5e0
	[17751.115123]      __do_softirq+0x1b8/0x480
	[17751.118823]      run_ksoftirqd+0x64/0x80
	[17751.122437]      smpboot_thread_fn+0x224/0x310
	[17751.126575]      kthread+0x150/0x170
	[17751.129838]      ret_from_fork+0x10/0x40
	[17751.133454] INFO: Freed in kfree_skbmem+0xa0/0xb0 age=19 cpu=7 pid=43
	[17751.139951]      free_debug_processing+0x1d4/0x2c0
	[17751.144436]      __slab_free+0x240/0x390
	[17751.148051]      kmem_cache_free+0x24c/0x270
	[17751.152014]      kfree_skbmem+0xa0/0xb0
	[17751.155543]      __kfree_skb+0x28/0x40
	[17751.159022]      napi_gro_receive+0x168/0x1c0
	[17751.163074]      hns_nic_rx_up_pro+0x58/0x90
	[17751.167041]      hns_nic_rx_poll_one+0x518/0xbc0
	[17751.171358]      hns_nic_common_poll+0x94/0x140
	[17751.175585]      net_rx_action+0x458/0x5e0
	[17751.179373]      __do_softirq+0x1b8/0x480
	[17751.183076]      run_ksoftirqd+0x64/0x80
	[17751.186691]      smpboot_thread_fn+0x224/0x310
	[17751.190826]      kthread+0x150/0x170
	[17751.194093]      ret_from_fork+0x10/0x40

Change-Id: I5fbdea5d0264c79dbcc91f8519cda1004b667866
Fixes: 13ac695e ("net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem")
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: lipeng <lipeng321@huawei.com>
Reported-by: Jun He <hjat2005@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git


Git-commit: 27463ad9
Signed-off-by: Dennis Cagle <dcagle@codeaurora.org>

The rationale for removing the check is only correct for rulesets
generated by ip(6)tables.

In iptables, a jump can only occur to a user-defined chain, i.e.
because we size the stack based on number of user-defined chains we
cannot exceed stack size.

However, the underlying binary format has no such restriction,
and the validation step only ensures that the jump target is a
valid rule start point.

IOW, its possible to build a rule blob that has no user-defined
chains but does contain a jump.

If this happens, no jump stack gets allocated and crash occurs
because no jumpstack was allocated.

Change-Id: I03e0851c2c9feeb4350c55bbc797a67ed7b3d8b7
Fixes: 7814b6ec ("netfilter: xtables: don't save/restore jumpstack offset")
Reported-by:  <syzbot+e783f671527912cd9403@syzkaller.appspotmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git


Git-commit: 57ebd808
Signed-off-by: Dennis Cagle <dcagle@codeaurora.org>

If the list search in sg_get_rq_mark() fails to find a valid request, we
return a bogus element. This then can later lead to a GPF in
sg_remove_scat().

So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case
the list search doesn't find a valid request.

Bug: 79090045
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Doug Gilbert <dgilbert@interlog.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Acked-by: Doug Gilbert <dgilbert@interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Chenbo Feng <fengc@google.com>
(cherry picked from commit 48ae8484)

Change-Id: If95d1a8eef3748c9937201e524184b89a5eaaf2e
Bug: 75300370
Git-repo: https://android.googlesource.com/kernel/msm


Git-commit: 58408c68
Signed-off-by: Dennis Cagle <dcagle@codeaurora.org>

CX GDSC has a parent supply which is required to be enabled
before turning on CX GDSC; therefore, specify VDD_CX as the
parent supply for CX GDSC.
Also update the min level for VDD_CX regulator.

Change-Id: If770109a03152e98183930289556d6c3cf6ec497
Signed-off-by: Odelu Kukatla <okukatla@codeaurora.org>

The patch frees up the non-guaranteed clients' requested size
along with the guard bytes to prevent memory fragmentation.

Change-Id: I4f7b1bbd95eb045f73c23543b046f169e09de4c1
Signed-off-by: Manoj Prabhu B <bmanoj@codeaurora.org>

* commit '6fe599d9':
  msm: camera: icp: Dump hfi queues in case of FW timeout
  msm: camera: sensor: Correct spelling error
  msm: camera: icp: allow reconfig io during streaming
  msm: camera: sync: Protect row state read
  ARM: dts: msm: Add register base address for sdm670/sdm845
  msm: camera: reqmgr: Create workq based on driver requirement
  msm: camera: flash: Optimizing flash off operation
  msm: camera: isp: Fix TPG acquire error
  msm: camera: ife: Changes CSID acquire resource logic
  msm: camera: util: validate patch offset value
  msm: camera: isp: Initialize used_bytes to avoid corruption
  msm: camera: sensor: Unlock the mutex in case of error
  msm: camera: sensor: Assign power settings pointer to null
  ARM: dts: msm: Modify qdss region for sdm670/sdm845
  msm: camera: sync: use lock to protect row state read

Change-Id: Ic8ecc6dc071d06307aca948eaa99b30ad035a32e
Signed-off-by: Sridhar Gujje <sgujje@codeaurora.org>

Update hyp carveout region on SDM670, to include 2MB more.

Change-Id: I68f9437bedb6c7115059114124023ba416059427
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>

As per current design each different pd service running on same
subsytem are using same qmi connection from HLOS pil, but it
has own disadvantages if each service crashed simultaneously and
using the same per client workqueue and override each other's data. To
overcome the same and to avoid much driver change creating qmi client
per service.

Change-Id: I45096798fb35d50903d7c99d42ae5ce16becf063
Signed-off-by: Gaurav Kohli <gkohli@codeaurora.org>

commit c52232a4 upstream.

On CPU hotunplug the enqueued timers of the unplugged CPU are migrated to a
live CPU. This happens from the control thread which initiated the unplug.

If the CPU on which the control thread runs came out from a longer idle
period then the base clock of that CPU might be stale because the control
thread runs prior to any event which forwards the clock.

In such a case the timers from the unplugged CPU are queued on the live CPU
based on the stale clock which can cause large delays due to increased
granularity of the outer timer wheels which are far away from base:;clock.

But there is a worse problem than that. The following sequence of events
illustrates it:

 - CPU0 timer1 is queued expires = 59969 and base->clk = 59131.

   The timer is queued at wheel level 2, with resulting expiry time = 60032
   (due to level granularity).

 - CPU1 enters idle @60007, with next timer expiry @60020.

 - CPU0 is hotplugged at @60009

 - CPU1 exits idle and runs the control thread which migrates the
   timers from CPU0

   timer1 is now queued in level 0 for immediate handling in the next
   softirq because the requested expiry time 59969 is before CPU1 base->clk
   60007

 - CPU1 runs code which forwards the base clock which succeeds because the
   next expiring timer. which was collected at idle entry time is still set
   to 60020.

   So it forwards beyond 60007 and therefore misses to expire the migrated
   timer1. That timer gets expired when the wheel wraps around again, which
   takes between 63 and 630ms depending on the HZ setting.

Address both problems by invoking forward_timer_base() for the control CPUs
timer base. All other places, which might run into a similar problem
(mod_timer()/add_timer_on()) already invoke forward_timer_base() to avoid
that.

[ tglx: Massaged comment and changelog ]

Change-Id: Ied68e3e2f7d429b6da90d645bfbe3293e01601e5
Fixes: a683f390 ("timers: Forward the wheel clock whenever possible")
Co-developed-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Signed-off-by: Lingutla Chandrasekhar <clingutla@codeaurora.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Anna-Maria Gleixner <anna-maria@linutronix.de>
Cc: linux-arm-msm@vger.kernel.org
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20180118115022.6368-1-clingutla@codeaurora.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Git-commit: c52232a4
Git-repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git


[gkohli@codeaurora: Resolve trivial merge conflicts]
Signed-off-by: Gaurav Kohli <gkohli@codeaurora.org>

This change adds the hx8399 FHD+ panel node to sdm670
CDP and MTP platform.

Change-Id: Ib09a41131802cd9f9fd571e6c5131ec8b5cf69a0
Signed-off-by: Sandeep Panda <spanda@codeaurora.org>

Wait for GMU to move to ACTIVE state before triggering preemption.
This is required to make sure CP doesn't interrupt GMU during
wake-up from IFPC.

Change-Id: I9c8ee07a4887deb30483b5523585d547b5d38806
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>

Currently, GMU recovery for preemption and performance
counter OOB set failures is not getting triggered.
Enable this to make sure GMU snapshot is dumped and
recovery happens for these failures.

Change-Id: Ie4084c236957538d396cfb504f50d7b325a5743d
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>

On GMU recovery failure, kgsl clears the GMU_FAULT bit
and also restores the kgsl state to orginal state from
which GMU/GPU wake up was triggered to make sure any
attempt to wake GMU/GPU after this is treated as a fresh
start/hard reset. But on recovery failure, GMU HS, clocks
and IRQ are still ON/enabled because of which any attempt
of GMU/GPU wakeup results in multiple warnings from GMU
start as HS, clocks and IRQ are still ON while doing a
fresh start i.e. wake up from SLUMBER.

Suspend the GMU on recovery failure to make sure next
attempt to wake up GMU/GPU is indeed a fresh start/
hard reset.

Change-Id: Ib0ffa8e19bbcf6ace1c438ec04275f7aabddce1b
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>

Kgsl driver polls GMU for fence status to become zero in case
it was one in IRQ handler and prints "AHB fence stuck in ISR"
error log in case it doesn't happen in multiple retries. Add a
small delay between two retries to make sure GMU firmware gets
sufficient time to abort power collapse. This will avoid this
error prints in scenarios where waiting loop finish much faster
and GMU is still in process of aborting power collapse. This
will also reduce number of retries.

Also, dump register GMU_AO_RBBM_INT_UNMASKED_STATUS_SHADOW as
part of error message to identify the unhandled IRQ when this
error happens.

Change-Id: Ia67a44db43d5a4ec3dd7f3323e7754d950490aec
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>

RSCC wake-up sequence should only be triggered if RSCC
sleep sequence was done earlier i.e. they should always
be balanced to make sure GMU FW, RSCC and PDC state are
in sync.

Add GMU_RSCC_SLEEP_SEQ_DONE GMU flag to track whether
RSCC sleep sequence was done or not and trigger sleep
and wake-up sequence based on this flag to make they
are always balanced.

Change-Id: I78d8be52a770bd6e939da91fa68b6fd01f10034e
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>

If the IRQ pending count is incremented, make sure it is decremented
even in case of errors.

Change-Id: I63443d4430b24ff82eb58d729e42f7115607ff25
Signed-off-by: Lynus Vaz <lvaz@codeaurora.org>

Destroy mutex before file free, to avoid use after free of mutex.

Change-Id: I4ff73dc17b15043eacbb299219a379bfd1a8efa6
Acked-by: Himateja Reddy <hmreddy@qti.qualcomm.com>
Signed-off-by: Tharun Kumar Merugu <mtharu@codeaurora.org>

Remove the use of dmac_flush_range for userspace buffers and add
msm_ion_do_cache_op for flushing user space buffers.

Change-Id: Ice73eafac840bd1cabee0a2bfc8a641832a7d0c8
Acked-by: Bharath Kumar <bkumar@qti.qualcomm.com>
Signed-off-by: Tharun Kumar Merugu <mtharu@codeaurora.org>

Change-Id: I83e14bb035506d4f01952003548cc739f24575d7
Signed-off-by: Kiran Raparthy <kraparth@codeaurora.org>
Signed-off-by: Satyanarayana Dash <sadash@codeaurora.org>

The battery is used on qcs605 project, add it for FG to load the right
battery profile and report accurate battery SoC.

Change-Id: I8fd9591122a022bc472bb055211e3555e4750839
Signed-off-by: xuji <xuji@codeaurora.org>
Signed-off-by: Satyanarayana Dash <sadash@codeaurora.org>