- 22 Aug, 2022 16 commits
-
-
David S. Miller authored
Gerhard Engleder says: ==================== tsnep: Various minor driver improvements During XDP development some general driver improvements has been done which I want to keep out of future patch series. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Gerhard Engleder authored
Other drivers record RX queue so it should make sense to do that also. Signed-off-by:
Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by:
-
Gerhard Engleder authored
DMA addresses up to 64bit are supported by the device. Configure DMA mask according to the capabilities of the device. Signed-off-by:
-
Gerhard Engleder authored
TX length can by calculated more efficient during map and unmap of fragments. Another reason is that, by moving TX statistic counting to tsnep_tx_poll() it can be used there for XDP too. Signed-off-by:
-
Gerhard Engleder authored
Add support for NETIF_F_LOOPBACK feature. Loopback mode is used for testing. Signed-off-by:
-
Gerhard Engleder authored
Fixed register define is not used, but register definition shall be kept in sync. Fixes: 403f69bb ("tsnep: Add TSN endpoint Ethernet MAC driver") Signed-off-by:
-
Mike Pattrick authored
Currently queue_userspace_packet will call kfree_skb for all frames, whether or not an error occurred. This can result in a single dropped frame being reported as multiple drops in dropwatch. This functions caller may also call kfree_skb in case of an error. This patch will consume the skbs instead and allow caller's to use kfree_skb. Signed-off-by:
Mike Pattrick <mkp@redhat.com> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2109957Signed-off-by:
-
Mike Pattrick authored
Frames sent to userspace can be reported as dropped in ovs_dp_process_packet, however, if they are dropped in the netlink code then netlink_attachskb will report the same frame as dropped. This patch checks for error codes which indicate that the frame has already been freed. Signed-off-by:
-
David S. Miller authored
Maxime Chevallier says: ==================== net: Introduce QUSGMII phy mode Re-sending, since the previous v4 was sent while net-next was closed. This is a resend of the V4 of a previous series [1] initially aimed at introducing inband extensions, with modes like QUSGMII. This mode allows passing info in the ethernet preamble between the MAC and the PHY, such as timestamps. This series has now become a preliminary series, that simply introduces the new interface mode, without support for inband extensions, that will come later. The reasonning is that work will need to be done in the networking subsystem, but also in the generic phy driver subsystem to allow serdes configuration for qusgmii. This series add the mode, the relevant binding changes, adds support for it in the lan966x driver, and also introduces a small helper to get the number of links a given phy mode can carry (think 1 for SGMII and 4 for QSGMII). This allows for better readability and will prove useful when (if) we support PSGMII (5 links on 1 interface) and OUSGMII (8 links on one interface). V4 contains no change but the collected Reviewed-by from Andrew. ==================== Signed-off-by: -
Maxime Chevallier authored
The Lan996x controller supports the QUSGMII mode, which is very similar to QSGMII in the way it's configured and the autonegociation capababilities it provides. This commit adds support for that mode, treating it most of the time like QSGMII, making sure that we do configure the PCS how we should. Signed-off-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Maxime Chevallier authored
Some phy modes such as QSGMII multiplex several MAC<->PHY links on one single physical interface. QSGMII used to be the only one supported, but other modes such as QUSGMII also carry multiple links. This helper allows getting the number of links that are multiplexed on a given interface. Signed-off-by:
-
Maxime Chevallier authored
Add a new QUSGMII mode, standing for "Quad Universal Serial Gigabit Media Independent Interface", a derivative of USGMII which, similarly to QSGMII, allows to multiplex 4 1Gbps links to a Quad-PHY. The main difference with QSGMII is that QUSGMII can include an extension instead of the standard 7bytes ethernet preamble, allowing to convey arbitrary data such as Timestamps. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Maxime Chevallier authored
The QUSGMII mode is a derivative of Cisco's USXGMII standard. This standard is pretty similar to SGMII, but allows for faster speeds, and has the build-in bits for Quad and Octa variants (like QSGMII). The main difference with SGMII/QSGMII is that USXGMII/QUSGMII re-uses the preamble to carry various information, named 'Extensions'. As of today, the USXGMII standard only mentions the "PCH" extension, which is used to convey timestamps, allowing in-band signaling of PTP timestamps without having to modify the frame itself. This commit adds support for that mode. When no extension is in use, it behaves exactly like QSGMII, although it's not compatible with QSGMII. Signed-off-by:
-
Ravi Gunasekaran authored
On the CPSW and ICSS peripherals, there is a possibility that the MDIO interface returns corrupt data on MDIO reads or writes incorrect data on MDIO writes. There is also a possibility for the MDIO interface to become unavailable until the next peripheral reset. The workaround is to configure the MDIO in manual mode and disable the MDIO state machine and emulate the MDIO protocol by reading and writing appropriate fields in MDIO_MANUAL_IF_REG register of the MDIO controller to manipulate the MDIO clock and data pins. More details about the errata i2329 and the workaround is available in: https://www.ti.com/lit/er/sprz487a/sprz487a.pdf Add implementation to disable MDIO state machine, configure MDIO in manual mode and achieve MDIO read and writes via MDIO Bitbanging Signed-off-by:
Ravi Gunasekaran <r-gunasekaran@ti.com> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Clark Wang authored
RTL8211F(D)(I)-VD-CG is the pin-to-pin upgrade chip from RTL8211F(D)(I)-CG. Add new PHY ID for this chip. It does not support RTL8211F_PHYCR2 anymore, so remove the w/r operation of this register. Signed-off-by:
Clark Wang <xiaoning.wang@nxp.com> Signed-off-by:
Wei Fang <wei.fang@nxp.com> Signed-off-by:
-
Kirill Tkhai authored
TCP_LISTEN sockets is a special case. They preserve skb with a newly connected sock till accept() makes it fully functional socket. Receive queue of such socket may grow after connected peer send messages there. Since these messages may contain scm_fds, we should expose correct fdinfo::scm_fds for listening socket too. Signed-off-by:
Kirill Tkhai <tkhai@ya.ru> Signed-off-by:
-
- 19 Aug, 2022 24 commits
-
-
Maksym Glubokiy authored
Size-check a type used for FW communication is packed as expected. Signed-off-by:
Oleksandr Mazur <oleksandr.mazur@plvision.eu> Signed-off-by:
Maksym Glubokiy <maksym.glubokiy@plvision.eu> Link: https://lore.kernel.org/r/20220818111419.414877-1-maksym.glubokiy@plvision.euSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Yang Yingliang authored
The skb pointer will be checked in kfree_skb(), so remove the outside check. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Taehee Yoo <ap420073@gmail.com> Link: https://lore.kernel.org/r/20220818093114.2449179-1-yangyingliang@huawei.comSigned-off-by:
-
Matthias May authored
There are currently 3 ip tunnels that are capable of carrying L2 traffic: gretap, vxlan and geneve. They all are capable to inherit the TOS/TTL for the outer IP-header from the inner frame. Add a test that verifies that these fields are correctly inherited. These tests failed before the following commits: b09ab9c9 ("ip6_tunnel: allow to inherit from VLAN encapsulated IP") 3f8a8447 ("ip6_gre: use actual protocol to select xmit") 41337f52 ("ip6_gre: set DSCP for non-IP") 7ae29fd1 ("ip_tunnel: allow to inherit from VLAN encapsulated IP") 7074732c ("ip_tunnels: allow VXLAN/GENEVE to inherit TOS/TTL from VLAN") ca2bb695 ("geneve: do not use RT_TOS for IPv6 flowlabel") b4ab94d6 ("geneve: fix TOS inheriting for ipv4") Signed-off-by:
Matthias May <matthias.may@westermo.com> Link: https://lore.kernel.org/r/20220817073649.26117-1-matthias.may@westermo.comSigned-off-by:
-
Jakub Kicinski authored
Sean Anderson says: ==================== net: dpaa: Cleanups in preparation for phylink conversion This series contains several cleanup patches for dpaa/fman. While they are intended to prepare for a phylink conversion, they stand on their own. This series was originally submitted as part of [1]. [1] https://lore.kernel.org/netdev/20220715215954.1449214-1-sean.anderson@seco.com ==================== Link: https://lore.kernel.org/r/20220818161649.2058728-1-sean.anderson@seco.comSigned-off-by:
-
Sean Anderson authored
This option is present in params, so use it instead of the fman private version. Signed-off-by:
Sean Anderson <sean.anderson@seco.com> Acked-by:
Camelia Groza <camelia.groza@nxp.com> Signed-off-by:
-
Sean Anderson authored
In preparation for moving each of the initialization functions to their own file, export some common functions so they can be re-used. This adds an fman prefix to set_multi to make it a bit less genericly-named. Signed-off-by:
-
Sean Anderson authored
memac is the only mac which parses fixed links. Move the parsing/configuring to its initialization function. Signed-off-by:
-
Sean Anderson authored
Move the reference to our device to mac_device. This way, macs can use it in their log messages. Signed-off-by:
-
Sean Anderson authored
Instead of re-matching the compatible string in order to determine the init function, just store it in the match data. The separate setup functions aren't needed anymore. Merge their content into init as well. To ensure everything compiles correctly, we move them to the bottom of the file. Signed-off-by:
-
Sean Anderson authored
This moves the reading of the PCS property out of the generic probe and into the mac-specific initialization function. This reduces the mac-specific jobs done in the top-level probe function. Signed-off-by:
-
Sean Anderson authored
There are two ways that GRS can be set: graceful_stop and dtsec_isr. It is cleared by graceful_start. If it is already set before calling graceful_stop, then that means that dtsec_isr set it. In that case, we will not set GRS nor will we clear it (which seems like a bug?). For GTS the logic is similar, except that there is no one else messing with this bit (so we will always set and clear it). Simplify the logic by always setting/clearing GRS/GTS. This is less racy that the previous behavior, and ensures that we always end up clearing the bits. This can of course clear GRS while dtsec_isr is waiting, but because we have already done our own waiting it should be fine. This is the last user of enum comm_mode, so remove it. Signed-off-by:
-
Sean Anderson authored
All macs use the same start/stop functions. The actual mac-specific code lives in enable/disable. Move these functions to an appropriate struct, and inline the phy enable/disable calls to the caller of start/stop. Signed-off-by:
-
Sean Anderson authored
mac_priv_s->enable() and ->disable() are always called with a comm_mode of COMM_MODE_RX_AND_TX. Remove this parameter, and refactor the macs appropriately. Signed-off-by:
-
Sean Anderson authored
This converts the license text of files in the fman directory to use SPDX license identifiers instead. Signed-off-by:
-
Sean Anderson authored
This converts the MAC portion of the FMan MAC bindings to yaml. Signed-off-by:
-
Jakub Kicinski authored
This reverts commit 5417197d, reversing changes made to 0630f64d. Reverting to allow addressing review comments. Link: https://lore.kernel.org/all/4c5dbea0-52a9-1c3d-7547-00ea54c90550@linux.intel.com/Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski authored
No conflicts. Signed-off-by: -
Lorenzo Bianconi authored
Add the capability to map non-linear xdp frames in XDP_TX and ndo_xdp_xmit callback. Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> 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/20220817173628.109102-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Jakub Kicinski authored
Petr Machata says: ==================== selftests: mlxsw: Add ordering tests for unified bridge model Amit Cohen writes: Commit 798661c7 ("Merge branch 'mlxsw-unified-bridge-conversion-part-6'") converted mlxsw driver to use unified bridge model. In the legacy model, when a RIF was created / destroyed, it was firmware's responsibility to update it in the relevant FID classification records. In the unified bridge model, this responsibility moved to software. This set adds tests to check the order of configuration for the following classifications: 1. {Port, VID} -> FID 2. VID -> FID 3. VNI -> FID (after decapsulation) In addition, in the legacy model, software is responsible to update a table which is used to determine the packet's egress VID. Add a test to check that the order of configuration does not impact switch behavior. See more details in the commit messages. Note that the tests supposed to pass also using the legacy model, they are added now as with the new model they test the driver and not the firmware. Patch set overview: Patch #1 adds test for {Port, VID} -> FID Patch #2 adds test for VID -> FID Patch #3 adds test for VNI -> FID Patch #4 adds test for egress VID classification ==================== Link: https://lore.kernel.org/r/cover.1660747162.git.petrm@nvidia.comSigned-off-by:
-
Amit Cohen authored
After routing, the device always consults a table that determines the packet's egress VID based on {egress RIF, egress local port}. In the unified bridge model, it is up to software to maintain this table via REIV register. The table needs to be updated in the following flows: 1. When a RIF is set on a FID, for each FID's {Port, VID} mapping, a new {RIF, Port}->VID mapping should be created. 2. When a {Port, VID} is mapped to a FID and the FID already has a RIF, a new {RIF, Port}->VID mapping should be created. Add a test to verify that packets get the correct VID after routing, regardless of the order of the configuration. # ./egress_vid_classification.sh TEST: Add RIF for existing {port, VID}->FID mapping [ OK ] TEST: Add {port, VID}->FID mapping for FID with a RIF [ OK ] Signed-off-by:Amit Cohen <amcohen@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Amit Cohen authored
Before layer 2 forwarding, the device classifies an incoming packet to a FID. After classification, the FID is known, but also all the attributes of the FID, such as the router interface (RIF) via which a packet that needs to be routed will ingress the router block. For VXLAN decapsulation, the FID classification is done according to the VNI. When a RIF is added on top of a FID, the existing VNI->FID mapping should be updated by the software with the new RIF. In addition, when a new mapping is added for FID which already has a RIF, the correct RIF should be used for it. Add a test to verify that packets can be routed after decapsulation which is done after VNI->FID classification, regardless of the order of the configuration. # ./ingress_rif_conf_vxlan.sh TEST: Add RIF for existing VNI->FID mapping [ OK ] TEST: Add VNI->FID mapping for FID with a RIF [ OK ] Signed-off-by:
-
Amit Cohen authored
Before layer 2 forwarding, the device classifies an incoming packet to a FID. After classification, the FID is known, but also all the attributes of the FID, such as the router interface (RIF) via which a packet that needs to be routed will ingress the router block. For VLAN-aware bridges (802.1Q), the FID classification is done according to VID. When a RIF is added on top of a FID, the existing VID->FID mapping should be updated by the software with the new RIF. We never map multiple VLANs to the same FID using VID->FID, so we cannot create VID->FID for FID which already has a RIF using 802.1Q. Anyway, verify that packets can be routed via port which is added after the FID already has a RIF. Add a test to verify that packets can be routed after VID->FID classification, regardless of the order of the configuration. # ./ingress_rif_conf_1q.sh TEST: Add RIF for existing VID->FID mapping [ OK ] TEST: Add port to VID->FID mapping for FID with a RIF [ OK ] Signed-off-by:
-
Amit Cohen authored
Before layer 2 forwarding, the device classifies an incoming packet to a FID. After classification, the FID is known, but also all the attributes of the FID, such as the router interface (RIF) via which a packet that needs to be routed will ingress the router block. For VLAN-unaware bridges (802.1D), the FID classification is done according to {Port, VID}. When a RIF is added on top of a FID, all the existing {Port, VID}->FID mappings should be updated by the software with the new RIF. In addition, when a new mapping is added for FID which already has a RIF, the correct RIF should be used for it. Add a test to verify that packets can be routed after {Port, VID}->FID classification, regardless of the order of the configuration. # ./ingress_rif_conf_1d.sh TEST: Add RIF for existing {port, VID}->FID mapping [ OK ] TEST: Add {port, VID}->FID mapping for FID with a RIF [ OK ] Signed-off-by: -
Lorenzo Bianconi authored
Get rid of unnecessary txd_pdma pointer in mtk_xdp_submit_frame for loop since it is actually used at the end of the routine using latest mtk_tx_dma consumed pointer as reference. Signed-off-by:
-
