- 18 Apr, 2023 33 commits
-
-
Samin Guo authored
dwmac supports multiple modess. When working under rmii and rgmii, you need to set different phy interfaces. According to the dwmac document, when working in rmii, it needs to be set to 0x4, and rgmii needs to be set to 0x1. The phy interface needs to be set in syscon, the format is as follows: starfive,syscon: <&syscon, offset, shift> Tested-by:
Tommaso Merciai <tomm.merciai@gmail.com> Signed-off-by:
Samin Guo <samin.guo@starfivetech.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Samin Guo authored
This adds StarFive dwmac driver support on the StarFive JH7110 SoC. Tested-by:
Emil Renner Berthing <kernel@esmil.dk> Signed-off-by:
-
Yanhong Wang authored
Add documentation to describe StarFive dwmac driver(GMAC). Signed-off-by:
Yanhong Wang <yanhong.wang@starfivetech.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Samin Guo authored
According to: stmmac_platform.c: stmmac_probe_config_dt stmmac_main.c: stmmac_dvr_probe dwmac controller may require one (stmmaceth) or two (stmmaceth+ahb) reset signals, and the maxItems of resets/reset-names is going to be 2. The gmac of Starfive Jh7110 SOC must have two resets. it uses snps,dwmac-5.20 IP. Reviewed-by:
-
Emil Renner Berthing authored
Add "snps,dwmac-5.20" compatible string for 5.20 version that can avoid to define some platform data in the glue layer. Tested-by:
-
Emil Renner Berthing authored
Add dwmac-5.20 IP version to snps.dwmac.yaml Acked-by:
-
Paolo Abeni authored
Heiner Kallweit says: ==================== r8169: use new macros from netdev_queues.h Add one missing subqueue version of the macros, and use the new macros in r8169 to simplify the code. ==================== Link: https://lore.kernel.org/r/7147a001-3d9c-a48d-d398-a94c666aa65b@gmail.comSigned-off-by:
-
Heiner Kallweit authored
Use new net core macro netif_subqueue_completed_wake to simplify the code of the tx cleanup path. Reviewed-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Use new net core macro netif_subqueue_maybe_stop in the start_xmit path to simplify the code. Whilst at it, set the tx queue start threshold to twice the stop threshold. Before values were the same, resulting in stopping/starting the queue more often than needed. Signed-off-by:
-
Heiner Kallweit authored
Add netif_subqueue_completed_wake, complementing the subqueue versions netif_subqueue_try_stop and netif_subqueue_maybe_stop. Reviewed-by:
-
Jakub Kicinski authored
Vladimir Oltean says: ==================== Ocelot/Felix driver support for preemptible traffic classes The series "Add tc-mqprio and tc-taprio support for preemptible traffic classes" from: https://lore.kernel.org/netdev/20230220122343.1156614-1-vladimir.oltean@nxp.com/ was eventually submitted in a form without the support for the Ocelot/Felix switch driver. This patch set picks up that work again, and presents a fairly modified form compared to the original. ==================== Link: https://lore.kernel.org/r/20230415170551.3939607-1-vladimir.oltean@nxp.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Vladimir Oltean authored
In order to not transmit (preemptible) frames which will be received by the link partner as corrupted (because it doesn't support FP), the hardware requires the driver to program the QSYS_PREEMPTION_CFG_P_QUEUES register only after the MAC Merge layer becomes active (verification succeeds, or was disabled). There are some cases when FP is known (through experimentation) to be broken. Give priority to FP over cut-through switching, and disable FP for known broken link modes. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
Vladimir Oltean authored
The mqprio queue configuration can appear either through TC_SETUP_QDISC_MQPRIO or through TC_SETUP_QDISC_TAPRIO. Make sure both are treated in the same way. Code does nothing new for now (except for rejecting multiple TXQs per TC, which is a useless concept with DSA switches). Signed-off-by:
Ferenc Fejes <fejes@inf.elte.hu> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
This doesn't apply anything to hardware and in general doesn't do anything that the software variant doesn't do, except for checking that there isn't more than 1 TXQ per TC (TXQs for a DSA switch are a dubious concept anyway). The reason we add this is to be able to parse one more field added to struct tc_mqprio_qopt_offload, namely preemptible_tcs. Signed-off-by:
-
Vladimir Oltean authored
ocelot_mm_update_port_status() updates mm->verify_status, but when the verification state of a port changes, an IRQ isn't emitted, but rather, only when the verification state reaches one of the final states (like DISABLED, FAILED, SUCCEEDED) - things that would affect mm->tx_active, which is what the IRQ *is* actually emitted for. That is to say, user space may miss reports of an intermediary MAC Merge verification state (like from INITIAL to VERIFYING), unless there was an IRQ notifying the driver of the change in mm->tx_active as well. This is not a huge deal, but for reliable reporting to user space, let's call ocelot_mm_update_port_status() synchronously from ocelot_port_get_mm(), which makes user space see the current MM status. Signed-off-by:
-
Vladimir Oltean authored
The MAC Merge IRQ of all ports is shared with the PTP TX timestamp IRQ of all ports, which means that currently, when a PTP TX timestamp is generated, felix_irq_handler() also polls for the MAC Merge layer status of all ports, looking for changes. This makes the kernel do more work, and under certain circumstances may make ptp4l require a tx_timestamp_timeout argument higher than before. Changes to the MAC Merge layer status are only to be expected under certain conditions - its TX direction needs to be enabled - so we can check early if that is the case, and omit register access otherwise. Make ocelot_mm_update_port_status() skip register access if mm->tx_enabled is unset, and also call it once more, outside IRQ context, from ocelot_port_set_mm(), when mm->tx_enabled transitions from true to false, because an IRQ is also expected in that case. Also, a port may have its MAC Merge layer enabled but it may not have generated the interrupt. In that case, there's no point in writing to DEV_MM_STATUS to acknowledge that IRQ. We can reduce the number of register writes per port with MM enabled by keeping an "ack" variable which writes the "write-one-to-clear" bits. Those are 3 in number: PRMPT_ACTIVE_STICKY, UNEXP_RX_PFRM_STICKY and UNEXP_TX_PFRM_STICKY. The other fields in DEV_MM_STATUS are read-only and it doesn't matter what is written to them, so writing zero is just fine. Signed-off-by:
-
Vladimir Oltean authored
Unfortunately, the workarounds for the hardware bugs make it pointless to keep fine-grained locking for the MAC Merge state of each port. Our vsc9959_cut_through_fwd() implementation requires ocelot->fwd_domain_lock to be held, in order to serialize with changes to the bridging domains and to port speed changes (which affect which ports can be cut-through). Simultaneously, the traffic classes which can be cut-through cannot be preemptible at the same time, and this will depend on the MAC Merge layer state (which changes from threaded interrupt context). Since vsc9959_cut_through_fwd() would have to hold the mm->lock of all ports for a correct and race-free implementation with respect to ocelot_mm_irq(), in practice it means that any time a port's mm->lock is held, it would potentially block holders of ocelot->fwd_domain_lock. In the interest of simple locking rules, make all MAC Merge layer state changes (and preemptible traffic class changes) be serialized by the ocelot->fwd_domain_lock. Signed-off-by:
-
Vladimir Oltean authored
When the switch emits an IRQ, we don't know what caused it, and we iterate through all ports to check the MAC Merge status. Move that iteration inside the ocelot lib; we will change the locking in a future change and it would be good to encapsulate that lock completely within the ocelot lib. Signed-off-by:
-
Jakub Kicinski authored
Song Yoong Siang says: ==================== XDP Rx HWTS metadata for stmmac driver Implemented XDP receive hardware timestamp metadata for stmmac driver. This patchset is tested with tools/testing/selftests/bpf/xdp_hw_metadata. Below are the test steps and results. Command on DUT: sudo ./xdp_hw_metadata <interface name> Command on Link Partner: echo -n xdp | nc -u -q1 <destination IPv4 addr> 9091 echo -n skb | nc -u -q1 <destination IPv4 addr> 9092 Result for port 9091: poll: 1 (0) skip=1 fail=0 redir=1 xsk_ring_cons__peek: 1 0x55f69f65f6d0: rx_desc[0]->addr=100000000008000 addr=8100 comp_addr=8000 rx_timestamp: 1677762069053692631 No rx_hash err=-95 0x55f69f65f6d0: complete idx=8 addr=8000 Result for port 9092: poll: 1 (0) skip=2 fail=0 redir=1 found skb hwtstamp = 1677762071.937207680 ==================== Link: https://lore.kernel.org/r/20230415064503.3225835-1-yoong.siang.song@intel.comSigned-off-by:
-
Song Yoong Siang authored
Add receive hardware timestamp metadata support via kfunc to XDP Zero Copy receive packets. Signed-off-by:
Song Yoong Siang <yoong.siang.song@intel.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
Song Yoong Siang authored
Add receive hardware timestamp metadata support via kfunc to XDP receive packets. Suggested-by:
Stanislav Fomichev <sdf@google.com> Signed-off-by:
-
Song Yoong Siang authored
Introduce struct stmmac_xdp_buff as a preparation to support XDP Rx metadata via kfuncs. Signed-off-by:
-
Jakub Kicinski authored
Leon Romanovsky says: ==================== Support tunnel mode in mlx5 IPsec packet offload This series extends mlx5 to support tunnel mode in its IPsec packet offload implementation. v0: https://lore.kernel.org/all/cover.1681106636.git.leonro@nvidia.com ==================== Link: https://lore.kernel.org/r/cover.1681388425.git.leonro@nvidia.comSigned-off-by:
-
Leon Romanovsky authored
Open mlx5 driver to accept IPsec tunnel mode. Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Reviewed-by:
Sridhar Samudrala <sridhar.samudrala@intel.com> Signed-off-by:
-
Leon Romanovsky authored
Current hardware doesn't support double encapsulation which is happening when IPsec packet offload tunnel mode is configured together with eswitch encap option. Any user attempt to add new SA/policy after he/she sets encap mode, will generate the following FW syndrome: mlx5_core 0000:08:00.0: mlx5_cmd_out_err:803:(pid 1904): CREATE_FLOW_TABLE(0x930) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0xa43321), err(-22) Make sure that we block encap changes before creating flow steering tables. This is applicable only for packet offload in tunnel mode, while packet offload in transport mode and crypto offload, don't have such limitation as they don't perform encapsulation. Reviewed-by:
Raed Salem <raeds@nvidia.com> Signed-off-by:
-
Leon Romanovsky authored
Existing eswitch encap option enables header encapsulation. Unfortunately currently available hardware isn't able to perform double encapsulation, which can happen once IPsec packet offload tunnel mode is used together with encap mode set to BASIC. So as a solution for misconfiguration, provide an option to block encap changes, which will be used for IPsec packet offload. Reviewed-by:
Emeel Hakim <ehakim@nvidia.com> Signed-off-by:
-
Leon Romanovsky authored
In IPsec packet offload mode all header manipulations are performed by hardware, which is responsible to add/remove L2 header with source and destinations MACs. CX-7 devices don't support offload of in-kernel routing functionality, as such HW needs external help to fill other side MAC as it isn't available for HW. As a solution, let's listen to neigh ARP updates and reconfigure IPsec rules on the fly once new MAC data information arrives. Signed-off-by:
-
Leon Romanovsky authored
Extend mlx5 driver with logic to support IPsec TX packet offload in tunnel mode. Signed-off-by:
-
Leon Romanovsky authored
Extend mlx5 driver with logic to support IPsec RX packet offload in tunnel mode. Signed-off-by:
-
Leon Romanovsky authored
Refactor setup_pkt_reformat() function to accommodate future extension to support tunnel mode. Signed-off-by:
-
Leon Romanovsky authored
Create SA flow steering tables both for RX and TX with tunnel reformat property. This allows to add and delete extra headers needed for tunnel mode. Reviewed-by:
-
Leon Romanovsky authored
Validate tunnel mode support for IPsec packet offload. Reviewed-by:
-
Leon Romanovsky authored
Extend packet reformat types and flow table capabilities with IPsec packet offload tunnel bits. Reviewed-by:
-
- 17 Apr, 2023 7 commits
-
-
Horatiu Vultur authored
From time to time, it was observed that the nanosecond part of the received timestamp, which is extracted from the IFH, it was actually bigger than 1 second. So then when actually calculating the full received timestamp, based on the nanosecond part from IFH and the second part which is read from HW, it was actually wrong. The issue seems to be inside the function lan966x_ifh_get, which extracts information from an IFH(which is an byte array) and returns the value in a u64. When extracting the timestamp value from the IFH, which starts at bit 192 and have the size of 32 bits, then if the most significant bit was set in the timestamp, then this bit was extended then the return value became 0xffffffff... . And the reason of this is because constants without any postfix are treated as signed longs and that is the reason why '1 << 31' becomes 0xffffffff80000000. This is fixed by adding the postfix 'ULL' to 1. Fixes: fd762783 ("net: lan966x: Stop using packing library") Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Xin Long says: ==================== sctp: add some missing peer_capables in sctp info dump The 1st patch removes the unused and obsolete hostname_address from sctp_association peer and also the bit from sctp_info peer_capables, and then reuses its bit for reconf_capable and use the higher available bit for intl_capable in the 2nd patch. ==================== Signed-off-by: -
Xin Long authored
There are two new peer capables have been added since sctp_diag was introduced into SCTP. When dumping the peer capables, these two new peer capables should also be included. To not break the old capables, reconf_capable takes the old hostname_address bit, and intl_capable uses the higher available bit in sctpi_peer_capable. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Xin Long authored
In the latest RFC9260, the Host Name Address param has been deprecated. For INIT chunk: Note 3: An INIT chunk MUST NOT contain the Host Name Address parameter. The receiver of an INIT chunk containing a Host Name Address parameter MUST send an ABORT chunk and MAY include an "Unresolvable Address" error cause. For Supported Address Types: The value indicating the Host Name Address parameter MUST NOT be used when sending this parameter and MUST be ignored when receiving this parameter. Currently Linux SCTP doesn't really support Host Name Address param, but only saves some flag and print debug info, which actually won't even be triggered due to the verification in sctp_verify_param(). This patch is to delete those dead code. Signed-off-by:
-
David S. Miller authored
Matthieu Baerts says: ==================== mptcp: various small cleanups Patch 1 makes a function static because it is only used in one file. Patch 2 adds info about the git trees we use to help occasional devs. Patch 3 removes an unused variable. Patch 4 removes duplicated entries from the help menu of a tool used in MPTCP selftests. Patch 5 removes some ShellCheck warnings in mptcp_join.sh selftest. Only very minor improvements then. ==================== Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
-
Matthieu Baerts authored
Most of the code had an issue according to ShellCheck. That's mainly due to the fact it incorrectly believes most of the code was unreachable because it's invoked by variable name, see how the "tests" array is used. Once SC2317 has been ignored, three small warnings were still visible: - SC2155: Declare and assign separately to avoid masking return values. - SC2046: Quote this to prevent word splitting: can be ignored because "ip netns pids" can display more than one pid. - SC2166: Prefer [ p ] || [ q ] as [ p -o q ] is not well defined. This probably didn't fix any actual issues but it might help spotting new interesting warnings reported by ShellCheck as just before, ShellCheck was reporting issues for most lines making it a bit useless. Signed-off-by:
-
Matthieu Baerts authored
mptcp_connect tool was printing some duplicated entries when showing how to use it: -j -l -r While at it, I also: - moved the very few entries that were not sorted, - added -R that was missing since commit 8a4b910d ("mptcp: selftests: add rcvbuf set option"), - removed the -u parameter that has been removed in commit f730b65c ("selftests: mptcp: try to set mptcp ulp mode in different sk states"). No need to backport this, it is just an internal tool used by our selftests. The help menu is mainly useful for MPTCP kernel devs. Acked-by:
-
