BoringSSL does not implement the ENGINE API. In Android we do not seem
to rely on the PKCS#11 -> DER extraction. Hence, make this conditional
on the SSL library used.
Bug: 135570712
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: I84af6633dd470083497087c7dd1a2734480e2b0e
vImplement callbacks for enabling/disabling
POWER_CONTROL.AutoDischargeDisconnect.
Programs VBUS_SINK_DISCONNECT_THRESHOLD based on the
voltage requested as sink, mode of operation.
The programmed threshold is based on vSinkDisconnect and
vSinkDisconnectPD values.
Add auto_discharge_disconnect to tdata to allow TCPC chip
level drivers enable AutoDischargeDisconnect.
Bug: 168555244
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20201029063138.1429760-9-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e1a97bf80ahttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
(cherry picked from commit 33936ca3f6348db3e2e79776b01bc8339c446c80)
(cherry picked from commit 3622a289e91fe57a4a6b8ca210119c1b645444ea)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 8285bc18a7fbf2409001ea1066136dd167a9cd97)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: I896d47412ec6eaa23b87c38be545618f811253c8
TCPCI spec allows TCPC hardware to autonomously discharge the vbus
capacitance upon disconnect. The expectation is that the TCPM enables
AutoDischargeDisconnect while entering SNK/SRC_ATTACHED states. Hardware
then automously discharges vbus when the vbus falls below a certain
threshold i.e. VBUS_SINK_DISCONNECT_THRESHOLD.
Apart from enabling the vbus discharge circuit, AutoDischargeDisconnect
is also used a flag to move TCPCI based TCPC implementations into
Attached.Snk/Attached.Src state as mentioned in
Figure 4-15. TCPC State Diagram before a Connection of the
USB Type-C Port Controller Interface Specification.
In such TCPC implementations, setting AutoDischargeDisconnect would
prevent TCPC into entering "Connection_Invalid" state as well.
Bug: 168555244
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20201029063138.1429760-8-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f321a02caehttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-next)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
(cherry picked from commit e9a276bd2a70537eab1b4162cca9b7eeb0f1514a)
(cherry picked from commit a53a13168af75458cc57fe1e7a0e1129562fcd1a)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 303a32911f5aca961031f4c1d57ee9c713f9e6cb)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Change-Id: I3e25e9045c335b48cefaddb70329dd4df7e0fd94
Background:
We can allocate buffer from ion_system_heap for general case,
if the buffer is needed to access by HW, we need to map/unmap
dma_address by iommu driver before and after HW engine access for
iommu case. For example, if the same buffer is accessed by three
HW engines, then every device driver needs to map/unmap dma_address
by iommu driver respectively.
For MTK platform, all the multimedia HW engines use the same
iommu HW and share the same iommu page table, so multiple map/unmap
dma_address by iommu driver maybe reduce performance seriously for
above case, especially for big size buffer. In order to improve
performance for MTK platform, we want to add ion_mtk_iommu_heap
and implement map/unmap dma_address by ion_mtk_iommu_heap:
a.heap->buf_ops.map_dma_buf: If more than one attachments map
dma_address by iommu driver about the same buffer, the function
only map once in first attachment, the other attachments of buffer
copy sg_table which has already mapped to respective sg_table directly
and don't mapping dma_address truly.
b.heap->buf_ops.unmap_dma_buf: Do nothing.
c.heap->buf_ops.release: unmap dma_address by iommu driver about buffer
and free the buffer.
Based on above description:
We will build ion_mtk_iommu_heap as a kernel module and ion_mtk_iommu_heap
also use some APIs like ion_system_heap but they not do export symbol
ion_page_pool_alloc()
ion_page_pool_free()
ion_page_pool_nr_pages()
ion_page_pool_shrink()
ion_page_pool_create()
ion_page_pool_destroy()
Bug: 158729041
Bug: 170264063
Change-Id: If3897d5e0105edefe03a51ac52c7b3d423aaa988
Signed-off-by: Chao Hao <chao.hao@mediatek.com>
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
(cherry picked from commit 34364883b1f7cf8aed0e3a36e38aa7803c73b203)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit 48979298f2c9f814293323e05754a9c1f2038146)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 4dad2d6066b354f9fb087430fca714ffdc05790f)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The begin[end]_cpu_access handles cache coherency.
However the kmap is always called here and it just
makes unnecessary overhead of kmap.
We don't need to call kmap on begin[end]_cpu_access
because ION no longer supports dma_buf_kmap callback
on ion dma, so remove it.
Bug: 158635261
Bug: 170264063
Signed-off-by: Hyesoo YU <hyesoo.yu@samsung.com>
Change-Id: I8a9a1715da2c0d7df59a3abe8790614b07f55fe6
(cherry picked from commit 0eb5f60e7dc89ed757b5fc29c488b21cc8a5a846)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit eb41cb99df24eaa68c936f1b62ae3afca4728014)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 2419380051284d5d00e6c053e69e13e977c41b0e)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
ion_dma_buf_unmap() interprets the priv pointer in the
attachment structure as a pointer to an ion_dma_buf_attachment
structure, and modifies the "mapped" field of that structure.
In cases where the heap specifies its own dma-buf ops, this
is not correct, as the priv pointer in the attachment structure
may point to a structure that is not an ion_dma_buf_attachment
structure, and thus, the current implementation of
ion_dma_buf_unmap() will modify the unknown structure--potentially
putting it in an inconsistent state--prior to calling the heap's
dma-buf unmap operation.
Thus, modify the structure pointed to by the priv field in the
attachment structure only if the heap doesn't provide its own
implementation of the unmap operation, as that guarantees that
the priv field points to an ion_dma_buf_attachment structure.
Bug: 157163668
Bug: 170264063
Change-Id: If79a90ae1ca54762bbead6e23518b21076efd44b
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
(cherry picked from commit 01b0584902c56d12569423ef8cdb37d3a132a629)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit af44ead94861b441f815786a55a6f6fcedb85b4e)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 2466e97c83568d752e56cec619488b891ca6e34c)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The non-cached ion buffer is flushed when allocated.
And then, that is is always mapped as non-cached after allocation.
In the absence of caching, cache maintenance operations
become unnecessary. However dma_buf_ops tries to maintain
cache coherency for non-cached buffer on begin[end]_cpu_access
and map[unmap]_dma_buf functions.
It creates unnecessary overhead, so let's remove it.
Bug: 151775080
Bug: 170264063
Signed-off-by: Hyesoo Yu <hyesoo.yu@samsung.com>
Change-Id: I168117c7002aec7930c84168d15816a09750b7d8
Signed-off-by: Hridya Valsaraju <hridya@google.com>
(cherry picked from commit 2c3b4cba8ab38d7eb9f474c78f9b4c70867bf71d)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit 70c2ed5eefe64293a100a2c1c07445a708dde15c)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 4f71346c250416c3a6799458d773c4525a3d2ed6)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The [un]map_dma_buf receives dma_buf_attachment by
parameter. The caller could set the dma_map_attrs
on dma_buf_attachment such as DMA_ATTR_SKIP_CPU_SYNC,
and expects that attributes are applied.
The dma_[un]map_sg is changed into dma_[un]map_sg_attrs
to send the attributes.
Bug: 151775080
Bug: 170264063
Signed-off-by: Hyesoo Yu <hyesoo.yu@samsung.com>
Change-Id: Id5ca12ff120bfeac53a84ffad91e7a219e2180cd
(cherry picked from commit 16ce0bda52c9948d52e5676359b6cade2662580f)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit da654356c8bfdd9420eb8a2ec1b60da034fb10b2)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit e53e099e2a849be6cf171d2d3c56715b415e3fc1)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Export the ion_query_heaps_kernel to allow the module
to get the registered heap information.
Bug: 149961819
Bug: 170264063
Signed-off-by: Hyesoo Yu <hyesoo.yu@samsung.com>
Change-Id: I3756ef0cbd17611593c8d2f45e46476a864faaec
(cherry picked from commit 62060692112ba17dff2757dfcb7f9d40d1cc0016)
Signed-off-by: J. Avila <elavila@google.com>
(cherry picked from commit d19d2506e5a9aad1001a6b8e49c2ddbf9f7204cd)
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 021629f579df13eece231b5c8ace30f0a5c150d5)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Adds the necessary SuperSpeed Plus support for f_accessory.
[Not upstream as this file is not upstream.]
Bug: 170925797
Signed-off-by: taehyun.cho <taehyun.cho@samsung.com>
Change-Id: Ia2a5f4a6cefac2418f8f29bf1a56355b96d80fc0
(cherry picked from commit 00572be28ec474d7953f1b9dd681cc2dd290d9bf)
[willmcvicker: only cherry-pick f_accessory from original patch]
Signed-off-by: Will McVicker <willmcvicker@google.com>
(cherry picked from commit 4d7ced0819d3f30acbde46991393249049cefa05)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add CONFIG_PSTORE_PMSG for last logcat support.
Bug: 171852252
Signed-off-by: Jonglin Lee <jonglin@google.com>
Change-Id: I3b130886a2223598700a2da45c70932b11a174d8
(cherry picked from commit 6c412f5b2c4dfce5c607b6535f09281fd27b238d)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Userspace leverages the transient trigger for vibrators.
Signed-off-by: Harpreet Eli Sangha <eliptus@google.com>
Change-Id: Iff727bb955c690f0e195efd476fa9801678d49b8
(cherry picked from commit b01bffe951bf7376a6c661ede682e7c7709f78cd)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Thread ID and CPU ID is useful to distinguish printk
callers from different threads/cpus. Enable config
to prepend the information to printk statements.
Bug: 171425082
Bug: 170888438
Signed-off-by: Jonglin Lee <jonglin@google.com>
Change-Id: Ia5b3396971c689618ae8235b9c75a9f8d07774f2
(cherry picked from commit db79bb68e2955f8d3974823e6a6391934bfd443d)
Signed-off-by: Will McVicker <willmcvicker@google.com>
Pull media fixes from Mauro Carvalho Chehab:
- a rand Kconfig fixup for mtk-vcodec
- a fix at h264 handling at cedrus codec driver
- some warning fixes when config PM is not enabled at marvell-ccic
- two fixes at venus codec driver: one related to codec profile and the
other one related to a bad error path which causes an OOPS on module
re-bind
* tag 'media/v5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
media: venus: pm_helpers: Fix kernel module reload
media: venus: venc: Fix setting of profile and level
media: cedrus: h264: Fix check for presence of scaling matrix
media: media/platform/marvell-ccic: fix warnings when CONFIG_PM is not enabled
media: mtk-vcodec: fix build breakage when one of VPU or SCP is enabled
media: mtk-vcodec: move firmware implementations into their own files
The following patches are now queued in f2fs/dev for 5.11, but
android-mainline and android12-5.4 have an old version of them:
libfs: Add generic function for setting dentry_ops
fscrypt: Have filesystems handle their d_ops
f2fs: Handle casefolding with Encryption
Get them up-to-date.
Link: https://lore.kernel.org/linux-f2fs-devel/20201119060904.463807-1-drosen@google.com
Bug: 161184936
Test: kvm-xfstests -c f2fs/default,f2fs/encrypt -g casefold
Change-Id: I359bf4f23631c1b8175de8d5f12d0787fd7f42bd
Signed-off-by: Eric Biggers <ebiggers@google.com>
Pull cifs fixes from Steve French:
"Four smb3 fixes for stable: one fixes a memleak, the other three
address a problem found with decryption offload that can cause a use
after free"
* tag '5.10-rc5-smb3-fixes' of git://git.samba.org/sfrench/cifs-2.6:
smb3: Handle error case during offload read path
smb3: Avoid Mid pending list corruption
smb3: Call cifs reconnect from demultiplex thread
cifs: fix a memleak with modefromsid
Twice now, when exercising ext4 looped on shmem huge pages, I have crashed
on the PF_ONLY_HEAD check inside PageWaiters(): ext4_finish_bio() calling
end_page_writeback() calling wake_up_page() on tail of a shmem huge page,
no longer an ext4 page at all.
The problem is that PageWriteback is not accompanied by a page reference
(as the NOTE at the end of test_clear_page_writeback() acknowledges): as
soon as TestClearPageWriteback has been done, that page could be removed
from page cache, freed, and reused for something else by the time that
wake_up_page() is reached.
https://lore.kernel.org/linux-mm/20200827122019.GC14765@casper.infradead.org/
Matthew Wilcox suggested avoiding or weakening the PageWaiters() tail
check; but I'm paranoid about even looking at an unreferenced struct page,
lest its memory might itself have already been reused or hotremoved (and
wake_up_page_bit() may modify that memory with its ClearPageWaiters()).
Then on crashing a second time, realized there's a stronger reason against
that approach. If my testing just occasionally crashes on that check,
when the page is reused for part of a compound page, wouldn't it be much
more common for the page to get reused as an order-0 page before reaching
wake_up_page()? And on rare occasions, might that reused page already be
marked PageWriteback by its new user, and already be waited upon? What
would that look like?
It would look like BUG_ON(PageWriteback) after wait_on_page_writeback()
in write_cache_pages() (though I have never seen that crash myself).
Matthew Wilcox explaining this to himself:
"page is allocated, added to page cache, dirtied, writeback starts,
--- thread A ---
filesystem calls end_page_writeback()
test_clear_page_writeback()
--- context switch to thread B ---
truncate_inode_pages_range() finds the page, it doesn't have writeback set,
we delete it from the page cache. Page gets reallocated, dirtied, writeback
starts again. Then we call write_cache_pages(), see
PageWriteback() set, call wait_on_page_writeback()
--- context switch back to thread A ---
wake_up_page(page, PG_writeback);
... thread B is woken, but because the wakeup was for the old use of
the page, PageWriteback is still set.
Devious"
And prior to 2a9127fcf2 ("mm: rewrite wait_on_page_bit_common() logic")
this would have been much less likely: before that, wake_page_function()'s
non-exclusive case would stop walking and not wake if it found Writeback
already set again; whereas now the non-exclusive case proceeds to wake.
I have not thought of a fix that does not add a little overhead: the
simplest fix is for end_page_writeback() to get_page() before calling
test_clear_page_writeback(), then put_page() after wake_up_page().
Was there a chance of missed wakeups before, since a page freed before
reaching wake_up_page() would have PageWaiters cleared? I think not,
because each waiter does hold a reference on the page. This bug comes
when the old use of the page, the one we do TestClearPageWriteback on,
had *no* waiters, so no additional page reference beyond the page cache
(and whoever racily freed it). The reuse of the page has a waiter
holding a reference, and its own PageWriteback set; but the belated
wake_up_page() has woken the reuse to hit that BUG_ON(PageWriteback).
Reported-by: syzbot+3622cea378100f45d59f@syzkaller.appspotmail.com
Reported-by: Qian Cai <cai@lca.pw>
Fixes: 2a9127fcf2 ("mm: rewrite wait_on_page_bit_common() logic")
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@vger.kernel.org # v5.8+
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull s390 fix from Heiko Carstens:
"Disable interrupts when restoring fpu and vector registers, otherwise
KVM guests might see corrupted register contents"
* tag 's390-5.10-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390: fix fpu restore in entry.S
Pull ARC fixes from Vineet Gupta:
"A couple more stack unwinder related fixes:
- More stack unwinding updates
- Misc minor fixes"
* tag 'arc-5.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARC: stack unwinding: reorganize how initial register state setup
ARC: stack unwinding: don't assume non-current task is sleeping
ARC: mm: fix spelling mistakes
ARC: bitops: Remove unecessary operation and value
Remove leftovers from previous rebase conflict.
This change doesn't affect the kernel functionality as it deletes
what already commented out but not removed by mistake.
Fixes: f37e05049b ("ANDROID: vfs: d_canonical_path for stacked FS")
Signed-off-by: Alessio Balsini <balsini@google.com>
Change-Id: Ic536b8ededb56833c17a5aacdd444d3a162a149d
While bringing in a change from older Kernel, commit 3adfd8e344
("ANDROID: sched: avoid placing RT threads on cores handling softirqs")
missed to add data type for cpu variable. Fix it by adding data type.
Bug: 168521633
Change-Id: I4cd3d0b68b5962004f295ce8d07546b2067bc728
Signed-off-by: Satya Durga Srinivasu Prabhala <satyap@codeaurora.org>
The following restrict vendor hooks are added. The vendor hook
can selectively opt in for the default scheduler behavior by not
modifying the done argument.
- android_rvh_sched_newidle_balance: For newly idle load balance.
- android_rvh_sched_nohz_balancer_kick: For deciding if an idle
CPU is woken up to do nohz balance or not.
- android_rvh_find_busiest_queue: For selecting the busiest runqueue
among the CPUs in the busiest group selected in find_busiest_group.
- android_rvh_migrate_queued_task: Vendor implementations may require
both source and destination CPUs runqueue locks to be held while
calling set_task_cpu() during a task migration. Add a hook when
a queued task is migration so that vendor implementation can detach
the task and call set_task_cpu() with both runqueue locks held.
Bug: 173661641
Change-Id: I6a09226081061b6433e4231359be252a0f28f04b
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Since commit db102bc6be ("ANDROID: GKI: Enable CONFIG_USB_XHCI_HCD")
android-mainline stopped booting on db845c, as the xhci modules
would fail to load (since its now built in functionality).
This patch resolves it by removing the USB_XHCI_HCD and
XHCI_PCI_RENESAS config options from the config fragment.
Fixes: db102bc6be ("ANDROID: GKI: Enable CONFIG_USB_XHCI_HCD")
Signed-off-by: John Stultz <john.stultz@linaro.org>
Change-Id: I2d10bd4af490e1ce13466e53f82c66d8bcac2d09
Some tasks, such as those related to audio, can be placed onto cores
which are too small to support them, leading to performance hits. Fix
this by having the sync wakeup path honor capacity.
Bug: 166278821
Signed-off-by: J. Avila <elavila@google.com>
Change-Id: I5f7ef330f952c95f9391eb733ad241345477c943
There is a race condition when a write operation is blocked
waiting for an available request and the function is disabled
due to disconnection or reset. usb_ep_disable() is called from
acc_function_disable() and causes the UDC to call the pending
requests' completions, which will wake up the writer thread and
proceed to call usb_ep_queue() before the endpoint is fully
disabled. The UDC driver may not handle this and could allow
the request to be requeued inadvertently. In DWC3's case, this
allows the HW to attempt a transfer with stale TRBs that point
to invalid DMA buffers.
Let's ensure the function driver acts as a good citizen and handle
it by adding another check for (!dev->offline || dev->disconnected)
after the wait_event to make sure the endpoint is enabled before
attempting to queue another request.
Bug: 173774644
Change-Id: I1aa005e0c1e3ed1e1d814ff79496b70fdb401571
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Pull Hyper-V fix from Wei Liu:
"One patch from Dexuan to fix VRAM cache type in Hyper-V framebuffer
driver"
* tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
video: hyperv_fb: Fix the cache type when mapping the VRAM
QC value-add requires the ability to override the value displayed
by show_cpuinfo_max_freq.
Bug: 173984660
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Ida11256f399f0730bc1228524b9687df3e7b8bf4
In the context of the pKVM project we need to use KVM in nVHE mode, so
let's disable VHE in gki_defconfig.
Bug: 160383565
Signed-off-by: Quentin Perret <qperret@google.com>
Change-Id: I4c11977971a91baecdbe620e23b6ce7edae0afe0
It is needed for many UFS devices, so build it in so that devices can
boot properly :)
Bug: 162046707
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I3c8d57dafbf985533e7d5b0977aaa8155cc34cf3
GKI 1 had CONFIG_USB_TYPEC and CONFIG_USB_TYPEC_TCPM enabled, but forgot
to enable the _UCSI driver as well. Do that now as everyone relies on
this class driver.
If platform-specific TYPEC changes are needed, just enable the
platform-specific tyepc driver for the specific platform.
Note, for some reason x86 forgot to enable TYPEC entirely, so fix that
up and enable it here so we catch build issues sooner.
Bug: 157965270
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I353eec6ed4f73525408033f283081b8013ede874
Platforms are using this, so enable the driver for all to use easier.
Bug: 157965270
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5a1a6b1231c51148810389c26bc53d734f5c1ca2
A bunch of HID config options are recommented to be =y in the default
android configuration, and vendors are using them, so enable them in the
GKI kernels as well to reduce the abi footprint.
The options enabled are:
CONFIG_HID_WACOM
CONFIG_HID_LOGITECH
CONFIG_HID_LOGITECH_DJ
CONFIG_HID_ROCCAT
CONFIG_HID_PRODIKEYS
CONFIG_HID_PICOLCD
CONFIG_HID_UCLOGIC
CONFIG_HID_WIIMOTE
Bug: 157965270
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Idc8eae67ec81b5dd925c09db2f3600633c55d0c4
Almost all systems support the USB XHCI controller these days, so build
it into the kernel so that everyone can share the same codebase.
If platform-specific XHCI changes are needed, do it in a
platform-specific XHCI driver using the provided api for that.
Bug: 157965270
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6e8b5d1fbcde86415f43d942aad0f828ab346928
We need to disable interrupts in load_fpu_regs(). Otherwise an
interrupt might come in after the registers are loaded, but before
CIF_FPU is cleared in load_fpu_regs(). When the interrupt returns,
CIF_FPU will be cleared and the registers will never be restored.
The entry.S code usually saves the interrupt state in __SF_EMPTY on the
stack when disabling/restoring interrupts. sie64a however saves the pointer
to the sie control block in __SF_SIE_CONTROL, which references the same
location. This is non-obvious to the reader. To avoid thrashing the sie
control block pointer in load_fpu_regs(), move the __SIE_* offsets eight
bytes after __SF_EMPTY on the stack.
Cc: <stable@vger.kernel.org> # 5.8
Fixes: 0b0ed657fe ("s390: remove critical section cleanup from entry.S")
Reported-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Sven Schnelle <svens@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
