summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-04-23soc: imx: gpc: fix power up sequencingLucas Stach1-11/+13
[ Upstream commit e0ea2d11f8a08ba7066ff897e16c5217215d1e68 ] Currently we wait only until the PGC inverts the isolation setting before disabling the peripheral clocks. This doesn't ensure that the reset is properly propagated through the peripheral devices in the power domain. Wait until the PGC signals that the power up request is done and wait a bit for resets to propagate before disabling the clocks. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23arm64: dts: marvell: Fix cpu compatible for AP807-quadAmit Kucheria1-4/+4
[ Upstream commit d136d2588b21b1a07515632ed61120c9f262909b ] make -k ARCH=arm64 dtbs_check shows the following errors. Fix them by removing the "arm,armv8" compatible. /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9130-db.dt.yaml: cpu@0: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9130-db.dt.yaml: cpu@0: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long CHECK arch/arm64/boot/dts/renesas/r8a774a1-hihope-rzg2m-ex.dt.yaml /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9130-db.dt.yaml: cpu@1: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9130-db.dt.yaml: cpu@1: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9130-db.dt.yaml: cpu@100: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9130-db.dt.yaml: cpu@100: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9130-db.dt.yaml: cpu@101: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9130-db.dt.yaml: cpu@101: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9131-db.dt.yaml: cpu@0: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9131-db.dt.yaml: cpu@0: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9131-db.dt.yaml: cpu@1: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9131-db.dt.yaml: cpu@1: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9131-db.dt.yaml: cpu@100: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9131-db.dt.yaml: cpu@100: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9131-db.dt.yaml: cpu@101: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9131-db.dt.yaml: cpu@101: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9132-db.dt.yaml: cpu@0: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9132-db.dt.yaml: cpu@0: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9132-db.dt.yaml: cpu@1: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9132-db.dt.yaml: cpu@1: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9132-db.dt.yaml: cpu@100: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9132-db.dt.yaml: cpu@100: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9132-db.dt.yaml: cpu@101: compatible: Additional items are not allowed ('arm,armv8' was unexpected) /home/amit/work/builds/build-check/arch/arm64/boot/dts/marvell/cn9132-db.dt.yaml: cpu@101: compatible: ['arm,cortex-a72', 'arm,armv8'] is too long Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23arm64: dts: clearfog-gt-8k: set gigabit PHY reset deassert delayRussell King1-0/+1
[ Upstream commit 46f94c7818e7ab82758fca74935ef3d454340b4e ] If the mv88e6xxx DSA driver is built as a module, it causes the ethernet driver to re-probe when it's loaded. This in turn causes the gigabit PHY to be momentarily reset and reprogrammed. However, we attempt to reprogram the PHY immediately after deasserting reset, and the PHY ignores the writes. This results in the PHY operating in the wrong mode, and the copper link states down. Set a reset deassert delay of 10ms for the gigabit PHY to avoid this. Fixes: babc5544c293 ("arm64: dts: clearfog-gt-8k: 1G eth PHY reset signal") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Acked-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23arm64: dts: marvell: espressobin: add ethernet aliasTomasz Maciej Nowak1-0/+6
[ Upstream commit 5253cb8c00a6f4356760efb38bca0e0393aa06de ] The maker of this board and its variants, stores MAC address in U-Boot environment. Add alias for bootloader to recognise, to which ethernet node inject the factory MAC address. Signed-off-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23xfs: fix regression in "cleanup xfs_dir2_block_getdents"Tommi Rantala1-5/+7
[ Upstream commit 3d28e7e278913a267b1de360efcd5e5274065ce2 ] Commit 263dde869bd09 ("xfs: cleanup xfs_dir2_block_getdents") introduced a getdents regression, when it converted the pointer arithmetics to offset calculations: offset is updated in the loop already for the next iteration, but the updated offset value is used incorrectly in two places, where we should have used the not-yet-updated value. This caused for example "git clean -ffdx" failures to cleanup certain directory structures when running in a container. Fix the regression by making sure we use proper offset in the loop body. Thanks to Christoph Hellwig for suggestion how to best fix the code. Cc: Christoph Hellwig <hch@lst.de> Fixes: 263dde869bd09 ("xfs: cleanup xfs_dir2_block_getdents") Signed-off-by: Tommi Rantala <tommi.t.rantala@nokia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23xfs: fix use-after-free when aborting corrupt attr inactivationDarrick J. Wong1-1/+1
[ Upstream commit 496b9bcd62b0b3a160be61e3265a086f97adcbd3 ] Log the corrupt buffer before we release the buffer. Fixes: a5155b870d687 ("xfs: always log corruption errors") Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23arm64: tegra: Fix Tegra194 PCIe compatible stringJon Hunter2-7/+7
[ Upstream commit f9f711efd441ad0d22874be49986d92121862335 ] If the kernel configuration option CONFIG_PCIE_DW_PLAT_HOST is enabled then this can cause the kernel to incorrectly probe the generic designware PCIe platform driver instead of the Tegra194 designware PCIe driver. This causes a boot failure on Tegra194 because the necessary configuration to access the hardware is not performed. The order in which the compatible strings are populated in Device-Tree is not relevant in this case, because the kernel will attempt to probe the device as soon as a driver is loaded and if the generic designware PCIe driver is loaded first, then this driver will be probed first. Therefore, to fix this problem, remove the "snps,dw-pcie" string from the compatible string as we never want this driver to be probe on Tegra194. Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23arm64: tegra: Add PCIe endpoint controllers nodes for Tegra194Vidya Sagar1-0/+99
[ Upstream commit 0c988b731e6430f0081991fdb4f63f7fc837df9a ] Add endpoint mode controllers nodes for the dual mode PCIe controllers present in Tegra194 SoC. Signed-off-by: Vidya Sagar <vidyas@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23clk: tegra: Fix Tegra PMC clock out parentsSowjanya Komatineni1-6/+6
[ Upstream commit 6fe38aa8cac3a5db38154331742835a4d9740788 ] Tegra PMC clocks clk_out_1, clk_out_2, and clk_out_3 supported parents are osc, osc_div2, osc_div4 and extern clock. Clock driver is using incorrect parents clk_m, clk_m_div2, clk_m_div4 for PMC clocks. This patch fixes this. Tested-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23power: supply: bq27xxx_battery: Silence deferred-probe errorDmitry Osipenko1-1/+4
[ Upstream commit 583b53ece0b0268c542a1eafadb62e3d4b0aab8c ] The driver fails to probe with -EPROBE_DEFER if battery's power supply (charger driver) isn't ready yet and this results in a bit noisy error message in KMSG during kernel's boot up. Let's silence the harmless error message. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Andrew F. Davis <afd@ti.com> Reviewed-by: Pali Rohár <pali@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23arm64: dts: allwinner: a64: Fix display clock register rangeJernej Skrabec1-1/+1
[ Upstream commit 3e9a1a8b7f811de3eb1445d72f68766b704ad17c ] Register range of display clocks is 0x10000, as it can be seen from DE2 documentation. Fix it. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Fixes: 2c796fc8f5dbd ("arm64: dts: allwinner: a64: add necessary device tree nodes for DE2 CCU") [wens@csie.org: added fixes tag] Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23memory: tegra: Correct debugfs clk rate-range on Tegra124Dmitry Osipenko1-0/+5
[ Upstream commit 141267bffd1dc19a76e4d50e3e4829f85a806875 ] Correctly set clk rate-range if number of available timings is zero. This fixes noisy "invalid range [4294967295, 0]" error messages during boot. Fixes: 6b9acd935546 ("memory: tegra: Refashion EMC debugfs interface on Tegra124") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23memory: tegra: Correct debugfs clk rate-range on Tegra30Dmitry Osipenko1-0/+5
[ Upstream commit a53670e1a734ba56fac84cf2b93b838bd4a6b835 ] Correctly set clk rate-range if number of available timings is zero. This fixes noisy "invalid range [4294967295, 0]" error messages during boot. Fixes: 8cee32b40040 ("memory: tegra: Implement EMC debugfs interface on Tegra30") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23memory: tegra: Correct debugfs clk rate-range on Tegra20Dmitry Osipenko1-0/+5
[ Upstream commit 2243af41115d0e36e6414df6dd2a0386e022d9f8 ] Correctly set clk rate-range if number of available timings is zero. This fixes noisy "invalid range [4294967295, 0]" error messages during boot. Fixes: 8209eefa3d37 ("memory: tegra: Implement EMC debugfs interface on Tegra20") Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23dmaengine: idxd: reflect shadow copy of traffic class programmingDave Jiang1-2/+2
[ Upstream commit a1fcaf07ec718bb1f11e29e952c9a4cb733d57a5 ] The traffic class are set to -1 at initialization until the user programs them. If the user choose not to, the driver will program appropriate defaults. The driver also needs to update the shadowed copies of the values after doing the programming. Fixes: c52ca478233c ("dmaengine: idxd: add configuration component of driver") Reported-by: Yixin Zhang <yixin.zhang@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/158386263076.10898.4586509576813094559.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23ARM: dts: rockchip: fix vqmmc-supply property name for rk3188-bqedison2qcJohan Jonker1-1/+1
[ Upstream commit 9cd568dc588c5d168615bf34f325fabe33b2c9a0 ] A test with the command below does not detect all errors in combination with 'additionalProperties: false' and allOf: - $ref: "synopsys-dw-mshc-common.yaml#" allOf: - $ref: "mmc-controller.yaml#" 'additionalProperties' applies to all properties that are not accounted-for by 'properties' or 'patternProperties' in the immediate schema. First when we combine rockchip-dw-mshc.yaml, synopsys-dw-mshc-common.yaml and mmc-controller.yaml it gives this error: arch/arm/boot/dts/rk3188-bqedison2qc.dt.yaml: mmc@10218000: 'vmmcq-supply' does not match any of the regexes: '^.*@[0-9]+$', '^clk-phase-(legacy|sd-hs|mmc-(hs|hs[24]00|ddr52)| uhs-(sdr(12|25|50|104)|ddr50))$', 'pinctrl-[0-9]+' 'vmmcq-supply' is not a valid property name for mmc nodes. Fix this error by renaming it to 'vqmmc-supply'. make ARCH=arm dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20200307134841.13803-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23f2fs: fix to avoid use-after-free in f2fs_write_multi_pages()Chao Yu1-1/+1
[ Upstream commit 95978caa138948054e06d00bfc3432b518699f1b ] In compress cluster, if physical block number is less than logic page number, race condition will cause use-after-free issue as described below: - f2fs_write_compressed_pages - fio.page = cic->rpages[0]; - f2fs_outplace_write_data - f2fs_compress_write_end_io - kfree(cic->rpages); - kfree(cic); - fio.page = cic->rpages[1]; f2fs_write_multi_pages+0xfd0/0x1a98 f2fs_write_data_pages+0x74c/0xb5c do_writepages+0x64/0x108 __writeback_single_inode+0xdc/0x4b8 writeback_sb_inodes+0x4d0/0xa68 __writeback_inodes_wb+0x88/0x178 wb_writeback+0x1f0/0x424 wb_workfn+0x2f4/0x574 process_one_work+0x210/0x48c worker_thread+0x2e8/0x44c kthread+0x110/0x120 ret_from_fork+0x10/0x18 Fixes: 4c8ff7095bef ("f2fs: support data compression") Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23f2fs: fix wrong check on F2FS_IOC_FSSETXATTRJaegeuk Kim1-5/+8
[ Upstream commit 99eabb914e0f870445d065e83e857507f9728a33 ] This fixes the incorrect failure when enabling project quota on casefold-enabled file. Cc: Daniel Rosenberg <drosen@google.com> Cc: kernel-team@android.com Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23xfs: fix iclog release error check race with shutdownBrian Foster1-4/+9
[ Upstream commit 6b789c337a5963ae57cbc7fe9e41488c40a9b014 ] Prior to commit df732b29c8 ("xfs: call xlog_state_release_iclog with l_icloglock held"), xlog_state_release_iclog() always performed a locked check of the iclog error state before proceeding into the sync state processing code. As of this commit, part of xlog_state_release_iclog() was open-coded into xfs_log_release_iclog() and as a result the locked error state check was lost. The lockless check still exists, but this doesn't account for the possibility of a race with a shutdown being performed by another task causing the iclog state to change while the original task waits on ->l_icloglock. This has reproduced very rarely via generic/475 and manifests as an assert failure in __xlog_state_release_iclog() due to an unexpected iclog state. Restore the locked error state check in xlog_state_release_iclog() to ensure that an iclog state update via shutdown doesn't race with the iclog release state processing code. Fixes: df732b29c807 ("xfs: call xlog_state_release_iclog with l_icloglock held") Reported-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23bpf: Reliably preserve btf_trace_xxx typesAndrii Nakryiko1-7/+11
[ Upstream commit 441420a1f0b3031f228453697406c86f110e59d4 ] btf_trace_xxx types, crucial for tp_btf BPF programs (raw tracepoint with verifier-checked direct memory access), have to be preserved in kernel BTF to allow verifier do its job and enforce type/memory safety. It was reported ([0]) that for kernels built with Clang current type-casting approach doesn't preserve these types. This patch fixes it by declaring an anonymous union for each registered tracepoint, capturing both struct bpf_raw_event_map information, as well as recording btf_trace_##call type reliably. Structurally, it's still the same content as for a plain struct bpf_raw_event_map, so no other changes are necessary. [0] https://github.com/iovisor/bcc/issues/2770#issuecomment-591007692 Fixes: e8c423fb31fa ("bpf: Add typecast to raw_tracepoints to help BTF generation") Reported-by: Wenbo Zhang <ethercflow@gmail.com> Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20200301081045.3491005-2-andriin@fb.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23f2fs: fix the panic in do_checkpoint()Sahitya Tummala3-11/+9
[ Upstream commit bf22c3cc8ce71454dddd772284773306a68031d8 ] There could be a scenario where f2fs_sync_meta_pages() will not ensure that all F2FS_DIRTY_META pages are submitted for IO. Thus, resulting in the below panic in do_checkpoint() - f2fs_bug_on(sbi, get_pages(sbi, F2FS_DIRTY_META) && !f2fs_cp_error(sbi)); This can happen in a low-memory condition, where shrinker could also be doing the writepage operation (stack shown below) at the same time when checkpoint is running on another core. schedule down_write f2fs_submit_page_write -> by this time, this page in page cache is tagged as PAGECACHE_TAG_WRITEBACK and PAGECACHE_TAG_DIRTY is cleared, due to which f2fs_sync_meta_pages() cannot sync this page in do_checkpoint() path. f2fs_do_write_meta_page __f2fs_write_meta_page f2fs_write_meta_page shrink_page_list shrink_inactive_list shrink_node_memcg shrink_node kswapd Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23f2fs: fix to avoid potential deadlockChao Yu1-3/+3
[ Upstream commit df77fbd8c5b222c680444801ffd20e8bbc90a56e ] Using f2fs_trylock_op() in f2fs_write_compressed_pages() to avoid potential deadlock like we did in f2fs_write_single_data_page(). Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23s390/crypto: explicitly memzero stack key material in aes_s390.cTorsten Duwe1-0/+3
[ Upstream commit 4a559cd15dbc79958fa9b18ad4e8afe4a0bf4744 ] aes_s390.c has several functions which allocate space for key material on the stack and leave the used keys there. It is considered good practice to clean these locations before the function returns. Link: https://lkml.kernel.org/r/20200221165511.GB6928@lst.de Signed-off-by: Torsten Duwe <duwe@suse.de> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23net/mlx5e: Enforce setting of a single FEC modeAya Levin1-0/+4
[ Upstream commit 4bd9d5070b92da012f2715cf8e4859acb78b8f35 ] Ethtool command allow setting of several FEC modes in a single set command. The driver can only set a single FEC mode at a time. With this patch driver will reply not-supported on setting several FEC modes. Signed-off-by: Aya Levin <ayal@mellanox.com> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23crypto: qce - use cryptlen when adding extra sglEneas U de Queiroz3-8/+10
[ Upstream commit d6364b8128439a8c0e381f80c38667de9f15eef8 ] The qce crypto driver appends an extra entry to the dst sgl, to maintain private state information. When the gcm driver sends requests to the ctr skcipher, it passes the authentication tag after the actual crypto payload, but it must not be touched. Commit 1336c2221bee ("crypto: qce - save a sg table slot for result buf") limited the destination sgl to avoid overwriting the authentication tag but it assumed the tag would be in a separate sgl entry. This is not always the case, so it is better to limit the length of the destination buffer to req->cryptlen before appending the result buf. Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23clk: imx: pll14xx: Add new frequency entries for pll1443x tableAnson Huang1-0/+2
[ Upstream commit 57795654fb553a78f07a9f92d87fb2582379cd93 ] Add new frequency entries to pll1443x table to meet different display settings requirement. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23clk: at91: usb: continue if clk_hw_round_rate() return zeroClaudiu Beznea1-0/+3
[ Upstream commit b0ecf1c6c6e82da4847900fad0272abfd014666d ] clk_hw_round_rate() may call round rate function of its parents. In case of SAM9X60 two of USB parrents are PLLA and UPLL. These clocks are controlled by clk-sam9x60-pll.c driver. The round rate function for this driver is sam9x60_pll_round_rate() which call in turn sam9x60_pll_get_best_div_mul(). In case the requested rate is not in the proper range (rate < characteristics->output[0].min && rate > characteristics->output[0].max) the sam9x60_pll_round_rate() will return a negative number to its caller (called by clk_core_round_rate_nolock()). clk_hw_round_rate() will return zero in case a negative number is returned by clk_core_round_rate_nolock(). With this, the USB clock will continue its rate computation even caller of clk_hw_round_rate() returned an error. With this, the USB clock on SAM9X60 may not chose the best parent. I detected this after a suspend/resume cycle on SAM9X60. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lkml.kernel.org/r/1579261009-4573-2-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23clk: Don't cache errors from clk_ops::get_phase()Stephen Boyd1-16/+32
[ Upstream commit f21cf9c77ee82ef8adfeb2143adfacf21ec1d5cc ] We don't check for errors from clk_ops::get_phase() before storing away the result into the clk_core::phase member. This can lead to some fairly confusing debugfs information if these ops do return an error. Let's skip the store when this op fails to fix this. While we're here, move the locking outside of clk_core_get_phase() to simplify callers from the debugfs side. Cc: Douglas Anderson <dianders@chromium.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lkml.kernel.org/r/20200205232802.29184-2-sboyd@kernel.org Acked-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23gfs2: clear ail1 list when gfs2 withdrawsBob Peterson1-4/+13
[ Upstream commit 30fe70a85a909a23dcbc2c628ca6655b2c85e7a1 ] This patch fixes a bug in which function gfs2_log_flush can get into an infinite loop when a gfs2 file system is withdrawn. The problem is the infinite loop "for (;;)" in gfs2_log_flush which would never finish because the io error and subsequent withdraw prevented the items from being taken off the ail list. This patch tries to clean up the mess by allowing withdraw situations to move not-in-flight buffer_heads to the ail2 list, where they will be dealt with later. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23drm/ttm: flush the fence on the bo after we individualize the reservation objectxinhui pan1-1/+3
[ Upstream commit 1bbcf69e42fe7fd49b6f4339c970729d0e343753 ] As we move the ttm_bo_individualize_resv() upwards, we need flush the copied fence too. Otherwise the driver keeps waiting for fence. run&Kill kfdtest, then perf top. 25.53% [ttm] [k] ttm_bo_delayed_delete 24.29% [kernel] [k] dma_resv_test_signaled_rcu 19.72% [kernel] [k] ww_mutex_lock Fix: 378e2d5b("drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more") Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/series/72339/ Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-23block, bfq: invoke flush_idle_tree after reparent_active_queues in pd_offlinePaolo Valente1-7/+13
commit 4d38a87fbb77fb9ff2ff4e914162a8ae6453eff5 upstream. In bfq_pd_offline(), the function bfq_flush_idle_tree() is invoked to flush the rb tree that contains all idle entities belonging to the pd (cgroup) being destroyed. In particular, bfq_flush_idle_tree() is invoked before bfq_reparent_active_queues(). Yet the latter may happen to add some entities to the idle tree. It happens if, in some of the calls to bfq_bfqq_move() performed by bfq_reparent_active_queues(), the queue to move is empty and gets expired. This commit simply reverses the invocation order between bfq_flush_idle_tree() and bfq_reparent_active_queues(). Tested-by: cki-project@redhat.com Signed-off-by: Paolo Valente <paolo.valente@linaro.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23block, bfq: make reparent_leaf_entity actually work only on leaf entitiesPaolo Valente1-17/+31
commit 576682fa52cbd95deb3773449566274f206acc58 upstream. bfq_reparent_leaf_entity() reparents the input leaf entity (a leaf entity represents just a bfq_queue in an entity tree). Yet, the input entity is guaranteed to always be a leaf entity only in two-level entity trees. In this respect, because of the error fixed by commit 14afc5936197 ("block, bfq: fix overwrite of bfq_group pointer in bfq_find_set_group()"), all (wrongly collapsed) entity trees happened to actually have only two levels. After the latter commit, this does not hold any longer. This commit fixes this problem by modifying bfq_reparent_leaf_entity(), so that it searches an active leaf entity down the path that stems from the input entity. Such a leaf entity is guaranteed to exist when bfq_reparent_leaf_entity() is invoked. Tested-by: cki-project@redhat.com Signed-off-by: Paolo Valente <paolo.valente@linaro.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23block, bfq: turn put_queue into release_process_ref in __bfq_bic_change_cgroupPaolo Valente3-6/+2
commit c8997736650060594845e42c5d01d3118aec8d25 upstream. A bfq_put_queue() may be invoked in __bfq_bic_change_cgroup(). The goal of this put is to release a process reference to a bfq_queue. But process-reference releases may trigger also some extra operation, and, to this goal, are handled through bfq_release_process_ref(). So, turn the invocation of bfq_put_queue() into an invocation of bfq_release_process_ref(). Tested-by: cki-project@redhat.com Signed-off-by: Paolo Valente <paolo.valente@linaro.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23afs: Fix race between post-modification dir edit and readdir/d_revalidateDavid Howells2-35/+76
commit 2105c2820d366b76f38e6ad61c75771881ecc532 upstream. AFS directories are retained locally as a structured file, with lookup being effected by a local search of the file contents. When a modification (such as mkdir) happens, the dir file content is modified locally rather than redownloading the directory. The directory contents are accessed in a number of ways, with a number of different locks schemes: (1) Download of contents - dvnode->validate_lock/write in afs_read_dir(). (2) Lookup and readdir - dvnode->validate_lock/read in afs_dir_iterate(), downgrading from (1) if necessary. (3) d_revalidate of child dentry - dvnode->validate_lock/read in afs_do_lookup_one() downgrading from (1) if necessary. (4) Edit of dir after modification - page locks on individual dir pages. Unfortunately, because (4) uses different locking scheme to (1) - (3), nothing protects against the page being scanned whilst the edit is underway. Even download is not safe as it doesn't lock the pages - relying instead on the validate_lock to serialise as a whole (the theory being that directory contents are treated as a block and always downloaded as a block). Fix this by write-locking dvnode->validate_lock around the edits. Care must be taken in the rename case as there may be two different dirs - but they need not be locked at the same time. In any case, once the lock is taken, the directory version must be rechecked, and the edit skipped if a later version has been downloaded by revalidation (there can't have been any local changes because the VFS holds the inode lock, but there can have been remote changes). Fixes: 63a4681ff39c ("afs: Locally edit directory data for mkdir/create/unlink/...") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23afs: Fix afs_d_validate() to set the right directory versionDavid Howells1-3/+3
commit 40fc81027f892284ce31f8b6de1e497f5b47e71f upstream. If a dentry's version is somewhere between invalid_before and the current directory version, we should be setting it forward to the current version, not backwards to the invalid_before version. Note that we're only doing this at all because dentry::d_fsdata isn't large enough on a 32-bit system. Fix this by using a separate variable for invalid_before so that we don't accidentally clobber the current dir version. Fixes: a4ff7401fbfa ("afs: Keep track of invalid-before version for dentry coherency") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23afs: Fix rename operation status deliveryDavid Howells3-21/+12
commit b98f0ec91c42d87a70da42726b852ac8d78a3257 upstream. The afs_deliver_fs_rename() and yfs_deliver_fs_rename() functions both only decode the second file status returned unless the parent directories are different - unfortunately, this means that the xdr pointer isn't advanced and the volsync record will be read incorrectly in such an instance. Fix this by always decoding the second status into the second status/callback block which wasn't being used if the dirs were the same. The afs_update_dentry_version() calls that update the directory data version numbers on the dentries can then unconditionally use the second status record as this will always reflect the state of the destination dir (the two records will be identical if the destination dir is the same as the source dir) Fixes: 260a980317da ("[AFS]: Add "directory write" support.") Fixes: 30062bd13e36 ("afs: Implement YFS support in the fs client") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23afs: Fix decoding of inline abort codes from version 1 status recordsDavid Howells1-0/+1
commit 3e0d9892c0e7fa426ca6bf921cb4b543ca265714 upstream. If we're decoding an AFSFetchStatus record and we see that the version is 1 and the abort code is set and we're expecting inline errors, then we store the abort code and ignore the remaining status record (which is correct), but we don't set the flag to say we got a valid abort code. This can affect operation of YFS.RemoveFile2 when removing a file and the operation of {,Y}FS.InlineBulkStatus when prospectively constructing or updating of a set of inodes during a lookup. Fix this to indicate the reception of a valid abort code. Fixes: a38a75581e6e ("afs: Fix unlink to handle YFS.RemoveFile2 better") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23afs: Fix missing XDR advance in xdr_decode_{AFS,YFS}FSFetchStatus()David Howells2-9/+17
commit c72057b56f7e24865840a6961d801a7f21d30a5f upstream. If we receive a status record that has VNOVNODE set in the abort field, xdr_decode_AFSFetchStatus() and xdr_decode_YFSFetchStatus() don't advance the XDR pointer, thereby corrupting anything subsequent decodes from the same block of data. This has the potential to affect AFS.InlineBulkStatus and YFS.InlineBulkStatus operation, but probably doesn't since the status records are extracted as individual blocks of data and the buffer pointer is reset between blocks. It does affect YFS.RemoveFile2 operation, corrupting the volsync record - though that is not currently used. Other operations abort the entire operation rather than returning an error inline, in which case there is no decoding to be done. Fix this by unconditionally advancing the xdr pointer. Fixes: 684b0f68cf1c ("afs: Fix AFSFetchStatus decoder to provide OpenAFS compatibility") Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23x86/Hyper-V: Report crash data in die() when panic_on_oops is setTianyu Lan3-4/+9
commit f3a99e761efa616028b255b4de58e9b5b87c5545 upstream. When oops happens with panic_on_oops unset, the oops thread is killed by die() and system continues to run. In such case, guest should not report crash register data to host since system still runs. Check panic_on_oops and return directly in hyperv_report_panic() when the function is called in the die() and panic_on_oops is unset. Fix it. Fixes: 7ed4325a44ea ("Drivers: hv: vmbus: Make panic reporting to be more useful") Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Link: https://lore.kernel.org/r/20200406155331.2105-7-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23x86/Hyper-V: Report crash register data when sysctl_record_panic_msg is not setTianyu Lan1-9/+14
commit 040026df7088c56ccbad28f7042308f67bde63df upstream. When sysctl_record_panic_msg is not set, the panic will not be reported to Hyper-V via hyperv_report_panic_msg(). So the crash should be reported via hyperv_report_panic(). Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com> Link: https://lore.kernel.org/r/20200406155331.2105-6-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23x86/Hyper-V: Report crash register data or kmsg before running crash kernelTianyu Lan1-0/+10
commit a11589563e96bf262767294b89b25a9d44e7303b upstream. We want to notify Hyper-V when a Linux guest VM crash occurs, so there is a record of the crash even when kdump is enabled. But crash_kexec_post_notifiers defaults to "false", so the kdump kernel runs before the notifiers and Hyper-V never gets notified. Fix this by always setting crash_kexec_post_notifiers to be true for Hyper-V VMs. Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com> Link: https://lore.kernel.org/r/20200406155331.2105-5-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23x86/Hyper-V: Trigger crash enlightenment only once during system crash.Tianyu Lan1-2/+14
commit 73f26e526f19afb3a06b76b970a76bcac2cafd05 upstream. When a guest VM panics, Hyper-V should be notified only once via the crash synthetic MSRs. Current Linux code might write these crash MSRs twice during a system panic: 1) hyperv_panic/die_event() calling hyperv_report_panic() 2) hv_kmsg_dump() calling hyperv_report_panic_msg() Fix this by not calling hyperv_report_panic() if a kmsg dump has been successfully registered. The notification will happen later via hyperv_report_panic_msg(). Fixes: 7ed4325a44ea ("Drivers: hv: vmbus: Make panic reporting to be more useful") Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com> Link: https://lore.kernel.org/r/20200406155331.2105-4-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23x86/Hyper-V: Free hv_panic_page when fail to register kmsg dumpTianyu Lan1-2/+5
commit 7f11a2cc10a4ae3a70e2c73361f4a9a33503539b upstream. If kmsg_dump_register() fails, hv_panic_page will not be used anywhere. So free and reset it. Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com> Link: https://lore.kernel.org/r/20200406155331.2105-3-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23x86/Hyper-V: Unload vmbus channel in hv panic callbackTianyu Lan2-8/+16
commit 74347a99e73ae00b8385f1209aaea193c670f901 upstream. When kdump is not configured, a Hyper-V VM might still respond to network traffic after a kernel panic when kernel parameter panic=0. The panic CPU goes into an infinite loop with interrupts enabled, and the VMbus driver interrupt handler still works because the VMbus connection is unloaded only in the kdump path. The network responses make the other end of the connection think the VM is still functional even though it has panic'ed, which could affect any failover actions that should be taken. Fix this by unloading the VMbus connection during the panic process. vmbus_initiate_unload() could then be called twice (e.g., by hyperv_panic_event() and hv_crash_handler(), so reset the connection state in vmbus_initiate_unload() to ensure the unload is done only once. Fixes: 81b18bce48af ("Drivers: HV: Send one page worth of kmsg dump over Hyper-V during panic") Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com> Link: https://lore.kernel.org/r/20200406155331.2105-2-Tianyu.Lan@microsoft.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23of: overlay: kmemleak in dup_and_fixup_symbol_prop()Frank Rowand1-0/+2
commit 478ff649b1c8eb2409b1a54fb75eb46f7c29f140 upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 4 of 5. target_path was not freed in the non-error path. Fixes: e0a58f3e08d4 ("of: overlay: remove a dependency on device node full_name") Reported-by: Erhard F. <erhard_f@mailbox.org> Signed-off-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23of: unittest: kmemleak in of_unittest_overlay_high_level()Frank Rowand1-1/+4
commit 145fc138f9aae4f9e1331352e301df28e16aed35 upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 3 of 5. of_unittest_overlay_high_level() failed to kfree the newly created property when the property named 'name' is skipped. Fixes: 39a751a4cb7e ("of: change overlay apply input data from unflattened to FDT") Reported-by: Erhard F. <erhard_f@mailbox.org> Signed-off-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23of: unittest: kmemleak in of_unittest_platform_populate()Frank Rowand1-2/+5
commit 216830d2413cc61be3f76bc02ffd905e47d2439e upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 2 of 5. of_unittest_platform_populate() left an elevated reference count for grandchild nodes (which are platform devices). Fix the platform device reference counts so that the memory will be freed. Fixes: fb2caa50fbac ("of/selftest: add testcase for nodes with same name and address") Reported-by: Erhard F. <erhard_f@mailbox.org> Signed-off-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23of: unittest: kmemleak on changeset destroyFrank Rowand1-0/+4
commit b3fb36ed694b05738d45218ea72cf7feb10ce2b1 upstream. kmemleak reports several memory leaks from devicetree unittest. This is the fix for problem 1 of 5. of_unittest_changeset() reaches deeply into the dynamic devicetree functions. Several nodes were left with an elevated reference count and thus were not properly cleaned up. Fix the reference counts so that the memory will be freed. Fixes: 201c910bd689 ("of: Transactional DT support.") Reported-by: Erhard F. <erhard_f@mailbox.org> Signed-off-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23xsk: Add missing check on user supplied headroom sizeMagnus Karlsson1-3/+2
commit 99e3a236dd43d06c65af0a2ef9cb44306aef6e02 upstream. Add a check that the headroom cannot be larger than the available space in the chunk. In the current code, a malicious user can set the headroom to a value larger than the chunk size minus the fixed XDP headroom. That way packets with a length larger than the supported size in the umem could get accepted and result in an out-of-bounds write. Fixes: c0c77d8fb787 ("xsk: add user memory registration support sockopt") Reported-by: Bui Quang Minh <minhquangbui99@gmail.com> Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=207225 Link: https://lore.kernel.org/bpf/1586849715-23490-1-git-send-email-magnus.karlsson@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-23ALSA: hda: Don't release card at firmware loading errorTakashi Iwai1-14/+5
commit 25faa4bd37c10f19e4b848b9032a17a3d44c6f09 upstream. At the error path of the firmware loading error, the driver tries to release the card object and set NULL to drvdata. This may be referred badly at the possible PM action, as the driver itself is still bound and the PM callbacks read the card object. Instead, we continue the probing as if it were no option set. This is often a better choice than the forced abort, too. Fixes: 5cb543dba986 ("ALSA: hda - Deferred probing with request_firmware_nowait()") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 Link: https://lore.kernel.org/r/20200413082034.25166-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-07-03 16:14:00 +0300