- Oct 20, 2023
-
-
Jeremy Cline authored
[ Upstream commit 354a6e70 ] The protocol is used in a bit mask to determine if the protocol is supported. Assert the provided protocol is less than the maximum defined so it doesn't potentially perform a shift-out-of-bounds and provide a clearer error for undefined protocols vs unsupported ones. Fixes: 6a2968aa ("NFC: basic NCI protocol implementation") Reported-and-tested-by:
<syzbot+0839b78e119aae1fec78@syzkaller.appspotmail.com> Closes: https://syzkaller.appspot.com/bug?extid=0839b78e119aae1fec78 Signed-off-by:
Jeremy Cline <jeremy@jcline.org> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20231009200054.82557-1-jeremy@jcline.org Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ralph Siemsen authored
[ Upstream commit f055ff23 ] Enable pin muxing (eg. programmable function), so that the RZ/N1 GPIO pins will be configured as specified by the pinmux in the DTS. This used to be enabled implicitly via CONFIG_GENERIC_PINMUX_FUNCTIONS, however that was removed, since the RZ/N1 driver does not call any of the generic pinmux functions. Fixes: 1308fb4e ("pinctrl: rzn1: Do not select GENERIC_PIN{CTRL_GROUPS,MUX_FUNCTIONS}") Signed-off-by:
Ralph Siemsen <ralph.siemsen@linaro.org> Reviewed-by:
Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20231004200008.1306798-1-ralph.siemsen@linaro.org Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Nils Hoppmann authored
[ Upstream commit a950a592 ] SMC_STAT_PAYLOAD_SUB(_smc_stats, _tech, key, _len, _rc) will calculate wrong bucket positions for payloads of exactly 4096 bytes and (1 << (m + 12)) bytes, with m == SMC_BUF_MAX - 1. Intended bucket distribution: Assume l == size of payload, m == SMC_BUF_MAX - 1. Bucket 0 : 0 < l <= 2^13 Bucket n, 1 <= n <= m-1 : 2^(n+12) < l <= 2^(n+13) Bucket m : l > 2^(m+12) Current solution: _pos = fls64((l) >> 13) [...] _pos = (_pos < m) ? ((l == 1 << (_pos + 12)) ? _pos - 1 : _pos) : m For l == 4096, _pos == -1, but should be _pos == 0. For l == (1 << (m + 12)), _pos == m, but should be _pos == m - 1. In order to avoid special treatment of these corner cases, the calculation is adjusted. The new solution first subtracts the length by one, and then calculates the correct bucket by shifting accordingly, i.e. _pos = fls64((l - 1) >> 13), l > 0. This not only fixes the issues named above, but also makes the whole bucket assignment easier to follow. Same is done for SMC_STAT_RMB_SIZE_SUB(_smc_stats, _tech, k, _len), where the calculation of the bucket position is similar to the one named above. Fixes: e0e4b8fa ("net/smc: Add SMC statistics support") Suggested-by:
Halil Pasic <pasic@linux.ibm.com> Signed-off-by:
Nils Hoppmann <niho@linux.ibm.com> Reviewed-by:
Halil Pasic <pasic@linux.ibm.com> Reviewed-by:
Wenjia Zhang <wenjia@linux.ibm.com> Reviewed-by:
Dust Li <dust.li@linux.alibaba.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Eric Dumazet authored
[ Upstream commit 31c07dff ] Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF. Getting a reference on the socket found in a lookup while holding a lock should happen before releasing the lock. nfc_llcp_sock_get_sn() has a similar problem. Finally nfc_llcp_recv_snl() needs to make sure the socket found by nfc_llcp_sock_from_sn() does not disappear. Fixes: 8f50020e ("NFC: LLCP late binding") Reported-by:
Sili Luo <rootlab@huawei.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Willy Tarreau <w@1wt.eu> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231009123110.3735515-1-edumazet@google.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Will Mortensen authored
[ Upstream commit da6192ca ] Commit 1e662209 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs flag change") seems to have accidentally inverted the logic added in commit 0bc73ad4 ("net/mlx5e: Mutually exclude RX-FCS and RX-port-timestamp"). The impact of this is a little unclear since it seems the FCS scattered with RX-FCS is (usually?) correct regardless. Fixes: 1e662209 ("net/mlx5e: Update rx ring hw mtu upon each rx-fcs flag change") Tested-by:
Charlotte Tan <charlotte@extrahop.com> Reviewed-by:
Charlotte Tan <charlotte@extrahop.com> Cc: Adham Faris <afaris@nvidia.com> Cc: Aya Levin <ayal@nvidia.com> Cc: Tariq Toukan <tariqt@nvidia.com> Cc: Moshe Shemesh <moshe@nvidia.com> Cc: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
Will Mortensen <will@extrahop.com> Reviewed-by:
Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20231006053706.514618-1-will@extrahop.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dan Carpenter authored
[ Upstream commit 7b5add9a ] The adapter->vf_mvs.l list needs to be initialized even if the list is empty. Otherwise it will lead to crashes. Fixes: a1cbb15c ("ixgbe: Add macvlan support for VF") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Simon Horman <horms@kernel.org> Reviewed-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Link: https://lore.kernel.org/r/ZSADNdIw8zFx1xw2@kadam Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Radu Pirea (NXP OSS) authored
[ Upstream commit fde2f2d7 ] When updating the SA, use the new update_pn flags instead of comparing the new PN with the initial one. Comparing the initial PN value with the new value will allow the user to update the SA using the initial PN value as a parameter like this: $ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \ ead3664f508eb06c40ac7104cdae4ce5 $ ip macsec set macsec0 tx sa 0 pn 1 off Fixes: 8ff0ac5b ("net/mlx5: Add MACsec offload Tx command support") Fixes: aae3454e ("net/mlx5e: Add MACsec offload Rx command support") Signed-off-by:
Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Reviewed-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Radu Pirea (NXP OSS) authored
[ Upstream commit e0a8c918 ] Updating the PN is not supported. Return -EINVAL if update_pn is true. The following command succeeded, but it should fail because the driver does not update the PN: ip macsec set macsec0 tx sa 0 pn 232 on Fixes: 28c5107a ("net: phy: mscc: macsec support") Signed-off-by:
Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Reviewed-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Radu Pirea (NXP OSS) authored
[ Upstream commit 0412cc84 ] Indicate next PN update using update_pn flag in macsec_context. Offloaded MACsec implementations does not know whether or not the MACSEC_SA_ATTR_PN attribute was passed for an SA update and assume that next PN should always updated, but this is not always true. The PN can be reset to its initial value using the following command: $ ip macsec set macsec0 tx sa 0 off #octeontx2-pf case Or, the update PN command will succeed even if the driver does not support PN updates. $ ip macsec set macsec0 tx sa 0 pn 1 on #mscc phy driver case Comparing the initial PN with the new PN value is not a solution. When the user updates the PN using its initial value the command will succeed, even if the driver does not support it. Like this: $ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \ ead3664f508eb06c40ac7104cdae4ce5 $ ip macsec set macsec0 tx sa 0 pn 1 on #mlx5 case Signed-off-by:
Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Reviewed-by:
Sabrina Dubroca <sd@queasysnail.net> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Stable-dep-of: e0a8c918 ("net: phy: mscc: macsec: reject PN update requests") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Eric Dumazet authored
[ Upstream commit 26c29961 ] syzbot uses panic_on_warn. This means that the skb_dump() I added in the blamed commit are not even called. Rewrite this so that we get the needed skb dump before syzbot crashes. Fixes: eeee4b77 ("net: add more debug info in skb_checksum_help()") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Willem de Bruijn <willemb@google.com> Reviewed-by:
Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20231006173355.2254983-1-edumazet@google.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
David Vernet authored
[ Upstream commit 82995598 ] The verifier, as part of check_return_code(), verifies that async callbacks such as from e.g. timers, will return 0. It does this by correctly checking that R0->var_off is in tnum_const(0), which effectively checks that it's in a range of 0. If this condition fails, however, it prints an error message which says that the value should have been in (0x0; 0x1). This results in possibly confusing output such as the following in which an async callback returns 1: At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x1) The fix is easy -- we should just pass the tnum_const(0) as the correct range to verbose_invalid_scalar(), which will then print the following: At async callback the register R0 has value (0x1; 0x0) should have been in (0x0; 0x0) Fixes: bfc6bb74 ("bpf: Implement verifier support for validation of async callbacks.") Signed-off-by:
David Vernet <void@manifault.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20231009161414.235829-1-void@manifault.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Konstantin Meskhidze authored
[ Upstream commit 39465cac ] Since size of 'header' pointer and '*header' structure is equal on 64-bit machines issue probably didn't cause any wrong behavior. But anyway, fixing typo is required. Fixes: 7a73ba74 ("drm/vmwgfx: Use TTM handles instead of SIDs as user-space surface handles.") Co-developed-by:
Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com> Signed-off-by:
Konstantin Meskhidze <konstantin.meskhidze@huawei.com> Reviewed-by:
Zack Rusin <zackr@vmware.com> Signed-off-by:
Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230905100203.1716731-1-konstantin.meskhidze@huawei.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Björn Töpel authored
[ Upstream commit 2f1b0d3d ] The RISC-V architecture does not expose sub-registers, and hold all 32-bit values in a sign-extended format [1] [2]: | The compiler and calling convention maintain an invariant that all | 32-bit values are held in a sign-extended format in 64-bit | registers. Even 32-bit unsigned integers extend bit 31 into bits | 63 through 32. Consequently, conversion between unsigned and | signed 32-bit integers is a no-op, as is conversion from a signed | 32-bit integer to a signed 64-bit integer. While BPF, on the other hand, exposes sub-registers, and use zero-extension (similar to arm64/x86). This has led to some subtle bugs, where a BPF JITted program has not sign-extended the a0 register (return value in RISC-V land), passed the return value up the kernel, e.g.: | int from_bpf(void); | | long foo(void) | { | return from_bpf(); | } Here, a0 would be 0xffff_ffff, instead of the expected 0xffff_ffff_ffff_ffff. Internally, the RISC-V JIT uses a5 as a dedicated register for BPF return values. Keep a5 zero-extended, but explicitly sign-extend a0 (which is used outside BPF land). Now that a0 (RISC-V ABI) and a5 (BPF ABI) differs, a0 is only moved to a5 for non-BPF native calls (BPF_PSEUDO_CALL). Fixes: 2353ecc6 ("bpf, riscv: add BPF JIT for RV64G") Signed-off-by:
Björn Töpel <bjorn@rivosinc.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf # [2] Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/download/draft-20230929-e5c800e661a53efe3c2678d71a306323b60eb13b/riscv-abi.pdf # [2] Link: https://lore.kernel.org/bpf/20231004120706.52848-2-bjorn@kernel.org Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Pu Lehui authored
[ Upstream commit 0fd1fd01 ] The current emit_call function is not suitable for kernel function call as it store return value to bpf R0 register. We can separate it out for common use. Meanwhile, simplify judgment logic, that is, fixed function address can use jal or auipc+jalr, while the unfixed can use only auipc+jalr. Signed-off-by:
Pu Lehui <pulehui@huawei.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Tested-by:
Björn Töpel <bjorn@rivosinc.com> Acked-by:
Björn Töpel <bjorn@rivosinc.com> Link: https://lore.kernel.org/bpf/20230215135205.1411105-3-pulehui@huaweicloud.com Stable-dep-of: 2f1b0d3d ("riscv, bpf: Sign-extend return values") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Roger Pau Monne authored
[ Upstream commit 66cf7435 ] Do not set netback interfaces (vifs) default TX queue size to the ring size. The TX queue size is not related to the ring size, and using the ring size (32) as the queue size can lead to packet drops. Note the TX side of the vif interface in the netback domain is the one receiving packets to be injected to the guest. Do not explicitly set the TX queue length to any value when creating the interface, and instead use the system default. Note that the queue length can also be adjusted at runtime. Fixes: f942dc25 ('xen network backend driver') Signed-off-by:
Roger Pau Monné <roger.pau@citrix.com> Reviewed-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Acked-by:
Wei Liu <wei.liu@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dan Carpenter authored
[ Upstream commit 1e0b72a2 ] The mlxsw_sp2_nve_vxlan_learning_set() function is supposed to return zero on success or negative error codes. So it needs to be type int instead of bool. Fixes: 4ee70efa ("mlxsw: spectrum_nve: Add support for VXLAN on Spectrum-2") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dinghao Liu authored
[ Upstream commit f990874b ] If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-after-free may happen in the second time we call clk_unregister(). Fix this by removing the first clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock(). Fixes: ded845a7 ("ieee802154: Add CA8210 IEEE 802.15.4 device driver") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Message-ID: <20231007033049.22353-1-dinghao.liu@zju.edu.cn> Signed-off-by:
Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Yoshihiro Shimoda authored
[ Upstream commit 39714428 ] The ravb_stop() should call cancel_work_sync(). Otherwise, ravb_tx_timeout_work() is possible to use the freed priv after ravb_remove() was called like below: CPU0 CPU1 ravb_tx_timeout() ravb_remove() unregister_netdev() free_netdev(ndev) // free priv ravb_tx_timeout_work() // use priv unregister_netdev() will call .ndo_stop() so that ravb_stop() is called. And, after phy_stop() is called, netif_carrier_off() is also called. So that .ndo_tx_timeout() will not be called after phy_stop(). Fixes: c156633f ("Renesas Ethernet AVB driver proper") Reported-by:
Zheng Wang <zyytlz.wz@163.com> Closes: https://lore.kernel.org/netdev/20230725030026.1664873-1-zyytlz.wz@163.com/ Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/20231005011201.14368-3-yoshihiro.shimoda.uh@renesas.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Yoshihiro Shimoda authored
[ Upstream commit e6864af6 ] In ravb_remove(), dma_free_coherent() should be call after unregister_netdev(). Otherwise, this controller is possible to use the freed buffer. Fixes: c156633f ("Renesas Ethernet AVB driver proper") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://lore.kernel.org/r/20231005011201.14368-2-yoshihiro.shimoda.uh@renesas.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Nícolas F. R. A. Prado authored
[ Upstream commit d192615c ] The DSU PMU allows monitoring performance events in the DSU cluster, which is done by configuring and reading back values from the DSU PMU system registers. However, for write-access to be allowed by ELs lower than EL3, the EL3 firmware needs to update the setting on the ACTLR3_EL3 register, as it is disallowed by default. That configuration is not done on the firmware used by the MT8195 SoC, as a consequence, booting a MT8195-based machine like mt8195-cherry-tomato-r2 with CONFIG_ARM_DSU_PMU enabled hangs the kernel just as it writes to the CLUSTERPMOVSCLR_EL1 register, since the instruction faults to EL3, and BL31 apparently just re-runs the instruction over and over. Mark the DSU PMU node in the Devicetree with status "fail", as the machine doesn't have a suitable firmware to make use of it from the kernel, and allowing its driver to probe would hang the kernel. Fixes: 37f25828 ("arm64: dts: Add mediatek SoC mt8195 and evaluation board") Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230720200753.322133-1-nfraprado@collabora.com Link: https://lore.kernel.org/r/20231003-mediatek-fixes-v6-7-v1-5-dad7cd62a8ff@collabora.com Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
John Watts authored
[ Upstream commit 1f223208 ] When adding the RISCV option I didn't gate it behind ARCH_SUNXI. As a result this option shows up with Allwinner support isn't enabled. Fix that by requiring ARCH_SUNXI to be set if RISCV is set. Fixes: 8abb9525 ("can: sun4i_can: Add support for the Allwinner D1") Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/linux-sunxi/CAMuHMdV2m54UAH0X2dG7stEg=grFihrdsz4+o7=_DpBMhjTbkw@mail.gmail.com/ Signed-off-by:
John Watts <contact@jookia.org> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/20230905231342.2042759-2-contact@jookia.org Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Lukas Magel authored
[ Upstream commit d9c2ba65 ] With patch [1], isotp_poll was updated to also queue the poller in the so->wait queue, which is used for send state changes. Since the queue now also contains polling tasks that are not interested in sending, the queue fill state can no longer be used as an indication of send readiness. As a consequence, nonblocking writes can lead to a race and lock-up of the socket if there is a second task polling the socket in parallel. With this patch, isotp_sendmsg does not consult wq_has_sleepers but instead tries to atomically set so->tx.state and waits on so->wait if it is unable to do so. This behavior is in alignment with isotp_poll, which also checks so->tx.state to determine send readiness. V2: - Revert direct exit to goto err_event_drop [1] https://lore.kernel.org/all/20230331125511.372783-1-michal.sojka@cvut.cz Reported-by:
Maxime Jayat <maxime.jayat@mobile-devices.fr> Closes: https://lore.kernel.org/linux-can/11328958-453f-447f-9af8-3b5824dfb041@munic.io/ Signed-off-by:
Lukas Magel <lukas.magel@posteo.net> Reviewed-by:
Oliver Hartkopp <socketcan@hartkopp.net> Fixes: 79e19fa7 ("can: isotp: isotp_ops: fix poll() to not report false EPOLLOUT events") Link: https://github.com/pylessard/python-udsoncan/issues/178#issuecomment-1743786590 Link: https://lore.kernel.org/all/20230827092205.7908-1-lukas.magel@posteo.net Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Marek Behún authored
[ Upstream commit 526c8ee0 ] Besides the QCA8337 switch the Turris 1.x device has on it's MDIO bus also Micron ethernet PHY (dedicated to the WAN port). We've been experiencing a strange behavior of the WAN ethernet interface, wherein the WAN PHY started timing out the MDIO accesses, for example when the interface was brought down and then back up. Bisecting led to commit 2cd54856 ("net: dsa: qca8k: add support for phy read/write with mgmt Ethernet"), which added support to access the QCA8337 switch's internal PHYs via management ethernet frames. Connecting the MDIO bus pins onto an oscilloscope, I was able to see that the MDIO bus was active whenever a request to read/write an internal PHY register was done via an management ethernet frame. My theory is that when the switch core always communicates with the internal PHYs via the MDIO bus, even when externally we request the access via ethernet. This MDIO bus is the same one via which the switch and internal PHYs are accessible to the board, and the board may have other devices connected on this bus. An ASCII illustration may give more insight: +---------+ +----| | | | WAN PHY | | +--| | | | +---------+ | | | | +----------------------------------+ | | | QCA8337 | MDC | | | +-------+ | ------o-+--|--------o------------o--| | | MDIO | | | | | PHY 1 |-|--to RJ45 --------o--|---o----+---------o--+--| | | | | | | | +-------+ | | +-------------+ | o--| | | | | MDIO MDC | | | | PHY 2 |-|--to RJ45 eth1 | | | o--+--| | | -----------|-|port0 | | | +-------+ | | | | | o--| | | | | switch core | | | | PHY 3 |-|--to RJ45 | +-------------+ o--+--| | | | | | +-------+ | | | o--| ... | | +----------------------------------+ When we send a request to read an internal PHY register via an ethernet management frame via eth1, the switch core receives the ethernet frame on port 0 and then communicates with the internal PHY via MDIO. At this time, other potential devices, such as the WAN PHY on Turris 1.x, cannot use the MDIO bus, since it may cause a bus conflict. Fix this issue by locking the MDIO bus even when we are accessing the PHY registers via ethernet management frames. Fixes: 2cd54856 ("net: dsa: qca8k: add support for phy read/write with mgmt Ethernet") Signed-off-by:
Marek Behún <kabel@kernel.org> Reviewed-by:
Christian Marangi <ansuelsmth@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Vladimir Oltean authored
[ Upstream commit 139ad114 ] The protocol converter configuration registers PCC8, PCCC, PCCD (implemented by the driver), as well as others, control protocol converters from multiple lanes (each represented as a different struct phy). So, if there are simultaneous calls to phy_set_mode_ext() to lanes sharing the same PCC register (either for the "old" or for the "new" protocol), corruption of the values programmed to hardware is possible, because lynx_28g_rmw() has no locking. Add a spinlock in the struct lynx_28g_priv shared by all lanes, and take the global spinlock from the phy_ops :: set_mode() implementation. There are no other callers which modify PCC registers. Fixes: 8f73b37c ("phy: add support for the Layerscape SerDes 28G") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Vladimir Oltean authored
[ Upstream commit 0ac87fe5 ] lynx_28g_cdr_lock_check() runs once per second in a workqueue to reset the lane receiver if the CDR has not locked onto bit transitions in the RX stream. But the PHY consumer may do stuff with the PHY simultaneously, and that isn't okay. Block concurrent generic PHY calls by holding the PHY mutex from this workqueue. Fixes: 8f73b37c ("phy: add support for the Layerscape SerDes 28G") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ioana Ciornei authored
[ Upstream commit f200bab3 ] The blamed commit added the CDR check work item but didn't cancel it on the remove path. Fix this by adding a remove function which takes care of it. Fixes: 8f73b37c ("phy: add support for the Layerscape SerDes 28G") Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Stephen Boyd authored
[ Upstream commit eba8c99a ] These debug printks are missing newlines, causing drm debug logs to be hard to read. Add newlines so that the messages are on their own line. Cc: Kuogee Hsieh <quic_khsieh@quicinc.com> Cc: Vinod Polimera <quic_vpolimer@quicinc.com> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Fixes: 601f0479 ("drm/msm/dp: add logs across DP driver for ease of debugging") Fixes: cd779808 ("drm/msm/dp: Add basic PSR support for eDP") Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/554533/ Link: https://lore.kernel.org/r/20230825230109.2264345-1-swboyd@chromium.org Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Abhinav Kumar authored
[ Upstream commit 95e681ca ] _dpu_plane_calc_bw() uses integer variables to calculate the bandwidth used during plane bandwidth calculations. However for high resolution displays this overflows easily and leads to below errors [dpu error]crtc83 failed performance check -7 Promote the intermediate variables to u64 to avoid overflow. changes in v2: - change to u64 where actually needed in the math Fixes: c33b7c03 ("drm/msm/dpu: add support for clk and bw scaling for display") Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reported-by:
Nia Espera <nespera@igalia.com> Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/32 Tested-by:
Nia Espera <nespera@igalia.com> Patchwork: https://patchwork.freedesktop.org/patch/556288/ Link: https://lore.kernel.org/r/20230908012616.20654-1-quic_abhinavk@quicinc.com Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Dan Carpenter authored
[ Upstream commit 6a1d4c79 ] The irq_of_parse_and_map() function returns zero on error. It never returns negative error codes. Fix the check. Fixes: a689554b ("drm/msm: Initial add DSI connector support") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/557715/ Link: https://lore.kernel.org/r/4f3c5c98-04f7-43f7-900f-5d7482c83eef@moroto.mountain Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Abhinav Kumar authored
[ Upstream commit ab483e3a ] dsi_wait4video_done() API waits for the DSI video mode engine to become idle so that we can transmit the DCS commands in the beginning of BLLP. However, with the current sequence, the MDP timing engine is turned on after the panel's pre_enable() callback which can send out the DCS commands needed to power up the panel. During those cases, this API will always timeout and print out the error spam leading to long bootup times and log flooding. Fix this by checking if the DSI video engine was actually busy before waiting for it to become idle otherwise this is a redundant wait. changes in v2: - move the reg read below the video mode check - minor fixes in commit text Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/34 Fixes: a689554b ("drm/msm: Initial add DSI connector support") Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/557853/ Link: https://lore.kernel.org/r/20230915204426.19011-1-quic_abhinavk@quicinc.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Kuogee Hsieh authored
[ Upstream commit 0c1a2e69 ] DP PHY re-initialization done using dp_ctrl_reinitialize_mainlink() will cause PLL unlocked initially and then PLL gets locked at the end of initialization. PLL_UNLOCKED interrupt will fire during this time if the interrupt mask is enabled. However currently DP driver link training implementation incorrectly re-initializes PHY unconditionally during link training as the PHY was already configured in dp_ctrl_enable_mainlink_clocks(). Fix this by re-initializing the PHY only if the previous link training failed. [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy Fixes: c943b494 ("drm/msm/dp: add displayPort driver support") Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/30 Signed-off-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Tested-by: Abhinav Kumar <quic_abhinavk@quicinc.com> # sc7280 Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/551847/ Link: https://lore.kernel.org/r/1691533190-19335-1-git-send-email-quic_khsieh@quicinc.com [quic_abhinavk@quicinc.com: added line break in commit text] Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Mikhail Kobuk authored
[ Upstream commit 87d315a3 ] Write into 'pctrl->gpio_bank' happens before the check for GPIO index validity, so out of bounds write may happen. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a1d1e0e3 ("pinctrl: nuvoton: Add driver for WPCM450") Signed-off-by:
Mikhail Kobuk <m.kobuk@ispras.ru> Reviewed-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Reviewed-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Link: https://lore.kernel.org/r/20230825101532.6624-1-m.kobuk@ispras.ru Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Kailang Yang authored
[ Upstream commit d93eeca6 ] This is merge model ALC287_FIXUP_THINKPAD_I2S_SPK and ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI. Signed-off-by:
Kailang Yang <kailang@realtek.com> Fixes: f7b069cf ("ALSA: hda/realtek: Fix generic fixup definition for cs35l41 amp") Link: https://lore.kernel.org/r/82a45234327c4c50b4988a27e9f64c37@realtek.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Kailang Yang authored
[ Upstream commit e43252db ] 0x17 was only speaker pin, DAC assigned will be 0x03. Headphone assigned to 0x02. Playback via headphone will get EQ filter processing. So,it needs to swap DAC. Tested-by:
Mark Pearson <mpearson@lenovo.com> Signed-off-by:
Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/r/4e4cfa1b3b4c46838aecafc6e8b6f876@realtek.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Stable-dep-of: d93eeca6 ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Fabian Vogt authored
[ Upstream commit c99c26b1 ] The LED for the mic mute button is controlled by GPIO2. The mute button LED is slightly more complex, it's controlled by two bits in coeff 0x0b. Signed-off-by:
Fabian Vogt <fabian@ritter-vogt.de> Link: https://lore.kernel.org/r/2693091.mvXUDI8C0e@fabians-envy Signed-off-by:
Takashi Iwai <tiwai@suse.de> Stable-dep-of: d93eeca6 ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
SungHwan Jung authored
[ Upstream commit 93dc18e1 ] This quirk enables mute LED on HP Victus 16-d1xxx (8A25) laptops, which use ALC245 codec. Signed-off-by:
SungHwan Jung <onenowy@gmail.com> Link: https://lore.kernel.org/r/20230823114051.3921-1-onenowy@gmail.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Stable-dep-of: d93eeca6 ("ALSA: hda/realtek - ALC287 merge RTK codec with CS CS35L41 AMP") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Shengjiu Wang authored
[ Upstream commit 197c53c8 ] On i.MX8MP, the BCE and TERE bit are binding with mclk enablement, if BCE and TERE are cleared the MCLK also be disabled on output pin, that cause the external codec (wm8960) in wrong state. Codec (wm8960) is using the mclk to generate PLL clock, if mclk is disabled before disabling PLL, the codec (wm8960) won't generate bclk and frameclk when sysclk switch to MCLK source in next test case. The test case: $aplay -r44100 test1.wav (PLL source) $aplay -r48000 test2.wav (MCLK source) aplay: pcm_write:2127: write error: Input/output error Fixes: 269f399d ("ASoC: fsl_sai: Disable bit clock with transmitter") Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1695116533-23287-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Shengjiu Wang authored
[ Upstream commit 3e4a8261 ] On i.MX8MP, the sai MCLK is bound with TX/RX enable bit, which means the TX/RE enable bit need to be enabled then MCLK can be output on PAD. Some codec (for example: WM8962) needs the MCLK output earlier, otherwise there will be issue for codec configuration. Add new soc data "mclk_with_tere" for this platform and enable the MCLK output in startup stage. As "mclk_with_tere" only applied to i.MX8MP, currently The soc data is shared with i.MX8MN, so need to add an i.MX8MN own soc data with "mclk_with_tere" disabled. Signed-off-by:
Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://lore.kernel.org/r/1683273322-2525-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by:
Mark Brown <broonie@kernel.org> Stable-dep-of: 197c53c8 ("ASoC: fsl_sai: Don't disable bitclock for i.MX8MP") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Rob Herring authored
[ Upstream commit 2d2998b8 ] It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. Convert reading boolean properties to to of_property_read_bool(). Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230310144733.1546413-1-robh@kernel.org Signed-off-by:
Mark Brown <broonie@kernel.org> Stable-dep-of: 197c53c8 ("ASoC: fsl_sai: Don't disable bitclock for i.MX8MP") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Balamurugan C authored
commit 381ddcd5 upstream. Adding support for ES83x6 codec in MTL match table. Signed-off-by:
Balamurugan C <balamurugan.c@intel.com> Reviewed-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20230919091136.1922253-2-yung-chuan.liao@linux.intel.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-