- 08 Dec, 2022 9 commits
-
-
Ido Schimmel authored
The parsing of the netlink messages and the validity checks are now performed in br_mdb_config_init() so we can remove br_mdb_parse(). This finally allows us to stop passing netlink attributes deep in the MDB control path and only use the MDB configuration structure. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Acked-by:
Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Ido Schimmel authored
The MDB group key (i.e., {source, destination, protocol, VID}) is currently determined under the multicast lock from the netlink attributes. Instead, use the group key from the MDB configuration structure that was prepared before acquiring the lock. No functional changes intended. Signed-off-by: -
Ido Schimmel authored
As an intermediate step towards only using the new MDB configuration structure, pass it further in the control path instead of passing individual attributes. No functional changes intended. Signed-off-by:
-
Ido Schimmel authored
The MDB configuration structure (i.e., struct br_mdb_config) now includes all the necessary information from the parsed RTM_{NEW,DEL}MDB netlink messages, so use it. This will later allow us to delete the calls to br_mdb_parse() from br_mdb_add() and br_mdb_del(). No functional changes intended. Signed-off-by: -
Ido Schimmel authored
These checks are now redundant as they are performed by br_mdb_config_init() while parsing the RTM_{NEW,DEL}MDB messages. Remove them. Signed-off-by: -
Ido Schimmel authored
Netlink attributes are currently passed deep in the MDB creation call chain, making it difficult to add new attributes. In addition, some validity checks are performed under the multicast lock although they can be performed before it is ever acquired. As a first step towards solving these issues, parse the RTM_{NEW,DEL}MDB messages into a configuration structure, relieving other functions from the need to handle raw netlink attributes. Subsequent patches will convert the MDB code to use this configuration structure. This is consistent with how other rtnetlink objects are handled, such as routes and nexthops. Signed-off-by: -
ye xingchen authored
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by:
ye xingchen <ye.xingchen@zte.com.cn> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/202212051918564721658@zte.com.cnSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'ieee802154-for-net-next-2022-12-05' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next Stefan Schmidt says: ==================== ieee802154-next 2022-12-05 Miquel continued his work towards full scanning support. For this, we now allow the creation of dedicated coordinator interfaces to allow a PAN coordinator to serve in the network and set the needed address filters with the hardware. On top of this we have the first part to allow scanning for available 15.4 networks. A new netlink scan group, within the existing nl802154 API, was added. In addition Miquel fixed two issues that have been introduced in the former patches to free an skb correctly and clarifying an expression in the stack. From David Girault we got tracing support when registering new PANs. * tag 'ieee802154-for-net-next-2022-12-05' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next: mac802154: Trace the registration of new PANs ieee802154: Advertize coordinators discovery mac802154: Allow the creation of coordinator interfaces mac802154: Clarify an expression mac802154: Move an skb free within the rx path ==================== Link: https://lore.kernel.org/r/20221205131909.1871790-1-stefan@datenfreihafen.orgSigned-off-by:
-
Oleksij Rempel authored
Add ASIX based USB 10Base-T1L adapter support: https://linux-automation.com/en/products/usb-t1l.htmlSigned-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Link: https://lore.kernel.org/r/20221205132102.2941732-1-o.rempel@pengutronix.deSigned-off-by:
-
- 07 Dec, 2022 18 commits
-
-
Paolo Abeni authored
Hariprasad Kelam says: ==================== CN10KB MAC block support OcteonTx2's next gen platform the CN10KB has RPM_USX MAC which has a different serdes when compared to RPM MAC. Though the underlying HW is different, the CSR interface has been designed largely inline with RPM MAC, with few exceptions though. So we are using the same CGX driver for RPM_USX MAC as well and will have a different set of APIs for RPM_USX where ever necessary. The RPM and RPM_USX blocks support a different number of LMACS. RPM_USX support 8 LMACS per MAC block whereas legacy RPM supports only 4 LMACS per MAC. with this RPM_USX support double the number of DMAC filters and fifo size. This patchset adds initial support for CN10KB's RPM_USX MAC i.e registering the driver and defining MAC operations (mac_ops). With these changes PF and VF netdev packet path will work and PF and VF netdev drivers are able to configure MAC features like pause frames,PFC and loopback etc. Also implements FEC stats for CN10K Mac block RPM and CN10KB Mac block RPM_USX and extends ethtool support for PF and VF drivers by defining get_fec_stats API to display FEC stats. ==================== Link: https://lore.kernel.org/r/20221205070521.21860-1-hkelam@marvell.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Hariprasad Kelam authored
CN10K silicon MAC block RPM and CN10KB silicon MAC block RPM_USX both support BASER and RSFEC modes. Also MAC (CGX) on OcteonTx2 silicon variants and MAC (RPM) on OcteonTx3 CN10K are different and FEC stats need to be read differently. CN10KB MAC block (RPM_USX) fec csr offsets are same as CN10K MAC block (RPM) mac_ops points to same fn(). Upper layer interface between RVU AF and PF netdev is kept same. Based on silicon variant appropriate fn() pointer is called to read FEC stats Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Signed-off-by:
Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by:
-
Hariprasad Kelam authored
This patch registers a callback for get_fec_stats such that FEC stats can be queried from the below command "ethtool -I --show-fec eth0" Signed-off-by:
-
Hariprasad Kelam authored
OcteonTx2's next gen platform the CN10KB has RPM_USX MAC which has a different serdes when compared to RPM MAC. Though the underlying HW is different, the CSR interface has been designed largely inline with RPM MAC, with few exceptions though. So we are using the same CGX driver for RPM_USX MAC as well and will have a different set of APIs for RPM_USX where ever necessary. The RPM and RPM_USX blocks support a different number of LMACS. RPM_USX support 8 LMACS per MAC block whereas legacy RPM supports only 4 LMACS per MAC. with this RPM_USX support double the number of DMAC filters and fifo size. This patch adds initial support for CN10KB's RPM_USX MAC i.e registering the driver and defining MAC operations (mac_ops). Adds the logic to configure internal loopback and pause frames and assign FIFO length to LMACS. Kernel reads lmac features like lmac type, autoneg, etc from shared firmware data this structure only supports 4 lmacs per MAC, this patch extends this structure to accommodate 8 lmacs. Signed-off-by:
-
Rakesh Babu Saladi authored
Most of the code in CGX/RPM driver assumes that max lmacs per given MAC as always, 4 and the number of MAC blocks also as 4. With this assumption, the max number of interfaces supported is hardcoded to 16. This creates a problem as next gen CN10KB silicon MAC supports 8 lmacs per MAC block. This patch solves the problem by using "max lmac per MAC block" value from constant csrs and uses cgx_cnt_max value which is populated based number of MAC blocks supported by silicon. Signed-off-by:
Rakesh Babu Saladi <rsaladi2@marvell.com> Signed-off-by:
-
Paolo Abeni authored
Oleksij Rempel says: ==================== net: dsa: microchip: add MTU support for KSZ8 series ==================== Link: https://lore.kernel.org/r/20221205052232.2834166-1-o.rempel@pengutronix.deSigned-off-by:
-
Oleksij Rempel authored
To make the code more comparable to KSZ9477 code, move DSA configurations to the same location. Signed-off-by:
Arun Ramadoss <arun.ramadoss@microchip.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Oleksij Rempel authored
KSZ8795 and KSZ9477 compatible series of switches use global max frame size configuration register. So, enable MTU normalization for this reason. Signed-off-by:
-
Oleksij Rempel authored
Make MTU configurable on KSZ87xx and KSZ88xx series of switches. Before this patch, pre-configured behavior was different on different switch series, due to opposite meaning of the same bit: - KSZ87xx: Reg 4, Bit 1 - if 1, max frame size is 1532; if 0 - 1514 - KSZ88xx: Reg 4, Bit 1 - if 1, max frame size is 1514; if 0 - 1532 Since the code was telling "... SW_LEGAL_PACKET_DISABLE, true)", I assume, the idea was to set max frame size to 1532. With this patch, by setting MTU size 1500, both switch series will be configured to the 1532 frame limit. This patch was tested on KSZ8873. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Oleksij Rempel authored
Add ksz_rmw8(), it will be used in the next patch. Signed-off-by:
-
Oleksij Rempel authored
If we have global MTU configuration, it is enough to configure it on CPU port only. Signed-off-by:
-
Oleksij Rempel authored
There are no HW specific registers, so we can process all of them in one location. Signed-off-by:
-
Yuan Can authored
The np needs to be released through of_node_put() in the error handling path of mtk_wed_wo_hardware_init(). Fixes: 79968444 ("net: ethernet: mtk_wed: introduce wed wo support") Signed-off-by:
Yuan Can <yuancan@huawei.com> Reviewed-by:
-
Lorenzo Bianconi authored
This patch adds reset parameter to mtk_wed_rx_ring_setup signature in order to align rx_ring_setup callback to tx_ring_setup one introduced in 'commit 23dca7a9 ("net: ethernet: mtk_wed: add reset to tx_ring_setup callback")' Co-developed-by:
Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
-
zhang songyi authored
Semicolons after "}" are not needed. Signed-off-by:
zhang songyi <zhang.songyi@zte.com.cn> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/202212051422158113766@zte.com.cnSigned-off-by:
-
ye xingchen authored
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by:
Martin Habets <habetsm.xilinx@gmail.com> Link: https://lore.kernel.org/r/202212051021451139126@zte.com.cnSigned-off-by:
-
Russell King (Oracle) authored
We currently have some complicated code in sfp_probe() which gets the I2C bus depending on whether the sfp node is DT or ACPI, and we use completely separate lookup functions. This could do with being in a separate function to make the code more readable, so move it to a new function, sfp_i2c_get(). We can also use fwnode_find_reference() to lookup the I2C bus fwnode before then decending into fwnode-type specific parsing. A future cleanup would be to move the fwnode-type specific parsing into the i2c layer, which is where it really should be. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1p1WGJ-0098wS-4w@rmk-PC.armlinux.org.ukSigned-off-by:
-
Kees Cook authored
The memcpy() in ncsi_cmd_handler_oem deserializes nca->data into a flexible array structure that overlapping with non-flex-array members (mfr_id) intentionally. Since the mem_to_flex() API is not finished, temporarily silence this warning, since it is a false positive, using unsafe_memcpy(). Reported-by:
Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/netdev/CACPK8Xdfi=OJKP0x0D1w87fQeFZ4A2DP2qzGCRcuVbpU-9=4sQ@mail.gmail.com/ Cc: Samuel Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221202212418.never.837-kees@kernel.orgSigned-off-by:
-
- 06 Dec, 2022 7 commits
-
-
Paolo Abeni authored
Horatiu Vultur says: ==================== net: lan966x: Enable PTP on bridge interfaces Before it was not allowed to run ptp on ports that are part of a bridge because in case of transparent clock the HW will still forward the frames so there would be duplicate frames. Now that there is VCAP support, it is possible to add entries in the VCAP to trap frames to the CPU and the CPU will forward these frames. The first part of the patch series, extends the VCAP support to be able to modify and get the rule, while the last patch uses the VCAP to trap the ptp frames. ==================== Link: https://lore.kernel.org/r/20221203104348.1749811-1-horatiu.vultur@microchip.comSigned-off-by:
-
Horatiu Vultur authored
Currently lan966x, doesn't allow to run PTP over interfaces that are part of the bridge. The reason is when the lan966x was receiving a PTP frame (regardless if L2/IPv4/IPv6) the HW it would flood this frame. Now that it is possible to add VCAP rules to the HW, such to trap these frames to the CPU, it is possible to run PTP also over interfaces that are part of the bridge. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
Add the function vcap_rule_get_key_u32 which allows to get the value and the mask of a key that exist on the rule. If the key doesn't exist, it would return error. Signed-off-by:
-
Horatiu Vultur authored
Add the function vcap_mod_rule which allows to update an existing rule in the vcap. It is required for the rule to exist in the vcap to be able to modify it. Signed-off-by:
-
Horatiu Vultur authored
Add function vcap_get_rule which returns a rule based on the internal rule id. The entire functionality of reading and decoding the rule from the VCAP was inside vcap_api_debugfs file. So move the entire implementation in vcap_api as this is used also by vcap_get_rule. Signed-off-by:
-
Lorenzo Bianconi authored
Since Wireless Ethernet Dispatcher is now available for mt7986 in mt76, enable hw flow support for MT7986 SoC. Signed-off-by:
-
Sudheer Mogilappagari authored
Add netlink based support for "ethtool -x <dev> [context x]" command by implementing ETHTOOL_MSG_RSS_GET netlink message. This is equivalent to functionality provided via ETHTOOL_GRSSH in ioctl path. It sends RSS table, hash key and hash function of an interface to user space. This patch implements existing functionality available in ioctl path and enables addition of new RSS context based parameters in future. Signed-off-by:
Sudheer Mogilappagari <sudheer.mogilappagari@intel.com> Link: https://lore.kernel.org/r/20221202002555.241580-1-sudheer.mogilappagari@intel.comSigned-off-by:
-
- 05 Dec, 2022 6 commits
-
-
Michael Walle authored
Rename the temperature sensors macros to match the names in the datasheet. Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Diana Wang authored
Rewrite nfp_net_set_rx_mode() to implement interface to delivery mc address and operations to firmware by using general mailbox for filtering multicast packets. The operations include add mc address and delete mc address. And the limitation of mc addresses number is 1024 for each net device. User triggers adding mc address by using command below: ip maddress add <mc address> dev <interface name> User triggers deleting mc address by using command below: ip maddress del <mc address> dev <interface name> Signed-off-by:
Diana Wang <na.wang@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
-
ye xingchen authored
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
David S. Miller authored
Merge tag 'rxrpc-next-20221201-b' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs David Howells says: ==================== rxrpc: Increasing SACK size and moving away from softirq, parts 2 & 3 Here are the second and third parts of patches in the process of moving rxrpc from doing a lot of its stuff in softirq context to doing it in an I/O thread in process context and thereby making it easier to support a larger SACK table. The full description is in the description for the first part[1] which is already in net-next. The second part includes some cleanups, adds some testing and overhauls some tracing: (1) Remove declaration of rxrpc_kernel_call_is_complete() as the definition is no longer present. (2) Remove the knet() and kproto() macros in favour of using tracepoints. (3) Remove handling of duplicate packets from recvmsg. The input side isn't now going to insert overlapping/duplicate packets into the recvmsg queue. (4) Don't use the rxrpc_conn_parameters struct in the rxrpc_connection or rxrpc_bundle structs - rather put the members in directly. (5) Extract the abort code from a received abort packet right up front rather than doing it in multiple places later. (6) Use enums and symbol lists rather than __builtin_return_address() to indicate where a tracepoint was triggered for local, peer, conn, call and skbuff tracing. (7) Add a refcount tracepoint for the rxrpc_bundle struct. (8) Implement an in-kernel server for the AFS rxperf testing program to talk to (enabled by a Kconfig option). This is tagged as rxrpc-next-20221201-a. The third part introduces the I/O thread and switches various bits over to running there: (1) Fix call timers and call and connection workqueues to not hold refs on the rxrpc_call and rxrpc_connection structs to thereby avoid messy cleanup when the last ref is put in softirq mode. (2) Split input.c so that the call packet processing bits are separate from the received packet distribution bits. Call packet processing gets bumped over to the call event handler. (3) Create a per-local endpoint I/O thread. Barring some tiny bits that still get done in softirq context, all packet reception, processing and transmission is done in this thread. That will allow a load of locking to be removed. (4) Perform packet processing and error processing from the I/O thread. (5) Provide a mechanism to process call event notifications in the I/O thread rather than queuing a work item for that call. (6) Move data and ACK transmission into the I/O thread. ACKs can then be transmitted at the point they're generated rather than getting delegated from softirq context to some process context somewhere. (7) Move call and local processor event handling into the I/O thread. (8) Move cwnd degradation to after packets have been transmitted so that they don't shorten the window too quickly. A bunch of simplifications can then be done: (1) The input_lock is no longer necessary as exclusion is achieved by running the code in the I/O thread only. (2) Don't need to use sk->sk_receive_queue.lock to guard socket state changes as the socket mutex should suffice. (3) Don't take spinlocks in RCU callback functions as they get run in softirq context and thus need _bh annotations. (4) RCU is then no longer needed for the peer's error_targets list. (5) Simplify the skbuff handling in the receive path by dropping the ref in the basic I/O thread loop and getting an extra ref as and when we need to queue the packet for recvmsg or another context. (6) Get the peer address earlier in the input process and pass it to the users so that we only do it once. This is tagged as rxrpc-next-20221201-b. Changes: ======== ver #2) - Added a patch to change four assertions into warnings in rxrpc_read() and fixed a checker warning from a __user annotation that should have been removed.. - Change a min() to min_t() in rxperf as PAGE_SIZE doesn't seem to match type size_t on i386. - Three error handling issues in rxrpc_new_incoming_call(): - If not DATA or not seq #1, should drop the packet, not abort. - Fix a goto that went to the wrong place, dropping a non-held lock. - Fix an rcu_read_lock that should've been an unlock. Tested-by:
Marc Dionne <marc.dionne@auristor.com> Tested-by: kafs-testing+fedora36_64checkkafs-build-144@auristor.com Link: https://lore.kernel.org/r/166794587113.2389296.16484814996876530222.stgit@warthog.procyon.org.uk/ [1] Link: https://lore.kernel.org/r/166982725699.621383.2358362793992993374.stgit@warthog.procyon.org.uk/ # v1 ==================== Signed-off-by:
-
Bhadram Varka authored
Add support for the Multi-Gigabit Ethernet (MGBE/XPCS) IP found on NVIDIA Tegra234 SoCs. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Bhadram Varka <vbhadram@nvidia.com> Co-developed-by:
Revanth Kumar Uppala <ruppala@nvidia.com> Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
-
Revanth Kumar Uppala authored
The Tegra MGBE ethernet controller requires that the SERDES link is powered-up after the PHY link is up, otherwise the link fails to become ready following a resume from suspend. Add a variable to indicate that the SERDES link must be powered-up after the PHY link. Signed-off-by:
-
