- 30 May, 2022 11 commits
-
-
Larry Finger authored
Sparse lists the following: CHECK drivers/net/wireless/realtek/rtw88/rtw8821c.c drivers/net/wireless/realtek/rtw88/rtw8821c.c:1880:22: warning: symbol 'rtw8821c_hw_spec' was not declared. Should it be static? The warning arises because the external declaration for rtw8821c_hw_spec occurs in rtw8821ce.h, which is not included in rtw8821c.h. That line is moved, and the now empty file rtw8821ce.h is deleted. Symbol 'rtw8821c_hw_spec' can be made constant. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220524153716.20450-1-Larry.Finger@lwfinger.net
-
Larry Finger authored
Sparse lists the following: CHECK drivers/net/wireless/realtek/rtw88/rtw8723d.c drivers/net/wireless/realtek/rtw88/rtw8723d.c:2704:22: warning: symbol 'rtw8723d_hw_spec' was not declared. Should it be static? The warning arises because the external declaration for rtw8723d_hw_spec occurs in rtw8723de.h, which is not included in rtw8723d.h. That line is moved, and the now empty file rtw8723de.h is deleted. Symbol 'rtw8723d_hw_spec' can be made constant. Signed-off-by:
-
Larry Finger authored
Sparse reports the following: CHECK drivers/net/wireless/realtek/rtw88/rtw8822c.c drivers/net/wireless/realtek/rtw88/rtw8822c.c:5313:22: warning: symbol 'rtw8822c_hw_spec' was not declared. Should it be static? The warning arises because the external declaration for rtw8822c_hw_spec occurs in rtw8822ce.h, which is not included in rtw8822c.h. That line is moved, and the now empty file rtw8822ce.h is deleted. Symbol 'rtw8822c_hw_spec' can be made constant. Signed-off-by:
-
Larry Finger authored
Sparse lists the following for rtw88: CHECK drivers/net/wireless/realtek/rtw88/rtw8822b.c drivers/net/wireless/realtek/rtw88/rtw8822b.c:2500:22: warning: symbol 'rtw8822b_hw_spec' was not declared. Should it be static? The warning arises because the external declaration for rtw8822b_hw_spec occurs in rtw8822be.h, which is not included in rtw8822b.h. That line is moved, and the now empty file rtw8822be.h is deleted. Symbol 'rtw8822b_hw_spec' can be made constant. Signed-off-by:
-
Po-Hao Huang authored
Add this check to avoid crash by dereferencing a null pointer. When hwscan fails due to no memory or dma failure, the scan flag in ieee80211_local is cleared. So mac80211 determine that it's not hw_scan then calls sw_scan_complete() with null vif, which is also freed during the fail. Signed-off-by:
Po-Hao Huang <phhuang@realtek.com> Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Zong-Zhe Yang authored
Since SAR is more expected to follow U-NII bands to plan subbands, division of 6GHz band is quite different from defined enum of subbands which is used by PHY in most cases. It's hard and painful if we want to keep using the same enum on SAR. So, we introduce another enum for SAR subbands and adjust SAR flow to use it. Besides, since 6GHz SAR subbands won't be divided with edge alignment, some cases will span two SAR subbands. For these cases, we describe them within an array of rtw89_sar_span and take the smaller one between SAR settings of the two subbands. Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
RX DCK is receiver DC calibration. To keep good RF performance, do this calibration again if the delta of thermal value from the last calibration is more than 8. Signed-off-by:
-
Ping-Ke Shih authored
This watchdog timeout status bit indicates hardware gets wrong, so run SER L2 flow that calls mac80211 to restart hardware. Signed-off-by:
-
Po Hao Huang authored
Add this check to avoid crash by dereferencing a null pointer. When hwscan fails due to no memory or dma failure, the scan flag in ieee80211_local is cleared. So mac80211 determine that it's not hw_scan then calls sw_scan_complete() with null vif, which is also freed during the fail. Signed-off-by:
-
Po Hao Huang authored
Previously channel maintained by driver could be different from the ones hardware actually is. Restore these variables back to prevent unexpected behavior. Signed-off-by:
-
Bernard Zhao authored
Delete if NULL check before dev_kfree_skb call. This change is to cleanup the code a bit. Signed-off-by:
Bernard Zhao <bernard@vivo.com> Signed-off-by:
-
- 20 May, 2022 29 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-nextJakub Kicinski authored
Pablo Neira Ayuso says: ==================== Netfilter updates for net-next The following patchset contains Netfilter updates for net-next, misc updates and fallout fixes from recent Florian's code rewritting (from last pull request): 1) Use new flowi4_l3mdev field in ip_route_me_harder(), from Martin Willi. 2) Avoid unnecessary GC with a timestamp in conncount, from William Tu and Yifeng Sun. 3) Remove TCP conntrack debugging, from Florian Westphal. 4) Fix compilation warning in ctnetlink, from Florian. * git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next: netfilter: ctnetlink: fix up for "netfilter: conntrack: remove unconfirmed list" netfilter: conntrack: remove pr_debug callsites from tcp tracker netfilter: nf_conncount: reduce unnecessary GC netfilter: Use l3mdev flow key when re-routing mangled packets ==================== Link: https://lore.kernel.org/r/20220519220206.722153-1-pablo@netfilter.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
I missed this in the barrage of GCC 12 warnings. Commit cf2df74e ("net: fix dev_fill_forward_path with pppoe + bridge") changed the pointer into an array. Fixes: d7e6f583 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net") Link: https://lore.kernel.org/r/20220520012555.2262461-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Mat Martineau says: ==================== mptcp: Miscellaneous fixes and a new test case Patches 1 and 3 remove helpers that were iterating over the subflow connection list without proper locking. Iteration was not needed in either case. Patch 2 fixes handling of MP_FAIL timeout, checking for orphaned subflows instead of using the MPTCP socket data lock and connection state. Patch 4 adds a test for MP_FAIL timeout using tc pedit to induce checksum failures. ==================== Link: https://lore.kernel.org/r/20220518220446.209750-1-mathew.j.martineau@linux.intel.comSigned-off-by:
-
Geliang Tang authored
Add the multiple subflows test case for MP_FAIL, to test the MP_FAIL reset case. Use the test_linkfail value to make 1024KB test files. Invoke reset_with_fail() to use 'iptables' and 'tc action pedit' rules to produce the bit flips to trigger the checksum failures on ns2eth2. Add delays on ns2eth1 to make sure more data can translate on ns2eth2. The check_invert flag is enabled in reset_with_fail(), so this test prints out the inverted bytes, instead of the file mismatch errors. Invoke pedit_action_pkts() to get the numbers of the packets edited by the tc pedit actions, and print this numbers to the output. Co-developed-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Geliang Tang <geliang.tang@suse.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Mat Martineau authored
The MPTCP socket's conn_list (list of subflows) requires the socket lock to access. The MP_FAIL timeout code added such an access, where it would check the list of subflows both in timer context and (later) in workqueue context where the socket lock is held. Rather than check the list twice, remove the check in the timeout handler and only depend on the check in the workqueue. Also remove the MPTCP_FAIL_NO_RESPONSE flag, since mptcp_mp_fail_no_response() has insignificant overhead and can be checked on each worker run. Fixes: 49fa1919 ("mptcp: reset subflow when MP_FAIL doesn't respond") Reported-by:
-
Mat Martineau authored
MP_FAIL timeout (waiting for a peer to respond to an MP_FAIL with another MP_FAIL) is implemented using the MPTCP socket's sk_timer. That timer is also used at MPTCP socket close, so it's important to not have the two timer users interfere with each other. At MPTCP socket close, all subflows are orphaned before sk_timer is manipulated. By checking the SOCK_DEAD flag on the subflows, each subflow can determine if the timer is safe to alter without acquiring any MPTCP-level lock. This replaces code that was using the mptcp_data_lock and MPTCP-level socket state checks that did not correctly protect the timer. Fixes: 49fa1919 ("mptcp: reset subflow when MP_FAIL doesn't respond") Reviewed-by:
-
Paolo Abeni authored
The mentioned helper requires the msk socket lock, and the current callers don't own it nor can't acquire it, so the access is racy. All the current callers are really checking for infinite mapping fallback, and the latter condition is explicitly tracked by the relevant msk variable: we can safely remove the caller usage - and the caller itself. The issue is present since MP_FAIL implementation, but the fix only applies since the infinite fallback support, ence the somewhat unexpected fixes tag. Fixes: 0530020a ("mptcp: track and update contiguous data status") Acked-and-tested-by:
-
Yuchung Cheng authored
This patch improves TCP PRR loss recovery behavior for a corner case. Previously during PRR conservation-bound mode, it strictly sends the amount equals to the amount newly acked or s/acked. The patch changes s.t. PRR may send additional amount that was banked previously (e.g. application-limited) in the conservation-bound mode, similar to the slow-start mode. This unifies and simplifies the algorithm further and may improve the recovery latency. This change still follow the general packet conservation design principle and always keep inflight/cwnd below the slow start threshold set by the congestion control module. PRR is described in RFC 6937. We'll include this change in the latest revision rfc6937-bis as well. Reported-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20220519003410.2531936-1-ycheng@google.comSigned-off-by:
-
Jakub Kicinski authored
The current title of our section of the documentation is Linux Networking Documentation. Since we're describing a section of Linux Documentation repeating those two words seems redundant. Link: https://lore.kernel.org/r/20220518234346.2088436-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
GCC 12 seems upset that we check ipa_irq against array bound but then proceed, anyway: drivers/net/ipa/ipa_interrupt.c: In function ‘ipa_interrupt_add’: drivers/net/ipa/ipa_interrupt.c:196:27: warning: array subscript 30 is above array bounds of ‘void (*[30])(struct ipa *, enum ipa_irq_id)’ [-Warray-bounds] 196 | interrupt->handler[ipa_irq] = handler; | ~~~~~~~~~~~~~~~~~~^~~~~~~~~ drivers/net/ipa/ipa_interrupt.c:42:27: note: while referencing ‘handler’ 42 | ipa_irq_handler_t handler[IPA_IRQ_COUNT]; | ^~~~~~~ Reviewed-by:Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20220519004417.2109886-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
GCC 12 warns: drivers/net/wwan/iosm/iosm_ipc_protocol_ops.c: In function ‘ipc_protocol_dl_td_process’: drivers/net/wwan/iosm/iosm_ipc_protocol_ops.c:406:13: warning: the comparison will always evaluate as ‘true’ for the address of ‘cb’ will never be NULL [-Waddress] 406 | if (!IPC_CB(skb)) { | ^ Indeed the check seems entirely pointless. Hopefully the other validation checks will catch if the cb is bad, but it can't be NULL. Reviewed-by:M Chetan Kumar <m.chetan.kumar@intel.com> Link: https://lore.kernel.org/r/20220519004342.2109832-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Martin Blumenstingl says: ==================== lantiq_gswip: Two small fixes While updating the Lantiq target in OpenWrt to Linux 5.15 I came across an FDB related error message. While that still needs to be solved I found two other small issues on the way. This series fixes the two minor issues found while revisiting the FDB code in the lantiq_gswip driver: - The first patch fixes the start index used in gswip_port_fdb() to find the entry with the matching bridge. The updated logic is now consistent with the rest of the driver. - The second patch fixes a typo in a dev_err() message. [0] https://lore.kernel.org/netdev/20220517194015.1081632-1-martin.blumenstingl@googlemail.com/ ==================== Link: https://lore.kernel.org/r/20220518220051.1520023-1-martin.blumenstingl@googlemail.comSigned-off-by:
-
Martin Blumenstingl authored
gswip_port_fdb_dump() reads the MAC bridge entries. The error message should say "failed to read mac bridge entry". While here, also add the index to the error print so humans can get to the cause of the problem easier. Acked-by:
Hauke Mehrtens <hauke@hauke-m.de> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
Martin Blumenstingl authored
The first N entries in priv->vlans are reserved for managing ports which are not part of a bridge. Use priv->hw_info->max_ports to consistently access per-bridge entries at index 7. Starting at priv->hw_info->cpu_port (6) is harmless in this case because priv->vlan[6].bridge is always NULL so the comparison result is always false (which results in this entry being skipped). Acked-by:
-
Ricardo Martinez authored
t7xx_request_irq() error: uninitialized symbol 'ret'. t7xx_core_hk_handler() error: potentially dereferencing uninitialized 'event'. If the condition to enter the loop that waits for the handshake event is false on the first iteration then the uninitialized 'event' will be dereferenced, fix this by initializing 'event' to NULL. t7xx_port_proxy_recv_skb() warn: variable dereferenced before check 'skb'. No need to check skb at t7xx_port_proxy_recv_skb() since we know it is always called with a valid skb by t7xx_cldma_gpd_rx_from_q(). Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Ricardo Martinez <ricardo.martinez@linux.intel.com> Link: https://lore.kernel.org/r/20220518195529.126246-1-ricardo.martinez@linux.intel.comSigned-off-by:
-
Jakub Kicinski authored
Russell King says: ==================== mtk_eth_soc phylink updates This series ultimately updates mtk_eth_soc to use phylink_pcs, with some fixes along the way. Previous attempts to update this driver (which is now marked as legacy) have failed due to lack of testing. I am hoping that this time will be different; Marek can test RGMII modes, but not SGMII. So all that we know is that this patch series probably doesn't break RGMII. 1) remove unused mac_mode and sgmii flags members from structures. 2) remove unnecessary interpretation of speed when configuring 1000 and 2500 Base-X 3) move configuration of SGMII duplex setting from mac_config() to link_up() 4) only pass in interface mode to mtk_sgmii_setup_mode_force() 5) move decision about which mtk_sgmii_setup_mode_*() function to call into mtk_sgmii.c 6) add a fixme comment for RGMII explaning why the call to mtk_gmac0_rgmii_adjust() is completely wrong - this needs to be addressed by someone who has the hardware and can test an appropriate fix. This fixme means that the driver still can't become non-legacy. 7) move gmac setup from mac_config() to mac_finish() - this preserves the order that we write to the hardware when we eventually convert to phylink_pcs() 8) move configuration of syscfg0 in SGMII/802.3z mode to mac_finish() for the same reasons as (7). 9) convert mtk_sgmii.c code structure and the mtk_sgmii structure to suit conversion to phylink_pcs 10) finally convert to phylink_pcs As there has been no feedback from mtk_eth_soc maintainers to my RFC on April 6th, not my reminder on April 11th, so it's now time to merge this anyway. Mediatek code seems to be submitted to the kernel and then the maintainers scarper... ==================== Link: https://lore.kernel.org/r/YoUIX+BN/ZbyXzTT@shell.armlinux.org.ukTested-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
-
Russell King (Oracle) authored
Partially convert mtk_eth_soc to phylink_pcs, moving the configuration, link up and AN restart over. However, it seems mac_pcs_get_state() doesn't actually get the state from the PCS, so we can't convert that over without a better understanding of the hardware. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King (Oracle) authored
Provide a mtk_pcs structure which encapsulates everything that the PCS functions need (the regmap and ana_rgc3 offset), and use this in the PCS functions. Provide shim functions to convert from the existing "mtk_sgmii_*" interface to the converted PCS functions. Signed-off-by:
-
Russell King (Oracle) authored
The SGMIISYS configuration is performed while ETHSYS_SYSCFG0 is in a disabled state. In order to preserve this when we switch to phylink_pcs we need to move the restoration of this register to the mac_finish() callback. Signed-off-by:
-
Russell King (Oracle) authored
Move the setting of the MTK_MAC_MCR register from the end of mac_config into the phylink mac_finish() method, to keep it as the very last write that is done during configuration. Signed-off-by:
-
Russell King (Oracle) authored
Add a fixme comment for the last remaining incorrect usage of state->speed in the mac_config() method, which is strangely in a code path which is only run when the PHY interface mode changes. This means if we are in RGMII mode, changes in state->speed will not cause the INTF_MODE, TRGMII_RCK_CTRL and TRGMII_TCK_CTRL registers to be set according to the speed, nor will the TRGPLL clock be set to the correct value. Signed-off-by:
-
Russell King (Oracle) authored
Provide mtk_sgmii_config() to wrap up the decisions about which SGMII configuration will be called. Signed-off-by:
-
Russell King (Oracle) authored
Now that mtk_sgmii_setup_mode_force() only uses the interface mode from the phylink state, pass just the interface mode into this function. Signed-off-by:
-
Russell King authored
Phylink does not guarantee that state->duplex will be set correctly in the mac_config() call, so it's a bug that the driver makes use of it. Move the 802.3z PCS duplex configuration to mac_link_up(). Signed-off-by:
-
Russell King (Oracle) authored
Phylink does not guarantee that state->speed will be set correctly in the mac_config() call, so it's a bug that the driver makes use of it. Moreover, it is making use of it in a function that is only ever called for 1000BASE-X and 2500BASE-X which operate at a fixed speed which happens to be the same setting irrespective of the interface mode. We can simply remove the switch statement and just set the SGMII interface speed. Signed-off-by:
-
Russell King (Oracle) authored
The PCS speed setting is a two bit field, but it is defined as two separate bits. Add a bitfield mask for the speed definitions, an use the FIELD_PREP() macro to define each PCS speed. Signed-off-by:
-
Russell King (Oracle) authored
The "flags" member of struct mtk_sgmii appears to be unused, as are the MTK_SGMII_PHYSPEED_* and MTK_HAS_FLAGS() macros. Remove them. Signed-off-by:
-
Russell King (Oracle) authored
mac->mode is only ever written to in one location, and is thus superflous. Remove it. Signed-off-by:
-
Jakub Kicinski authored
Artem points out that skb may try to take over the skb and queue it to its own list. Unlink the skb before calling out. Fixes: b1a2c178 ("tls: rx: clear ctx->recv_pkt earlier") Reported-by:
Artem Savkov <asavkov@redhat.com> Tested-by:
-
