Srujana Challa says:
====================
Add Support for Marvell OcteonTX2 Cryptographic
This patchset adds support for CPT in OcteonTX2 admin function(AF).
CPT is a cryptographic accelerator unit and it includes microcoded
Giga Cipher engines.
OcteonTX2 SOC's resource virtualization unit (RVU) supports multiple
physical and virtual functions. Each of the PF/VF's functionality is
determined by what kind of resources are attached to it. When the CPT
block is attached to a VF, it can function as a security device.
The following document provides an overview of the hardware and
different drivers for the OcteonTX2 SOC:
https://www.kernel.org/doc/Documentation/networking/device_drivers/marvell/octeontx2.rst
This patch series includes:
- Patch to update existing Marvell sources to support CPT.
- Patch that adds mailbox messages to the admin function (AF) driver,
to configure CPT HW registers.
- Patch to provide debug information about CPT.
====================
Link: https://lore.kernel.org/r/20201118114416.28307-1-schalla@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
On OcteonTX2 SoC, the admin function (AF) is the only one with all
priviliges to configure HW and alloc resources, PFs and it's VFs
have to request AF via mailbox for all their needs. This patch adds
a mailbox interface for CPT PFs and VFs to allocate resources
for cryptography. It also adds hardware CPT AF register defines.
Signed-off-by: Suheil Chandran <schandran@marvell.com>
Signed-off-by: Lukasz Bartosik <lbartosik@marvell.com>
Signed-off-by: Srujana Challa <schalla@marvell.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
On OcteonTX2 platform CPT instruction enqueue and NIX
packet send are only possible via LMTST operations which
uses LDEOR instruction. This patch moves lmt flush
function from OcteonTX2 nic driver to include/linux/soc
since it will be used by OcteonTX2 CPT and NIC driver for
LMTST.
Signed-off-by: Suheil Chandran <schandran@marvell.com>
Signed-off-by: Srujana Challa <schalla@marvell.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Performance analysis counters are maintained under the MLX4_EN_PERF_STAT
definition, which is never set.
Clean them up, with all related structures and logic.
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Link: https://lore.kernel.org/r/20201118103427.4314-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If there is only one keyslot, then blk_ksm_init() computes
slot_hashtable_size=1 and log_slot_ht_size=0. This causes
blk_ksm_find_keyslot() to crash later because it uses
hash_ptr(key, log_slot_ht_size) to find the hash bucket containing the
key, and hash_ptr() doesn't support the bits == 0 case.
Fix this by making the hash table always have at least 2 buckets.
Tested by running:
kvm-xfstests -c ext4 -g encrypt -m inlinecrypt \
-o blk-crypto-fallback.num_keyslots=1
Fixes: 1b26283970 ("block: Keyslot Manager for Inline Encryption")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The default IMA template used for all policy rules is the value set
for CONFIG_IMA_DEFAULT_TEMPLATE if the policy rule does not specify
a template. The default IMA template for buffer measurements should be
'ima-buf' - so that the measured buffer is correctly included in the IMA
measurement log entry.
With the default template format, buffer measurements are added to
the measurement list, but do not include the buffer data, making it
difficult, if not impossible, to validate. Including 'ima-buf'
template records in the measurement list by default, should not impact
existing attestation servers without 'ima-buf' template support.
Initialize a global 'ima-buf' template and select that template,
by default, for buffer measurements.
Signed-off-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
PCIe r6.0, sec 7.5.3.18, defines a new 64.0 GT/s bit in the Supported Link
Speeds Vector of Link Capabilities 2.
This patch does not affect the speed of the link, which should be
negotiated automatically by the hardware; it only adds decoding when
showing the speed to the user.
Decode this new speed. Previously, reading the speed of a link operating
at this speed showed "Unknown speed" instead of "64.0 GT/s".
Link: https://lore.kernel.org/r/aaaab33fe18975e123a84aebce2adb85f44e2bbe.1605739760.git.gustavo.pimentel@synopsys.com
Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRTLbB6QfY48x44uB6AXGG7T9hjvgUCX7dYpAAKCRCAXGG7T9hj
vqRpAQDiOASJZyPTwbB3kW7EPIyMz5kZgeJUyX4BEBUOR0g3CAEA/Qz9ZE9h9h3l
YIXs9LDGQJ0pOl04wOzjte57AjzGoAM=
=B9Bu
-----END PGP SIGNATURE-----
Merge tag 'for-linus-5.10b-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen fix from Juergen Gross:
"A single fix for avoiding WARN splats when booting a Xen guest with
nosmt"
* tag 'for-linus-5.10b-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
x86/xen: don't unbind uninitialized lock_kicker_irq
In case when tcp socket received FIN after some data and the
parser haven't started before reading data caller will receive
an empty buffer. This behavior differs from plain TCP socket and
leads to special treating in user-space.
The flow that triggers the race is simple. Server sends small
amount of data right after the connection is configured to use TLS
and closes the connection. In this case receiver sees TLS Handshake
data, configures TLS socket right after Change Cipher Spec record.
While the configuration is in process, TCP socket receives small
Application Data record, Encrypted Alert record and FIN packet. So
the TCP socket changes sk_shutdown to RCV_SHUTDOWN and sk_flag with
SK_DONE bit set. The received data is not parsed upon arrival and is
never sent to user-space.
Patch unpauses parser directly if we have unparsed data in tcp
receive queue.
Fixes: fcf4793e27 ("tls: check RCV_SHUTDOWN in tls_wait_data")
Signed-off-by: Vadim Fedorenko <vfedorenko@novek.ru>
Link: https://lore.kernel.org/r/1605801588-12236-1-git-send-email-vfedorenko@novek.ru
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
- Fix boot when intel iommu initialisation fails under TXT (tboot)
- Fix intel iommu compilation error when DMAR is enabled without ATS
- Temporarily update IOMMU MAINTAINERs entry
-----BEGIN PGP SIGNATURE-----
iQFEBAABCgAuFiEEPxTL6PPUbjXGY88ct6xw3ITBYzQFAl+3p6gQHHdpbGxAa2Vy
bmVsLm9yZwAKCRC3rHDchMFjNPowCADBKq5PBRwqIM1tmntRu5rePf/WuB1BotlJ
cUUR8dIxFDvKMeGvN4mDbn/5jjL1+TlD7sQqFh+gcWJ9tImpAMzp1ENbg71isl5o
Ej21X9YhjfiIsKpTrNGxcetCkYaR2tp8Z4/WzSQaO+IGB578dQ9VwiwSnDyFdWUb
1Qcj712ainYvKjbq4NyL80lPm9v43OV8QZ73WeelzBjE2UcDFAV0Xl4BIX8uuGtv
I1x03JfgzmzhVBmpj5HUGPsSopMDdo5K4vlcqscqSqvBY90iHD5fgRF4ZatTjR1t
PVM/1+c9vdJIWSxSt1hsB8DPtqXVOvGjzrLW/h63rxyWsISwkAq0
=DNX/
-----END PGP SIGNATURE-----
Merge tag 'iommu-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull iommu fixes from Will Deacon:
"Two straightforward vt-d fixes:
- Fix boot when intel iommu initialisation fails under TXT (tboot)
- Fix intel iommu compilation error when DMAR is enabled without ATS
and temporarily update IOMMU MAINTAINERs entry"
* tag 'iommu-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
MAINTAINERS: Temporarily add myself to the IOMMU entry
iommu/vt-d: Fix compile error with CONFIG_PCI_ATS not set
iommu/vt-d: Avoid panic if iommu init fails in tboot system
While allmodconfig and allyesconfig build for s390 there are also
various bots running compile tests with randconfig, where PCI is
disabled. This reveals that a lot of drivers should actually depend on
HAS_IOMEM.
Adding this to each device driver would be a never ending story,
therefore just disable COMPILE_TEST for s390.
The reasoning is more or less the same as described in
commit bc083a64b6 ("init/Kconfig: make COMPILE_TEST depend on !UML").
Reported-by: kernel test robot <lkp@intel.com>
Suggested-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Rename some variable and functions to better clarify
what they are and what they do.
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Instead of creating the sysfs attributes for the stp root_dev by hand,
pass them to subsys_system_register() as parameter.
This also ensures that the attributes are available when the KOBJ_ADD
event is raised.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Add kernel command line and last breaking event.
The kernel command line is taken from early_command_line and printed
only if kernel is not running as protected virtualization guest and
if it has been already initialized from the "COMMAND_LINE".
Linux version 5.10.0-rc3-22794-gecaa72788df0-dirty (gor@tuxmaker) #28 SMP PREEMPT Mon Nov 9 17:41:20 CET 2020
Kernel command line: audit_enable=0 audit=0 selinux=0 crashkernel=296M root=/dev/dasda1 dasd=ec5b
memblock=debug die
Kernel fault: interruption code 0005 ilc:2
PSW : 0000000180000000 0000000000012f92 (parse_boot_command_line+0x27a/0x46c)
R:0 T:0 IO:0 EX:0 Key:0 M:0 W:0 P:0 AS:0 CC:0 PM:0 RI:0 EA:3
GPRS: 0000000000000000 00ffffffffffffff 0000000000000000 000000000001a65c
000000000000bf60 0000000000000000 00000000000003c0 0000000000000000
0000000000000080 000000000002322d 000000007f29ef20 0000000000efd018
000000000311c000 0000000000010070 0000000000012f82 000000000000bea8
Call Trace:
(sp:000000000000bea8 [<000000000002016e>] 000000000002016e)
sp:000000000000bf18 [<0000000000012408>] startup_kernel+0x88/0x2fc
sp:000000000000bf60 [<00000000000100c4>] startup_normal+0xb0/0xb0
Last Breaking-Event-Address:
[<00000000000135ba>] strcmp+0x22/0x24
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Acked-by: Viktor Mihajlovski <mihajlov@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Information printed by print_pgm_check_info() is crucial for
debugging decompressor problems. Printing instruction addresses is
better than nothing, but turns further debugging into tedious job of
figuring out which function those addresses correspond to.
This change adds simplistic symbols resolution support. And adds %pS
format specifier support to decompressor_printk().
Decompressor symbols list is extracted and sorted with
nm -n -S:
...
0000000000010000 0000000000000014 T startup
0000000000010014 00000000000000b0 t startup_normal
0000000000010180 00000000000000b2 t startup_kdump
...
Then functions are filtered and contracted to a form:
"10000 14 startup\0""10014 b0 startup_normal\0""10180 b2 startup_kdump\0"
...
Which makes it trivial to find beginning of an entry and names are 0
terminated, so could be used as is. Symbols are binary-searched.
To get symbols list with final addresses and then get it into the
decompressor's image the same trick as for kallsyms is used.
Decompressor's vmlinux is linked twice.
Symbols are stored in .decompressor.syms section, current size is about
2kb.
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Use SYM_CODE_* annotations for asm functions, so that function lengths
are recognized correctly.
Also currently the most part of startup is marked as startup_kdump. Move
misplaced startup_kdump where it belongs.
$ nm -n -S arch/s390/boot/compressed/vmlinux
Before:
0000000000010000 T startup
0000000000010010 T startup_kdump
After:
0000000000010000 0000000000000014 T startup
0000000000010014 00000000000000b0 t startup_normal
0000000000010180 00000000000000b2 t startup_kdump
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
The decompressor does not have any special debug means. Running the
kernel under qemu with gdb is helpful but tedious exercise if done
repeatedly. It is also not applicable to debugging under LPAR and z/VM.
One special thing which stands out is a working sclp_early_printk,
which could be used once the kernel switches to 64-bit addressing mode.
But sclp_early_printk does not provide any string formating capabilities.
Formatting and printing string without printk-alike function is a
not fun. The lack of printk-alike function means people would save up on
testing and introduce more bugs.
So, finally, provide decompressor_printk function, which fits on one
screen and trades features for simplicity.
It only supports "%s", "%x" and "%lx" specifiers and zero padding for
hex values.
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Currently the kernel minimal compiler requirement is gcc 4.9 or
clang 10.0.1.
* gcc -mhotpatch option is supported since 4.8.
* A combination of -pg -mrecord-mcount -mnop-mcount -mfentry flags is
supported since gcc 9 and since clang 10.
Drop support for old -pg function prologues. Which leaves binary
compatible -mhotpatch / -mnop-mcount -mfentry prologues in a form:
brcl 0,0
Which are also do not require initial nop optimization / conversion and
presence of _mcount symbol.
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Currently we have to consider too many different values which
in the end only affect identity mapping size. These are:
1. max_physmem_end - end of physical memory online or standby.
Always <= end of the last online memory block (get_mem_detect_end()).
2. CONFIG_MAX_PHYSMEM_BITS - the maximum size of physical memory the
kernel is able to support.
3. "mem=" kernel command line option which limits physical memory usage.
4. OLDMEM_BASE which is a kdump memory limit when the kernel is executed as
crash kernel.
5. "hsa" size which is a memory limit when the kernel is executed during
zfcp/nvme dump.
Through out kernel startup and run we juggle all those values at once
but that does not bring any amusement, only confusion and complexity.
Unify all those values to a single one we should really care, that is
our identity mapping size.
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Instead of creating the sysfs attributes for the prng devices by hand,
describe them in .groups and let the misdevice core handle it.
This also ensures that the attributes are available when the KOBJ_ADD
event is raised.
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
System call and program check handler both use the system call exit
path when returning to previous context. However the program check
handler jumps right to the end of the system call exit path if the
previous context is kernel context.
This lead to the quite odd double disabling of interrupts in the
system call exit path introduced with commit ce9dfafe29 ("s390:
fix system call exit path").
To avoid that have a separate program check handler exit path if the
previous context is kernel context.
Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
- sdhci-of-arasan: Stabilize communication by fixing tap value configs
- sdhci-pci: Use SDR25 timing for HS mode for BYT-based Intel HWs
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAl+3nr8XHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCmbSQ//QkzuRoGDX9OuCorTF5FbesZk
5dKPjxPcZy+EbMPegEZkH8hIEpHWgiwnUt4UjN7TbxsPsdpEXzws+ChY1mvdID0o
K1Uj1bl4ngKHDiLgFChwoLvVPpbK9H0SMV4tosymBnhBpsVE4MfYSRd68ZP2EIXh
9YpP4SJYBfMqhPpvddqA4o4qzYLgAG5NhOTmsp1HvAE2nrDZ5UclrJRVzIu+zd0m
nGP9Jbh+ygGF3GpYOYgg6KawBe9MnTwThY7yBDt7K5Qad+WXvXQ/wJ23hfNs3+0a
S17uSF29Ymd8X6Na8mSjNvZIN2bsDjxj/yy1VnQRebQR0jzzbb0ebBSXpjNWJiZ7
xLj9YJLiNNEu7eFRp4/9zFI5r5y1VxqV8bAuuLIa0HMEdKEq6aia2JxLEznnD1TA
ZQZoe916UiEnMSVrkdu8rkg4hnzmAngc4DxJMrE4AeRInQevA0dLdwpma8Vn0cIb
HIEd9U5Oz83emM+ongQTW5EF1NhKuHqtxACmCNIFBMrZ/T9PT3Qgq4yhOSEx/GOg
+tegTFumlz8LduwQekMdEdUp8BDlVdRlsEvqg1A4CtXmZ2lFG2NCQVjJXNxMCT+E
Mh6+Pv8XojVPLBhkTh4WmE6MaOEwSdknzR+UJ2tKB5Pa7iyJT1nD4/T4jKp2/HNn
qgqO2W5LWuOn/oLaalI=
=kfSz
-----END PGP SIGNATURE-----
Merge tag 'mmc-v5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC fixes from Ulf Hansson:
"A couple of MMC fixes:
- sdhci-of-arasan: Stabilize communication by fixing tap value configs
- sdhci-pci: Use SDR25 timing for HS mode for BYT-based Intel HWs"
* tag 'mmc-v5.10-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: sdhci-of-arasan: Issue DLL reset explicitly
mmc: sdhci-of-arasan: Use Mask writes for Tap delays
mmc: sdhci-of-arasan: Allow configuring zero tap values
mmc: sdhci-pci: Prefer SDR25 timing for High Speed mode for BYT-based Intel controllers
Jump to init_err_release to cleanup. bnxt_unmap_bars() will also be
called but it will do nothing if the BARs are not mapped yet.
Fixes: c0c050c58d ("bnxt_en: New Broadcom ethernet driver.")
Reported-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Link: https://lore.kernel.org/r/1605858271-8209-1-git-send-email-michael.chan@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
rose_send_frame() dereferences `neigh->dev` when called from
rose_transmit_clear_request(), and the first occurrence of the
`neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
and it is initialized in rose_add_loopback_neigh() as NULL.
i.e when `rose_loopback_neigh` used in rose_loopback_timer()
its `->dev` was still NULL and rose_loopback_timer() was calling
rose_rx_call_request() without checking for NULL.
- net/rose/rose_link.c
This bug seems to get triggered in this line:
rose_call = (ax25_address *)neigh->dev->dev_addr;
Fix it by adding NULL checking for `rose_loopback_neigh->dev`
in rose_loopback_timer().
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Reported-by: syzbot+a1c743815982d9496393@syzkaller.appspotmail.com
Tested-by: syzbot+a1c743815982d9496393@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
Signed-off-by: Anmol Karn <anmol.karan123@gmail.com>
Link: https://lore.kernel.org/r/20201119191043.28813-1-anmol.karan123@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The static checker is fooled by the non-static locking scheme
implemented by the mentioned helpers.
Let's make its life easier adding some unconditional annotation
so that the helpers are now interpreted as a plain spinlock from
sparse.
v1 -> v2:
- add __releases() annotation to unlock_sock_fast()
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Link: https://lore.kernel.org/r/6ed7ae627d8271fb7f20e0a9c6750fbba1ac2635.1605634911.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Convert netsec driver to xdp_return_frame_bulk APIs.
Rely on xdp_return_frame_rx_napi for XDP_TX in order to try to recycle
the page in the "in-irq" page_pool cache.
Co-developed-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://lore.kernel.org/r/01487b8f5167d62649339469cdd0c6d8df885902.1605605531.git.lorenzo@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
A collection of small fixes: the only core change is a minor error
code handling in the control API, and all the rest are device-specific
fixes, mostly quirks, fixups and ASoC Intel fixes.
It looks boring, and good so.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl+2wKcOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE9ELBAAjjNoPsqs+Bw9AFORMch23vXXLiQscsz5FMWy
gWTDlyvVoYvjEhkQ+b2EWY61c63Un6gCWiSOJrDh6J1mou+I/8iJ2oGgpVV7DNNx
sRW6yaOYs+dpymIoCsYAJadxEdfaaAItoFL0y8/um/kRpOpLSXpNCBuwKMMYziXA
HPjOQQv9KuUoY2qXQTDJdIzznwwSmX/6B/IPzi0dtgZ8J04izOd5gFd9MVCTbNi6
kjxw1h5j1hdLiOIDUiomunHRnNfYoTdQwDcdCPi+JOU6hZHEBjyDwG3pPm/lVsJf
PsJJWUcEQrR8c17vxsXt2Dh+SlGJNqBUXhqTy+3cef6NUJ0U4FCGMW28zRWrf753
27tSdpxFh24ghvCfzsJAtki5XqJmpnp1xChHY1/9D1bz6FtmFbL5kykdg25jY0Fr
z4mkogWfc74GE3jYg+l7KbjNb4iV45u13hJ9bXXD8YVbLtLIJF20euwMJ5jGImOM
E+WCy73QKq0C+2w476pZLr3mnEUmXRheMhkwYuPjow7g+QGMs3ivLoku2kWOR4OY
Bhd6nClyfixadf0/W8LKVacS3h3HIOeyMm+qQo09zOlhoyPxW32K/ug06ugLOSPQ
0lD1H209yjBtIoTJcw00Q4hSe35+WwOPWoBpRZRWCiRksr7rH97KKmFdvII8wwTY
n2dxu8c=
=E7Lw
-----END PGP SIGNATURE-----
Merge tag 'sound-5.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of small fixes: the only core change is a minor error
code handling in the control API, and all the rest are device-specific
fixes, mostly quirks, fixups and ASoC Intel fixes.
It looks boring, and good so"
* tag 'sound-5.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: mixart: Fix mutex deadlock
ALSA: hda/ca0132: Fix compile warning without PCI
ASOC: Intel: kbl_rt5663_rt5514_max98927: Do not try to disable disabled clock
ALSA: usb-audio: Add delay quirk for all Logitech USB devices
ASoC: Intel: catpt: Correct clock selection for dai trigger
ASoC: Intel: catpt: Skip position update for unprepared streams
ASoC: qcom: lpass-platform: Fix memory leak
ASoC: Intel: KMB: Fix S24_LE configuration
ALSA: hda: Add Alderlake-S PCI ID and HDMI codec vid
ALSA: usb-audio: Use ALC1220-VB-DT mapping for ASUS ROG Strix TRX40 mobo
ALSA: firewire: Clean up a locking issue in copy_resp_to_buf()
ASoC: rt1015: increase the time to detect BCLK
ALSA: ctl: fix error path at adding user-defined element set
ALSA: hda/realtek - HP Headset Mic can't detect after boot
ALSA: hda/realtek - Add supported mute Led for HP
ALSA: hda/realtek: Add some Clove SSID in the ALC293(ALC1220)
ALSA: hda/realtek - Add supported for Lenovo ThinkPad Headset Button
ASoC: rt1015: add delay to fix pop noise from speaker
There is no easy way to distinguish if a conntracked tcp packet is
marked invalid because of tcp_in_window() check error or because
it doesn't belong to an existing connection. With this patch,
openvswitch sets liberal tcp flag for the established sessions so
that out of window packets are not marked invalid.
A helper function - nf_ct_set_tcp_be_liberal(nf_conn) is added which
sets this flag for both the directions of the nf_conn.
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Numan Siddique <nusiddiq@redhat.com>
Acked-by: Florian Westphal <fw@strlen.de>
Link: https://lore.kernel.org/r/20201116130126.3065077-1-nusiddiq@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
core:
- vram helper TTM regression fix
amdgpu:
- Pageflip fix for navi1x with 5 or 6 displays
- Remove experimental flag for Arcturus
- Fix regression in atomic commit tail rework
i915:
- Fix tgl power gating issue
- Memory leak fixes
- Selftest fixes
- Display bpc fix
- Fix TGL MOCS for PTE tracking
dw-hdmi:
- probing fix
sun4i:
- probing fix
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJftx+jAAoJEAx081l5xIa+iP0P+gJuMX12yISdXJ4u/VdZCEGO
SZ2taoqgpnYtd0SiYUgh436yNOB9KsZZLm/413k3vj4Rx+Dm7Fm9MfTu8cVn63pd
qS51CGwTGUOp3E+Zc94qqMWgQqg/oqSA9NeWy7Q/kOP5H2Ic3dBWyjiVUdzVlN55
V7X8ac6rsgOfvRq7f8QxWgEHf9WMM+890euFmTbc2/YK7bbdDZt5eckuJsf1rfuk
PJKUQHi2YmtaQoNb16ctOkCLmTeFjK626OpO4zFFDQxElCVSxNnC85CqV2gYUOI5
NqjBrLISDeHB6omBdDp8U08Los7y6j+0C6xL78ZV/OErEbb5h9TvdhOHgPDJS7uf
KN/LLcEE/S7gmmYcP6osA4bsBGXumHkR7VuctLwEOc2lXCF6eJs2zc1m69Yo68kD
z7+OkCPLZd4nZ2sJoBt4MhA+jGFb4pIyRTlBMDeJUo+i6Hn4eJeE7gJJNYRM6Ief
DVBgVQxS4qyN0HGf7QlgpnJhcZ1xW06t4yGPzMO1gCPOt+gzzP2d5KWF9hJaRSwX
foSkSwoiEXA6OjZb/uoKxAxbp+292P9au70L2y7mruvScyKBAhUOuNmuF4j9jZQ+
WkHE0YgGfMxbCYugnFizyiW7r9kDjYGUIOMFyron1T8n16CWfDuw5Ih7tAtcEtti
QWWRRyF0vZzuS22v2QPB
=ZJKB
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2020-11-20-2' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Weekly fixes pull.
This contains some fixes for sun4i/dw-hdmi probing, then amdgpu
enables arcturus hw without experimental flag and two other fixes and
a group of i915 fixes.
It also has a backported from next fix for the warn on reported in
ast/drm_gem_vram_helper code in the merge window. There's a separate
report which initially looked to be the same problem, but I'm going to
chase that up next week a bit more as I don't think the bisect landed
anywhere useful.
Summary:
core:
- vram helper TTM regression fix
amdgpu:
- Pageflip fix for navi1x with 5 or 6 displays
- Remove experimental flag for Arcturus
- Fix regression in atomic commit tail rework
i915:
- Fix tgl power gating issue
- Memory leak fixes
- Selftest fixes
- Display bpc fix
- Fix TGL MOCS for PTE tracking
dw-hdmi:
- probing fix
sun4i:
- probing fix"
* tag 'drm-fixes-2020-11-20-2' of git://anongit.freedesktop.org/drm/drm:
drm/i915/gt: Fixup tgl mocs for PTE tracking
drm/vram-helper: Fix use of top-down placement
drm/i915/gt: Remember to free the virtual breadcrumbs
drm/i915: Handle max_bpc==16
drm/amd/display: Always get CRTC updated constant values inside commit tail
drm/sun4i: backend: Fix probe failure with multiple backends
drm/sun4i: dw-hdmi: fix error return code in sun8i_dw_hdmi_bind()
drm/i915/selftests: Fix wrong return value of perf_request_latency()
drm/i915/selftests: Fix wrong return value of perf_series_engines()
drm/i915: Avoid memory leak with more than 16 workarounds on a list
drm/i915/tgl: Fix Media power gate sequence.
drm/amdgpu: remove experimental flag from arcturus
drm/amd/display: Add missing pflip irq for dcn2.0
drm/i915/gvt: return error when failing to take the module reference
drm: bridge: dw-hdmi: Avoid resetting force in the detect function
drm/i915/gvt: Set ENHANCED_FRAME_CAP bit
drm/i915/gvt: Temporarily disable vfio_edid for BXT/APL
Email from solarflare.com will stop working. Update the maintainers.
A replacement for linux-net-drivers@solarflare.com is not working yet,
for now remove it.
Signed-off-by: Martin Habets <mhabets@solarflare.com>
Signed-off-by: Edward Cree <ecree@solarflare.com>
Link: https://lore.kernel.org/r/20201120113207.GA1605547@mh-desktop
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Convert Renesas PCIe Host controller bindings documentation to
json-schema. Note that some compatible doesn't contain on
the original documentation so that incremental patches are required
for it.
Link: https://lore.kernel.org/r/1604455096-13923-2-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
I've discovered that due to the recent commit 49d7d695ca ("spi: dw:
Explicitly de-assert CS on SPI transfer completion") a concurrent usage of
the spidev devices with different chip-selects causes the "SPI transfer
timed out" error. The root cause of the problem has turned to be in a race
condition of the SPI-transfer execution procedure and the spi_setup()
method being called at the same time. In particular in calling the
spi_set_cs(false) while there is an SPI-transfer being executed. In my
case due to the commit cited above all CSs get to be switched off by
calling the spi_setup() for /dev/spidev0.1 while there is an concurrent
SPI-transfer execution performed on /dev/spidev0.0. Of course a situation
of the spi_setup() being called while there is an SPI-transfer being
executed for two different SPI peripheral devices of the same controller
may happen not only for the spidev driver, but for instance for MMC SPI +
some another device, or spi_setup() being called from an SPI-peripheral
probe method while some other device has already been probed and is being
used by a corresponding driver...
Of course I could have provided a fix affecting the DW APB SSI driver
only, for instance, by creating a mutual exclusive access to the set_cs
callback and setting/clearing only the bit responsible for the
corresponding chip-select. But after a short research I've discovered that
the problem most likely affects a lot of the other drivers:
- drivers/spi/spi-sun4i.c - RMW the chip-select register;
- drivers/spi/spi-rockchip.c - RMW the chip-select register;
- drivers/spi/spi-qup.c - RMW a generic force-CS flag in a CSR.
- drivers/spi/spi-sifive.c - set a generic CS-mode flag in a CSR.
- drivers/spi/spi-bcm63xx-hsspi.c - uses an internal mutex to serialize
the bus config changes, but still isn't protected from the race
condition described above;
- drivers/spi/spi-geni-qcom.c - RMW a chip-select internal flag and set the
CS state in HW;
- drivers/spi/spi-orion.c - RMW a chip-select register;
- drivers/spi/spi-cadence.c - RMW a chip-select register;
- drivers/spi/spi-armada-3700.c - RMW a chip-select register;
- drivers/spi/spi-lantiq-ssc.c - overwrites the chip-select register;
- drivers/spi/spi-sun6i.c - RMW a chip-select register;
- drivers/spi/spi-synquacer.c - RMW a chip-select register;
- drivers/spi/spi-altera.c - directly sets the chip-select state;
- drivers/spi/spi-omap2-mcspi.c - RMW an internally cached CS state and
writes it to HW;
- drivers/spi/spi-mt65xx.c - RMW some CSR;
- drivers/spi/spi-jcore.c - directly sets the chip-selects state;
- drivers/spi/spi-mt7621.c - RMW a chip-select register;
I could have missed some drivers, but a scale of the problem is obvious.
As you can see most of the drivers perform an unprotected
Read-modify-write chip-select register modification in the set_cs callback.
Seeing the spi_setup() function is calling the spi_set_cs() and it can be
executed concurrently with SPI-transfers exec procedure, which also calls
spi_set_cs() in the SPI core spi_transfer_one_message() method, the race
condition of the register modification turns to be obvious.
To sum up the problem denoted above affects each driver for a controller
having more than one chip-select lane and which:
1) performs the RMW to some CS-related register with no serialization;
2) directly disables any CS on spi_set_cs(dev, false).
* the later is the case of the DW APB SSI driver.
The controllers which equipped with a single CS theoretically can also
experience the problem, but in practice will not since normally the
spi_setup() isn't called concurrently with the SPI-transfers executed on
the same SPI peripheral device.
In order to generically fix the denoted bug I'd suggest to serialize an
access to the controller IO by taking the IO mutex in the spi_setup()
callback. The mutex is held while there is an SPI communication going on
on the SPI-bus of the corresponding SPI-controller. So calling the
spi_setup() method and disabling/updating the CS state within it would be
safe while there is no any SPI-transfers being executed. Also note I
suppose it would be safer to protect the spi_controller->setup() callback
invocation too, seeing some of the SPI-controller drivers update a HW
state in there.
Fixes: 49d7d695ca ("spi: dw: Explicitly de-assert CS on SPI transfer completion")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Link: https://lore.kernel.org/r/20201117094517.5654-1-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Previously ASPM L1 Substates control registers (CTL1 and CTL2) weren't
saved and restored during suspend/resume leading to L1 Substates
configuration being lost post-resume.
Save the L1 Substates control registers so that the configuration is
retained post-resume.
Link: https://lore.kernel.org/r/20201024190442.871-1-vidyas@nvidia.com
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The variable 'tmp' is used multiple times in the brcm_pcie_setup()
function. One such usage did not initialize 'tmp' to the current value
of the target register. By luck the mistake does not currently affect
behavior; regardless 'tmp' is now initialized properly.
Suggested-by: Rafał Miłecki <zajec5@gmail.com>
Link: https://lore.kernel.org/r/20201102205712.23332-1-james.quinlan@broadcom.com
Fixes: c045213703 ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver")
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Currently the GIC node in V3s DTSI follows some old DT examples, and
being broken. This leads a warning at boot.
Fix this.
Fixes: f989086ccb ("ARM: dts: sunxi: add dtsi file for V3s SoC")
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20201120050851.4123759-1-icenowy@aosc.io
Drop unused members dev and base from struct rcar_pcie_host.
Link: https://lore.kernel.org/r/20201023162008.967-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
A recent change to ndctl to attempt to reconfigure namespaces in place
uncovered a label accounting problem in block-window-type namespaces.
The ndctl "create.sh" test is able to trigger this signature:
WARNING: CPU: 34 PID: 9167 at drivers/nvdimm/label.c:1100 __blk_label_update+0x9a3/0xbc0 [libnvdimm]
[..]
RIP: 0010:__blk_label_update+0x9a3/0xbc0 [libnvdimm]
[..]
Call Trace:
uuid_store+0x21b/0x2f0 [libnvdimm]
kernfs_fop_write+0xcf/0x1c0
vfs_write+0xcc/0x380
ksys_write+0x68/0xe0
When allocated capacity for a namespace is renamed (new UUID) the labels
with the old UUID need to be deleted. The ndctl behavior to always
destroy namespaces on reconfiguration hid this problem.
The immediate impact of this bug is limited since block-window-type
namespaces only seem to exist in the specification and not in any
shipping products. However, the label handling code is being reused for
other technologies like CXL region labels, so there is a benefit to
making sure both vertical labels sets (block-window) and horizontal
label sets (pmem) have a functional reference implementation in
libnvdimm.
Fixes: c4703ce11c ("libnvdimm/namespace: Fix label tracking error")
Cc: <stable@vger.kernel.org>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
