- 10 Mar, 2022 31 commits
-
-
Marc Kleine-Budde authored
Newer versions of the widely used open source firmware candleLight support hardware timestamps. The support is activated by setting the GS_CAN_MODE_HW_TIMESTAMP in the GS_USB_BREQ_MODE request. Although timestamp support is not yet supported by this driver, add the missing bit for documentation purpose. Link: https://lore.kernel.org/all/20220309124132.291861-9-mkl@pengutronix.de Link: https://github.com/candle-usb/candleLight_fw/commit/44431f4a4354a878fbd15b273bf04fce1dcdff7eSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch moves the call to SET_NETDEV_DEV() after all handling (including cleanup) of the bt_const->feature is done. This looks more consistent. Link: https://lore.kernel.org/all/20220309124132.291861-8-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch rewraps the arguments of usb_control_msg() and usb_fill_bulk_urb() to make full use of the standard line length of 80 characters. Link: https://lore.kernel.org/all/20220309124132.291861-7-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch rewraps the arguments of netdev_err() to make full use of the standard line length of 80 characters. Link: https://lore.kernel.org/all/20220309124132.291861-6-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch converts the driver to use BIT() to define flags. Link: https://lore.kernel.org/all/20220309124132.291861-5-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch sorts the include files alphabetically. Link: https://lore.kernel.org/all/20220309124132.291861-4-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
This patch fixes a checkpatch warning by converting a "unsigned" into an "unsigned int". Link: https://lore.kernel.org/all/20220309124132.291861-3-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
With this patch a consistent one space indention throughout the whole driver is used. Link: https://lore.kernel.org/all/20220309124132.291861-2-mkl@pengutronix.deSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Ulrich Hecht authored
Adds support for the CANFD IP variant in the V3U SoC. Differences to controllers in other SoCs are limited to an increase in the number of channels from two to eight, an absence of dedicated registers for "classic" CAN mode, and a number of differences in magic numbers (register offsets and layouts). Inspired by BSP patch by Kazuya Mizuguchi. Link: https://lore.kernel.org/all/20220309162609.3726306-2-uli+renesas@fpond.euSigned-off-by: Ulrich Hecht <uli+renesas@fpond.eu> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Ulrich Hecht authored
Document support for rcar_canfd on R8A779A0 (V3U) SoCs. Link: https://lore.kernel.org/all/20220309162609.3726306-5-uli+renesas@fpond.euSigned-off-by: Ulrich Hecht <uli+renesas@fpond.eu> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Vincent Mailhol authored
can: etas_es58x: es58x_fd_rx_event_msg(): initialize rx_event_msg before calling es58x_check_msg_len() Function es58x_fd_rx_event() invokes the es58x_check_msg_len() macro: | ret = es58x_check_msg_len(es58x_dev->dev, *rx_event_msg, msg_len); While doing so, it dereferences an uninitialized variable: *rx_event_msg. This is actually harmless because es58x_check_msg_len() only uses preprocessor macros (sizeof() and __stringify()) on *rx_event_msg. c.f. [1]. Nonetheless, this pattern is confusing so the lines are reordered to make sure that rx_event_msg is correctly initialized. This patch also fixes a false positive warning reported by cppcheck: | cppcheck possible warnings: (new ones prefixed by >>, may not be real problems) | | In file included from drivers/net/can/usb/etas_es58x/es58x_fd.c: | >> drivers/net/can/usb/etas_es58x/es58x_fd.c:174:8: warning: Uninitialized variable: rx_event_msg [uninitvar] | ret = es58x_check_msg_len(es58x_dev->dev, *rx_event_msg, msg_len); | ^ [1] https://elixir.bootlin.com/linux/v5.16/source/drivers/net/can/usb/etas_es58x/es58x_core.h#L467 Link: https://lore.kernel.org/all/20220306101302.708783-1-mailhol.vincent@wanadoo.frSigned-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Oliver Hartkopp authored
The vxcan driver provides a pair of virtual CAN interfaces to exchange CAN traffic between different namespaces - analogue to veth. In opposite to the vcan driver the local sent CAN traffic on this interface is not echo'ed back but only sent to the remote peer. This is unusual and can be easily fixed by removing IFF_ECHO from the netdevice flags that are set for vxcan interfaces by default at startup. Without IFF_ECHO set on driver level, the local sent CAN frames are echo'ed in af_can.c in can_send(). This patch makes vxcan interfaces adopt the same local echo behavior and procedures as known from the vcan interfaces. Fixes: a8f820a3 ("can: add Virtual CAN Tunnel driver (vxcan)") Link: https://lore.kernel.org/all/20220309120416.83514-5-socketcan@hartkopp.netSigned-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Oliver Hartkopp authored
With can_create_echo_skb() the skb which is forwarded to the peer CAN interface shares the sk pointer from the originating socket. This makes the CAN frame show up in the peer namespace as a TX packet. With the use of skb_clone() analogue to the handling in gw.c the peer skb gets a new start in the peer namespace and correctly appears as a RX packet. Link: https://lore.kernel.org/all/20220309120416.83514-4-socketcan@hartkopp.netSigned-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Oliver Hartkopp authored
The reason to extend the max PDU size from 4095 Byte (12 bit length value) to a 32 bit value (up to 4 GByte) was to be able to flash 64 kByte bootloaders with a single ISO-TP PDU. The max PDU size in the Linux kernel implementation was set to 8200 Bytes to be able to test the length information escape sequence. It turns out that the demand for 64 kByte PDUs is real so the value for MAX_MSG_LENGTH is set to 66000 to be able to potentially add some checksums to the 65.536 Byte block. Link: https://github.com/linux-can/can-utils/issues/347#issuecomment-1056142301 Link: https://lore.kernel.org/all/20220309120416.83514-3-socketcan@hartkopp.netSigned-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Oliver Hartkopp authored
The N_As value describes the time a CAN frame needs on the wire when transmitted by the CAN controller. Even very short CAN FD frames need arround 100 usecs (bitrate 1Mbit/s, data bitrate 8Mbit/s). Having N_As to be zero (the former default) leads to 'no CAN frame separation' when STmin is set to zero by the receiving node. This 'burst mode' should not be enabled by default as it could potentially dump a high number of CAN frames into the netdev queue from the soft hrtimer context. This does not affect the system stability but is just not nice and cooperative. With this N_As/frame_txtime value the 'burst mode' is disabled by default. As user space applications usually do not set the frame_txtime element of struct can_isotp_options the new in-kernel default is very likely overwritten with zero when the sockopt() CAN_ISOTP_OPTS is invoked. To make sure that a N_As value of zero is only set intentional the value '0' is now interpreted as 'do not change the current value'. When a frame_txtime of zero is required for testing purposes this CAN_ISOTP_FRAME_TXTIME_ZERO u32 value has to be set in frame_txtime. Link: https://lore.kernel.org/all/20220309120416.83514-2-socketcan@hartkopp.netSigned-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Oliver Hartkopp authored
Instead of dumping the CAN frames into the netdevice queue the process to transmit consecutive frames (CF) now waits for the frame to be transmitted and therefore echo'ed from the CAN interface. Link: https://lore.kernel.org/all/20220309120416.83514-1-socketcan@hartkopp.netSigned-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Luiz Angelo Daros de Luca authored
DSA_TAG_PROTO_RTL8_4L is not defined. It should be DSA_TAG_PROTO_RTL8_4T. Fixes: cd87fecd ("net: dsa: tag_rtl8_4: add rtl8_4t trailing variant") Reported-by: Arınç ÜNAL <arinc.unal@arinc9.com> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20220309175641.12943-1-luizluca@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Robert Hancock authored
Use napi_alloc_skb to allocate memory when refilling the RX ring in axienet_poll for more efficiency. napi_alloc_skb() can reuse softirq-local cache of freed skbs which may still be cache-warm and skipping allocator calls. Signed-off-by: Robert Hancock <robert.hancock@calian.com> Link: https://lore.kernel.org/r/20220308211013.1530955-1-robert.hancock@calian.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
Back when tcp_tso_autosize() and TCP pacing were introduced, our focus was really to reduce burst sizes for long distance flows. The simple heuristic of using sk_pacing_rate/1024 has worked well, but can lead to too small packets for hosts in the same rack/cluster, when thousands of flows compete for the bottleneck. Neal Cardwell had the idea of making the TSO burst size a function of both sk_pacing_rate and tcp_min_rtt() Indeed, for local flows, sending bigger bursts is better to reduce cpu costs, as occasional losses can be repaired quite fast. This patch is based on Neal Cardwell implementation done more than two years ago. bbr is adjusting max_pacing_rate based on measured bandwidth, while cubic would over estimate max_pacing_rate. /proc/sys/net/ipv4/tcp_tso_rtt_log can be used to tune or disable this new feature, in logarithmic steps. Tested: 100Gbit NIC, two hosts in the same rack, 4K MTU. 600 flows rate-limited to 20000000 bytes per second. Before patch: (TSO sizes would be limited to 20000000/1024/4096 -> 4 segments per TSO) ~# echo 0 >/proc/sys/net/ipv4/tcp_tso_rtt_log ~# nstat -n;perf stat ./super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000;nstat|egrep "TcpInSegs|TcpOutSegs|TcpRetransSegs|Delivered" 96005 Performance counter stats for './super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000': 65,945.29 msec task-clock # 2.845 CPUs utilized 1,314,632 context-switches # 19935.279 M/sec 5,292 cpu-migrations # 80.249 M/sec 940,641 page-faults # 14264.023 M/sec 201,117,030,926 cycles # 3049769.216 GHz (83.45%) 17,699,435,405 stalled-cycles-frontend # 8.80% frontend cycles idle (83.48%) 136,584,015,071 stalled-cycles-backend # 67.91% backend cycles idle (83.44%) 53,809,530,436 instructions # 0.27 insn per cycle # 2.54 stalled cycles per insn (83.36%) 9,062,315,523 branches # 137422329.563 M/sec (83.22%) 153,008,621 branch-misses # 1.69% of all branches (83.32%) 23.182970846 seconds time elapsed TcpInSegs 15648792 0.0 TcpOutSegs 58659110 0.0 # Average of 3.7 4K segments per TSO packet TcpExtTCPDelivered 58654791 0.0 TcpExtTCPDeliveredCE 19 0.0 After patch: ~# echo 9 >/proc/sys/net/ipv4/tcp_tso_rtt_log ~# nstat -n;perf stat ./super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000;nstat|egrep "TcpInSegs|TcpOutSegs|TcpRetransSegs|Delivered" 96046 Performance counter stats for './super_netperf 600 -H otrv6 -l 20 -- -K dctcp -q 20000000': 48,982.58 msec task-clock # 2.104 CPUs utilized 186,014 context-switches # 3797.599 M/sec 3,109 cpu-migrations # 63.472 M/sec 941,180 page-faults # 19214.814 M/sec 153,459,763,868 cycles # 3132982.807 GHz (83.56%) 12,069,861,356 stalled-cycles-frontend # 7.87% frontend cycles idle (83.32%) 120,485,917,953 stalled-cycles-backend # 78.51% backend cycles idle (83.24%) 36,803,672,106 instructions # 0.24 insn per cycle # 3.27 stalled cycles per insn (83.18%) 5,947,266,275 branches # 121417383.427 M/sec (83.64%) 87,984,616 branch-misses # 1.48% of all branches (83.43%) 23.281200256 seconds time elapsed TcpInSegs 1434706 0.0 TcpOutSegs 58883378 0.0 # Average of 41 4K segments per TSO packet TcpExtTCPDelivered 58878971 0.0 TcpExtTCPDeliveredCE 9664 0.0 Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Link: https://lore.kernel.org/r/20220309015757.2532973-1-eric.dumazet@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
tcp_should_autocork() is evaluating if it makes senses to not immediately send current skb, hoping that user space will add more payload on it by the time TCP stack reacts to upcoming TX completions. If current skb got MSG_EOR mark, then we know that no further data will be added, it is therefore futile to wait. SOF_TIMESTAMPING_TX_ACK will become a bit more accurate, if prior packets are still in qdisc/device queues. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Willem de Bruijn <willemb@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Link: https://lore.kernel.org/r/20220309054706.2857266-1-eric.dumazet@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Michael Sit Wei Hong authored
Add PCI ID for Ethernet TSN Controller on ADL-N. Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com> Link: https://lore.kernel.org/r/20220309033415.3370250-1-michael.wei.hong.sit@intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Dust Li authored
when CONFIG_SYSCTL not set, smc_sysctl_net_init/exit need to be static inline to avoid missing-prototypes if compile with W=1. Since __net_exit has noinline annotation when CONFIG_NET_NS not set, it should not be used with static inline. So remove the __net_init/exit when CONFIG_SYSCTL not set. Fixes: 7de8eb0d ("net/smc: fix compile warning for smc_sysctl") Signed-off-by: Dust Li <dust.li@linux.alibaba.com> Link: https://lore.kernel.org/r/20220309033051.41893-1-dust.li@linux.alibaba.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Dimitris Michailidis says: ==================== net/fungible: fix errors when CONFIG_TLS_DEVICE=n This pair of patches fix compile errors in funeth when CONFIG_TLS_DEVICE=n. The errors are due to symbols that are not defined in this config but are used in code guarded by "if (IS_ENABLED(CONFIG_TLS_DEVICE) ..." One option is to place this code under preprocessor guards that will keep the compiler from looking at the code. The option adopted here is to define the offending symbols also when CONFIG_TLS_DEVICE=n. The first patch does this for two functions in tls.h. The second does the same for driver symbols and makes tls.h inclusion unconditional. ==================== Link: https://lore.kernel.org/r/20220309034032.405212-1-dmichail@fungible.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Dimitris Michailidis authored
Include the TLS headers unconditionally and define driver TLS symbols used in code compiled also when CONFIG_TLS_DEVICE=n to fix the following errors: ../drivers/net/ethernet/fungible/funeth/funeth_tx.c: In function ‘write_pkt_desc’: ../drivers/net/ethernet/fungible/funeth/funeth_tx.c:244:13: error: implicit declaration of function ‘tls_driver_ctx’ [-Werror=implicit-function-declaration] 244 | tls_ctx = tls_driver_ctx(skb->sk, TLS_OFFLOAD_CTX_DIR_TX); | ^~~~~~~~~~~~~~ ../drivers/net/ethernet/fungible/funeth/funeth_tx.c:244:37: error: ‘TLS_OFFLOAD_CTX_DIR_TX’ undeclared (first use in this function) 244 | tls_ctx = tls_driver_ctx(skb->sk, TLS_OFFLOAD_CTX_DIR_TX); | ^~~~~~~~~~~~~~~~~~~~~~ ../drivers/net/ethernet/fungible/funeth/funeth_tx.c:244:37: note: each undeclared identifier is reported only once for each function it appears in ../drivers/net/ethernet/fungible/funeth/funeth_tx.c:245:23: error: dereferencing pointer to incomplete type ‘struct fun_ktls_tx_ctx’ 245 | tls->tlsid = tls_ctx->tlsid; | ^~ ../drivers/net/ethernet/fungible/funeth/funeth_tx.c: In function ‘fun_start_xmit’: ../drivers/net/ethernet/fungible/funeth/funeth_tx.c:310:6: error: implicit declaration of function ‘tls_is_sk_tx_device_offloaded’ [-Werror=implicit-function-declaration] 310 | tls_is_sk_tx_device_offloaded(skb->sk)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../drivers/net/ethernet/fungible/funeth/funeth_tx.c:311:9: error: implicit declaration of function ‘fun_tls_tx’; did you mean ‘fun_xdp_tx’? [-Werror=implicit-function-declaration] 311 | skb = fun_tls_tx(skb, q, &tls_len); | ^~~~~~~~~~ | fun_xdp_tx ../drivers/net/ethernet/fungible/funeth/funeth_tx.c:311:7: warning: assignment to ‘struct sk_buff *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 311 | skb = fun_tls_tx(skb, q, &tls_len); | ^ Fixes: db37bc17 ("net/funeth: add the data path") Reported-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Dimitris Michailidis <dmichail@fungible.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Dimitris Michailidis authored
Having the definitions of {__,}tls_driver_ctx() under an #if guard means code referencing them also needs to rely on the preprocessor. The protection doesn't appear needed so make the definitions unconditional. Fixes: db37bc17 ("net/funeth: add the data path") Reported-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Dimitris Michailidis <dmichail@fungible.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
This reverts: commit 02acd399 ("bnxt_en: parse result field when NVRAM package install fails") commit 22f5dba5 ("bnxt_en: add an nvm test for hw diagnose") commit bafed3f2 ("bnxt_en: implement hw health reporter") These patches are still under discussion / I don't think they are right, and since the authors don't reply promptly let me lessen my load of "things I need to resolve before next release" and revert them. Acked-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/20220308173659.304915-1-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Heiner Kallweit authored
If HW doesn't support PTP, then it doesn't support it. This is neither a problem nor can the user do something about it. Therefore change the message level to info. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/ee685745-f1ab-e9bf-f20e-077d55dff441@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Chen Yu authored
There is occasional suspend error from e1000e which blocks the system from further suspending. And the issue was found on a WhiskeyLake-U platform with I219-V: [ 20.078957] PM: pci_pm_suspend(): e1000e_pm_suspend+0x0/0x780 [e1000e] returns -2 [ 20.078970] PM: dpm_run_callback(): pci_pm_suspend+0x0/0x170 returns -2 [ 20.078974] e1000e 0000:00:1f.6: PM: pci_pm_suspend+0x0/0x170 returned -2 after 371012 usecs [ 20.078978] e1000e 0000:00:1f.6: PM: failed to suspend async: error -2 According to the code flow, this might be caused by broken MDI read/write to PHY registers. However currently the code does not tell us which register is broken. Thus enhance the debug information to print the offender PHY register. So the next the issue is reproduced, this information could be used for narrow down. Acked-by: Paul Menzel <pmenzel@molgen.mpg.de> Reported-by: Todd Brandt <todd.e.brandt@intel.com> Signed-off-by: Chen Yu <yu.c.chen@intel.com> Tested-by: Naama Meir <naamax.meir@linux.intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20220308172030.451566-1-anthony.l.nguyen@intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Min Li authored
rsmu (Renesas Synchronization Management Unit ) driver is located in drivers/mfd and responsible for creating multiple devices including idt82p33 phc, which will then use the exposed regmap and mutex handle to access i2c/spi bus. Signed-off-by: Min Li <min.li.xe@renesas.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Link: https://lore.kernel.org/r/1646748651-16811-1-git-send-email-min.li.xe@renesas.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Oleksij Rempel authored
This chips supports two ways to configure max MTU size: - by setting SW_LEGAL_PACKET_DISABLE bit: if this bit is 0 allowed packed size will be between 64 and bytes 1518. If this bit is 1, it will accept packets up to 2000 bytes. - by setting SW_JUMBO_PACKET bit. If this bit is set, the chip will ignore SW_LEGAL_PACKET_DISABLE value and use REG_SW_MTU__2 register to configure MTU size. Current driver has disabled SW_JUMBO_PACKET bit and activates SW_LEGAL_PACKET_DISABLE. So the switch will pass all packets up to 2000 without any way to configure it. By providing port_change_mtu we are switch to SW_JUMBO_PACKET way and will be able to configure MTU up to ~9000. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20220308135857.1119028-1-o.rempel@pengutronix.deSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Guo Zhengkui authored
Fix the following coccicheck warning: drivers/net/vxlan/vxlan_core.c:2995:5-8: Unneeded variable: "ret". Return "0" on line 3004. Fixes: f9c4bb0b ("vxlan: vni filtering support on collect metadata device") Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com> Acked-by: Roopa Prabhu <roopa@nvidia.com> Link: https://lore.kernel.org/r/20220308134321.29862-1-guozhengkui@vivo.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 09 Mar, 2022 9 commits
-
-
Vladimir Oltean authored
When CONFIG_TCP_MD5SIG isn't enabled, there is a compilation bug due to the fact that the static inline definition of tcp_inbound_md5_hash() has an unexpected semicolon. Remove it. Fixes: 1330b6ef ("skb: make drop reason booleanable") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20220309122012.668986-1-vladimir.oltean@nxp.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Lukas Bulwahn authored
Commit 429c83c7 ("dt-bindings: net: dsa: realtek: convert to YAML schema, add MDIO") converts realtek-smi.txt to realtek.yaml, but missed to adjust its reference in MAINTAINERS. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a broken reference. Repair this file reference in REALTEK RTL83xx SMI DSA ROUTER CHIPS. Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Horatiu Vultur authored
The registers used to inject a frame to one of the ports is shared between all the net devices. Therefore, there can be race conditions for accessing the registers when two processes send frames at the same time on different ports. To fix this, add a spinlock around the function 'lan966x_port_ifh_xmit()'. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Changcheng Deng authored
Use min_t() in order to make code cleaner. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dimitris Michailidis authored
fun_core.ko uses sbitmaps and needs to select SBITMAP. Fixes below errors: ERROR: modpost: "__sbitmap_queue_get" [drivers/net/ethernet/fungible/funcore/funcore.ko] undefined! ERROR: modpost: "sbitmap_finish_wait" [drivers/net/ethernet/fungible/funcore/funcore.ko] undefined! ERROR: modpost: "sbitmap_queue_clear" [drivers/net/ethernet/fungible/funcore/funcore.ko] undefined! ERROR: modpost: "sbitmap_prepare_to_wait" [drivers/net/ethernet/fungible/funcore/funcore.ko] undefined! ERROR: modpost: "sbitmap_queue_init_node" [drivers/net/ethernet/fungible/funcore/funcore.ko] undefined! ERROR: modpost: "sbitmap_queue_wake_all" [drivers/net/ethernet/fungible/funcore/funcore.ko] undefined! v2: correct "Fixes" SHA Fixes: 749efb1e ("net/fungible: Kconfig, Makefiles, and MAINTAINERS") Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dimitris Michailidis <dmichail@fungible.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Dimitris Michailidis authored
Stephen Rothwell reported the following failure on powerpc: ERROR: modpost: ".local_memory_node" [drivers/net/ethernet/fungible/funeth/funeth.ko] undefined! AFAICS this is because local_memory_node() is a non-inline non-exported function when CONFIG_HAVE_MEMORYLESS_NODES=y. It is also the wrong API to get a CPU's memory node. Use cpu_to_mem() in the two spots it's used. Fixes: ee6373dd ("net/funeth: probing and netdev ops") Fixes: db37bc17 ("net/funeth: add the data path") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Dimitris Michailidis <dmichail@fungible.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
We have a number of cases where function returns drop/no drop decision as a boolean. Now that we want to report the reason code as well we have to pass extra output arguments. We can make the reason code evaluate correctly as bool. I believe we're good to reorder the reasons as they are reported to user space as strings. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Vladimir Oltean says: ==================== Incremental fixups for DSA unicast filtering There are some bugs I've discovered in the recently merged "DSA unicast filtering" series: https://patchwork.kernel.org/project/netdevbpf/cover/20220302191417.1288145-1-vladimir.oltean@nxp.com/ First bug is the dereference of an uninitialized list (dp->fdbs) when the "initial" tag protocol is placed in the device tree for the Felix switch driver. This is a scenario I hadn't tested. It is handled by patches 1-3. Second bug is actually a sum of bugs that canceled each other out during my previous testing. The MAC address change of a DSA slave interface breaks termination for the other slave interfaces. But this actually does not happen if the slave interface whose address is changing is down. And even when up, traffic termination is still not broken because we fail to properly disable host flooding. Patches 4-6 handle this for the Felix driver (the only one benefiting from unicast filtering so far). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
The Felix driver declares FDB isolation but puts all standalone ports in VID 0. This is mostly problem-free as discussed with Alvin here: https://patchwork.kernel.org/project/netdevbpf/cover/20220302191417.1288145-1-vladimir.oltean@nxp.com/#24763870 however there is one catch. DSA still thinks that FDB entries are installed on the CPU port as many times as there are user ports, and this is problematic when multiple user ports share the same MAC address. Consider the default case where all user ports inherit their MAC address from the DSA master, and then the user runs: ip link set swp0 address 00:01:02:03:04:05 The above will make dsa_slave_set_mac_address() call dsa_port_standalone_host_fdb_add() for 00:01:02:03:04:05 in port 0's standalone database, and dsa_port_standalone_host_fdb_del() for the old address of swp0, again in swp0's standalone database. Both the ->port_fdb_add() and ->port_fdb_del() will be propagated down to the felix driver, which will end up deleting the old MAC address from the CPU port. But this is still in use by other user ports, so we end up breaking unicast termination for them. There isn't a problem in the fact that DSA keeps track of host standalone addresses in the individual database of each user port: some drivers like sja1105 need this. There also isn't a problem in the fact that some drivers choose the same VID/FID for all standalone ports. It is just that the deletion of these host addresses must be delayed until they are known to not be in use any longer, and only the driver has this knowledge. Since DSA keeps these addresses in &cpu_dp->fdbs and &cpu_db->mdbs, it is just a matter of walking over those lists and see whether the same MAC address is present on the CPU port in the port db of another user port. I have considered reusing the generic dsa_port_walk_fdbs() and dsa_port_walk_mdbs() schemes for this, but locking makes it difficult. In the ->port_fdb_add() method and co, &dp->addr_lists_lock is held, but dsa_port_walk_fdbs() also acquires that lock. Also, even assuming that we introduce an unlocked variant of the address iterator, we'd still need some relatively complex data structures, and a void *ctx in the dsa_fdb_walk_cb_t which we don't currently pass, such that drivers are able to figure out, after iterating, whether the same MAC address is or isn't present in the port db of another port. All the above, plus the fact that I expect other drivers to follow the same model as felix where all standalone ports use the same FID, made me conclude that a generic method provided by DSA is necessary: dsa_fdb_present_in_other_db() and the mdb equivalent. Felix calls this from the ->port_fdb_del() handler for the CPU port, when the database was classified to either a port db, or a LAG db. For symmetry, we also call this from ->port_fdb_add(), because if the address was installed once, then installing it a second time serves no purpose: it's already in hardware in VID 0 and it affects all standalone ports. This change moves dsa_db_equal() from switch.c to dsa.c, since it now has one more caller. Fixes: 54c31984 ("net: mscc: ocelot: enforce FDB isolation when VLAN-unaware") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-