- 16 Jan, 2023 36 commits
-
-
Colin Foster authored
Several bindings for ethernet switches are available for non-dsa switches by way of ethernet-switch.yaml. Remove these duplicate entries and utilize the common bindings for the VSC7514. Signed-off-by:
Colin Foster <colin.foster@in-advantage.com> Suggested-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Colin Foster authored
The dsa-port.yaml binding had several references that can be common to all ethernet ports, not just dsa-specific ones. Break out the generic bindings to ethernet-switch-port.yaml they can be used by non-dsa drivers. Signed-off-by:
-
Colin Foster authored
The dsa.yaml bindings had references that can apply to non-dsa switches. To prevent duplication of this information, keep the dsa-specific information inside dsa.yaml and move the remaining generic information to the newly created ethernet-switch.yaml. Signed-off-by:
-
Colin Foster authored
dsa.yaml contains a reference to dsa-port.yaml, so a duplicate reference to the binding isn't necessary. Remove this unnecessary reference. Signed-off-by:
Arınç ÜNAL <arinc.unal@arinc9.com> Reviewed-by:
-
Colin Foster authored
The dsa.yaml binding contains duplicated bindings for address and size cells, as well as the reference to dsa-port.yaml. Instead of duplicating this information, remove the reference to dsa-port.yaml and include the full reference to dsa.yaml. Signed-off-by:
-
Colin Foster authored
Explicitly allow additional properties for both the ethernet-port and ethernet-ports properties. This specifically will allow the qca8k.yaml binding to use shared properties. Signed-off-by:
-
Colin Foster authored
DSA switches can fall into one of two categories: switches where all ports follow standard '(ethernet-)?port' properties, and switches that have additional properties for the ports. The scenario where DSA ports are all standardized can be handled by switches with a reference to the new 'dsa.yaml#/$defs/ethernet-ports'. The scenario where DSA ports require additional properties can reference '$dsa.yaml#' directly. This will allow switches to reference these standard definitions of the DSA switch, but add additional properties under the port nodes. Suggested-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
Colin Foster authored
The children of the switch node don't have a unit address, and therefore should not need the #address-cells or #size-cells entries. Fix the example schemas accordingly. Suggested-by:
-
Colin Foster authored
The property use-bcm-hdr was documented as an entry under the ports node for the bcm_sf2 DSA switch. This property is actually evaluated for each port. Correct the documentation to match the actual behavior and properly reference dsa-port.yaml for additional properties of the node. Suggested-by:
-
Colin Foster authored
The MAINTAINERS file has Andrew Lunn, Florian Fainelli, and Vladimir Oltean listed as the maintainers for generic dsa bindings. Update dsa.yaml and dsa-port.yaml accordingly. Signed-off-by:
-
David S. Miller authored
Steen Hegelund says: ==================== net: microchip: Add support for two classes of VCAP rules This adds support for two classes of VCAP rules: - Permanent rules (added e.g. for PTP support) - TC user rules (added by the TC userspace tool) For this to work the VCAP Loopups must be enabled from boot, so that the "internal" clients like PTP can add rules that are always active. When the TC tool add a flower filter the VCAP rule corresponding to this filter will be disabled (kept in memory) until a TC matchall filter creates a link from chain 0 to the chain (lookup) where the flower filter was added. When the flower filter is enabled it will be written to the appropriate VCAP lookup and become active in HW. Likewise the flower filter will be disabled if there is no link from chain 0 to the chain of the filter (lookup), and when that happens the corresponding VCAP rule will be read from the VCAP instance and stored in memory until it is deleted or enabled again. Version History: ================ v4 Removed a leftover 'Fixes' tag from v2. No functional changes. v3 Removed the change that allowed rules to always be added in the LAN996x even though the lookups are not enabled (Horatiu Vultur). This was sent separately to net instead. Removed the 'Fixes' tags due to the patch sent to net by Horatiu Vultur. Added a check for validity of the chain source when enabling a lookup. v2 Adding a missing goto exit in vcap_add_rule (Dan Carpenter). Added missing checks for error returns in vcap_enable_rule. v1 Initial version ==================== Signed-off-by: -
Steen Hegelund authored
This supports that individual rules are enabled and disabled via chain information. This is done by keeping disabled rules in the VCAP list (cached) until they are enabled, and only at this time are the rules written to the VCAP HW. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by:
-
Steen Hegelund authored
This allows a VCAP rule to be in one of 3 states: - permanently stored in the VCAP HW (for rules that must always be present) - enabled (stored in HW) when the corresponding lookup has been enabled - disabled (stored in SW) when the lookup is disabled This way important VCAP rules can be added even before the user enables the VCAP lookups using a TC matchall filter. Signed-off-by:
-
Steen Hegelund authored
This changes the way the chain information verified when adding a new tc flower filter. When adding a flower filter it is now checked that the filter contains a goto action to one of the IS2 VCAP lookups, except for the last lookup which may omit this goto action. It is also checked if you attempt to add multiple matchall filters to enable the same VCAP lookup. This will be rejected. Signed-off-by:
-
Steen Hegelund authored
This adds both the source and destination chain id to the information kept for enabled port lookups. This allows enabling and disabling a chain of lookups by walking the chain information for a port. This changes the way that VCAP lookups are enabled from userspace: instead of one matchall rule that enables all the 4 Sparx5 IS2 lookups, you need a matchall rule per lookup. In practice that is done by adding one matchall rule in chain 0 to goto IS2 Lookup 0, and then for each lookup you add a rule per lookup (low priority) that does a goto to the next lookup chain. Examples: If you want IS2 Lookup 0 to be enabled you add the same matchall filter as before: tc filter add dev eth12 ingress chain 0 prio 1000 handle 1000 matchall \ skip_sw action goto chain 8000000 If you also want to enable lookup 1 to 3 in IS2 and chain them you need to add the following matchall filters: tc filter add dev eth12 ingress chain 8000000 prio 1000 handle 1000 \ matchall skip_sw action goto chain 8100000 tc filter add dev eth12 ingress chain 8100000 prio 1000 handle 1000 \ matchall skip_sw action goto chain 8200000 tc filter add dev eth12 ingress chain 8200000 prio 1000 handle 1000 \ matchall skip_sw action goto chain 8300000 Signed-off-by: -
Steen Hegelund authored
The conversion to the platform specific multi-word format is moved from the key/action add functions to the encoding key/action. This allows rules that are disabled (not in VCAP HW) to use the same format for keys/actions as rules that have just been read from VCAP HW. Signed-off-by:
-
Steen Hegelund authored
This changes the VCAP lookups state to always be enabled so that it is possible to add "internal" VCAP rules that must be available even though the user has not yet enabled the VCAP chains via a TC matchall filter. The API callback to enable and disable VCAP lookups is therefore removed. Signed-off-by:
-
Steen Hegelund authored
When a rule counter is external to the VCAP such as the Sparx5 IS2 counters are, then this counter must be reset when a new rule is created. Signed-off-by:
-
Steen Hegelund authored
For consistency the VCAP cache area is erased just before the new rule is being encoded. Signed-off-by:
-
Heiner Kallweit authored
ASPM issues may result in the NIC not being accessible any longer. In this case disabling ASPM may not work. Therefore detect this case by checking whether register reads return ~0, and try to make the NIC accessible again by resetting the secondary bus. v2: - add exception handling for the case that pci_reset_bus() fails Suggested-by:
Alexander Duyck <alexander.duyck@gmail.com> Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Alexander Duyck <alexanderduyck@fb.com> Signed-off-by:
-
Kurt Kanzenbach authored
The switch receives management traffic such as STP and LLDP. However, PTP messages are not received, only transmitted. Ideally, the switch would trap all PTP messages to the management CPU. This particular switch has a PTP block which identifies PTP messages and traps them to a dedicated port. There is a register to program this destination. This is not used at the moment. Therefore, program it to the same port as the MGMT traffic is trapped to. This allows to receive PTP messages as soon as timestamping is enabled. In addition, the datasheet mentions that this register is not valid e.g., for 6190 variants. So, add a new PTP operation which is added for the 6390 and 6290 devices. Tested simply like this on Marvell 88E6390, revision 1: |/ # ptp4l -2 -i lan4 --tx_timestamp_timeout=40 -m |[...] |ptp4l[147.450]: master offset 56 s2 freq +1262 path delay 413 |ptp4l[148.450]: master offset 22 s2 freq +1244 path delay 434 |ptp4l[149.450]: master offset 5 s2 freq +1234 path delay 446 |ptp4l[150.451]: master offset 3 s2 freq +1233 path delay 451 |ptp4l[151.451]: master offset 1 s2 freq +1232 path delay 451 |ptp4l[152.451]: master offset -3 s2 freq +1229 path delay 451 |ptp4l[153.451]: master offset 9 s2 freq +1240 path delay 451 Link: https://lore.kernel.org/r/CAFSKS=PJBpvtRJxrR4sG1hyxpnUnQpiHg4SrUNzAhkWnyt9ivg@mail.gmail.comSigned-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Tested-by:
-
Bobby Eshleman authored
This commit changes virtio/vsock to use sk_buff instead of virtio_vsock_pkt. Beyond better conforming to other net code, using sk_buff allows vsock to use sk_buff-dependent features in the future (such as sockmap) and improves throughput. This patch introduces the following performance changes: Tool: Uperf Env: Phys Host + L1 Guest Payload: 64k Threads: 16 Test Runs: 10 Type: SOCK_STREAM Before: commit b7bfaa76 ("Linux 6.2-rc3") Before ------ g2h: 16.77Gb/s h2g: 10.56Gb/s After ----- g2h: 21.04Gb/s h2g: 10.76Gb/s Signed-off-by:
Bobby Eshleman <bobby.eshleman@bytedance.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-01-13 (ixgbe) This series contains updates to ixgbe driver only. Jesse resolves warning for RCU pointer by no longer restoring old pointer. Sebastian adds waiting for updating of link info on devices utilizing crosstalk fix to avoid false link state. ==================== Signed-off-by: -
Kirill Tkhai authored
After switching to TCP_ESTABLISHED or TCP_LISTEN sk_state, alive SOCK_STREAM and SOCK_SEQPACKET sockets can't change it anymore (since commit 3ff8bff7 "unix: Fix race in SOCK_SEQPACKET's unix_dgram_sendmsg()"). Thus, we do not need to take lock here. Signed-off-by:
Kirill Tkhai <tkhai@ya.ru> Reviewed-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Signed-off-by:
-
David S. Miller authored
Heng Qi says: ==================== virtio-net: support multi buffer xdp Changes since PATCH v4: - Make netdev_warn() in [PATCH 2/10] independent from [PATCH 3/10]. Changes since PATCH v3: - Separate fix patch [2/10] for MTU calculation of single buffer xdp. Note that this patch needs to be backported to the stable branch. Changes since PATCH v2: - Even if single buffer xdp has a hole mechanism, there will be no problem (limiting mtu and turning off GUEST GSO), so there is no need to backport "[PATCH 1/9]"; - Modify calculation of MTU for single buffer xdp in virtnet_xdp_set(); - Make truesize in mergeable mode return to literal meaning; - Add some comments for legibility; Changes since RFC: - Using headroom instead of vi->xdp_enabled to avoid re-reading in add_recvbuf_mergeable(); - Disable GRO_HW and keep linearization for single buffer xdp; - Renamed to virtnet_build_xdp_buff_mrg(); - pr_debug() to netdev_dbg(); - Adjusted the order of the patch series. Currently, virtio net only supports xdp for single-buffer packets or linearized multi-buffer packets. This patchset supports xdp for multi-buffer packets, then larger MTU can be used if xdp sets the xdp.frags. This does not affect single buffer handling. In order to build multi-buffer xdp neatly, we integrated the code into virtnet_build_xdp_buff_mrg() for xdp. The first buffer is used for prepared xdp buff, and the rest of the buffers are added to its skb_shared_info structure. This structure can also be conveniently converted during XDP_PASS to get the corresponding skb. Since virtio net uses comp pages, and bpf_xdp_frags_increase_tail() is based on the assumption of the page pool, (rxq->frag_size - skb_frag_size(frag) - skb_frag_off(frag)) is negative in most cases. So we didn't set xdp_rxq->frag_size in virtnet_open() to disable the tail increase. ==================== Signed-off-by: -
Heng Qi authored
Driver can pass the skb to stack by build_skb_from_xdp_buff(). Driver forwards multi-buffer packets using the send queue when XDP_TX and XDP_REDIRECT, and clears the reference of multi pages when XDP_DROP. Signed-off-by:
Heng Qi <hengqi@linux.alibaba.com> Reviewed-by:
Xuan Zhuo <xuanzhuo@linux.alibaba.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Heng Qi authored
For the clear construction of xdp_buff, we remove the xdp processing interleaved with page_to_skb(). Now, the logic of xdp and building skb from xdp are separate and independent. Signed-off-by:
-
Heng Qi authored
This converts the xdp_buff directly to a skb, including multi-buffer and single buffer xdp. We'll isolate the construction of skb based on xdp from page_to_skb(). Signed-off-by:
-
Heng Qi authored
This serves as the basis for XDP_TX and XDP_REDIRECT to send a multi-buffer xdp_frame. Signed-off-by:
-
Heng Qi authored
Build multi-buffer xdp using virtnet_build_xdp_buff_mrg(). For the prefilled buffer before xdp is set, we will probably use vq reset in the future. At the same time, virtio net currently uses comp pages, and bpf_xdp_frags_increase_tail() needs to calculate the tailroom of the last frag, which will involve the offset of the corresponding page and cause a negative value, so we disable tail increase by not setting xdp_rxq->frag_size. Signed-off-by:
-
Heng Qi authored
Support xdp for multi buffer packets in mergeable mode. Putting the first buffer as the linear part for xdp_buff, and the rest of the buffers as non-linear fragments to struct skb_shared_info in the tailroom belonging to xdp_buff. Let 'truesize' return to its literal meaning, that is, when xdp is set, it includes the length of headroom and tailroom. Signed-off-by:
-
Heng Qi authored
Update relative record value for xdp_frame as basis for multi-buffer xdp transmission. Signed-off-by:
-
Heng Qi authored
When the xdp program sets xdp.frags, which means it can process multi-buffer packets over larger MTU, so we continue to support xdp. Signed-off-by:
-
Heng Qi authored
When single-buffer xdp is loaded, the size of the buffer filled each time is 'sz = (PAGE_SIZE - headroom - tailroom)', which is the maximum packet length that the driver allows the device to pass in. Otherwise, the packet with a length greater than sz will come in, so num_buf will be greater than or equal to 2, and xdp_linearize_page() will be performed and the packet will be dropped because the total length is greater than PAGE_SIZE. So the maximum value of MTU for single-buffer xdp is 'max_sz = sz - ETH_HLEN'. Signed-off-by:
-
Heng Qi authored
XDP core assumes that the frame_size of xdp_buff and the length of the frag are PAGE_SIZE. The hole may cause the processing of xdp to fail, so we disable the hole mechanism when xdp is set. Signed-off-by:
-
Srujana Challa authored
Updates CPT inbound inline IPsec configure mailbox to take CPT credit, opcode, credit_th and bpid from VF. This patch also adds a mailbox to read inbound IPsec configuration. Signed-off-by:
Srujana Challa <schalla@marvell.com> Signed-off-by:
-
- 14 Jan, 2023 4 commits
-
-
Jakub Kicinski authored
David Thompson says: ==================== mlxbf_gige: add BlueField-3 support This patch series adds driver logic to the "mlxbf_gige" Ethernet driver in order to support the third generation BlueField SoC (BF3). The existing "mlxbf_gige" driver is extended with BF3-specific logic and run-time decisions are made by the driver depending on the SoC generation (BF2 vs. BF3). The BF3 SoC is similar to BF2 SoC with regards to transmit and receive packet processing: * Driver rings usage; consumer & producer indices * Single queue for receive and transmit * DMA operation The differences between BF3 and BF2 SoC are: * In addition to supporting 1Gbps interface speed, the BF3 SoC adds support for 10Mbps and 100Mbps interface speeds * BF3 requires SerDes config logic to support its SGMII interface * BF3 adds support for "ethtool -s" for interface speed config * BF3 utilizes different MDIO logic for accessing the board-level PHY device Testing - Successful build of kernel for ARM64, ARM32, X86_64 - Tested ARM64 build on FastModels, Palladium, SoC ==================== Link: https://lore.kernel.org/r/20230112202609.21331-1-davthompson@nvidia.comSigned-off-by:Jakub Kicinski <kuba@kernel.org>
-
David Thompson authored
This patch fixes the white space issue raised by checkpatch: CHECK: Alignment should match open parenthesis +static int mlxbf_gige_eth_ioctl(struct net_device *netdev, + struct ifreq *ifr, int cmd) Signed-off-by:
David Thompson <davthompson@nvidia.com> Signed-off-by:
Asmaa Mnebhi <asmaa@nvidia.com> Signed-off-by:
-
David Thompson authored
This patch extends the "ethtool_ops" data structure to include the "set_link_ksettings" callback. This change enables configuration of the various interface speeds that the BlueField-3 supports (10Mbps, 100Mbps, and 1Gbps). Signed-off-by:
-
David Thompson authored
The BlueField-3 OOB interface supports 10Mbps, 100Mbps, and 1Gbps speeds. The external PHY is responsible for autonegotiating the speed with the link partner. Once the autonegotiation is done, the BlueField PLU needs to be configured accordingly. This patch does two things: 1) Initialize the advertised control flow/duplex/speed in the probe based on the BlueField SoC generation (2 or 3) 2) Adjust the PLU speed config in the PHY interrupt handler Signed-off-by:
-
