- 28 Jan, 2021 40 commits
-
-
Pali Rohár authored
The Ubiquiti U-Fiber Instant SFP GPON module has nonsensical information stored in its EEPROM. It claims to support all transceiver types including 10G Ethernet. Clear all claimed modes and set only 1000baseX_Full, which is the only one supported. This module has also phys_id set to SFF, and the SFP subsystem currently does not allow to use SFP modules detected as SFFs. Add exception for this module so it can be detected as supported. This change finally allows to detect and use SFP GPON module Ubiquiti U-Fiber Instant on Linux system. EEPROM content of this SFP module is (where XX is serial number): 00: 02 04 0b ff ff ff ff ff ff ff ff 03 0c 00 14 c8 ???........??.?? 10: 00 00 00 00 55 42 4e 54 20 20 20 20 20 20 20 20 ....UBNT 20: 20 20 20 20 00 18 e8 29 55 46 2d 49 4e 53 54 41 .??)UF-INSTA 30: 4e 54 20 20 20 20 20 20 34 20 20 20 05 1e 00 36 NT 4 ??.6 40: 00 06 00 00 55 42 4e 54 XX XX XX XX XX XX XX XX .?..UBNTXXXXXXXX 50: 20 20 20 20 31 34 30 31 32 33 20 20 60 80 02 41 140123 `??A Signed-off-by:
Pali Rohár <pali@kernel.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Pali Rohár authored
The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Wong, Vee Khee authored
Added PCI IDs for both Ethernet TSN Controllers on the ADL-S. Also, skip SerDes programming sequences as these are being carried out at the BIOS level for ADL-S. Signed-off-by:
Wong, Vee Khee <vee.khee.wong@intel.com> Link: https://lore.kernel.org/r/20210126085832.3814-1-vee.khee.wong@intel.comSigned-off-by:
-
Eric Dumazet authored
Rework initial test to jump over init code if memory allocation has failed. Signed-off-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20210127152731.748663-1-eric.dumazet@gmail.comSigned-off-by:
-
Lorenzo Carletti authored
In the rtl8366rb driver there are some jam tables which contain undocumented values. While trying to understand what these tables actually do, I noticed a discrepancy in how one of those was treated. Most of them were plain u16 arrays, while the ethernet one was an u16 matrix. By looking at the vendor's droplets of source code these tables came from, I found out that they were all originally u16 matrixes. This commit standardizes the jam tables, turning them all into jam_tbl_entry arrays. Each entry contains 2 u16 values. This change makes it easier to understand how the jam tables are used and also makes it possible for a single function to handle all of them, removing some duplicated code. Signed-off-by:
Lorenzo Carletti <lorenzo.carletti98@gmail.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Jakub Kicinski authored
Saeed Mahameed says: ==================== mlx5 devlink traps support Add support for devlink traps [1] reporting in mlx5, mlx5 will also report/trap packets filtered due to dest mac steering miss The first patch in the series defines the new DMAC trap type in devlink for this purpose. Other patches in the series are mlx5 only and they gradually traps support. Supported traps: DMAC: Drops due to destination MAC not configured in the MAC table VLAN: Drops due to vlan not configured in the vlan table Design note: devlink instance is managed by the low level mlx5 core layer, mlx5 core will serve as an abstraction layer for trap reporting, since we might have multiple mlx5 interfaces who might want to report traps on the same device. ==================== Link: https://lore.kernel.org/r/20210126232419.175836-1-saeedm@nvidia.comSigned-off-by:
-
Aya Levin authored
Avoid trapping packets when the interface is down, and revive them when interface is back up. Add API to mlx5 core retrieving the action by trap id. Use it to apply traps when interface is up, and disable then when interface is down. Signed-off-by:
Aya Levin <ayal@nvidia.com> Reviewed-by:
Moshe Shemesh <moshe@nvidia.com> Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
-
Aya Levin authored
Add support for trapping packets which didn't match any DMAC in the MAC table. Add a listener which adds/removes MAC trap rule in the flow steering according to the trap's action trap/drop. Signed-off-by:
-
Aya Levin authored
Add support for listening to blocking events in the ETH driver. Listen on trap event. If received, call mlx5e_handle_trap_event() which: 1) Verifies if driver needs open/close trap-RQ with respect to the active traps count. 2) Inspects trap id and its action (trap/drop) and add/remove the flow steering rule accordingly. Otherwise, return an error. Signed-off-by:
-
Aya Levin authored
Introduce mlx5e_trap which includes a dedicated RQ and NAPI for trapped packets. Trap-RQ processes packets that were destined to be dropped, but for debug and visibility sake these packets are trapped and reported to devlink. Trap-RQ connects between the HW and the driver and is not a part of a channel. Open mlx5e_create_rq() and mlx5_core_destroy_rq() as API and add dedicate RQ handlers which report to devlink of trapped packets. Signed-off-by:
-
Aya Levin authored
In order to support RQs outside of channel context, change mlx5e_init_di_list() signature to accept NUMA node instead of cpu. In addition, expose dma info helpers as API. This API will be used for RQ's creation in other files in downstream patches. Signed-off-by:
-
Aya Levin authored
Add flow group to the L2 table to hold the catch-all DMAC rule. Add API which adds/removes DMAC trap rule. This rule catches packets that were destined to be dropped due to no-match with previous DMAC rules. The trap rule steer these packets to the trap tir related to the trap-RQ. Signed-off-by:
-
Aya Levin authored
Add flow group to the VLAN table to hold the catch-all VLAN rule. Add API which adds/removes VLAN trap rule. This rule catches packets that were destined to be dropped due to no-match with previous VLAN rules. The trap rule steer these packets to the trap tir related to the trap-RQ. Signed-off-by:
-
Aya Levin authored
Change steering flow to optimize traffic in promiscuous mode. On demand, add a high priority table containing a catch-all rule. All incoming packets are caught by this rule and steered directly to the TTC table. Prior to this change, packets in promiscuous mode may suffer from up to 4 steering hops before reaching TTC table. In addition, this patch will allow us adding a catch-all rule at the end of MAC table to serve MAC trap, with no impact on promiscuous mode performance. Signed-off-by:
Maor Gottlieb <maorg@nvidia.com> Reviewed-by:
-
Aya Levin authored
In order to allow mlx5 core driver to trigger synchronous operations to its consumers, add a blocking events handler. Add wrappers to blocking_notifier_[call_chain/chain_register/chain_unregister]. Add trap callback for action set and notify about this change. Following patches in the set add a listener for this event. Signed-off-by:
-
Aya Levin authored
Change the naming of events notifier head to clarify that it handles only firmware events. Coming patches in the set, add event notifier for software events. Signed-off-by:
-
Aya Levin authored
Core driver is registered to the devlink traps service, which enables the admin to redeem packets that were destined to be dropped due to a particular reason. Register to DMAC filter, allow visibility of packets that were filtered out by the MAC table. Signed-off-by:
-
Aya Levin authored
Add traps registration to mlx5_core devlink register/unregister flow. This patch registers INGRESS_VLAN_FILTER trap. Signed-off-by:
-
Aya Levin authored
Add devlink traps infra-structure to mlx5 core driver. Add traps list to mlx5_priv and corresponding API: - mlx5_devlink_trap_report() to wrap trap reports to devlink - mlx5_devlink_trap_get_num_active() to decide whether to open/close trap resources. Signed-off-by:
-
Aya Levin authored
Add packet trap that can report packets that were dropped due to destination MAC filtering. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
-
Andrew Lunn authored
Early generations of the mv88e6xxx did not have the global 2 registers. In order to keep the driver slim, it was decided to make the code for these registers optional. Over time, more generations of switches have been added, always supporting global 2 and adding more and more registers. No effort has been made to keep these additional registers also optional to slim the driver down when used for older generations. Optional global 2 now just gives additional development and maintenance burden for no real gain. Make global 2 support always compiled in. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
Jakub Kicinski authored
Merge tag 'mac80211-next-for-net-next-2021-01-27' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== More updates: * many minstrel improvements, including removal of the old minstrel in favour of minstrel_ht * speed improvements on FQ * support for RX decapsulation (header conversion) offload * RTNL reduction: limit RTNL usage in the wireless stack mostly to where really needed (regulatory not yet) to reduce contention on it * tag 'mac80211-next-for-net-next-2021-01-27' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: (24 commits) mac80211: minstrel_ht: fix regression in the max_prob_rate fix virt_wifi: fix deadlock on RTNL cfg80211: avoid holding the RTNL when calling the driver cfg80211: change netdev registration/unregistration semantics mac80211: minstrel_ht: fix rounding error in throughput calculation mac80211: minstrel_ht: increase stats update interval mac80211: minstrel_ht: fix max probability rate selection mac80211: minstrel_ht: improve sample rate selection mac80211: minstrel_ht: improve ampdu length estimation mac80211: minstrel_ht: remove old ewma based rate average code mac80211: remove legacy minstrel rate control mac80211: minstrel_ht: add support for OFDM rates on non-HT clients mac80211: minstrel_ht: clean up CCK code mac80211: introduce aql_enable node in debugfs cfg80211: Add phyrate conversion support for extended MCS in 60GHz band cfg80211: add VHT rate entries for MCS-10 and MCS-11 mac80211: reduce peer HE MCS/NSS to own capabilities mac80211: remove NSS number of 160MHz if not support 160MHz for HE mac80211_hwsim: add 6GHz channels mac80211: add LDPC encoding to ieee80211_parse_tx_radiotap ... ==================== Link: https://lore.kernel.org/r/20210127210915.135550-1-johannes@sipsolutions.netSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-5.12-20210127' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2021-01-27 The first two patches are by me and fix typos on the CAN gw protocol and the flexcan driver. The next patch is by Vincent Mailhol and targets the CAN driver infrastructure, it exports the function that converts the CAN state into a human readable string. A patch by me, which target the CAN driver infrastructure, too, makes the calculation in can_fd_len2dlc() more readable. A patch by Tom Rix fixes a checkpatch warning in the mcba_usb driver. The next seven patches target the mcp251xfd driver. Su Yanjun's patch replaces several hardcoded assumptions when calling regmap, by using regmap_get_val_bytes(). The remaining patches are by me. First an open coded check is replaced by an existing helper function, then in the TX path the padding for CAN-FD frames is cleaned up. The next two patches clean up the RTR frame handling in the RX and TX path. Then support for len8_dlc is added. The last patch adds BQL support. * tag 'linux-can-next-for-5.12-20210127' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: mcp251xfd: add BQL support can: mcp251xfd: add len8_dlc support can: mcp251xfd: mcp251xfd_tx_obj_from_skb(): don't copy data for RTR CAN frames in TX-path can: mcp251xfd: mcp251xfd_hw_rx_obj_to_skb(): don't copy data for RTR CAN frames in RX-path can: mcp251xfd: mcp251xfd_tx_obj_from_skb(): clean up padding of CAN-FD frames can: mcp251xfd: mcp251xfd_start_xmit(): use mcp251xfd_get_tx_free() to check TX is is full can: mcp251xfd: replace sizeof(u32) with val_bytes in regmap can: mcba_usb: remove h from printk format specifier can: length: can_fd_len2dlc(): make legnth calculation readable again can: dev: export can_get_state_str() function can: flexcan: fix typos can: gw: fix typo ==================== Link: https://lore.kernel.org/r/20210127092227.2775573-1-mkl@pengutronix.deSigned-off-by:
-
Hoang Huu Le authored
Remove a duplicate code checking for header size in tipc_msg_create() as it's already being done in tipc_msg_init(). Acked-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
Hoang Huu Le <hoang.h.le@dektech.com.au> Link: https://lore.kernel.org/r/20210127025123.6390-1-hoang.h.le@dektech.com.auSigned-off-by:
-
Jakub Kicinski authored
Nikolay Aleksandrov says: ==================== net: bridge: multicast: per-port EHT hosts limit This set adds a simple configurable per-port EHT tracked hosts limit. Patch 01 adds a default limit of 512 tracked hosts per-port, since the EHT changes are still only in net-next that shouldn't be a problem. Then patch 02 adds the ability to configure and retrieve the hosts limit and to retrieve the current number of tracked hosts per port. Let's be on the safe side and limit the number of tracked hosts by default while allowing the user to increase that limit if needed. ==================== Link: https://lore.kernel.org/r/20210126093533.441338-1-razor@blackwall.orgSigned-off-by:
-
Nikolay Aleksandrov authored
Add two new port attributes which make EHT hosts limit configurable and export the current number of tracked EHT hosts: - IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT: configure/retrieve current limit - IFLA_BRPORT_MCAST_EHT_HOSTS_CNT: current number of tracked hosts Setting IFLA_BRPORT_MCAST_EHT_HOSTS_LIMIT to 0 is currently not allowed. Note that we have to increase RTNL_SLAVE_MAX_TYPE to 38 minimum, I've increased it to 40 to have space for two more future entries. v2: move br_multicast_eht_set_hosts_limit() to br_multicast_eht.c, no functional change Signed-off-by:Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
Nikolay Aleksandrov authored
Add a default limit of 512 for number of tracked EHT hosts per-port. Signed-off-by:
-
Jiapeng Zhong authored
Fix the following coccicheck warnings: ./drivers/net/ethernet/rocker/rocker_ofdpa.c:926:34-36: WARNING !A || A && B is equivalent to !A || B. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Zhong <abaci-bugfix@linux.alibaba.com> Link: https://lore.kernel.org/r/1611648783-3916-1-git-send-email-abaci-bugfix@linux.alibaba.comSigned-off-by:
-
Masahiro Yamada authored
These Kconfig files are included from net/Kconfig, inside the if NET ... endif. Remove 'depends on NET', which we know it is already met. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20210125232026.106855-1-masahiroy@kernel.orgSigned-off-by:
-
Masahiro Yamada authored
CONFIG_NET_L3_MASTER_DEV is a bool option. Change the ifeq conditional to the standard obj-$(CONFIG_NET_L3_MASTER_DEV) form. Use obj-y in net/l3mdev/Makefile because Kbuild visits this Makefile only when CONFIG_NET_L3_MASTER_DEV=y. Signed-off-by:
David Ahern <dsahern@kernel.org> Link: https://lore.kernel.org/r/20210125231659.106201-4-masahiroy@kernel.orgSigned-off-by:
-
Masahiro Yamada authored
CONFIG_NET_SWITCHDEV is a bool option. Change the ifeq conditional to the standard obj-$(CONFIG_NET_SWITCHDEV) form. Use obj-y in net/switchdev/Makefile because Kbuild visits this Makefile only when CONFIG_NET_SWITCHDEV=y. Signed-off-by:
-
Masahiro Yamada authored
CONFIG_DCB is a bool option. Change the ifeq conditional to the standard obj-$(CONFIG_DCB) form. Use obj-y in net/dcb/Makefile because Kbuild visits this Makefile only when CONFIG_DCB=y. Signed-off-by:
-
Masahiro Yamada authored
When CONFIG_NET is disabled, nothing under the net/ directory is compiled. Move the CONFIG_NET guard to the top Makefile so the net/ directory is entirely skipped. When Kbuild visits net/Makefile, CONFIG_NET is obvioulsy 'y' because CONFIG_NET is a bool option. Clean up net/Makefile. Signed-off-by:
-
Masahiro Yamada authored
CONFIG_NET is a bool option, and this file is compiled only when CONFIG_NET=y. Remove #ifdef CONFIG_NET, which we know it is always met. Signed-off-by:
-
Jakub Kicinski authored
Mat Martineau says: ==================== MPTCP: IPv4-mapped IPv6 addressing for subflows This patch series from the MPTCP tree adds support for IPv4-mapped IPv6 addressing that was missing when multiple subflows were first implemented. Patches 1 and 2 handle the conversion and comparison of the mapped addresses. Patch 3 contains a minor refactor in the path manager's handling of addresses. Patches 4 and 5 add selftests for the new functionality and adjust the selftest timeout. ==================== Link: https://lore.kernel.org/r/20210125185904.6997-1-mathew.j.martineau@linux.intel.comSigned-off-by:
-
Matthieu Baerts authored
On slow systems with kernel debug settings, we can reach the current timeout when all tests are executed. Likely some tests need be improved to remove some 'sleep' and wait (less) for a specific action. This can also improve stability. Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Geliang Tang authored
Here, we make sure we support IPv4-mapped in IPv6 addresses in different contexts: - a v4-mapped address is received by the PM and can be used as v4. - a v4 address is received by the PM and can be used even with a v4 mapped socket. We also make sure we don't try to establish subflows between v4 and v6 addresses, e.g. if a real v6 address ends with a valid v4 address. Co-developed-by:
Geliang Tang <geliangtang@gmail.com> Signed-off-by:
-
Matthieu Baerts authored
To avoid confusions like when working on the previous patch, better to declare and assign this variable only where it is needed. Signed-off-by:
-
Matthieu Baerts authored
On one side, we can allow the creation of subflows between v4 mapped in v6 and v4 addresses. For that we look for v4mapped addresses between the local address we want to select and the remote one. On the other side, we also properly deal with received v4mapped addresses, either announced ones or set via Netlink. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/122Suggested-by:
-
Matthieu Baerts authored
With an IPv4 mapped in v6 socket, we were trying to call inet6_bind() with an IPv4 address resulting in a -EINVAL error because the given addr_len -- size of the address structure -- was too short. We now make sure to use address structures for the same family as the MPTCP socket for both the bind() and the connect(). It means we convert v4 addresses to v4 mapped in v6 or the opposite if needed. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/122Co-developed-by:
-
