summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-07-29selftests/bpf: Bump internal send_signal/send_signal_tracepoint timeoutDaniel Müller2-6/+3
The send_signal/send_signal_tracepoint is pretty flaky, with at least one failure in every ten runs on a few attempts I've tried it: > test_send_signal_common:PASS:pipe_c2p 0 nsec > test_send_signal_common:PASS:pipe_p2c 0 nsec > test_send_signal_common:PASS:fork 0 nsec > test_send_signal_common:PASS:skel_open_and_load 0 nsec > test_send_signal_common:PASS:skel_attach 0 nsec > test_send_signal_common:PASS:pipe_read 0 nsec > test_send_signal_common:PASS:pipe_write 0 nsec > test_send_signal_common:PASS:reading pipe 0 nsec > test_send_signal_common:PASS:reading pipe error: size 0 0 nsec > test_send_signal_common:FAIL:incorrect result unexpected incorrect result: actual 48 != expected 50 > test_send_signal_common:PASS:pipe_write 0 nsec > #139/1 send_signal/send_signal_tracepoint:FAIL The reason does not appear to be a correctness issue in the strict sense. Rather, we merely do not receive the signal we are waiting for within the provided timeout. Let's bump the timeout by a factor of ten. With that change I have not been able to reproduce the failure in 150+ iterations. I am also sneaking in a small simplification to the test_progs test selection logic. Signed-off-by: Daniel Müller <deso@posteo.net> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20220727182955.4044988-1-deso@posteo.net
2022-07-29bpftool: Don't try to return value from void function in skeletonJörn-Thorben Hinz1-1/+1
A skeleton generated by bpftool previously contained a return followed by an expression in OBJ_NAME__detach(), which has return type void. This did not hurt, the bpf_object__detach_skeleton() called there returns void itself anyway, but led to a warning when compiling with e.g. -pedantic. Signed-off-by: Jörn-Thorben Hinz <jthinz@mailbox.tu-berlin.de> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20220726133203.514087-1-jthinz@mailbox.tu-berlin.de
2022-07-29bpftool: Replace sizeof(arr)/sizeof(arr[0]) with ARRAY_SIZE macroRongguang Wei1-1/+1
Use the ARRAY_SIZE macro and make the code more compact. Signed-off-by: Rongguang Wei <weirongguang@kylinos.cn> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20220726093045.3374026-1-clementwei90@163.com
2022-07-29bpf: btf: Fix vsnprintf return value checkFedor Tokarev1-1/+1
vsnprintf returns the number of characters which would have been written if enough space had been available, excluding the terminating null byte. Thus, the return value of 'len_left' means that the last character has been dropped. Signed-off-by: Fedor Tokarev <ftokarev@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Alan Maguire <alan.maguire@oracle.com> Link: https://lore.kernel.org/bpf/20220711211317.GA1143610@laptop
2022-07-29libbpf: Support PPC in arch_specific_syscall_pfxDaniel Müller1-1/+10
Commit 708ac5bea0ce ("libbpf: add ksyscall/kretsyscall sections support for syscall kprobes") added the arch_specific_syscall_pfx() function, which returns a string representing the architecture in use. As it turns out this function is currently not aware of Power PC, where NULL is returned. That's being flagged by the libbpf CI system, which builds for ppc64le and the compiler sees a NULL pointer being passed in to a %s format string. With this change we add representations for two more architectures, for Power PC and Power PC 64, and also adjust the string format logic to handle NULL pointers gracefully, in an attempt to prevent similar issues with other architectures in the future. Fixes: 708ac5bea0ce ("libbpf: add ksyscall/kretsyscall sections support for syscall kprobes") Signed-off-by: Daniel Müller <deso@posteo.net> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20220728222345.3125975-1-deso@posteo.net
2022-07-27selftests/bpf: Adjust vmtest.sh to use local kernel configurationDaniel Müller1-19/+34
So far the vmtest.sh script, which can be used as a convenient way to run bpf selftests, has obtained the kernel config safe to use for testing from the libbpf/libbpf GitHub repository [0]. Given that we now have included this configuration into this very repository, we can just consume it from here as well, eliminating the necessity of remote accesses. With this change we adjust the logic in the script to use the configuration from below tools/testing/selftests/bpf/configs/ instead of pulling it over the network. [0] https://github.com/libbpf/libbpf Signed-off-by: Daniel Müller <deso@posteo.net> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Acked-by: Mykola Lysenko <mykolal@fb.com> Link: https://lore.kernel.org/bpf/20220727001156.3553701-4-deso@posteo.net
2022-07-27selftests/bpf: Copy over libbpf configsDaniel Müller4-0/+471
This change integrates libbpf maintained configurations and black/white lists [0] into the repository, co-located with the BPF selftests themselves. We minimize the kernel configurations to keep future updates as small as possible [1]. Furthermore, we make both kernel configurations build on top of the existing configuration tools/testing/selftests/bpf/config (to be concatenated before build). Lastly, we replaced the terms blacklist & whitelist with denylist and allowlist, respectively. [0] https://github.com/libbpf/libbpf/tree/20f03302350a4143825cedcbd210c4d7112c1898/travis-ci/vmtest/configs [1] https://lore.kernel.org/bpf/20220712212124.3180314-1-deso@posteo.net/T/#m30a53648352ed494e556ac003042a9ad0a8f98c6 Signed-off-by: Daniel Müller <deso@posteo.net> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Acked-by: Mykola Lysenko <mykolal@fb.com> Link: https://lore.kernel.org/bpf/20220727001156.3553701-3-deso@posteo.net
2022-07-27selftests/bpf: Sort configurationDaniel Müller1-50/+49
This change makes sure to sort the existing minimal kernel configuration containing options required for running BPF selftests alphabetically. Doing so will make it easier to diff it against other configurations, which in turn helps with maintaining disjunct config files that build on top of each other. It also helped identify the CONFIG_IPV6_GRE being set twice and removes one of the occurrences. Lastly, we change NET_CLS_BPF from 'm' to 'y'. Having this option as 'm' will cause failures of the btf_skc_cls_ingress selftest. Signed-off-by: Daniel Müller <deso@posteo.net> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Acked-by: Mykola Lysenko <mykolal@fb.com> Link: https://lore.kernel.org/bpf/20220727001156.3553701-2-deso@posteo.net
2022-07-26selftests/bpf: Attach to socketcall() in test_probe_userIlya Leoshkevich2-13/+51
test_probe_user fails on architectures where libc uses socketcall(SYS_CONNECT) instead of connect(). Fix by attaching to socketcall as well. Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/bpf/20220726134008.256968-3-iii@linux.ibm.com
2022-07-26libbpf: Extend BPF_KSYSCALL documentationIlya Leoshkevich1-4/+11
Explicitly list known quirks. Mention that socket-related syscalls can be invoked via socketcall(). Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/bpf/20220726134008.256968-2-iii@linux.ibm.com
2022-07-26bpf, devmap: Compute proper xdp_frame len redirecting framesLorenzo Bianconi1-2/+2
Even if it is currently forbidden to XDP_REDIRECT a multi-frag xdp_frame into a devmap, compute proper xdp_frame length in __xdp_enqueue and is_valid_dst routines running xdp_get_frame_len(). Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/894d99c01139e921bdb6868158ff8e67f661c072.1658596075.git.lorenzo@kernel.org
2022-07-26bpf: Fix bpf_xdp_pointer return pointerJoanne Koong1-1/+1
For the case where offset + len == size, bpf_xdp_pointer should return a valid pointer to the addr because that access is permitted. We should only return NULL in the case where offset + len exceeds size. Fixes: 3f364222d032 ("net: xdp: introduce bpf_xdp_pointer utility routine") Signed-off-by: Joanne Koong <joannelkoong@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Martin KaFai Lau <kafai@fb.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/bpf/20220722220105.2065466-1-joannelkoong@gmail.com
2022-07-26selftests/bpf: Don't assign outer source IP to hostPaul Chaignon2-11/+86
The previous commit fixed a bug in the bpf_skb_set_tunnel_key helper to avoid dropping packets whose outer source IP address isn't assigned to a host interface. This commit changes the corresponding selftest to not assign the outer source IP address to an interface. Not assigning the source IP to an interface causes two issues in the existing test: 1. The ARP requests will fail for that IP address so we need to add the ARP entry manually. 2. The encapsulated ICMP echo reply traffic will not reach the VXLAN device. It will be dropped by the stack before, because the outer destination IP is unknown. To solve 2., we have two choices. Either we perform decapsulation ourselves in a BPF program attached at veth1 (the base device for the VXLAN device), or we switch the outer destination address when we receive the packet at veth1, such that the stack properly demultiplexes it to the VXLAN device afterward. This commit implements the second approach, where we switch the outer destination address from the unassigned IP address to the assigned one, only for VXLAN traffic ingressing veth1. Then, at the vxlan device, the BPF program that checks the output of bpf_skb_get_tunnel_key needs to be updated as the expected local IP address is now the unassigned one. Signed-off-by: Paul Chaignon <paul@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/4addde76eaf3477a58975bef15ed2788c44e5f55.1658759380.git.paul@isovalent.com
2022-07-26bpf: Set flow flag to allow any source IP in bpf_tunnel_keyPaul Chaignon1-0/+1
Commit 26101f5ab6bd ("bpf: Add source ip in "struct bpf_tunnel_key"") added support for getting and setting the outer source IP of encapsulated packets via the bpf_skb_{get,set}_tunnel_key BPF helper. This change allows BPF programs to set any IP address as the source, including for example the IP address of a container running on the same host. In that last case, however, the encapsulated packets are dropped when looking up the route because the source IP address isn't assigned to any interface on the host. To avoid this, we need to set the FLOWI_FLAG_ANYSRC flag. Fixes: 26101f5ab6bd ("bpf: Add source ip in "struct bpf_tunnel_key"") Signed-off-by: Paul Chaignon <paul@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/76873d384e21288abe5767551a0799ac93ec07fb.1658759380.git.paul@isovalent.com
2022-07-26geneve: Use ip_tunnel_key flow flags in route lookupsPaul Chaignon1-0/+1
Use the new ip_tunnel_key field with the flow flags in the IPv4 route lookups for the encapsulated packet. This will be used by the bpf_skb_set_tunnel_key helper in the subsequent commit. Signed-off-by: Paul Chaignon <paul@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/fcc2e0eea01e8ea465a180126366ec20596ba530.1658759380.git.paul@isovalent.com
2022-07-26vxlan: Use ip_tunnel_key flow flags in route lookupsPaul Chaignon1-4/+7
Use the new ip_tunnel_key field with the flow flags in the IPv4 route lookups for the encapsulated packet. This will be used by the bpf_skb_set_tunnel_key helper in a subsequent commit. Signed-off-by: Paul Chaignon <paul@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/1ffc95c3d60182fd5ec0cf6602083f8f68afe98f.1658759380.git.paul@isovalent.com
2022-07-26ip_tunnels: Add new flow flags field to ip_tunnel_keyPaul Chaignon1-0/+1
This commit extends the ip_tunnel_key struct with a new field for the flow flags, to pass them to the route lookups. This new field will be populated and used in subsequent commits. Signed-off-by: Paul Chaignon <paul@isovalent.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/f8bfd4983bd06685a59b1e3ba76ca27496f51ef3.1658759380.git.paul@isovalent.com
2022-07-26Merge branch 'add-mtu-change-with-stmmac-interface-running'Jakub Kicinski7-313/+459
Christian Marangi says: ==================== Add MTU change with stmmac interface running This series is to permit MTU change while the interface is running. Major rework are needed to permit to allocate a new dma conf based on the new MTU before applying it. This is to make sure there is enough space to allocate all the DMA queue before releasing the stmmac driver. This was tested with a simple way to stress the network while the interface is running. 2 ssh connection to the device: - One generating simple traffic with while true; do free; done - The other making the mtu change with a delay of 1 second The connection is correctly stopped and recovered after the MTU is changed. The first 2 patch of this series are minor fixup that fix problems presented while testing this. One fix a problem when we renable a queue while we are generating a new dma conf. The other is a corner case that was notice while stressing the driver and turning down the interface while there was some traffic. (this is a follow-up of a simpler patch that wanted to add the same feature. It was suggested to first try to check if it was possible to apply the new configuration. Posting as RFC as it does major rework for the new concept of DMA conf) ==================== Link: https://lore.kernel.org/r/20220723142933.16030-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-26net: ethernet: stmicro: stmmac: permit MTU change with interface upChristian Marangi1-6/+24
Remove the limitation where the interface needs to be down to change MTU by releasing and opening the stmmac driver to set the new MTU. Also call the set_filter function to correctly init the port. This permits to remove the EBUSY error while the ethernet port is running permitting a correct MTU change if for example a DSA request a MTU change for a switch CPU port. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-26net: ethernet: stmicro: stmmac: generate stmmac dma conf before openChristian Marangi1-173/+289
Rework the driver to generate the stmmac dma_conf before stmmac_open. This permits a function to first check if it's possible to allocate a new dma_config and then pass it directly to __stmmac_open and "open" the interface with the new configuration. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-26net: ethernet: stmicro: stmmac: move dma conf to dedicated structChristian Marangi7-163/+172
Move dma buf conf to dedicated struct. This in preparation for code rework that will permit to allocate separate dma_conf without affecting the priv struct. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-26net: ethernet: stmicro: stmmac: first disable all queues and disconnect in ↵Christian Marangi1-2/+2
release Disable all queues and disconnect before tx_disable in stmmac_release to prevent a corner case where packet may be still queued at the same time tx_disable is called resulting in kernel panic if some packet still has to be processed. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-26net: ethernet: stmicro: stmmac: move queue reset to dedicated functionsChristian Marangi1-28/+31
Move queue reset to dedicated functions. This aside from a simple cleanup is also required to allocate a dma conf without resetting the tx queue while the device is temporarily detached as now the reset is not part of the dma init function and can be done later in the code flow. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-26net: delete extra space and tab in blank lineWilliam Dean2-2/+2
delete extra space and tab in blank line, there is no functional change. Reported-by: Hacash Robot <hacashRobot@santino.com> Signed-off-by: William Dean <williamsukatube@gmail.com> Link: https://lore.kernel.org/r/20220723073222.2961602-1-williamsukatube@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-26Merge tag 'wireless-next-2022-07-25' of ↵Jakub Kicinski179-6856/+9151
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v5.20 Third set of patches for v5.20. MLO work continues and we have a lot of stack changes due to that, including driver API changes. Not much driver patches except on mt76. Major changes: cfg80211/mac80211 - more prepartion for Wi-Fi 7 Multi-Link Operation (MLO) support, works with one link now - align with IEEE Draft P802.11be_D2.0 - hardware timestamps for receive and transmit mt76 - preparation for new chipset support - ACPI SAR support * tag 'wireless-next-2022-07-25' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (254 commits) wifi: mac80211: fix link data leak wifi: mac80211: mlme: fix disassoc with MLO wifi: mac80211: add macros to loop over active links wifi: mac80211: remove erroneous sband/link validation wifi: mac80211: mlme: transmit assoc frame with address translation wifi: mac80211: verify link addresses are different wifi: mac80211: rx: track link in RX data wifi: mac80211: optionally implement MLO multicast TX wifi: mac80211: expand ieee80211_mgmt_tx() for MLO wifi: nl80211: add MLO link ID to the NL80211_CMD_FRAME TX API wifi: mac80211: report link ID to cfg80211 on mgmt RX wifi: cfg80211: report link ID in NL80211_CMD_FRAME wifi: mac80211: add hardware timestamps for RX and TX wifi: cfg80211: add hardware timestamps to frame RX info wifi: cfg80211/nl80211: move rx management data into a struct wifi: cfg80211: add a function for reporting TX status with hardware timestamps wifi: nl80211: add RX and TX timestamp attributes wifi: ieee80211: add helper functions for detecting TM/FTM frames wifi: mac80211_hwsim: handle links for wmediumd/virtio wifi: mac80211: sta_info: fix link_sta insertion ... ==================== Link: https://lore.kernel.org/r/20220725174547.EA465C341C6@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-26dt-bindings: net: fsl,fec: Add nvmem-cells / nvmem-cell-names propertiesAlexander Stein1-1/+5
These properties are inherited from ethernet-controller.yaml. This fixes the dt_binding_check warning: imx8mm-tqma8mqml-mba8mx.dt.yaml: ethernet@30be0000: 'nvmem-cell-names', 'nvmem-cells' do not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220720063924.1412799-1-alexander.stein@ew.tq-group.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-07-25Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo10-19/+14
ath.git patches for v5.20. One fix and rest minor cleanup.
2022-07-25Merge branch '40GbE' of ↵David S. Miller4-33/+58
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== 40GbE Intel Wired LAN Driver Updates 2022-07-22 This series contains updates to i40e and iavf drivers. Przemyslaw adds a helper function for determining whether TC MQPRIO is enabled for i40e. Avinash utilizes the driver's bookkeeping of filters to check for duplicate filter before sending the request to the PF for iavf. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25net: ethernet: mtk-ppe: fix traffic offload with bridged wlanLorenzo Bianconi1-17/+13
A typical flow offload scenario for OpenWrt users is routed traffic received by the wan interface that is redirected to a wlan device belonging to the lan bridge. Current implementation fails to fill wdma offload info in mtk_flow_get_wdma_info() since odev device is the local bridge. Fix the issue running dev_fill_forward_path routine in mtk_flow_get_wdma_info in order to identify the wlan device. Tested-by: Paolo Valerio <pvalerio@redhat.com> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25Merge branch 'mlxsw-Spectrum-2-PTP-preparations'David S. Miller8-77/+344
Ido Schimmel says: ==================== mlxsw: Spectrum-2 PTP preparations This patchset includes various preparations required for Spectrum-2 PTP support. Most of the changes are non-functional (e.g., renaming, adding registers). The only intentional user visible change is in patch #10 where the PHC time is initialized to zero in accordance with the recommendation of the PTP maintainer. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: spectrum_ptp: Rename mlxsw_sp1_ptp_phc_adjfreq()Amit Cohen1-2/+2
The function mlxsw_sp_ptp_phc_adjfreq() configures MTUTC register to adjust hardware frequency by a given value. This configuration will be same for Spectrum-2. In preparation for Spectrum-2 PTP support, rename the function to not be Spectrum-1 specific. Later, it will be used for Spectrum-2 also. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: spectrum_ptp: Rename mlxsw_sp_ptp_get_message_types()Amit Cohen1-5/+6
Spectrum-1 and Spectrum-2 differ in their time stamping capabilities. The former can be configured to time stamp only a subset of received PTP events (e.g., only Sync), whereas the latter will time stamp all PTP events or none. In preparation for Spectrum-2 PTP support, rename the function that parses the hardware time stamping configuration upon %SIOCSHWTSTAMP to be Spectrum-1 specific. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: spectrum_ptp: Use 'struct mlxsw_sp_ptp_clock' per ASICAmit Cohen1-31/+44
Currently, there is one shared structure that holds the required structures for PTP clock. Most of the existing fields are relevant only for Spectrum-1 (cycles, timecounter, and more). Rename the structure to be specific for Spectrum-1 and align the existing code. Add a common structure which includes the structures which will be used also for Spectrum-2. This structure will be returned from clock_init() operation, as the definition is shared between all ASICs' operations. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: spectrum_ptp: Use 'struct mlxsw_sp_ptp_state' per ASICAmit Cohen1-16/+35
Currently, there is one shared structure that holds the required structures and details for PTP. Most of the existing fields are relevant only for Spectrum-1 (hash table, lock for hash table, delayed work, and more). Rename the structure to be specific for Spectrum-1 and align the existing code. Add a common structure which includes 'struct mlxsw_sp *mlxsw_sp' and will be returned from ptp_init() operation, as the definition is shared between all ASICs' operations. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: pci: Simplify FRC clock readingAmit Cohen2-9/+12
Currently, the reading of FRC values (high and low) is done using macro which calls to a function. In addition, to calculate the offset of FRC, a simple macro is used. This code can be simplified by adding an helper function and calculating the offset explicitly instead of using an additional macro for that. Add the helper function and convert the existing code. This helper will be used later to read UTC clock. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: spectrum_ptp: Initialize the clock to zero as part of initializationAmit Cohen1-2/+1
As lately recommended in the mailing list[1], set the clock to zero time as part of initialization. The idea is that when the clock reads 'Jan 1, 1970', then it is clearly wrong and user will not mistakenly think that the clock is set correctly. If as part of initialization, the driver sets the clock, user might see correct date and time (maybe with a small shift) and assume that there is no need to sync the clock. Fix the existing code of Spectrum-1 to set the 'timecounter' to zero. [1]: https://lore.kernel.org/netdev/20220201191041.GB7009@hoboy.vegasvil.org/ Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: Rename 'read_frc_capable' bit to 'read_clock_capable'Danielle Ratson3-3/+3
Rename the 'read_frc_capable' bit to 'read_clock_capable' since now it can be both the FRC and UTC clocks. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: resources: Add resource identifier for maximum number of FIDsAmit Cohen1-0/+2
Add a resource identifier for maximum number of FIDs so that it could be later used to query the information from firmware. In Spectrum-2 and Spectrum-3, the correction field of PTP packets which are sent as control packets is not updated at egress port. To overcome this limitation, some packets will be sent as data packets. The header should include FID, which is supposed to be 'Max FID + port - 1'. As preparation, add the required resource, to be able to query the value from firmware later. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: spectrum: Fix the shift of FID field in TX headerDanielle Ratson1-1/+1
Currently, the field FID in TX header is defined, but is not used as it is relevant only for data packets. mlxsw driver currently sends all host-generated traffic as control packets and not as data packets. In Spectrum-2 and Spectrum-3, the correction field of PTP packets which are sent as control packets is not updated at egress port. To overcome this limitation while adding support for PTP, some packets will be sent as data packets. Fix the wrong shift in the definition, to allow using the field later. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: Set time stamp type as part of config profileDanielle Ratson4-1/+38
The type of time stamp field in the CQE is configured via the CONFIG_PROFILE command during driver initialization. Add the definition of the relevant fields to the command's payload and set the type to UTC for Spectrum-2 and above. This configuration can be done as part of the preparations to PTP support, as the type of the time stamp will not break any existing behavior. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: cmd: Add UTC related fields to query firmware commandDanielle Ratson1-0/+26
Add UTC sec and nsec PCI BAR and offset to query firmware command for a future use. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: pci_hw: Add 'time_stamp' and 'time_stamp_type' fields to CQEv2Danielle Ratson1-0/+78
The Completion Queue Element version 2 (CQEv2) includes various metadata fields of packets. Add 'time_stamp' and 'time_stamp_type' fields along with functions to extract the seconds and nanoseconds for a future use. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Amit Cohen <amcohen@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: reg: Add Monitoring Time Precision Correction Port Configuration RegisterDanielle Ratson1-0/+62
In Spectrum-2, all the packets are time stamped, the MTPCPC register is used to configure the types of packets that will adjust the correction field and which port will trap PTP packets. If ingress correction is set on a port for a given packet type, then when such a packet is received via the port, the current time stamp is subtracted from the correction field. If egress correction is set on a port for a given packet type, then when such a packet is transmitted via the port, the current time stamp is added to the correction field. Assuming the systems is configured correctly, the above means that the correction field will contain the transient delay between the ports. Add this register for a future use in order to support PTP in Spectrum-2. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: reg: Add MTUTC register's fields for supporting PTP in Spectrum-2Danielle Ratson2-4/+31
The MTUTC register configures the HW UTC counter. Add the relevant fields and operations to support PTP in Spectrum-2 and update mlxsw_reg_mtutc_pack() with the new fields for a future use. Signed-off-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25mlxsw: Rename mlxsw_reg_mtptptp_pack() to mlxsw_reg_mtptpt_pack()Danielle Ratson2-4/+4
The right name of the register is MTPTPT, which refers to Monitoring Precision Time Protocol Trap Register. Therefore, rename the function mlxsw_reg_mtptptp_pack() to mlxsw_reg_mtptpt_pack(). Signed-off-by: Danielle Ratson <danieller@nvidia.com> Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25Merge branch 'master' of ↵David S. Miller9-42/+25
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next Steffen Klassert says: ==================== pull request (net-next): ipsec-next 2022-07-20 1) Don't set DST_NOPOLICY in IPv4, a recent patch made this superfluous. From Eyal Birger. 2) Convert alg_key to flexible array member to avoid an iproute2 compile warning when built with gcc-12. From Stephen Hemminger. 3) xfrm_register_km and xfrm_unregister_km do always return 0 so change the type to void. From Zhengchao Shao. 4) Fix spelling mistake in esp6.c From Zhang Jiaming. 5) Improve the wording of comment above XFRM_OFFLOAD flags. From Petr Vaněk. Please pull or let me know if there are problems. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25Merge branch 'macb-versal-device-support'David S. Miller3-4/+19
Harini Katakam says: ==================== macb: Add Versal compatible string to Macb driver Add Versal device support. v2: - Sort compatible strings alphabetically in DT bindings. - Reorganize new config and CAPS order to be cleaner. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25net: macb: Update tsu clk usage in runtime suspend/resume for VersalHarini Katakam2-2/+16
On Versal TSU clock cannot be disabled irrespective of whether PTP is used. Hence introduce a new Versal config structure with a "need tsu" caps flag and check the same in runtime_suspend/resume before cutting off clocks. More information on this for future reference: This is an IP limitation on versions 1p11 and 1p12 when Qbv is enabled (See designcfg1, bit 3). However it is better to rely on an SoC specific check rather than the IP version because tsu clk property itself may not represent actual HW tsu clock on some chip designs. Signed-off-by: Harini Katakam <harini.katakam@xilinx.com> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25net: macb: Sort CAPS flags by bit positionsHarini Katakam1-2/+2
Sort capability flags by the bit position set. Signed-off-by: Harini Katakam <harini.katakam@xilinx.com> Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-25dt-bindings: net: cdns,macb: Add versal compatible stringRadhey Shyam Pandey1-0/+1
Add versal compatible string. Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-27 00:46:43 +0300