summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-10-13netfs: Fix READ/WRITE confusion when calling iov_iter_xarray()David Howells
[ Upstream commit 330de47d14af0c3995db81cc03cf5ca683d94d81 ] Fix netfs_clear_unread() to pass READ to iov_iter_xarray() instead of WRITE (the flag is about the operation accessing the buffer, not what sort of access it is doing to the buffer). Fixes: 3d3c95046742 ("netfs: Provide readahead and readpage netfs helpers") Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> cc: linux-cachefs@redhat.com cc: linux-afs@lists.infradead.org cc: ceph-devel@vger.kernel.org cc: linux-cifs@vger.kernel.org cc: linux-nfs@vger.kernel.org cc: v9fs-developer@lists.sourceforge.net cc: linux-fsdevel@vger.kernel.org cc: linux-mm@kvack.org Link: https://lore.kernel.org/r/162729351325.813557.9242842205308443901.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/162886603464.3940407.3790841170414793899.stgit@warthog.procyon.org.uk Link: https://lore.kernel.org/r/163239074602.1243337.14154704004485867017.stgit@warthog.procyon.org.uk Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13drm/i915/bdb: Fix version checkLukasz Majczak
[ Upstream commit fdddf8c3a477f77b3a623f220e78d45e89fc50d5 ] With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+" the size of bdb_lfp_backlight_data structure has been increased, causing if-statement in the parse_lfp_backlight function that comapres this structure size to the one retrieved from BDB, always to fail for older revisions. This patch calculates expected size of the structure for a given BDB version and compares it with the value gathered from BDB. Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221) Fixes: d381baad29b4 ("drm/i915/vbt: Fix backlight parsing for VBT 234+") Tested-by: Lukasz Majczak <lma@semihalf.com> Signed-off-by: Lukasz Majczak <lma@semihalf.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210930134606.227234-1-lma@semihalf.com (cherry picked from commit 4378daf5d04eed59724e6d0e74755e17dce2e105) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13drm/i915/tc: Fix TypeC port init/resume time sanitizationImre Deak
[ Upstream commit a532cde31de3cae6ed60e60d6f9379771f652809 ] Atm during driver loading and system resume TypeC ports are accessed before their HW/SW state is synced. Move the TypeC port sanitization to the encoder's sync_state hook to fix this. v2: Handle the encoder disabled case in gen11_dsi_sync_state() as well (Jose, Jani) Fixes: f9e76a6e68d3 ("drm/i915: Add an encoder hook to sanitize its state during init/resume") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929132833.2253961-1-imre.deak@intel.com (cherry picked from commit 7194dc998dfffca096c30b3cd39625158608992d) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13drm/i915/jsl: Add W/A 1409054076 for JSLTejas Upadhyay
[ Upstream commit 544021e3f2aa3c4c6c5aabc58907e8bab69b3762 ] When pipe A is disabled and MIPI DSI is enabled on pipe B, the AMT KVMR feature will incorrectly see pipe A as enabled. Set 0x42080 bit 23=1 before enabling DSI on pipe B and leave it set while DSI is enabled on pipe B. No impact to setting it all the time. Changes since V5: - Added reviewed-by - Removed redundant braces and debug message format - Imre Changes since V4: - Modified function comment Wa_<number>:icl,jsl,ehl - Lucas - Modified debug message in sync state - Imre Changes since V3: - More meaningful name to workaround - Imre - Remove boolean check clear flag - Add WA_verify hook in dsi sync_state Changes since V2: - Used REG_BIT, ignored pipe A and used sw state check - Jani - Made function wrapper - Jani Changes since V1: - ./dim checkpatch errors addressed Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210615105613.851491-1-tejaskumarx.surendrakumar.upadhyay@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13drm/i915/audio: Use BIOS provided value for RKL HDA linkKai-Heng Feng
[ Upstream commit ffac30be2a06b2516b2ce2afa2dcb2cf8af65a52 ] Commit 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver") makes HDMI audio on Lenovo P350 disappear. So in addition to TGL, extend the logic to RKL to use BIOS provided value to fix the regression. Fixes: 989634fb49ad ("drm/i915/audio: set HDA link parameters in driver") Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210906041300.508458-1-kai.heng.feng@canonical.com (cherry picked from commit c6b40ee330fe09b332715bb7ec1467e4fcbe2e65) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13ARM: imx6: disable the GIC CPU interface before calling stby-poweroff sequenceOleksij Rempel
[ Upstream commit 783f3db030563f7bcdfe2d26428af98ea1699a8e ] Any pending interrupt can prevent entering standby based power off state. To avoid it, disable the GIC CPU interface. Fixes: 8148d2136002 ("ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set") Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13dt-bindings: drm/bridge: ti-sn65dsi86: Fix reg valueGeert Uytterhoeven
[ Upstream commit b2d70c0dbf2731a37d1c7bcc86ab2387954d5f56 ] make dtbs_check: arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dt.yaml: bridge@2c: reg:0:0: 45 was expected According to the datasheet, the I2C address can be either 0x2c or 0x2d, depending on the ADDR control input. Fixes: e3896e6dddf0b821 ("dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Link: https://lore.kernel.org/r/08f73c2aa0d4e580303357dfae107d084d962835.1632486753.git.geert+renesas@glider.be Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13arm64: dts: ls1028a: fix eSDHC2 nodeMichael Walle
[ Upstream commit 8b94aa318aa746fbbc668d6b9b3ad812c835230c ] On the LS1028A this instance of the eSDHC controller is intended for either an eMMC or eSDIO card. It doesn't provide a card detect pin and its IO voltage is fixed at 1.8V. Remove the bogus broken-cd property, instead add the non-removable property. Fix the voltage-ranges property and set it to 1.8V only. Fixes: 491d3a3fc113 ("arm64: dts: ls1028a: Add esdhc node in dts") Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13arm64: dts: imx8mm-kontron-n801x-som: do not allow to switch off buck2Heiko Thiery
[ Upstream commit 9786cca4b477f2b2f9d573d474c929d87579b501 ] The buck2 output of the PMIC is the VDD core voltage of the cpu. Switching off this will poweroff the CPU. Add the 'regulator-always-on' property to avoid this. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards") Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13arm64: dts: imx8: change the spi-nor txHaibo Chen
[ Upstream commit 04aa946d57b20c40e541fb4ba2bcb390a22f404c ] Before commit 0e30f47232ab5 ("mtd: spi-nor: add support for DTR protocol"), for all PP command, it only support 1-1-1 mode, no matter the tx setting in dts. But after the upper commit, the logic change. It will choose the best mode(fastest mode) which flash device and spi-nor host controller both support. qspi and fspi host controller do not support read 1-4-4 mode. so need to set the tx to 1, let the common code finally select read 1-1-4 mode. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13ARM: dts: imx: change the spi-nor txHaibo Chen
[ Upstream commit b2a4f4a302b83976ad0d2930abe0f38e6119a144 ] Before commit 0e30f47232ab5 ("mtd: spi-nor: add support for DTR protocol"), for all PP command, it only support 1-1-1 mode, no matter the tx setting in dts. But after the upper commit, the logic change. It will choose the best mode(fastest mode) which flash device and spi-nor host controller both support. Though the spi-nor device on imx6sx-sdb/imx6ul(l/z)-14x14-evk board do not support PP-1-4-4/PP-1-1-4, but if tx is 4 in dts file, it will also impact the read mode selection. For the spi-nor device on the upper mentioned boards, they support read 1-4-4 mode and read 1-1-4 mode according to the device internal sfdp register. But qspi host controller do not support read 1-4-4 mode. so need to set the tx to 1, let the common code finally select read 1-1-4 mode, PP-1-1-1 mode. Signed-off-by: Haibo Chen <haibo.chen@nxp.com> Fixes: 0e30f47232ab ("mtd: spi-nor: add support for DTR protocol") Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13ptp_pch: Load module automatically if ID matchesAndy Shevchenko
[ Upstream commit 7cd8b1542a7ba0720c5a0a85ed414a122015228b ] The driver can't be loaded automatically because it misses module alias to be provided. Add corresponding MODULE_DEVICE_TABLE() call to the driver. Fixes: 863d08ece9bf ("supports eg20t ptp clock") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13powerpc/fsl/dts: Fix phy-connection-type for fm1mac3Pali Rohár
[ Upstream commit eed183abc0d3b8adb64fd1363b7cea7986cd58d6 ] Property phy-connection-type contains invalid value "sgmii-2500" per scheme defined in file ethernet-controller.yaml. Correct phy-connection-type value should be "2500base-x". Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: 84e0f1c13806 ("powerpc/mpc85xx: Add MDIO bus muxing support to the board device tree(s)") Acked-by: Scott Wood <oss@buserror.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13netfilter: nf_tables: honor NLM_F_CREATE and NLM_F_EXCL in event notificationPablo Neira Ayuso
[ Upstream commit 6fb721cf781808ee2ca5e737fb0592cc68de3381 ] Include the NLM_F_CREATE and NLM_F_EXCL flags in netlink event notifications, otherwise userspace cannot distiguish between create and add commands. Fixes: 96518518cc41 ("netfilter: add nftables") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13MIPS: Revert "add support for buggy MT7621S core detection"Ilya Lipnitskiy
[ Upstream commit 740da9d7ca4e25f5d87db9f80d75432681b61305 ] This reverts commit 6decd1aad15f56b169217789630a0098b496de0e. CPULAUNCH register is not set properly by some bootloaders, causing a regression until a bootloader change is made, which is hard if not impossible on some embedded devices. Revert the change until a more robust core detection mechanism that works on MT7621S routers such as Netgear R6220 as well as platforms like Digi EX15 can be made. Link: https://lore.kernel.org/lkml/4d9e3b39-7caa-d372-5d7b-42dcec36fec7@kernel.org Fixes: 6decd1aad15f ("MIPS: add support for buggy MT7621S core detection") Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com> Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Acked-by: Greg Ungerer <gerg@kernel.org> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13net: stmmac: dwmac-rk: Fix ethernet on rk3399 based devicesPunit Agrawal
[ Upstream commit aec3f415f7244b7747a7952596971adb0df2f568 ] Commit 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings") while getting rid of a runtime PM warning ended up breaking ethernet on rk3399 based devices. By dropping an extra reference to the device, the commit ends up enabling suspend / resume of the ethernet device - which appears to be broken. While the issue with runtime pm is being investigated, partially revert commit 2d26f6e39afb to restore the network on rk3399. Fixes: 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings") Suggested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Punit Agrawal <punitagrawal@gmail.com> Cc: Michael Riesch <michael.riesch@wolfvision.net> Tested-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20210929135049.3426058-1-punitagrawal@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13net: mscc: ocelot: fix VCAP filters remaining active after being deletedVladimir Oltean
[ Upstream commit 019d9329e7481cfaccbd8ed17b1e04ca76970f13 ] When ocelot_flower.c calls ocelot_vcap_filter_add(), the filter has a given filter->id.cookie. This filter is added to the block->rules list. However, when ocelot_flower.c calls ocelot_vcap_block_find_filter_by_id() which passes the cookie as argument, the filter is never found by filter->id.cookie when searching through the block->rules list. This is unsurprising, since the filter->id.cookie is an unsigned long, but the cookie argument provided to ocelot_vcap_block_find_filter_by_id() is a signed int, and the comparison fails. Fixes: 50c6cc5b9283 ("net: mscc: ocelot: store a namespaced VCAP filter ID") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20210930125330.2078625-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13net_sched: fix NULL deref in fifo_set_limit()Eric Dumazet
[ Upstream commit 560ee196fe9e5037e5015e2cdb14b3aecb1cd7dc ] syzbot reported another NULL deref in fifo_set_limit() [1] I could repro the issue with : unshare -n tc qd add dev lo root handle 1:0 tbf limit 200000 burst 70000 rate 100Mbit tc qd replace dev lo parent 1:0 pfifo_fast tc qd change dev lo root handle 1:0 tbf limit 300000 burst 70000 rate 100Mbit pfifo_fast does not have a change() operation. Make fifo_set_limit() more robust about this. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 1cf99067 P4D 1cf99067 PUD 7ca49067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 1 PID: 14443 Comm: syz-executor959 Not tainted 5.15.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffffc9000e2f7310 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffffff8d6ecc00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff888024c27910 RDI: ffff888071e34000 RBP: ffff888071e34000 R08: 0000000000000001 R09: ffffffff8fcfb947 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888024c27910 R13: ffff888071e34018 R14: 0000000000000000 R15: ffff88801ef74800 FS: 00007f321d897700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 00000000722c3000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: fifo_set_limit net/sched/sch_fifo.c:242 [inline] fifo_set_limit+0x198/0x210 net/sched/sch_fifo.c:227 tbf_change+0x6ec/0x16d0 net/sched/sch_tbf.c:418 qdisc_change net/sched/sch_api.c:1332 [inline] tc_modify_qdisc+0xd9a/0x1a60 net/sched/sch_api.c:1634 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5572 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504 netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340 netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: fb0305ce1b03 ("net-sched: consolidate default fifo qdisc setup") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Link: https://lore.kernel.org/r/20210930212239.3430364-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13libbpf: Fix memory leak in strsetAndrii Nakryiko
[ Upstream commit b0e875bac0fab3e7a7431c2eee36a8ccc0c712ac ] Free struct strset itself, not just its internal parts. Fixes: 90d76d3ececc ("libbpf: Extract internal set-of-strings datastructure APIs") Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20211001185910.86492-1-andrii@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13phy: mdio: fix memory leakPavel Skripkin
[ Upstream commit ca6e11c337daf7925ff8a2aac8e84490a8691905 ] Syzbot reported memory leak in MDIO bus interface, the problem was in wrong state logic. MDIOBUS_ALLOCATED indicates 2 states: 1. Bus is only allocated 2. Bus allocated and __mdiobus_register() fails, but device_register() was called In case of device_register() has been called we should call put_device() to correctly free the memory allocated for this device, but mdiobus_free() calls just kfree(dev) in case of MDIOBUS_ALLOCATED state To avoid this behaviour we need to set bus->state to MDIOBUS_UNREGISTERED _before_ calling device_register(), because put_device() should be called even in case of device_register() failure. Link: https://lore.kernel.org/netdev/YVMRWNDZDUOvQjHL@shell.armlinux.org.uk/ Fixes: 46abc02175b3 ("phylib: give mdio buses a device tree presence") Reported-and-tested-by: syzbot+398e7dc692ddbbb4cfec@syzkaller.appspotmail.com Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Link: https://lore.kernel.org/r/eceae1429fbf8fa5c73dd2a0d39d525aa905074d.1633024062.git.paskripkin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13libbpf: Fix segfault in light skeleton for objects without BTFKumar Kartikeya Dwivedi
[ Upstream commit 4729445b47efebf089da4ccbcd1b116ffa2ad4af ] When fed an empty BPF object, bpftool gen skeleton -L crashes at btf__set_fd() since it assumes presence of obj->btf, however for the sequence below clang adds no .BTF section (hence no BTF). Reproducer: $ touch a.bpf.c $ clang -O2 -g -target bpf -c a.bpf.c $ bpftool gen skeleton -L a.bpf.o /* SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) */ /* THIS FILE IS AUTOGENERATED! */ struct a_bpf { struct bpf_loader_ctx ctx; Segmentation fault (core dumped) The same occurs for files compiled without BTF info, i.e. without clang's -g flag. Fixes: 67234743736a (libbpf: Generate loader program out of BPF ELF file.) Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20210930061634.1840768-1-memxor@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13net/mlx5e: Fix the presented RQ index in PTP statsLama Kayal
[ Upstream commit dd1979cf3c710398a9eeba4853b908fe16426814 ] PTP-RQ counters title format contains PTP-RQ identifier, which is mistakenly not passed to sprinft(). This leads to unexpected garbage values instead. This patch fixes it. Before applying the patch: ethtool -S eth3 | grep ptp_rq ptp_rq15_packets: 0 ptp_rq8_bytes: 0 ptp_rq6_csum_complete: 0 ptp_rq14_csum_complete_tail: 0 ptp_rq3_csum_complete_tail_slow : 0 ptp_rq9_csum_unnecessary: 0 ptp_rq1_csum_unnecessary_inner: 0 ptp_rq7_csum_none: 0 ptp_rq10_xdp_drop: 0 ptp_rq9_xdp_redirect: 0 ptp_rq13_lro_packets: 0 ptp_rq12_lro_bytes: 0 ptp_rq10_ecn_mark: 0 ptp_rq9_removed_vlan_packets: 0 ptp_rq5_wqe_err: 0 ptp_rq8_mpwqe_filler_cqes: 0 ptp_rq2_mpwqe_filler_strides: 0 ptp_rq5_oversize_pkts_sw_drop: 0 ptp_rq6_buff_alloc_err: 0 ptp_rq15_cqe_compress_blks: 0 ptp_rq2_cqe_compress_pkts: 0 ptp_rq2_cache_reuse: 0 ptp_rq12_cache_full: 0 ptp_rq11_cache_empty: 256 ptp_rq12_cache_busy: 0 ptp_rq11_cache_waive: 0 ptp_rq12_congst_umr: 0 ptp_rq11_arfs_err: 0 ptp_rq9_recover: 0 After applying the patch: ethtool -S eth3 | grep ptp_rq ptp_rq0_packets: 0 ptp_rq0_bytes: 0 ptp_rq0_csum_complete: 0 ptp_rq0_csum_complete_tail: 0 ptp_rq0_csum_complete_tail_slow : 0 ptp_rq0_csum_unnecessary: 0 ptp_rq0_csum_unnecessary_inner: 0 ptp_rq0_csum_none: 0 ptp_rq0_xdp_drop: 0 ptp_rq0_xdp_redirect: 0 ptp_rq0_lro_packets: 0 ptp_rq0_lro_bytes: 0 ptp_rq0_ecn_mark: 0 ptp_rq0_removed_vlan_packets: 0 ptp_rq0_wqe_err: 0 ptp_rq0_mpwqe_filler_cqes: 0 ptp_rq0_mpwqe_filler_strides: 0 ptp_rq0_oversize_pkts_sw_drop: 0 ptp_rq0_buff_alloc_err: 0 ptp_rq0_cqe_compress_blks: 0 ptp_rq0_cqe_compress_pkts: 0 ptp_rq0_cache_reuse: 0 ptp_rq0_cache_full: 0 ptp_rq0_cache_empty: 256 ptp_rq0_cache_busy: 0 ptp_rq0_cache_waive: 0 ptp_rq0_congst_umr: 0 ptp_rq0_arfs_err: 0 ptp_rq0_recover: 0 Fixes: a28359e922c6 ("net/mlx5e: Add PTP-RX statistics") Signed-off-by: Lama Kayal <lkayal@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13net/mlx5: Fix setting number of EQs of SFsShay Drory
[ Upstream commit f88c4876347400a577598e06f1b230a7b19ee0e9 ] When setting number of completion EQs of the SF, consider number of online CPUs. Without this consideration, when number of online cpus are less than 8, unnecessary 8 completion EQs are allocated. Fixes: c36326d38d93 ("net/mlx5: Round-Robin EQs over IRQs") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13net/mlx5: Fix length of irq_index in charsShay Drory
[ Upstream commit ac8b7d50ae4c3f5325c599f3d6e939ecef6a585a ] The maximum irq_index can be 2047, This means irq_name should have 4 characters reserve for the irq_index. Hence, increase it to 4. Fixes: 3af26495a247 ("net/mlx5: Enlarge interrupt field in CREATE_EQ") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13net/mlx5: Avoid generating event after PPS out in Real time modeAya Levin
[ Upstream commit 99b9a678b2e474756770900595cb09c94498bfca ] When in Real-time mode, HW clock is synced with the PTP daemon. Hence driver should not re-calibrate the next pulse (via MTPPSE repetitive events mechanism). This patch arms repetitive events only in free-running mode. Fixes: 432119de33d9 ("net/mlx5: Add cyc2time HW translation mode support") Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Eran Ben Elisha <eranbe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13net/mlx5: Force round second at 1PPS out start timeAya Levin
[ Upstream commit 64728294703e77827cc31a1b164ca867400067f5 ] Allow configuration of 1PPS start time only with time-stamp representing a round second. Prior to this patch driver allowed setting of a non-round-second which is not supported by the device. Avoid unexpected behavior by restricting start-time configuration to a round-second. Fixes: 4272f9b88db9 ("net/mlx5e: Change 1PPS out scheme") Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Eran Ben Elisha <eranbe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13net/mlx5: E-Switch, Fix double allocation of acl flow counterMoshe Shemesh
[ Upstream commit a586775f83bd729ad60b56352dbe067f4bb0beee ] Flow counter is allocated in eswitch legacy acl setting functions without checking if already allocated by previous setting. Add a check to avoid such double allocation. Fixes: 07bab9502641 ("net/mlx5: E-Switch, Refactor eswitch ingress acl codes") Fixes: ea651a86d468 ("net/mlx5: E-Switch, Refactor eswitch egress acl codes") Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13net/mlx5e: Keep the value for maximum number of channels in-syncTariq Toukan
[ Upstream commit 9d758d4a3a039b9d7086d4759ed255b748713eee ] The value for maximum number of channels is first calculated based on the netdev's profile and current function resources (specifically, number of MSIX vectors, which depends among other things on the number of online cores in the system). This value is then used to calculate the netdev's number of rxqs/txqs. Once created (by alloc_etherdev_mqs), the number of netdev's rxqs/txqs is constant and we must not exceed it. To achieve this, keep the maximum number of channels in sync upon any netdevice re-attach. Use mlx5e_get_max_num_channels() for calculating the number of netdev's rxqs/txqs. After netdev is created, use mlx5e_calc_max_nch() (which coinsiders core device resources, profile, and netdev) to init or update priv->max_nch. Before this patch, the value of priv->max_nch might get out of sync, mistakenly allowing accesses to out-of-bounds objects, which would crash the system. Track the number of channels stats structures used in a separate field, as they are persistent to suspend/resume operations. All the collected stats of every channel index that ever existed should be preserved. They are reset only when struct mlx5e_priv is, in mlx5e_priv_cleanup(), which is part of the profile changing flow. There is no point anymore in blocking a profile change due to max_nch mismatch in mlx5e_netdev_change_profile(). Remove the limitation. Fixes: a1f240f18017 ("net/mlx5e: Adjust to max number of channles when re-attaching") Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Maxim Mikityanskiy <maximmi@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13net/mlx5e: IPSEC RX, enable checksum completeRaed Salem
[ Upstream commit f9a10440f0b1f33faa792af26f4e9823a9b8b6a4 ] Currently in Rx data path IPsec crypto offloaded packets uses csum_none flag, so checksum is handled by the stack, this naturally have some performance/cpu utilization impact on such flows. As Nvidia NIC starting from ConnectX6DX provides checksum complete value out of the box also for such flows there is no sense in taking csum_none path, furthermore the stack (xfrm) have the method to handle checksum complete corrections for such flows i.e. IPsec trailer removal and consequently checksum value adjustment. Because of the above and in addition the ConnectX6DX is the first HW which supports IPsec crypto offload then it is safe to report csum complete for IPsec offloaded traffic. Fixes: b2ac7541e377 ("net/mlx5e: IPsec: Add Connect-X IPsec Rx data path offload") Signed-off-by: Raed Salem <raeds@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13bpf: Fix integer overflow in prealloc_elems_and_freelist()Tatsuhiko Yasumatsu
[ Upstream commit 30e29a9a2bc6a4888335a6ede968b75cd329657a ] In prealloc_elems_and_freelist(), the multiplication to calculate the size passed to bpf_map_area_alloc() could lead to an integer overflow. As a result, out-of-bounds write could occur in pcpu_freelist_populate() as reported by KASAN: [...] [ 16.968613] BUG: KASAN: slab-out-of-bounds in pcpu_freelist_populate+0xd9/0x100 [ 16.969408] Write of size 8 at addr ffff888104fc6ea0 by task crash/78 [ 16.970038] [ 16.970195] CPU: 0 PID: 78 Comm: crash Not tainted 5.15.0-rc2+ #1 [ 16.970878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 16.972026] Call Trace: [ 16.972306] dump_stack_lvl+0x34/0x44 [ 16.972687] print_address_description.constprop.0+0x21/0x140 [ 16.973297] ? pcpu_freelist_populate+0xd9/0x100 [ 16.973777] ? pcpu_freelist_populate+0xd9/0x100 [ 16.974257] kasan_report.cold+0x7f/0x11b [ 16.974681] ? pcpu_freelist_populate+0xd9/0x100 [ 16.975190] pcpu_freelist_populate+0xd9/0x100 [ 16.975669] stack_map_alloc+0x209/0x2a0 [ 16.976106] __sys_bpf+0xd83/0x2ce0 [...] The possibility of this overflow was originally discussed in [0], but was overlooked. Fix the integer overflow by changing elem_size to u64 from u32. [0] https://lore.kernel.org/bpf/728b238e-a481-eb50-98e9-b0f430ab01e7@gmail.com/ Fixes: 557c0c6e7df8 ("bpf: convert stackmap to pre-allocation") Signed-off-by: Tatsuhiko Yasumatsu <th.yasumatsu@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20210930135545.173698-1-th.yasumatsu@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13soc: ti: omap-prm: Fix external abort for am335x prussTony Lindgren
[ Upstream commit b232537074fcaf0c2837abbb217429c097bb7598 ] Starting with v5.15-rc1, we may now see some am335x beaglebone black device produce the following error on pruss probe: Unhandled fault: external abort on non-linefetch (0x1008) at 0xe0326000 This has started with the enabling of pruss for am335x in the dts files. Turns out the is caused by the PRM reset handling not waiting for the reset bit to clear. To fix the issue, let's always wait for the reset bit to clear, even if there is a separate reset status register. We attempted to fix a similar issue for dra7 iva with a udelay() in commit effe89e40037 ("soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva"). There is no longer a need for the udelay() for dra7 iva reset either with the check added for reset bit clearing. Cc: Drew Fustini <pdp7pdp7@gmail.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: "H. Nikolaus Schaller" <hns@goldelico.com> Cc: Robert Nelson <robertcnelson@gmail.com> Cc: Yongqin Liu <yongqin.liu@linaro.org> Fixes: effe89e40037 ("soc: ti: omap-prm: Fix occasional abort on reset deassert for dra7 iva") Reported-by: Matti Vaittinen <mazziesaccount@gmail.com> Tested-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13bpf, arm: Fix register clobbering in div/mod implementationJohan Almbladh
[ Upstream commit 79e3445b38e0cab94264a3894c0c3d57c930b97e ] On ARM CPUs that lack div/mod instructions, ALU32 BPF_DIV and BPF_MOD are implemented using a call to a helper function. Before, the emitted code for those function calls failed to preserve caller-saved ARM registers. Since some of those registers happen to be mapped to BPF registers, it resulted in eBPF register values being overwritten. This patch emits code to push and pop the remaining caller-saved ARM registers r2-r3 into the stack during the div/mod function call. ARM registers r0-r1 are used as arguments and return value, and those were already saved and restored correctly. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Johan Almbladh <johan.almbladh@anyfinetworks.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13netfilter: nf_tables: reverse order in rule replacement expansionPablo Neira Ayuso
[ Upstream commit 2c964c558641a3bddaee5719c9e6d8805f777812 ] Deactivate old rule first, then append the new rule, so rule replacement notification via netlink first reports the deletion of the old rule with handle X in first place, then it adds the new rule (reusing the handle X of the replaced old rule). Note that the abort path releases the transaction that has been created by nft_delrule() on error. Fixes: ca08987885a1 ("netfilter: nf_tables: deactivate expressions in rule replecement routine") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13netfilter: nf_tables: add position handle in event notificationPablo Neira Ayuso
[ Upstream commit e189ae161dd784aa5d454b0832f818cacc0e131b ] Add position handle to allow to identify the rule location from netlink events. Otherwise, userspace cannot incrementally update a userspace cache through monitoring events. Skip handle dump if the rule has been either inserted (at the beginning of the ruleset) or appended (at the end of the ruleset), the NLM_F_APPEND netlink flag is sufficient in these two cases. Handle NLM_F_REPLACE as NLM_F_APPEND since the rule replacement expansion appends it after the specified rule handle. Fixes: 96518518cc41 ("netfilter: add nftables") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13netfilter: conntrack: fix boot failure with nf_conntrack.enable_hooks=1Florian Westphal
[ Upstream commit 339031bafe6b281cf2dcb8364217288b9fdab555 ] This is a revert of 7b1957b049 ("netfilter: nf_defrag_ipv4: use net_generic infra") and a partial revert of 8b0adbe3e3 ("netfilter: nf_defrag_ipv6: use net_generic infra"). If conntrack is builtin and kernel is booted with: nf_conntrack.enable_hooks=1 .... kernel will fail to boot due to a NULL deref in nf_defrag_ipv4_enable(): Its called before the ipv4 defrag initcall is made, so net_generic() returns NULL. To resolve this, move the user refcount back to struct net so calls to those functions are possible even before their initcalls have run. Fixes: 7b1957b04956 ("netfilter: nf_defrag_ipv4: use net_generic infra") Fixes: 8b0adbe3e38d ("netfilter: nf_defrag_ipv6: use net_generic infra"). Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13iwlwifi: pcie: add configuration of a Wi-Fi adapter on Dell XPS 15Vladimir Zapolskiy
[ Upstream commit fe5c735d0d47b495be6753d6aea4f8f78c909a0a ] There is a Killer AX1650 2x2 Wi-Fi 6 and Bluetooth 5.1 wireless adapter found on Dell XPS 15 (9510) laptop, its configuration was present on Linux v5.7, however accidentally it has been removed from the list of supported devices, let's add it back. The problem is manifested on driver initialization: Intel(R) Wireless WiFi driver for Linux iwlwifi 0000:00:14.3: enabling device (0000 -> 0002) iwlwifi: No config found for PCI dev 43f0/1651, rev=0x354, rfid=0x10a100 iwlwifi: probe of 0000:00:14.3 failed with error -22 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213939 Fixes: 3f910a25839b ("iwlwifi: pcie: convert all AX101 devices to the device tables") Cc: Julien Wajsberg <felash@gmail.com> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Acked-by: Luca Coelho <luca@coelho.fi> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210924122154.2376577-1-vladimir.zapolskiy@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13xtensa: call irqchip_init only when CONFIG_USE_OF is selectedMax Filippov
[ Upstream commit 6489f8d0e1d93a3603d8dad8125797559e4cf2a2 ] During boot time kernel configured with OF=y but USE_OF=n displays the following warnings and hangs shortly after starting userspace: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/irq/irqdomain.c:695 irq_create_mapping_affinity+0x29/0xc0 irq_create_mapping_affinity(, 6) called with NULL domain CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0-rc3-00001-gd67ed2510d28 #30 Call Trace: __warn+0x69/0xc4 warn_slowpath_fmt+0x6c/0x94 irq_create_mapping_affinity+0x29/0xc0 local_timer_setup+0x40/0x88 time_init+0xb1/0xe8 start_kernel+0x31d/0x3f4 _startup+0x13b/0x13b ---[ end trace 1e6630e1c5eda35b ]--- ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at arch/xtensa/kernel/time.c:141 local_timer_setup+0x58/0x88 error: can't map timer irq CPU: 0 PID: 0 Comm: swapper Tainted: G W 5.15.0-rc3-00001-gd67ed2510d28 #30 Call Trace: __warn+0x69/0xc4 warn_slowpath_fmt+0x6c/0x94 local_timer_setup+0x58/0x88 time_init+0xb1/0xe8 start_kernel+0x31d/0x3f4 _startup+0x13b/0x13b ---[ end trace 1e6630e1c5eda35c ]--- Failed to request irq 0 (timer) Fix that by calling irqchip_init only when CONFIG_USE_OF is selected and calling legacy interrupt controller init otherwise. Fixes: da844a81779e ("xtensa: add device trees support") Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13xtensa: use CONFIG_USE_OF instead of CONFIG_OFRandy Dunlap
[ Upstream commit d67ed2510d28a1eb33171010d35cf52178cfcbdd ] CONFIG_OF can be set by a randconfig or by a user -- without setting the early flattree option (OF_EARLY_FLATTREE). This causes build errors. However, if randconfig or a user sets USE_OF in the Xtensa config, the right kconfig symbols are set to fix the build. Fixes these build errors: ../arch/xtensa/kernel/setup.c:67:19: error: ‘__dtb_start’ undeclared here (not in a function); did you mean ‘dtb_start’? 67 | void *dtb_start = __dtb_start; | ^~~~~~~~~~~ ../arch/xtensa/kernel/setup.c: In function 'xtensa_dt_io_area': ../arch/xtensa/kernel/setup.c:201:14: error: implicit declaration of function 'of_flat_dt_is_compatible'; did you mean 'of_machine_is_compatible'? [-Werror=implicit-function-declaration] 201 | if (!of_flat_dt_is_compatible(node, "simple-bus")) ../arch/xtensa/kernel/setup.c:204:18: error: implicit declaration of function 'of_get_flat_dt_prop' [-Werror=implicit-function-declaration] 204 | ranges = of_get_flat_dt_prop(node, "ranges", &len); ../arch/xtensa/kernel/setup.c:204:16: error: assignment to 'const __be32 *' {aka 'const unsigned int *'} from 'int' makes pointer from integer without a cast [-Werror=int-conversion] 204 | ranges = of_get_flat_dt_prop(node, "ranges", &len); | ^ ../arch/xtensa/kernel/setup.c: In function 'early_init_devtree': ../arch/xtensa/kernel/setup.c:228:9: error: implicit declaration of function 'early_init_dt_scan'; did you mean 'early_init_devtree'? [-Werror=implicit-function-declaration] 228 | early_init_dt_scan(params); ../arch/xtensa/kernel/setup.c:229:9: error: implicit declaration of function 'of_scan_flat_dt' [-Werror=implicit-function-declaration] 229 | of_scan_flat_dt(xtensa_dt_io_area, NULL); xtensa-elf-ld: arch/xtensa/mm/mmu.o:(.text+0x0): undefined reference to `xtensa_kio_paddr' Fixes: da844a81779e ("xtensa: add device trees support") Fixes: 6cb971114f63 ("xtensa: remap io area defined in device tree") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13arm64: dts: qcom: pm8150: use qcom,pm8998-pon bindingDmitry Baryshkov
[ Upstream commit a153d317168aa3d61a204fadc85bac3995381d33 ] Change pm8150 to use the qcom,pm8998-pon compatible string for the pon in order to pass reboot mode properly. Fixes: 5101f22a5c37 ("arm64: dts: qcom: pm8150: Add base dts file") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Amit Pundir <amit.pundir@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210916151341.1797512-1-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13ath5k: fix building with LEDS=mArnd Bergmann
[ Upstream commit fb8c3a3c52400512fc8b3b61150057b888c30b0d ] Randconfig builds still show a failure for the ath5k driver, similar to the one that was fixed for ath9k earlier: WARNING: unmet direct dependencies detected for MAC80211_LEDS Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y]) Selected by [m]: - ATH5K [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && (PCI [=y] || ATH25) && MAC80211 [=y] net/mac80211/led.c: In function 'ieee80211_alloc_led_names': net/mac80211/led.c:34:22: error: 'struct led_trigger' has no member named 'name' 34 | local->rx_led.name = kasprintf(GFP_KERNEL, "%srx", | ^ Copying the same logic from my ath9k patch makes this one work as well, stubbing out the calls to the LED subsystem. Fixes: b64acb28da83 ("ath9k: fix build error with LEDS_CLASS=m") Fixes: 72cdab808714 ("ath9k: Do not select MAC80211_LEDS by default") Fixes: 3a078876caee ("ath5k: convert LED code to use mac80211 triggers") Link: https://lore.kernel.org/all/20210722105501.1000781-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210920122359.353810-1-arnd@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13PCI: hv: Fix sleep while in non-sleep context when removing child devices ↵Long Li
from the bus [ Upstream commit 41608b64b10b80fe00dd253cd8326ec8ad85930f ] In hv_pci_bus_exit, the code is holding a spinlock while calling pci_destroy_slot(), which takes a mutex. This is not safe for spinlock. Fix this by moving the children to be deleted to a list on the stack, and removing them after spinlock is released. Fixes: 94d22763207a ("PCI: hv: Fix a race condition when removing the device") Cc: "K. Y. Srinivasan" <kys@microsoft.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Cc: Stephen Hemminger <sthemmin@microsoft.com> Cc: Wei Liu <wei.liu@kernel.org> Cc: Dexuan Cui <decui@microsoft.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Rob Herring <robh@kernel.org> Cc: "Krzysztof Wilczyński" <kw@linux.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Michael Kelley <mikelley@microsoft.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/linux-hyperv/20210823152130.GA21501@kili/ Signed-off-by: Long Li <longli@microsoft.com> Reviewed-by: Wei Liu <wei.liu@kernel.org> Link: https://lore.kernel.org/r/1630365207-20616-1-git-send-email-longli@linuxonhyperv.com Signed-off-by: Wei Liu <wei.liu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13ARM: dts: imx6qdl-pico: Fix Ethernet supportFabio Estevam
[ Upstream commit 450e7fe9b1b3c90eeed74a2fe0eeb13a7b57f3da ] Currently, it is no longer possible to retrieve a DHCP address on the imx6qdl-pico board. This issue has been exposed by commit f5d9aa79dfdf ("ARM: imx6q: remove clk-out fixup for the Atheros AR8031 and AR8035 PHYs"). Fix it by describing the qca,clk-out-frequency property as suggested by the commit above. Fixes: 98670a0bb0ef14bbb3 ("ARM: dts: imx6qdl: Add imx6qdl-pico support") Signed-off-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13ARM: dts: imx: Fix USB host power regulator polarity on M53MenloMarek Vasut
[ Upstream commit 5c187e2eb3f92daa38cb3d4ab45e1107ea34108e ] The MIC2025 switch input signal nEN is active low, describe it as such in the DT. The previous change to this regulator polarity was incorrectly influenced by broken quirks in gpiolib-of.c, which is now long fixed. So fix this regulator polarity setting here once and for all. Fixes: 3c3601cd6a6d3 ("ARM: dts: imx53: Update USB configuration on M53Menlo") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13ARM: dts: imx: Add missing pinctrl-names for panel on M53MenloMarek Vasut
[ Upstream commit c8c1efe14a4aadcfe93a158b1272e48298d2de15 ] The panel already contains pinctrl-0 phandle, but it is missing the default pinctrl-names property, so the pin configuration is ignored. Fill in the missing pinctrl-names property, so the pin configuration is applied. Fixes: d81765d693db6 ("ARM: dts: imx53: Update LCD panel node on M53Menlo") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP Linux Team <linux-imx@nxp.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13soc: qcom: mdt_loader: Drop PT_LOAD check on hash segmentShawn Guo
[ Upstream commit 833d51d7c66d6708abbc02398892b96b950167b9 ] PT_LOAD type denotes that the segment should be loaded into the final firmware memory region. Hash segment is not one such, because it's only needed for PAS init and shouldn't be in the final firmware memory region. That's why mdt_phdr_valid() explicitly reject non PT_LOAD segment and hash segment. This actually makes the hash segment type check in qcom_mdt_read_metadata() unnecessary and redundant. For a hash segment, it won't be loaded into firmware memory region anyway, due to the QCOM_MDT_TYPE_HASH check in mdt_phdr_valid(), even if it has a PT_LOAD type for some reason (misusing or abusing?). Some firmware files on Sony phones are such examples, e.g WCNSS firmware of Sony Xperia M4 Aqua phone. The type of hash segment is just PT_LOAD. Drop the unnecessary hash segment type check in qcom_mdt_read_metadata() to fix firmware loading failure on these phones, while hash segment is still kept away from the final firmware memory region. Fixes: 498b98e93900 ("soc: qcom: mdt_loader: Support loading non-split images") Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210828070202.7033-1-shawn.guo@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13iwlwifi: mvm: Fix possible NULL dereferenceIlan Peer
[ Upstream commit 24d5f16e407b75bc59d5419b957a9cab423b2681 ] In __iwl_mvm_remove_time_event() check that 'te_data->vif' is NULL before dereferencing it. Fixes: 7b3954a1d69a ("iwlwifi: mvm: Explicitly stop session protection before unbinding") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210907143156.e80e52167d93.Ie2247f43f8acb2cee6dff5b07a3947c79a772835@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13ARM: at91: pm: do not panic if ram controllers are not enabledClaudiu Beznea
[ Upstream commit 1605de1b3ca66e3eddbca4b3c353c13c26476fe2 ] In case PM is enabled but there is no RAM controller information in DT the code will panic. Avoid such scenarios by not initializing platform specific PM code in case RAM controller is not provided via DT. Reported-by: Eugen Hristev <eugen.hristev@microchip.com> Fixes: 827de1f123ba0 ("ARM: at91: remove at91_dt_initialize and machine init_early()") Fixes: 892e1f4a3ae58 ("ARM: at91: pm: add sama7g5 ddr phy controller") Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Link: https://lore.kernel.org/r/20210823131915.23857-2-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13Revert "arm64: dts: qcom: sc7280: Fixup the cpufreq node"Douglas Anderson
[ Upstream commit a48c730a4e0bf480bcde12d795a9cd6f9ef14d1e ] This reverts commit 11e03d692101e484df9322f892a8b6e111a82bfd. As per discussion [1] the patch shouldn't have landed. Let's revert. [1] https://lore.kernel.org/r/fde7bac239f796b039b9be58b391fb77@codeaurora.org/ Fixes: 11e03d692101 ("arm64: dts: qcom: sc7280: Fixup the cpufreq node") Reported-by: Matthias Kaehlcke <mka@chromium.org> Cc: Sibi Sankar <sibis@codeaurora.org> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210907121220.1.I08460f490473b70de0d768db45f030a4d5c17828@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13ARM: dts: qcom: apq8064: Use 27MHz PXO clock as DSI PLL referenceMarijn Suijten
[ Upstream commit f1db21c315f4b4f8c3fbea56aac500673132d317 ] The 28NM DSI PLL driver for msm8960 calculates with a 27MHz reference clock and should hence use PXO, not CXO which runs at 19.2MHz. Note that none of the DSI PHY/PLL drivers currently use this "ref" clock; they all rely on (sometimes inexistant) global clock names and usually function normally without a parent clock. This discrepancy will be corrected in a future patch, for which this change needs to be in place first. Fixes: 6969d1d9c615 ("ARM: dts: qcom-apq8064: Set 'cxo_board' as ref clock of the DSI PHY") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Link: https://lore.kernel.org/r/20210829203027.276143-2-marijn.suijten@somainline.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13soc: qcom: socinfo: Fixed argument passed to platform_set_data()Antonio Martorana
[ Upstream commit 9c5a4ec69bbf5951f84ada9e0db9c6c50de61808 ] Set qcom_socinfo pointer as data being stored instead of pointer to soc_device structure. Aligns with future calls to platform_get_data() which expects qcom_socinfo pointer. Fixes: efb448d0a3fc ("soc: qcom: Add socinfo driver") Signed-off-by: Antonio Martorana <amartora@codeaurora.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/1629159879-95777-1-git-send-email-amartora@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-17 08:31:23 +0000