- 20 Nov, 2019 40 commits
-
-
Jia-Ju Bai authored
[ Upstream commit 8d11eb84 ] The driver may sleep in a interrupt handler. The function call paths (from bottom to top) in Linux-4.16 are: [FUNC] kzalloc(GFP_KERNEL) drivers/media/pci/ivtv/ivtv-yuv.c, 938: kzalloc in ivtv_yuv_init drivers/media/pci/ivtv/ivtv-yuv.c, 960: ivtv_yuv_init in ivtv_yuv_next_free drivers/media/pci/ivtv/ivtv-yuv.c, 1126: ivtv_yuv_next_free in ivtv_yuv_setup_stream_frame drivers/media/pci/ivtv/ivtv-irq.c, 827: ivtv_yuv_setup_stream_frame in ivtv_irq_dec_data_req drivers/media/pci/ivtv/ivtv-irq.c, 1013: ivtv_irq_dec_data_req in ivtv_irq_handler To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool DSAC. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Arnd Bergmann authored
[ Upstream commit 8d1a4817 ] A warning that I thought to be solved by a previous patch of mine has resurfaced with gcc-8: media/imx/imx-media-csi.c: In function 'csi_link_validate': media/imx/imx-media-csi.c:1025:20: error: 'upstream_ep' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c:1026:24: error: 'upstream_ep.bus_type' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c:127:19: error: 'upstream_ep.bus.parallel.bus_width' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c: In function 'csi_enum_mbus_code': media/imx/imx-media-csi.c:132:9: error: '*((void *)&upstream_ep+12)' may be used uninitialized in this function [-Werror=maybe-uninitialized] media/imx/imx-media-csi.c:132:48: error: 'upstream_ep.bus.parallel.bus_width' may be used uninitialized in this function [-Werror=maybe-uninitialized] I spent some more time digging in this time, and think I have a better fix, bailing out of the function that either initializes or errors out here, which simplifies the code enough for gcc to figure out what is going on. The earlier partial workaround can be removed now, as the new workaround is better. Fixes: 890f2769 ("media: imx: work around false-positive warning") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Petr Machata authored
[ Upstream commit 12ba7e10 ] Up until now, mlxsw tolerated firmware versions that weren't exactly matching the required version, if the branch number matched. That allowed the users to test various firmware versions as long as they were on the right branch. On the other hand, it made it impossible for mlxsw to put a hard lower bound on a version that fixes all problems known to date. If a user had a somewhat older FW version installed, mlxsw would start up just fine, possibly performing non-optimally as it would use features that trigger problematic behavior. Therefore tweak the check to accept any FW version that is: - on the same branch as the preferred version, and - the same as or newer than the preferred version. Signed-off-by:
Petr Machata <petrm@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Vicente Bergas authored
[ Upstream commit 88a20edf ] The microSD card slot in the Sapphire board is not working because of several issues: 1.- The vmmc power supply is missing in the DTS. It is capable of 3.0V and has a GPIO-based enable control. 2.- The vqmmc power supply can provide up to 3.3V, but it is capped in the DTS to just 3.0V because of the vmmc capability. This results in a conflict from the mmc driver requesting an unsupportable voltage range from 3.3V to 3.0V (min > max) as reported in dmesg. So, extend the range up to 3.3V. The hw should be able to stand this 0.3V tolerance. See mmc_regulator_set_vqmmc in drivers/mmc/core/core.c. 3.- The card detect signal is non-working. There is a known conflict with jtag, but the workaround in drivers/soc/rockchip/grf.c does not work. Adding the broken-cd attribute to the DTS fixes the issue. Signed-off-by:
Vicente Bergas <vicencb@gmail.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Dengcheng Zhu authored
[ Upstream commit a6da4d6f ] We can rely on the system kernel and the dump capture kernel themselves in memory usage. Being restrictive with 512MB limit may cause kexec tool failure on some platforms. Tested-by:
Rachel Mozes <rachel.mozes@intel.com> Reported-by:
Dengcheng Zhu <dzhu@wavecomp.com> Signed-off-by:
Paul Burton <paul.burton@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/20568/ Cc: pburton@wavecomp.com Cc: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Signed-off-by:
-
Qiuxu Zhuo authored
[ Upstream commit 6f6da136 ] The {i3200|i7core|sb|skx}_edac drivers show DIMM capacity using the wrong unit symbol: 'Mb' - megabit. Fix them by replacing 'Mb' with 'MiB' - mebibyte. [Tony: These are all "edac_dbg()" messages, so this won't break scripts that parse console logs.] Signed-off-by:
Qiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Aristeu Rozanski <aris@redhat.com> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-edac@vger.kernel.org Link: https://lkml.kernel.org/r/20180919003433.16475-1-tony.luck@intel.comSigned-off-by:
-
Matthew Whitehead authored
[ Upstream commit 2893cc8f ] Presently we check first if CPUID is enabled. If it is not already enabled, then we next call identify_cpu_without_cpuid() and clear X86_FEATURE_CPUID. Unfortunately, identify_cpu_without_cpuid() is the function where CPUID becomes _enabled_ on Cyrix 6x86/6x86L CPUs. Reverse the calling sequence so that CPUID is first enabled, and then check a second time to see if the feature has now been activated. [ bp: Massage commit message and remove trailing whitespace. ] Suggested-by:
Andy Lutomirski <luto@amacapital.net> Signed-off-by:
Matthew Whitehead <tedheadster@gmail.com> Signed-off-by:
-
Matthew Whitehead authored
[ Upstream commit 03b099bd ] There are comments in processor-cyrix.h advising you to _not_ make calls using the deprecated macros in this style: setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80); This is because it expands the macro into a non-functioning calling sequence. The calling order must be: outb(CX86_CCR2, 0x22); inb(0x23); From the comments: * When using the old macros a line like * setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88); * gets expanded to: * do { * outb((CX86_CCR2), 0x22); * outb((({ * outb((CX86_CCR2), 0x22); * inb(0x23); * }) | 0x88), 0x23); * } while (0); The new macros fix this problem, so use them instead. Signed-off-by:
-
YueHaibing authored
[ Upstream commit 06983aa5 ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 2b49117a ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit b78ac6ec ] Allow the configuration of the MDIO clock divider when the Device Tree contains 'clock-frequency' property (similar to I2C and SPI buses). Because the hardware may have lost its state during suspend/resume, re-apply the MDIO clock divider upon resumption. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Prashant Bhole authored
[ Upstream commit 32c00979 ] following commit: commit d58e468b ("flow_dissector: implements flow dissector BPF hook") added struct bpf_flow_keys which conflicts with the struct with same name in sockex2_kern.c and sockex3_kern.c similar to commit: commit 534e0e52 ("samples/bpf: fix a compilation failure") we tried the rename it "flow_keys" but it also conflicted with struct having same name in include/net/flow_dissector.h. Hence renaming the struct to "flow_key_record". Also, this commit doesn't fix the compilation error completely because the similar struct is present in sockex3_kern.c. Hence renaming it in both files sockex3_user.c and sockex3_kern.c Signed-off-by:
Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Acked-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Keith Busch authored
[ Upstream commit c4eed62a ] The secondary bus reset may have link side effects that a hotplug capable port may incorrectly react to. Use the slot specific reset for hotplug ports, fixing the undesirable link down-up handling during error recovering. Signed-off-by:
Keith Busch <keith.busch@intel.com> [bhelgaas: fold in https://lore.kernel.org/linux-pci/20180926152326.14821-1-keith.busch@intel.com for issue reported by Stephen Rothwell <sfr@canb.auug.org.au>] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Sinan Kaya <okaya@kernel.org> Signed-off-by:
-
Keith Busch authored
[ Upstream commit 9d938ea5 ] The AER driver has never read the config space of an endpoint that reported a fatal error because the link to that device is considered unreliable. An ERR_FATAL from an upstream port almost certainly indicates an error on its upstream link, so we can't expect to reliably read its config space for the same reason. Signed-off-by:
-
Keith Busch authored
[ Upstream commit 60271ab0 ] Error handling may be running in parallel with a hot removal. Reference count the device during AER handling so the device can not be freed while AER wants to reference it. Signed-off-by:
-
Shahed Shaikh authored
[ Upstream commit 75a110a1 ] This is a workaround for FW bug - MFW generates bandwidth attention in single function mode, which is only expected to be generated in multi function mode. This undesired attention in SF mode results in incorrect HW configuration and resulting into Tx timeout. Signed-off-by:
Shahed Shaikh <Shahed.Shaikh@cavium.com> Signed-off-by:
Ariel Elior <ariel.elior@cavium.com> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 1ba23b1d ] SPI controller nodes should be named 'spi' rather than 'qspi'. Fixing the name enables dtc SPI bus checks. Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by:
-
Baruch Siach authored
[ Upstream commit e807f029 ] The vmmc phandle, like all power supply property names, must have the '-supply' suffix. Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by:
-
Yannick Fertré authored
[ Upstream commit 67330599 ] Enable panel raydium RM68200, DSI bridge & display controller. Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Signed-off-by:
-
Borislav Petkov authored
[ Upstream commit 7401a633 ] Clear the MCE struct which is used for collecting the injection details after injection. Also, populate it with more details from the machine. Signed-off-by:
-
Rob Herring authored
[ Upstream commit cf680cc5 ] dtc has new checks for I2C and SPI buses. Fix the warnings in node names and unit-addresses. arch/arm/boot/dts/dove-cubox.dtb: Warning (i2c_bus_reg): /i2c-mux/i2c@0/clock-generator: I2C bus unit address format error, expected "60" arch/arm/boot/dts/dove-cubox-es.dtb: Warning (i2c_bus_reg): /i2c-mux/i2c@0/clock-generator: I2C bus unit address format error, expected "60" arch/arm/boot/dts/dove-cubox.dtb: Warning (spi_bus_bridge): /mbus/internal-regs/spi-ctrl@10600: node name for SPI buses should be 'spi' arch/arm/boot/dts/dove-cubox-es.dtb: Warning (spi_bus_bridge): /mbus/internal-regs/spi-ctrl@10600: node name for SPI buses should be 'spi' arch/arm/boot/dts/dove-dove-db.dtb: Warning (spi_bus_bridge): /mbus/internal-regs/spi-ctrl@10600: node name for SPI buses should be 'spi' arch/arm/boot/dts/dove-sbc-a510.dtb: Warning (spi_bus_bridge): /mbus/internal-regs/spi-ctrl@10600: node name for SPI buses should be 'spi' arch/arm/boot/dts/dove-sbc-a510.dtb: Warning (spi_bus_bridge): /mbus/internal-regs/spi-ctrl@14600: node name for SPI buses should be 'spi' arch/arm/boot/dts/orion5x-kuroboxpro.dtb: Warning (i2c_bus_reg): /soc/internal-regs/i2c@11000/rtc: I2C bus unit address format error, expected "32" arch/arm/boot/dts/orion5x-linkstation-lschl.dtb: Warning (i2c_bus_reg): /soc/internal-regs/i2c@11000/rtc: I2C bus unit address format error, expected "32" arch/arm/boot/dts/orion5x-linkstation-lsgl.dtb: Warning (i2c_bus_reg): /soc/internal-regs/i2c@11000/rtc: I2C bus unit address format error, expected "32" arch/arm/boot/dts/orion5x-linkstation-lswtgl.dtb: Warning (i2c_bus_reg): /soc/internal-regs/i2c@11000/rtc: I2C bus unit address format error, expected "32" Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Gregory Clement <gregory.clement@bootlin.com> Signed-off-by:
-
Stefan Agner authored
[ Upstream commit cd560235 ] The table id (second) argument to MODULE_DEVICE_TABLE is often referenced otherwise. This is not the case for CPU features. This leads to a warning when building the kernel with Clang: arch/arm/crypto/crc32-ce-glue.c:239:33: warning: variable 'crc32_cpu_feature' is not needed and will not be emitted [-Wunneeded-internal-declaration] static const struct cpu_feature crc32_cpu_feature[] = { ^ Avoid warnings by using __maybe_unused, similar to commit 1f318a8b ("modules: mark __inittest/__exittest as __maybe_unused"). Fixes: 2a9faf8b ("crypto: arm/crc32 - enable module autoloading based on CPU feature bits") Signed-off-by:
Stefan Agner <stefan@agner.ch> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Stefan Agner authored
[ Upstream commit c785896b ] The table id (second) argument to MODULE_DEVICE_TABLE is often referenced otherwise. This is not the case for CPU features. This leads to warnings when building the kernel with Clang: arch/arm/crypto/aes-ce-glue.c:450:1: warning: variable 'cpu_feature_match_AES' is not needed and will not be emitted [-Wunneeded-internal-declaration] module_cpu_feature_match(AES, aes_init); ^ Avoid warnings by using __maybe_unused, similar to commit 1f318a8b ("modules: mark __inittest/__exittest as __maybe_unused"). Fixes: 67bad2fd ("cpu: add generic support for CPU feature based module autoloading") Signed-off-by:
-
Eric Biggers authored
[ Upstream commit a5e9f557 ] In commit 9f480fae ("crypto: chacha20 - Fix keystream alignment for chacha20_block()"), I had missed that chacha20_block() can be called directly on the buffer passed to get_random_bytes(), which can have any alignment. So, while my commit didn't break anything, it didn't fully solve the alignment problems. Revert my solution and just update chacha20_block() to use put_unaligned_le32(), so the output buffer need not be aligned. This is simpler, and on many CPUs it's the same speed. But, I kept the 'tmp' buffers in extract_crng_user() and _get_random_bytes() 4-byte aligned, since that alignment is actually needed for _crng_backtrack_protect() too. Reported-by:
Stephan Müller <smueller@chronox.de> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Nathan Chancellor authored
[ Upstream commit 8cfde784 ] Clang warns when one enumerated type is converted implicitly to another: drivers/spi/spi-pic32.c:323:8: warning: implicit conversion from enumeration type 'enum dma_data_direction' to different enumeration type 'enum dma_transfer_direction' [-Wenum-conversion] DMA_FROM_DEVICE, ^~~~~~~~~~~~~~~ drivers/spi/spi-pic32.c:333:8: warning: implicit conversion from enumeration type 'enum dma_data_direction' to different enumeration type 'enum dma_transfer_direction' [-Wenum-conversion] DMA_TO_DEVICE, ^~~~~~~~~~~~~ 2 warnings generated. Use the proper enums from dma_transfer_direction (DMA_FROM_DEVICE = DMA_DEV_TO_MEM = 2, DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1) to satify Clang. Link: https://github.com/ClangBuiltLinux/linux/issues/159Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 2f967f9e ] SPI controller nodes should be named 'spi' rather than 'ssp'. Fixing the name enables dtc SPI bus checks. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit ecde2956 ] The "lcdaclk_b_1" group is muxed with the function "lcd" but needs a separate entry to be muxed in with "lcda" rather than "lcd". Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 2f217d24 ] The unit address of the Cortex-A9 SCU device node contains one zero too many. Remove it. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Chao Yu authored
[ Upstream commit dc4cd125 ] Step to reproduce this bug: 1. logon as root 2. mount -t f2fs /dev/sdd /mnt; 3. touch /mnt/file; 4. chown system /mnt/file; chgrp system /mnt/file; 5. xfs_io -f /mnt/file -c "fsync"; 6. godown /mnt; 7. umount /mnt; 8. mount -t f2fs /dev/sdd /mnt; After step 8) we will expect file's uid/gid are all system, but during recovery, these two fields were not been recovered, fix it. Signed-off-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
Jaegeuk Kim authored
[ Upstream commit f84262b0 ] If we have an error in f2fs_build_free_nids, we're able to fall into a loop to find free nids. Suggested-by:
Chao Yu <chao@kernel.org> Reviewed-by:
-
Rob Herring authored
[ Upstream commit cc893871 ] dtc has new checks for I2C and SPI buses. Fix the warnings in node names and unit-addresses. arch/arm/boot/dts/am437x-idk-evm.dtb: Warning (spi_bus_bridge): /ocp@44000000/qspi@47900000: node name for SPI buses should be 'spi' arch/arm/boot/dts/am437x-sk-evm.dtb: Warning (spi_bus_bridge): /ocp@44000000/qspi@47900000: node name for SPI buses should be 'spi' arch/arm/boot/dts/am43x-epos-evm.dtb: Warning (spi_bus_bridge): /ocp@44000000/qspi@47900000: node name for SPI buses should be 'spi' arch/arm/boot/dts/omap3-n9.dtb: Warning (i2c_bus_reg): /ocp@68000000/i2c@48060000/ak8975@0f: I2C bus unit address format error, expected "f" arch/arm/boot/dts/am335x-osd3358-sm-red.dtb: Warning (i2c_bus_reg): /ocp/i2c@44e0b000/pressure@78: I2C bus unit address format error, expected "76" arch/arm/boot/dts/am335x-boneblack.dtb: Warning (i2c_bus_reg): /ocp/i2c@44e0b000/tda19988: I2C bus unit address format error, expected "70" arch/arm/boot/dts/am335x-boneblack-wireless.dtb: Warning (i2c_bus_reg): /ocp/i2c@44e0b000/tda19988: I2C bus unit address format error, expected "70" arch/arm/boot/dts/am335x-sancloud-bbe.dtb: Warning (i2c_bus_reg): /ocp/i2c@44e0b000/tda19988: I2C bus unit address format error, expected "70" arch/arm/boot/dts/am571x-idk.dtb: Warning (spi_bus_bridge): /ocp/qspi@4b300000: node name for SPI buses should be 'spi' arch/arm/boot/dts/am572x-idk.dtb: Warning (spi_bus_bridge): /ocp/qspi@4b300000: node name for SPI buses should be 'spi' arch/arm/boot/dts/am574x-idk.dtb: Warning (spi_bus_bridge): /ocp/qspi@4b300000: node name for SPI buses should be 'spi' arch/arm/boot/dts/am57xx-cl-som-am57x.dtb: Warning (spi_bus_bridge): /ocp/qspi@4b300000: node name for SPI buses should be 'spi' arch/arm/boot/dts/am57xx-sbc-am57x.dtb: Warning (spi_bus_bridge): /ocp/qspi@4b300000: node name for SPI buses should be 'spi' arch/arm/boot/dts/dra72-evm.dtb: Warning (spi_bus_bridge): /ocp/qspi@4b300000: node name for SPI buses should be 'spi' arch/arm/boot/dts/dra72-evm-revc.dtb: Warning (spi_bus_bridge): /ocp/qspi@4b300000: node name for SPI buses should be 'spi' arch/arm/boot/dts/dra76-evm.dtb: Warning (spi_bus_bridge): /ocp/qspi@4b300000: node name for SPI buses should be 'spi' arch/arm/boot/dts/dra7-evm.dtb: Warning (spi_bus_bridge): /ocp/qspi@4b300000: node name for SPI buses should be 'spi' arch/arm/boot/dts/am335x-pdu001.dtb: Warning (spi_bus_reg): /ocp/spi@481a0000/cfaf240320a032t: SPI bus unit address format error, expected "0" arch/arm/boot/dts/keystone-k2g-evm.dtb: Warning (spi_bus_bridge): /soc@0/qspi@2940000: node name for SPI buses should be 'spi' arch/arm/boot/dts/keystone-k2g-ice.dtb: Warning (spi_bus_bridge): /soc@0/qspi@2940000: node name for SPI buses should be 'spi' Cc: "Benoît Cousson" <bcousson@baylibre.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Santosh Shilimkar <ssantosh@kernel.org> Cc: linux-omap@vger.kernel.org Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Grygorii Strashko authored
[ Upstream commit dcbf6b18 ] am335x-evm has only one CPSW external port physically wired, but DT defines 2 ext. ports. As result, PHY connection failure reported for the second ext. port. Update DT to reflect am335x-evm board HW configuration, and, while here, switch to use phy-handle instead of phy_id. Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Keith Busch authored
[ Upstream commit c29de841 ] The PCI port driver saves the PCI state after initializing the device with the applicable service devices. This was, however, before the service drivers were even registered because PCI probe happens before the device_initcall initialized those service drivers. The config space state that the services set up were not being saved. The end result would cause PCI devices to not react to events that the drivers think they did if the PCI state ever needed to be restored. Fix this by changing the service drivers from using the init calls to having the portdrv driver calling the services directly. This will get the state saved as desired, while making the relationship between the port driver and the services under it more explicit in the code. Signed-off-by:
-
Petr Machata authored
[ Upstream commit a9f36656 ] With introduction of MC-aware mode to mlxsw, it became necessary to configure TCs above 7 as well. There is now code in mlxsw to disable ETS for these higher classes, but disablement of max shaper was neglected. By default, max shaper is currently disabled to begin with, so the problem is just cosmetic. However, for symmetry, do like we do for ETS configuration, and call mlxsw_sp_port_ets_maxrate_set() for both TC i and i + 8. Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 6c3efbe7 ] The ucode chunk might be relatively large and the allocation with kmalloc() may fail occasionally. Since the data isn't DMA-transferred but by manual loops, we can use vmalloc instead of kmalloc. For a better performance, though, kvmalloc() would be the best choice in such a case, so let's replace with it. Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103431Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Arend van Spriel authored
[ Upstream commit 59c2a30d ] When obtaining the firmware capability a buffer is provided of 512 bytes. However, if all features in firmware are supported the buffer needs to be 565 bytes as otherwise truncated information is retrieved from firmware. Increasing the buffer to 768 bytes on stack. Reviewed-by:
Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Signed-off-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Vasily Gorbik authored
[ Upstream commit 26f4414a ] Correct stack frame overhead for 31-bit vdso, which should be 96 rather then 160. This is done by reusing STACK_FRAME_OVERHEAD definition which contains correct value based on build flags. This fixes stack unwinding within vdso code for 31-bit processes. While at it replace all hard coded stack frame overhead values with the same definition in vdso64 as well. Reviewed-by:
Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Vasily Gorbik authored
[ Upstream commit d1befa65 ] vdso_fault used is_compat_task function (on s390 it tests "current" thread_info flags) to distinguish compat tasks and map 31-bit vdso pages. But "current" task might not correspond to mm context. When 31-bit compat inferior is executed under gdb, gdb does PTRACE_PEEKTEXT on vdso page, causing vdso_fault with "current" being 64-bit gdb process. So, 31-bit inferior ends up with 64-bit vdso mapped. To avoid this problem a new compat_mm flag has been introduced into mm context. This flag is used in vdso_fault and vdso_mremap instead of is_compat_task. Signed-off-by:
-
Halil Pasic authored
[ Upstream commit 1c472d46 ] The AP bus scan is aborted before doing anything worth mentioning if ap_select_domain() fails, e.g. if the ap_rights.aqm mask is all zeros. As the result of this the ap bus fails to manage (e.g. create and register) devices like it is supposed to. Let us make ap_scan_bus() work even if ap_select_domain() can't select a default domain. Let's also make ap_select_domain() return void, as there are no more callers interested in its return value. Signed-off-by:
Halil Pasic <pasic@linux.ibm.com> Reported-by:
Michael Mueller <mimu@linux.ibm.com> Fixes: 7e0bdbe5 "s390/zcrypt: AP bus support for alternate driver(s)" [freude@linux.ibm.com: title and patch header slightly modified] Signed-off-by:
Harald Freudenberger <freude@linux.ibm.com> Signed-off-by:
-
Guido Kiener authored
[ Upstream commit 0e59088e ] Add parameter 'tag' to function usbtmc_ioctl_abort_bulk_out_tag() for future versions. Use USBTMC_BUFSIZE (4k) instead of USBTMC_SIZE_IOBUFFER (2k). Using USBTMC_SIZE_IOBUFFER is deprecated. Insert a sleep of 50 ms between subsequent CHECK_ABORT_BULK_OUT_STATUS control requests to avoid stressing the instrument with repeated requests. Use common macro USB_CTRL_GET_TIMEOUT instead of USBTMC_TIMEOUT. Signed-off-by:
Guido Kiener <guido.kiener@rohde-schwarz.com> Reviewed-by:
Steve Bayless <steve_bayless@keysight.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
