- 04 Sep, 2024 13 commits
-
-
Marc Kleine-Budde authored
The driver contains workarounds for some of the rk3568v2 errata. Add ethtool-based statistics ("ethtool -S") to track how often an erratum workaround was needed. Tested-by:Alibek Omarov <a1ba.omarov@gmail.com> Acked-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20240904-rockchip-canfd-v5-15-8ae22bcb27cc@pengutronix.deSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
can: rockchip_canfd: rkcanfd_get_berr_counter_corrected(): work around broken {RX,TX}ERRORCNT register Tests show that sometimes both CAN bus error counters read 0x0, even if the controller is in warning mode (RKCANFD_REG_STATE_ERROR_WARNING_STATE in RKCANFD_REG_STATE set). To work around this issue, if both error counters read from hardware are 0x0, use the structure priv->bec, otherwise save the read value in priv->bec. In rkcanfd_handle_rx_int_one() decrement the priv->bec.rxerr for successfully RX'ed CAN frames. In rkcanfd_handle_tx_done_one() decrement the priv->bec.txerr for successfully TX'ed CAN frames. Tested-by: -
Marc Kleine-Budde authored
The rk3568 CAN-FD errata sheet as of Tue 07 Nov 2023 11:25:31 +08:00 says: | A dominant bit at the third bit of the intermission may cause a | transmission error. | | When sampling the third bit of the intermission as a dominant bit, if | tx_req is configured to transmit extended frames at this time, the | extended frame may be sent to the bus in the format of a standard | frame. The extended frame will be sent as a standard frame and will not | result in error frames Turn on "Interframe Spaceing RX Mode" only during TX to work around erratum 12, according to rock-chip: | Spaceing RX Mode = 1, the third Bit between frames cannot receive | and send, and the fourth Bit begins to receive and send. | | Spaceing RX Mode = 0, allowing the third Bit between frames to | receive and send. Message-ID: <be72939f-0a9e-0608-dfff-7b0096a26eba@rock-chips.com> Tested-by:
-
Marc Kleine-Budde authored
The rk3568 CAN-FD errata sheet as of Tue 07 Nov 2023 11:25:31 +08:00 says: | The CAN controller's transmission of extended frames may | intermittently change into standard frames. | | When using the CAN controller to send extended frames, if the | 'tx_req' is configured as 1 and coincides with the internal | transmission point, the extended frame will be transmitted onto the | bus in the format of a standard frame. To work around Erratum 6, the driver is in self-receiving mode (RXSTX) and all received CAN frames are passed through rkcanfd_rxstx_filter(). Add a check in rkcanfd_rxstx_filter() whether the received frame corresponds to the current outgoing frame, but the extended CAN ID has been mangled to a standard ID. In this case re-send the original CAN frame. Tested-by:
-
Marc Kleine-Budde authored
The IP core has a TX event FIFO. In other IP cores, this type of FIFO usually contains the events that a CAN frame has been successfully sent. However, the IP core on the rk3568v2 the FIFO also holds events of unsuccessful transmission attempts. It turned out that the best way to work around this problem is to set the IP core to self-receive mode (RXSTX), filter out the self-received frames and insert them into the complete TX path. Add a pair new functions to check if 2 struct canfd_frame are equal. The 1st checks if the header of the CAN frames are equal, the 2nd checks if the data portion are equal: - rkcanfd_can_frame_header_equal() - rkcanfd_can_frame_data_equal() Tested-by:
-
Marc Kleine-Budde authored
Tests on the rk3568v2 and rk3568v3 show that a reduced "baudclk" (e.g. 80MHz, compared to the standard 300MHz) significantly increases the possibility of incorrect FIFO counters, i.e. erratum 5. Print an info message if the clock is below the known good value of 300MHz. Tested-by:
-
Marc Kleine-Budde authored
can: rockchip_canfd: rkcanfd_handle_rx_int_one(): implement workaround for erratum 5: check for empty FIFO The rk3568 CAN-FD errata sheet as of Tue 07 Nov 2023 11:25:31 +08:00 says: | Erratum 5: Counters related to the TXFIFO and RXFIFO exhibit | abnormal counting behavior. | | Due to a bug in the cross-asynchronous logic of the enable signals | for rx_fifo_cnt and txe_fifo_frame_cnt counters, the counts of these | two counters become inaccurate. This issue has resulted in the | inability to use the TXFIFO and RXFIFO functions. The errata sheet mentioned above states that only the rk3568v2 is affected by this erratum, but tests with the rk3568v2 and rk3568v3 show that the RX_FIFO_CNT is sometimes too high. This leads to CAN frames being read from the FIFO, which is then already empty. Further tests on the rk3568v2 and rk3568v3 show that in this situation (i.e. empty FIFO) all elements of the FIFO header (frameinfo, id, ts) contain the same data. On the rk3568v2 and rk3568v3, this problem only occurs extremely rarely with the standard clock of 300 MHz, but almost immediately at 80 MHz. To workaround this problem, check for empty FIFO with rkcanfd_fifo_header_empty() in rkcanfd_handle_rx_int_one() and exit early. Tested-by:
-
Marc Kleine-Budde authored
Even the rk3568v3 has some known issues. Document them together with a reproducer. Tested-by:
-
Marc Kleine-Budde authored
Add the support for the rk3568v3 SoC, the CAN-FD IP core has 7 documented errata. Tested-by:
-
Marc Kleine-Budde authored
The errata sheets doesn't say anything about CAN-FD, but tests on the rk3568v2 and rk3568v3 show that receiving certain CAN-FD frames triggers an Error Interrupt. Mark the CAN-FD support as broken. Tested-by:
-
Marc Kleine-Budde authored
Add a basic infrastructure for quirks for the 12 documented errata. Tested-by:
-
Marc Kleine-Budde authored
Add driver for the Rockchip CAN-FD controller. The IP core on the rk3568v2 SoC has 12 documented errata. Corrections for these errata will be added in the upcoming patches. Since several workarounds are required for the TX path, only add the base driver that only implements the RX path. Although the RX path implements CAN-FD support, it's not activated in ctrlmode_supported, as the IP core in the rk3568v2 has problems with receiving or sending certain CAN-FD frames. Tested-by:
-
Marc Kleine-Budde authored
Add documentation for the rockchip rk3568 CAN-FD controller. Co-developed-by:
Elaine Zhang <zhangqing@rock-chips.com> Signed-off-by:
Rob Herring (Arm) <robh@kernel.org> Reviewed-by:
-
- 03 Sep, 2024 27 commits
-
-
Yue Haibing authored
Commit 6b7c5b94 ("net: Add be2net driver.") declared be_pci_fnum_get() and be_cmd_reset() but never implemented. And commit 9fa465c0 ("be2net: remove code duplication relating to Lancer reset sequence") removed lancer_test_and_set_rdy_state() but leave declaration. Commit 76a9e08e ("be2net: cleanup wake-on-lan code") left behind be_is_wol_supported() declaration. Commit baaa08d1 ("be2net: do not call be_set/get_fw_log_level() on Skyhawk-R") removed be_get_fw_log_level() but leave declaration. Signed-off-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240902113238.557515-1-yuehaibing@huawei.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Yue Haibing authored
There is no caller and implementation in tree. Signed-off-by:
-
Krzysztof Kozlowski authored
This reverts commit bf4d87f8 because it introduced dev_err_probe() in non-probe path, which is not desired. In general, calling dev_err_probe() after successful probe in case of handling -EPROBE_DEFER error, will set deferred status on the device already probed. This is however not a problem here now, because dev_err_probe() in affected places is used for handling errors from request_firmware(), which does not return -EPROBE_DEFER. Still usage of dev_err_probe() in such case is not correct, because request_firmware() could once return -EPROBE_DEFER. Fixes: bf4d87f8 ("net: alacritech: Switch to use dev_err_probe()") Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Florian Westphal authored
This update allows listing default firewalld ruleset on Fedora 40 via tools/net/ynl/cli.py --spec \ Documentation/netlink/specs/nftables.yaml --dump getrule Default ruleset uses fib, reject and objref expressions which were missing. Other missing expressions can be added later. Improve decoding while at it: - add bitwise, ct and lookup attributes - wire up the quota expression - translate raw verdict codes to a human reable name, e.g. 'code': 4294967293 becomes 'code': 'jump'. v2: forgot fib addrtype in enum list (Donald Hunter) Reviewed-by:Donald Hunter <donald.hunter@gmail.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Link: https://patch.msgid.link/20240902214112.2549-1-fw@strlen.deSigned-off-by:
-
Jakub Kicinski authored
Matthieu Baerts says: ==================== mptcp: MIB counters for MPJ TX + misc improvements Recently, a few issues have been discovered around the creation of additional subflows. Without these counters, it was difficult to point out the reason why some subflows were not created as expected. In patch 3, all error paths from __mptcp_subflow_connect() are covered, except the one related to the 'fully established mode', because it can only happen with the userspace PM, which will propagate the error to the userspace in this case (ENOTCONN). These new counters are also verified in the MPTCP Join selftest in patch 6. While at it, a few other patches are improving the MPTCP path-manager code ... - Patch 1: 'flush' related helpers are renamed to avoid confusions - Patch 2: directly pass known ID and flags to create a new subflow, i/o getting them later by iterating over all endpoints again ... and the MPJoin selftests: - Patch 4: reduce the number of positional parameters - Patch 5: only one line for the 'join' checks, instead of 3 - Patch 7: more explicit check names, instead of sometimes too cryptic ones: rtx, ptx, ftx, ctx, fclzrx, sum - Patch 8: specify client/server instead of 'invert' for some checks not suggesting one specific direction - Patch 9: mute errors of mptcp_connect when ran in the background - Patch 10: simplify checksum_tests by using a for-loop - Patch 11: remove 'define' re-definitions ==================== Link: https://patch.msgid.link/20240902-net-next-mptcp-mib-mpjtx-misc-v1-0-d3e0f3773b90@kernel.orgSigned-off-by: -
Matthieu Baerts (NGI0) authored
'MPTCP_PM_NAME' is defined in 'linux/mptcp_pm.h', included in 'linux/mptcp.h', no need to re-define it. 'MPTCP_PM_EVENTS' is not defined in 'linux/mptcp.h', but 'MPTCP_PM_EV_GRP_NAME' is, with the same value. We can then use the latter, and drop the other one. Reviewed-by:
Geliang Tang <geliang@kernel.org> Signed-off-by:
Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20240902-net-next-mptcp-mib-mpjtx-misc-v1-11-d3e0f3773b90@kernel.orgSigned-off-by:
-
Geliang Tang authored
The four checksum tests are similar, only one line is different. So a for-loop can be used to simplify these tests. Signed-off-by:
Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by:
-
Matthieu Baerts (NGI0) authored
The test is supposed to be killed before the end, which will likely cause "Connection reset by peer" errors. It is confusing, especially because in case of real transfer errors, the test will not be marked as failed. But that's OK, there are many other tests checking that. Reviewed-by:
-
Matthieu Baerts (NGI0) authored
Instead of displaying 'invert' when looking at some events like MP_FAIL, MP_FASTCLOSE, MP_RESET, RM_ADDR, which is a bit vague because they are not traditionnaly sent from one side, the host being checked is now printed. For the ADD_ADDR, only display the host when it is the client sending it, which is more unusual. Also before, the 'invert' message was printed after a few checks, but it was not clear which ones exactly. Reviewed-by:
-
Matthieu Baerts (NGI0) authored
Before, the check names had to be very short. It is no longer the case now that these checks are printed on a dedicated line. Then, it looks better to have more explicit names. Reviewed-by:
-
Matthieu Baerts (NGI0) authored
A few new MPJoinSynTx MIB counters have been added in a previous commit. They are being validated here in mptcp_join.sh selftest, each time the number of received MPJ are checked. Most of the time, the number of sent SYN+MPJ is the same as the received ones. But sometimes, there are more, because there are dropped, or there are errors. While at it, the "no MPC reuse with single endpoint" subtest has been modified to force a bind() error. Reviewed-by:
-
Matthieu Baerts (NGI0) authored
Most tests are checking if the expected number of SYN/SYN+ACK/ACK JOINs have been received, each of them on one line. More Join related tests are going to be checked soon, no need to add 5 new lines per test in case of success, just one is enough. In case of issue, the errors will still be reported like before. Reviewed-by:
-
Matthieu Baerts (NGI0) authored
chk_join_nr() currently takes 9 positional parameters, 6 of them are optional. It makes it hard to read: chk_join_nr 1 1 1 1 0 1 1 0 4 Naming these vars helps to make it easier to read: join_csum_ns1=1 join_csum_ns2=0 \ join_fail_nr=1 join_rst_nr=1 join_infi_nr=0 \ join_corrupted_pkts=4 \ chk_join_nr 1 1 1 It will then be easier to add new optional parameters. Reviewed-by: -
Matthieu Baerts (NGI0) authored
Recently, a few issues have been discovered around the creation of additional subflows. Without these counters, it was difficult to point out the reason why some subflows were not created as expected. These counters should have been added earlier, because there is no other simple ways to extract such information from the kernel, and understand why subflows have not been created. While at it, some pr_debug() have been added, just in case the errno needs to be printed. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/509Reviewed-by:
-
Matthieu Baerts (NGI0) authored
__mptcp_subflow_connect() is currently called from the path-managers, which have all the required information to create subflows. No need to call the PM again to re-iterate over the list of entries with RCU lock to get more info. Instead, it is possible to pass a mptcp_pm_addr_entry structure, instead of a mptcp_addr_info one. The former contains the ifindex and the flags that are required when creating the new subflow. This is a partial revert of commit ee285257 ("mptcp: drop flags and ifindex arguments"). While at it, the local ID can also be set if it is known and 0, to avoid having to set it in the 'rebuild_header' hook, which will cause a new iteration of the endpoint entries. Reviewed-by:
Mat Martineau <martineau@kernel.org> Signed-off-by:
-
Matthieu Baerts (NGI0) authored
Rename all the helpers specific to the flushing operations to make it clear that the intention is to flush all created subflows, and remove all announced addresses, not just a specific selection. That way, it is easier to understand why the id_avail_bitmap and local_addr_used are reset at the end. Reviewed-by:
-
Jakub Kicinski authored
Gal Pressman says: ==================== RX software timestamp for all All devices support SOF_TIMESTAMPING_RX_SOFTWARE by virtue of net_timestamp_check() being called in the device independent code. Following Willem's suggestion [1], make it so drivers do not have to handle SOF_TIMESTAMPING_RX_SOFTWARE and SOF_TIMESTAMPING_SOFTWARE, nor setting of the PHC index to -1. All drivers will now report RX software timestamp as supported. The series is limited to 15 patches, I will submit other drivers in subsequent submissions. [1] https://lore.kernel.org/netdev/661550e348224_23a2b2294f7@willemb.c.googlers.com.notmuch/ v1: https://lore.kernel.org/20240829144253.122215-1-gal@nvidia.com ==================== Link: https://patch.msgid.link/20240901112803.212753-1-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Carolina Jubran <cjubran@nvidia.com> Reviewed-by:
Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by:
Gal Pressman <gal@nvidia.com> Reviewed-by:
Marcin Wojtas <marcin.s.wojtas@gmail.com> Link: https://patch.msgid.link/20240901112803.212753-16-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Subbaraya Sundeep <sbhatta@marvell.com> Link: https://patch.msgid.link/20240901112803.212753-15-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20240901112803.212753-13-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Jijie Shao <shaojijie@huawei.com> Link: https://patch.msgid.link/20240901112803.212753-11-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://patch.msgid.link/20240901112803.212753-10-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Link: https://patch.msgid.link/20240901112803.212753-8-gal@nvidia.comSigned-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Shannon Nelson <shannon.nelson@amd.com> Reviewed-by:
Brett Creeley <brett.creeley@amd.com> Link: https://patch.msgid.link/20240901112803.212753-7-gal@nvidia.comSigned-off-by:
-
