Add speed-bin 3 to support the fmax of 1.8 GHz and 1.6 GHz
for perf and power clusters respectively.
And also update the cpufreq table for the same.
Change-Id: Ia3be3f321b53bbbb4c37f5e86e451ca86ec8cdc9
Signed-off-by: Odelu Kukatla <okukatla@codeaurora.org>
KTM suspend/reboot frequency mitigation is not required for target
which has LMH DCVS hardware support. lmh_dcvs_available flag in the
KTM is initialized only post OSM driver is up. But during KTM probe,
it checks this flag to register suspend/reboot notifier. Since
it is not initialized, it always register with these notifier and
does frequency mitigation whenever it notifies KTM.
To avoid this, check if the LMH DCVS related devicetree node is
enabled during KTM probe before enabling suspend/reboot notifier
registration. To be safe use the same check in CPU frequency policy
callback for KTM max cpu frequency request as well.
Change-Id: I337477dd296e1e681498d702ab03c164d7554186
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manafm@codeaurora.org>
In function glink_xprt_notify_rxv work item is queued without
wakelock. This allows system to go in suspend state without
scheduling this work item.
Wakelock is taken to avoid system suspend before workqueue
execution.
CRs-Fixed: 2098623
Change-Id: Ic5f74dbb4bf315f1cb6aa528367a6fb80e8a11b6
Signed-off-by: Dhoat Harpal <hdhoat@codeaurora.org>
Do not call runtime suspend forcefully while holding the mutex as runtime
suspend also tries to acquire the same mutex. Instead acquire it properly
with the condition of runtime_pm enablement status without mutex.
Change-Id: I2347820e81ded0821e6f56a415af3bed17a951b4
Signed-off-by: Mukesh Kumar Savaliya <msavaliy@codeaurora.org>
when HAL request to skip zsl frames, isp need to
configure and skip all snapshot frames.
Change-Id: Ib091b9c707e8df7df671d8a942fc94bbb92de0b3
Signed-off-by: Ramesh V <ramev@codeaurora.org>
This change enables a new LP property to specify panel specific
low power modes. This is needed to differentiate between normal
panel "on" and "on but low power" scenarios, something that
is not available through the standard DRM DPMS property.
The sde connector calculates a consolidated "power mode" setting
between the DPMS and LP properties and provides a callback to
the underlying display driver(s) whenever one of them is updated.
CRs-Fixed: 2071893
Change-Id: If5c80ac9eefbf1f119bcae5513ae18c7be6f618d
Signed-off-by: Clarence Ip <cip@codeaurora.org>
Signed-off-by: Ray Zhang <rayz@codeaurora.org>
Remove device tree entries related to turing from coresight on sdm/a 636
target.
Change-Id: I22200dbb670d85d70a54caa61c110fd399b70211
Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
Add enabled flag to the CRTC to be able to track the enabled or
disabled status in the display thread instead of the atomic
state. The atomic state is swapped prior to the display thread
dispatch. This is before the display thread executes the enable
or disable operation, so the state is not properly reflected for
a running VSYNC work item.
Also, simplify the CRTC VBLANK function structure to use a
single common function call to update the CRTC's VBLANK
registration with the encoder to avoid extra refs and unrefs.
CRs-Fixed: 2071893
Change-Id: I9b473becec15427b03b5ebf0333e10e4911dfd9b
Signed-off-by: Lloyd Atkinson <latkinso@codeaurora.org>
Signed-off-by: Ray Zhang <rayz@codeaurora.org>
Enabling multi-channel bit for SCO Tx is required to fix
random 0s getting inserted. Set water mark level 1 for
SCO Tx only.
CRs-Fixed: 2094921
Change-Id: Ic26ef47478ed2ae8edb05aeaec182bb170c4f32d
Signed-off-by: Satish Kodishala <skodisha@codeaurora.org>
wsa881x speaker damage has been reported due to DC at
wsa output. Add a register setting which will reset
the soundwire when there are any
DC or synchronization issues.
CRs-Fixed: 2086505
Change-Id: I929d2eb7d096005e5089f3bfabded6901d81439e
Signed-off-by: Vatsal Bucha <vbucha@codeaurora.org>
Move the debug print in the sde core irq out of the general
DRM DEBUG log area and into pr_debug directly to avoid flooding
the DRM general logs.
CRs-Fixed: 2005394
Change-Id: Ib9456bb49ed1d8c045f353b4a41f43575fc3fd03
Signed-off-by: Lloyd Atkinson <latkinso@codeaurora.org>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Fix disable callflow in sde encoder so that the physical
encoder has a chance to wait for the frame done first, before
the virtual encoder declares an error for a missed frame done
event in the encoder disable case.
Change-Id: Ifc6cad708ad98324eef31435e709ad763059abbf
Signed-off-by: Lloyd Atkinson <latkinso@codeaurora.org>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Need to check for and wait for the unlikely event of a hardware
initiated CTL reset in video mode. Need to wait for the reset to
complete before initiating the next kickoff. If CTL reset fails
to complete, initiate a panic.
CRs-Fixed: 2005394
Change-Id: I27dfaf602a9c2ba2faacabe723a9593a39ed891e
Signed-off-by: Lloyd Atkinson <latkinso@codeaurora.org>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Add logic in the SDE video encoder vblank irq handler to verify
that the hardware actually flushed before decrementing the
pending flush counter. This prevents incorrectly signaling that
the buffer was flipped.
Change-Id: Idd723f80a8a7f5f596654a784c3a76abe75c4f19
Signed-off-by: Lloyd Atkinson <latkinso@codeaurora.org>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Need to consider hardware pipe priority when validating an
atomic commit. Hardware requires certain source pipes to be
left-most compared to other source pipes when in source split
configurations.
CRs-Fixed: 2005394
Change-Id: I4a19fbe9f78db8e557720ef7973034fdbd2f8a58
Signed-off-by: Lloyd Atkinson <latkinso@codeaurora.org>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Add checks to sde debug facility to reject poorly formed
register block ranges. Add names for dsc and vbif register
blocks. Register the vbif hw block under the vbif base register.
Fix the names of the printed register blocks to be 0 based as
expected. Fix the DSC register length initialization. Sort
register ranges before printing. Register mdp top block
address before dumping the sde debug bus.
Change-Id: I0179d59543de52537937abcc7d556f79569e9c55
Signed-off-by: Lloyd Atkinson <latkinso@codeaurora.org>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Add support for dumping the sde and vbif debug buses. Can be
triggered via sysfs, or via the SDE_DBG_DUMP macros by providing
"dbg_bus" or "vbif_dbg_bus" strings in the dump area list.
Change-Id: I8b3261a7bdc0161e77729ed0d05bf90cf9214298
Signed-off-by: Lloyd Atkinson <latkinso@codeaurora.org>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Need the capability to dump the content of sde registers during
panic and other scenarios. Add debugfs facility for triggering
register dumping. Add registration of sde and vbif as base
hardware blocks. Add the blocks within the sde as named register
dumping ranges.
CRs-Fixed: 2005394
Change-Id: I410c4e5270447d4d3a8364287fa61748ead5410f
Signed-off-by: Lloyd Atkinson <latkinso@codeaurora.org>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Need to read register block length from the DTSI and populate
into the catalog to support register debug dumping. Also add a
name string to each of the blocks for debug purposes.
CRs-Fixed: 2005394
Change-Id: Ia2299a51d649942b9335bc023d098d9c4882f1de
Signed-off-by: Lloyd Atkinson <latkinso@codeaurora.org>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Specify the lengths of the register blocks for the sde hardware
on msm8998, needed to support register dumping.
Change-Id: I7f798b8a98cc3a8f919e994e1203d2d7c76687d0
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Add a mutex to protect q6_proxy_clk_vote.
The proxy vote/unvote may be called from different contexts
which can result in a a race condition.
Change-Id: I402090be5ff35897ed61499a13bf52eb60a1f5cf
CRs-Fixed: 2094724
Acked-by: Ady Abraham <adya@qti.qualcomm.com>
Signed-off-by: Skylar Chang <chiaweic@codeaurora.org>
Overflow on memcpy is possible in kernel driver for st21nfca's
NFC HCI layer when handling connectivity events if aid_len or
params_len are bigger than the buffer size.
Memory leak is possible when parameter tag is invalid.
Bug: 62679581
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Add debug log to dump the GPU speed bin value incase probe
fails due to efused bin value mismatch with speed bin value.
Change-Id: I329523f8dbb82272418981a54a1c2e6cf5e90b85
Signed-off-by: Hareesh Gundu <hareeshg@codeaurora.org>
On virtual platform, cnss doesn't support dynamic dump.
Change-Id: I1734ed62be7753875efe85ed18beaf382af50654
Signed-off-by: Zhiqiang Tu <ztu@codeaurora.org>
commit bed9ff165960921303a100228585f2d1691b42eb upstream.
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ed18c5fa945768a9bec994e786edbbbc7695acf6 upstream.
This optimization significantly reduces xhci driver load time.
In ACPI tables the acpi companion port devices are children of
the hub device. The port devices are identified by their port number
returned by the ACPI _ADR method.
_ADR 0 is reserved for the root hub device.
The current implementation to find a acpi companion port device
loops through all acpi port devices under that parent hub, evaluating
their _ADR method each time a new port device is added.
for a xHC controller with 25 ports under its roothub it
will end up invoking ACPI bytecode 625 times before all ports
are ready, making it really slow.
The _ADR values are already read and cached earler. So instead of
running the bytecode again we can check the cached _ADR value first,
and then fall back to the old way.
As one of the more significant changes, the xhci load time on
Intel kabylake reduced by 70%, (28ms) from
initcall xhci_pci_init+0x0/0x49 returned 0 after 39537 usecs
to
initcall xhci_pci_init+0x0/0x49 returned 0 after 11270 usecs
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6fc2e83077b05a061afe9b24f2fdff7a0434eb67 upstream.
This patches fixes the LBR kernel crashes on Intel Atom.
The kernel was assuming that if the CPU supports 64-bit format
LBR, then it has an LBR_SELECT MSR. Atom uses 64-bit LBR format
but does not have LBR_SELECT. That was causing NULL pointer
dereferences in a couple of places.
Signed-off-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: kan.liang@intel.com
Fixes: 96f3eda67f ("perf/x86/intel: Fix static checker warning in lbr enable")
Link: http://lkml.kernel.org/r/1449182000-31524-2-git-send-email-eranian@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Denys Zagorui <dzagorui@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dd1c1f2f2028a7b851f701fc6a8ebe39dcb95e7c upstream.
This was reported many times, and this was even mentioned in commit
52ee2dfdd4 ("pids: refactor vnr/nr_ns helpers to make them safe") but
somehow nobody bothered to fix the obvious problem: task_tgid_nr_ns() is
not safe because task->group_leader points to nowhere after the exiting
task passes exit_notify(), rcu_read_lock() can not help.
We really need to change __unhash_process() to nullify group_leader,
parent, and real_parent, but this needs some cleanups. Until then we
can turn task_tgid_nr_ns() into another user of __task_pid_nr_ns() and
fix the problem.
Reported-by: Troy Kensinger <tkensinger@google.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 197e7e521384a23b9e585178f3f11c9fa08274b9 upstream.
The 'move_paghes()' system call was introduced long long ago with the
same permission checks as for sending a signal (except using
CAP_SYS_NICE instead of CAP_SYS_KILL for the overriding capability).
That turns out to not be a great choice - while the system call really
only moves physical page allocations around (and you need other
capabilities to do a lot of it), you can check the return value to map
out some the virtual address choices and defeat ASLR of a binary that
still shares your uid.
So change the access checks to the more common 'ptrace_may_access()'
model instead.
This tightens the access checks for the uid, and also effectively
changes the CAP_SYS_NICE check to CAP_SYS_PTRACE, but it's unlikely that
anybody really _uses_ this legacy system call any more (we hav ebetter
NUMA placement models these days), so I expect nobody to notice.
Famous last words.
Reported-by: Otto Ebeling <otto.ebeling@iki.fi>
Acked-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 277867ade8262583f4280cadbe90e0031a3706a7 upstream.
of_find_compatible_node() is calling of_node_put() on its first argument
thus leading to an unbalanced of_node_get/put() issue if the node has not
been retained before that.
Instead of passing the root node, pass NULL, which does exactly the same:
iterate over all DT nodes, starting from the root node.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Fixes: 3d61467f9b ("irqchip: atmel-aic: Implement RTC irq fixup")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 469bcef53c546bb792aa66303933272991b7831d upstream.
aic_common_irq_fixup() is calling twice of_node_put() on the same node
thus leading to an unbalanced refcount on the root node.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Fixes: b2f579b58e ("irqchip: atmel-aic: Add irq fixup infrastructure")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e93c17301ac55321fc18e0f8316e924e58a83c8c upstream.
This closes a hole in our SMAP implementation.
This patch comes from grsecurity. Good catch!
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/314cc9f294e8f14ed85485727556ad4f15bb1659.1502159503.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 462cdace790ac2ed6aad1b19c9c0af0143b6aab0 upstream.
The current test for bio vec merging is not fully accurate and can be
tricked into merging bios when certain grant combinations are used.
The result of these malicious bio merges is a bio that extends past
the memory page used by any of the originating bios.
Take into account the following scenario, where a guest creates two
grant references that point to the same mfn, ie: grant 1 -> mfn A,
grant 2 -> mfn A.
These references are then used in a PV block request, and mapped by
the backend domain, thus obtaining two different pfns that point to
the same mfn, pfn B -> mfn A, pfn C -> mfn A.
If those grants happen to be used in two consecutive sectors of a disk
IO operation becoming two different bios in the backend domain, the
checks in xen_biovec_phys_mergeable will succeed, because bfn1 == bfn2
(they both point to the same mfn). However due to the bio merging,
the backend domain will end up with a bio that expands past mfn A into
mfn A + 1.
Fix this by making sure the check in xen_biovec_phys_mergeable takes
into account the offset and the length of the bio, this basically
replicates whats done in __BIOVEC_PHYS_MERGEABLE using mfns (bus
addresses). While there also remove the usage of
__BIOVEC_PHYS_MERGEABLE, since that's already checked by the callers
of xen_biovec_phys_mergeable.
Reported-by: "Jan H. Schönherr" <jschoenh@amazon.de>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c715b72c1ba406f133217b509044c38d8e714a37 upstream.
Moving the x86_64 and arm64 PIE base from 0x555555554000 to 0x000100000000
broke AddressSanitizer. This is a partial revert of:
eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
02445990a96e ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB")
The AddressSanitizer tool has hard-coded expectations about where
executable mappings are loaded.
The motivation for changing the PIE base in the above commits was to
avoid the Stack-Clash CVEs that allowed executable mappings to get too
close to heap and stack. This was mainly a problem on 32-bit, but the
64-bit bases were moved too, in an effort to proactively protect those
systems (proofs of concept do exist that show 64-bit collisions, but
other recent changes to fix stack accounting and setuid behaviors will
minimize the impact).
The new 32-bit PIE base is fine for ASan (since it matches the ET_EXEC
base), so only the 64-bit PIE base needs to be reverted to let x86 and
arm64 ASan binaries run again. Future changes to the 64-bit PIE base on
these architectures can be made optional once a more dynamic method for
dealing with AddressSanitizer is found. (e.g. always loading PIE into
the mmap region for marked binaries.)
Link: http://lkml.kernel.org/r/20170807201542.GA21271@beast
Fixes: eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
Fixes: 02445990a96e ("arm64: move ELF_ET_DYN_BASE to 4GB / 4MB")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Kostya Serebryany <kcc@google.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
