- 17 Oct, 2023 2 commits
-
-
Yunsheng Lin authored
Currently page_pool_alloc_frag() is not supported in 32-bit arch with 64-bit DMA because of the overlap issue between pp_frag_count and dma_addr_upper in 'struct page' for those arches, which seems to be quite common, see [1], which means driver may need to handle it when using fragment API. It is assumed that the combination of the above arch with an address space >16TB does not exist, as all those arches have 64b equivalent, it seems logical to use the 64b version for a system with a large address space. It is also assumed that dma address is page aligned when we are dma mapping a page aligned buffer, see [2]. That means we're storing 12 bits of 0 at the lower end for a dma address, we can reuse those bits for the above arches to support 32b+12b, which is 16TB of memory. If we make a wrong assumption, a warning is emitted so that user can report to us. 1. https://lore.kernel.org/all/20211117075652.58299-1-linyunsheng@huawei.com/ 2. https://lore.kernel.org/all/20230818145145.4b357c89@kernel.org/Tested-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com> CC: Lorenzo Bianconi <lorenzo@kernel.org> CC: Alexander Duyck <alexander.duyck@gmail.com> CC: Liang Chen <liangchen.linux@gmail.com> CC: Guillaume Tucker <guillaume.tucker@collabora.com> CC: Matthew Wilcox <willy@infradead.org> CC: Linux-MM <linux-mm@kvack.org> Link: https://lore.kernel.org/r/20231013064827.61135-2-linyunsheng@huawei.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jacob Keller authored
A few networking drivers including bnx2x, bnxt, qede, and idpf call tcp_gro_complete as part of offloading TCP GRO. The function is only defined if CONFIG_INET is true, since its TCP specific and is meaningless if the kernel lacks IP networking support. The combination of trying to use the complex network drivers with CONFIG_NET but not CONFIG_INET is rather unlikely in practice: most use cases are going to need IP networking. The tcp_gro_complete function just sets some data in the socket buffer for use in processing the TCP packet in the event that the GRO was offloaded to the device. If the kernel lacks TCP support, such setup will simply go unused. The bnx2x, bnxt, and qede drivers wrap their TCP offload support in CONFIG_INET checks and skip handling on such kernels. The idpf driver did not check CONFIG_INET and thus fails to link if the kernel is configured with CONFIG_NET=y, CONFIG_IDPF=(m|y), and CONFIG_INET=n. While checking CONFIG_INET does allow the driver to bypass significantly more instructions in the event that we know TCP networking isn't supported, the configuration is unlikely to be used widely. Rather than require driver authors to care about this, stub the tcp_gro_complete function when CONFIG_INET=n. This allows drivers to be left as-is. It does mean the idpf driver will perform slightly more work than strictly necessary when CONFIG_INET=n, since it will still execute some of the skb setup in idpf_rx_rsc. However, that work would be performed in the case where CONFIG_INET=y anyways. I did not change the existing drivers, since they appear to wrap a significant portion of code when CONFIG_INET=n. There is little benefit in trashing these drivers just to unwrap and remove the CONFIG_INET check. Using a stub for tcp_gro_complete is still beneficial, as it means future drivers no longer need to worry about this case of CONFIG_NET=y and CONFIG_INET=n, which should reduce noise from buildbots that check such a configuration. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Link: https://lore.kernel.org/r/20231013185502.1473541-1-jacob.e.keller@intel.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
- 16 Oct, 2023 20 commits
-
-
Muhammad Muzammil authored
resolved typing mistake from devce to device Signed-off-by: Muhammad Muzammil <m.muzzammilashraf@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20231013042304.7881-1-m.muzzammilashraf@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Liansen Zhai authored
When modifying netclassid, the command("echo 0x100001 > net_cls.classid") will take more time on many threads of one process, because the process create many fds. for example, one process exists 28000 fds and 60000 threads, echo command will task 45 seconds. Now, we only consider the main process when exec "iterate_fd", and the time is about 52 milliseconds. Signed-off-by: Liansen Zhai <zhailiansen@kuaishou.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20231012090330.29636-1-zhailiansen@kuaishou.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. Other implementations of .*get_drvinfo use strscpy so this patch brings sr_get_drvinfo() in line as well: igb/igb_ethtool.c +851 static void igb_get_drvinfo(struct net_device *netdev, igbvf/ethtool.c 167:static void igbvf_get_drvinfo(struct net_device *netdev, i40e/i40e_ethtool.c 1999:static void i40e_get_drvinfo(struct net_device *netdev, e1000/e1000_ethtool.c 529:static void e1000_get_drvinfo(struct net_device *netdev, ixgbevf/ethtool.c 211:static void ixgbevf_get_drvinfo(struct net_device *netdev, ... Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20231012-strncpy-drivers-net-usb-sr9800-c-v1-1-5540832c8ec2@google.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. Other implementations of .*get_drvinfo use strscpy so this patch brings lan78xx_get_drvinfo() in line as well: igb/igb_ethtool.c +851 static void igb_get_drvinfo(struct net_device *netdev, igbvf/ethtool.c 167:static void igbvf_get_drvinfo(struct net_device *netdev, i40e/i40e_ethtool.c 1999:static void i40e_get_drvinfo(struct net_device *netdev, e1000/e1000_ethtool.c 529:static void e1000_get_drvinfo(struct net_device *netdev, ixgbevf/ethtool.c 211:static void ixgbevf_get_drvinfo(struct net_device *netdev, Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20231012-strncpy-drivers-net-usb-lan78xx-c-v1-1-99d513061dfc@google.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. ethtool_sprintf() is designed specifically for get_strings() usage. Let's replace strncpy in favor of this dedicated helper function. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/r/20231012-strncpy-drivers-net-phy-smsc-c-v1-1-00528f7524b3@google.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. Considering the above, a suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. Other implementations of .*get_drvinfo also use strscpy so this patch brings keystone_get_drvinfo() in line as well: igb/igb_ethtool.c +851 static void igb_get_drvinfo(struct net_device *netdev, igbvf/ethtool.c 167:static void igbvf_get_drvinfo(struct net_device *netdev, i40e/i40e_ethtool.c 1999:static void i40e_get_drvinfo(struct net_device *netdev, e1000/e1000_ethtool.c 529:static void e1000_get_drvinfo(struct net_device *netdev, ixgbevf/ethtool.c 211:static void ixgbevf_get_drvinfo(struct net_device *netdev, Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20231012-strncpy-drivers-net-ethernet-ti-netcp_ethss-c-v1-1-93142e620864@google.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Haiyang Zhang authored
TCP pingpong threshold is 1 by default. But some applications, like SQL DB may prefer a higher pingpong threshold to activate delayed acks in quick ack mode for better performance. The pingpong threshold and related code were changed to 3 in the year 2019 in: commit 4a41f453 ("tcp: change pingpong threshold to 3") And reverted to 1 in the year 2022 in: commit 4d8f24ee ("Revert "tcp: change pingpong threshold to 3"") There is no single value that fits all applications. Add net.ipv4.tcp_pingpong_thresh sysctl tunable, so it can be tuned for optimal performance based on the application needs. Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://lore.kernel.org/r/1697056244-21888-1-git-send-email-haiyangz@microsoft.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Daniel Borkmann authored
Add an initial user for the newly added tcf_set_drop_reason() helper to set the drop reason for internal errors leading to TC_ACT_SHOT inside {__,}tcf_classify(). Right now this only adds a very basic SKB_DROP_REASON_TC_ERROR as a generic fallback indicator to mark drop locations. Where needed, such locations can be converted to more specific codes, for example, when hitting the reclassification limit, etc. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Victor Nogueira <victor@mojatatu.com> Link: https://lore.kernel.org/r/20231009092655.22025-2-daniel@iogearbox.netSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Daniel Borkmann authored
Currently, the kfree_skb_reason() in sch_handle_{ingress,egress}() can only express a basic SKB_DROP_REASON_TC_INGRESS or SKB_DROP_REASON_TC_EGRESS reason. Victor kicked-off an initial proposal to make this more flexible by disambiguating verdict from return code by moving the verdict into struct tcf_result and letting tcf_classify() return a negative error. If hit, then two new drop reasons were added in the proposal, that is SKB_DROP_REASON_TC_INGRESS_ERROR as well as SKB_DROP_REASON_TC_EGRESS_ERROR. Further analysis of the actual error codes would have required to attach to tcf_classify via kprobe/kretprobe to more deeply debug skb and the returned error. In order to make the kfree_skb_reason() in sch_handle_{ingress,egress}() more extensible, it can be addressed in a more straight forward way, that is: Instead of placing the verdict into struct tcf_result, we can just put the drop reason in there, which does not require changes throughout various classful schedulers given the existing verdict logic can stay as is. Then, SKB_DROP_REASON_TC_ERROR{,_*} can be added to the enum skb_drop_reason to disambiguate between an error or an intentional drop. New drop reason error codes can be added successively to the tc code base. For internal error locations which have not yet been annotated with a SKB_DROP_REASON_TC_ERROR{,_*}, the fallback is SKB_DROP_REASON_TC_INGRESS and SKB_DROP_REASON_TC_EGRESS, respectively. Generic errors could be marked with a SKB_DROP_REASON_TC_ERROR code until they are converted to more specific ones if it is found that they would be useful for troubleshooting. While drop reasons have infrastructure for subsystem specific error codes which are currently used by mac80211 and ovs, Jakub mentioned that it is preferred for tc to use the enum skb_drop_reason core codes given it is a better fit and currently the tooling support is better, too. With regards to the latter: [...] I think Alastair (bpftrace) is working on auto-prettifying enums when bpftrace outputs maps. So we can do something like: $ bpftrace -e 'tracepoint:skb:kfree_skb { @[args->reason] = count(); }' Attaching 1 probe... ^C @[SKB_DROP_REASON_TC_INGRESS]: 2 @[SKB_CONSUMED]: 34 ^^^^^^^^^^^^ names!! Auto-magically. [...] Add a small helper tcf_set_drop_reason() which can be used to set the drop reason into the tcf_result. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Victor Nogueira <victor@mojatatu.com> Link: https://lore.kernel.org/netdev/20231006063233.74345d36@kernel.orgReviewed-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/r/20231009092655.22025-1-daniel@iogearbox.netSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Gerhard Engleder authored
The tsnep network controller is able to extend the descriptor directly with data to be transmitted. In this case no TX data DMA address is necessary. Instead of the TX data DMA address the TX data buffer is placed at the end of the descriptor. The descriptor is read with a 64 bytes DMA read by the tsnep network controller. If the sum of descriptor data and TX data is less than or equal to 64 bytes, then no additional DMA read is necessary to read the TX data. Therefore, it makes sense to inline small fragments up to this limit within the descriptor ring. Inlined fragments need to be copied to the descriptor ring. On the other hand DMA mapping is not necessary. At most 40 bytes are copied, so copying should be faster than DMA mapping. For A53 1.2 GHz copying takes <100ns and DMA mapping takes >200ns. So inlining small fragments should result in lower CPU load. Performance improvement is small. Thus, comparision of CPU load with and without inlining of small fragments did not show any significant difference. With this optimization less DMA reads will be done, which decreases the load of the interconnect. Signed-off-by: Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Beniamino Galvani says: ==================== net: consolidate IPv4 route lookup for UDP tunnels At the moment different UDP tunnels rely on different functions for IPv4 route lookup, and those functions all implement the same logic. Only bareudp uses the generic ip_route_output_tunnel(), while geneve and vxlan basically duplicate it slightly differently. This series first extends the generic lookup function so that it is suitable for all UDP tunnel implementations. Then, bareudp, geneve and vxlan are adapted to use them. This results in code with less duplication and hopefully better maintainability. After this series is merged, IPv6 will be converted in a similar way. Changelog: v2 - fix compilation with IPv6 disabled ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Beniamino Galvani authored
The route lookup can be done now via generic function udp_tunnel_dst_lookup() to replace the custom implementations in vxlan_get_route(). Note that this patch only touches IPv4, while IPv6 still uses vxlan6_get_route(). After IPv6 route lookup gets converted as well, vxlan_xmit_one() can be simplified by removing local variables that will be passed via "struct ip_tunnel_key", such as remote_ip, local_ip, flow_flags, label. Suggested-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Beniamino Galvani authored
The route lookup can be done now via generic function udp_tunnel_dst_lookup() to replace the custom implementation in geneve_get_v4_rt(). Suggested-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Beniamino Galvani authored
Add a helper function to compute the tos/dsfield. In this way, we can factor out some duplicate code. Also, the helper will be called from more places in the next commit. Suggested-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Beniamino Galvani authored
Commit 451ef36b ("ip_tunnels: Add new flow flags field to ip_tunnel_key") added a new field to struct ip_tunnel_key to control route lookups. Currently the flag is used by vxlan and geneve tunnels; use it also in udp_tunnel_dst_lookup() so that it affects all tunnel types relying on this function. Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Beniamino Galvani authored
We want to make the function more generic so that it can be used by other UDP tunnel implementations such as geneve and vxlan. To do that, add the following arguments: - source and destination UDP port; - ifindex of the output interface, needed by vxlan; - the tos, because in some cases it is not taken from struct ip_tunnel_info (for example, when it's inherited from the inner packet); - the dst cache, because not all tunnel types (e.g. vxlan) want to use the one from struct ip_tunnel_info. With these parameters, the function no longer needs the full struct ip_tunnel_info as argument and we can pass only the relevant part of it (struct ip_tunnel_key). Suggested-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Beniamino Galvani authored
The function is now UDP-specific, the protocol is always IPPROTO_UDP. Suggested-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Beniamino Galvani authored
At the moment ip_route_output_tunnel() is used only by bareudp. Ideally, other UDP tunnel implementations should use it, but to do so the function needs to accept new parameters that are specific for UDP tunnels, such as the ports. Prepare for these changes by renaming the function to udp_tunnel_dst_lookup() and move it to file net/ipv4/udp_tunnel_core.c. Suggested-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: Beniamino Galvani <b.galvani@gmail.com> Reviewed-by: David Ahern <dsahern@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
zhujun2 authored
These variables are never referenced in the code, just remove them Signed-off-by: zhujun2 <zhujun2@cmss.chinamobile.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Christian Marangi authored
Simplify logic for rspq_check_napi. Drop redundant and wrong napi_is_scheduled call as it's not race free and directly use the output of napi_schedule to understand if a napi is pending or not. rspq_check_napi main logic is to check if is_new_response is true and check if a napi is not scheduled. The result of this function is then used to detect if we are missing some interrupt and act on top of this... With this knowing, we can rework and simplify the logic and make it less problematic with testing an internal bit for napi. Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 15 Oct, 2023 18 commits
-
-
David S. Miller authored
Xabier Marquiegui says: ==================== ptp: Support for multiple filtered timestamp event queue readers On systems with multiple timestamp event channels, there can be scenarios where multiple userspace readers want to access the timestamping data for various purposes. One such example is wanting to use a pps out for time synchronization, and wanting to timestamp external events with the synchronized time base simultaneously. Timestmp event consumers on the other hand, are often interested in a subset of the available timestamp channels. linuxptp ts2phc, for example, is not happy if more than one timestamping channel is active on the device it is reading from. Linked lists are introduced to support multiple timestamp event queue consumers, and timestamp event channel filters through IOCTLs, as well as a debugfs interface to do some simple verifications. Xabier Marquiegui (6): posix-clock: introduce posix_clock_context concept ptp: Replace timestamp event queue with linked list ptp: support multiple timestamp event readers ptp: support event queue reader channel masks ptp: add debugfs interface to see applied channel masks ptp: add testptp mask test drivers/ptp/ptp_chardev.c | 129 ++++++++++++++++---- drivers/ptp/ptp_clock.c | 45 ++++++- drivers/ptp/ptp_private.h | 28 +++-- drivers/ptp/ptp_sysfs.c | 13 +- include/linux/posix-clock.h | 35 ++++-- include/uapi/linux/ptp_clock.h | 2 + kernel/time/posix-clock.c | 36 ++++-- tools/testing/selftests/ptp/ptpchmaskfmt.sh | 14 +++ tools/testing/selftests/ptp/testptp.c | 19 ++- 9 files changed, 261 insertions(+), 60 deletions(-) create mode 100644 tools/testing/selftests/ptp/ptpchmaskfmt.sh --- v6: - correct commit message - correct coding style v5: https://lore.kernel.org/netdev/cover.1696804243.git.reibax@gmail.com/ - fix spelling on commit message - fix memory leak on ptp_open v4: https://lore.kernel.org/netdev/cover.1696511486.git.reibax@gmail.com/ - split modifications in different patches for improved organization - rename posix_clock_user to posix_clock_context - remove unnecessary flush_users clock operation - remove unnecessary tests - simpler queue clean procedure - fix/clean comment lines - simplified release procedures - filter modifications exclusive to currently open instance for simplicity and security - expand mask to 2048 channels - make more secure and simple: mask is only applied to the testptp instance. Use debugfs to verify effects. v3: https://lore.kernel.org/netdev/20230928133544.3642650-1-reibax@gmail.com/ - add this patchset overview file - fix use of safe and non safe linked lists for loops - introduce new posix_clock private_data and ida object ids for better dicrimination of timestamp consumers - safer resource release procedures - filter application by object id, aided by process id - friendlier testptp implementation of event queue channel filters v2: https://lore.kernel.org/netdev/20230912220217.2008895-1-reibax@gmail.com/ - fix ptp_poll() return value - Style changes to comform to checkpatch strict suggestions - more coherent ptp_read error exit routines - fix testptp compilation error: unknown type name 'pid_t' - rename mask variable for easier code traceability - more detailed commit message with two examples v1: https://lore.kernel.org/netdev/20230906104754.1324412-2-reibax@gmail.com/ ==================== Signed-off-by: Xabier Marquiegui <reibax@gmail.com> Suggested-by: Richard Cochran <richardcochran@gmail.com> Suggested-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xabier Marquiegui authored
Add option to test timestamp event queue mask manipulation in testptp. Option -F allows the user to specify a single channel that will be applied on the mask filter via IOCTL. The test program will maintain the file open until user input is received. This allows checking the effect of the IOCTL in debugfs. eg: Console 1: ``` Channel 12 exclusively enabled. Check on debugfs. Press any key to continue ``` Console 2: ``` 0x00000000 0x00000001 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000 ``` Signed-off-by: Xabier Marquiegui <reibax@gmail.com> Suggested-by: Richard Cochran <richardcochran@gmail.com> Suggested-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xabier Marquiegui authored
Use debugfs to be able to view channel mask applied to every timestamp event queue. Every time the device is opened, a new entry is created in `$DEBUGFS_MOUNTPOINT/ptpN/$INSTANCE_ADDRESS/mask`. The mask value can be viewed grouped in 32bit decimal values using cat, or converted to hexadecimal with the included `ptpchmaskfmt.sh` script. 32 bit values are listed from least significant to most significant. Signed-off-by: Xabier Marquiegui <reibax@gmail.com> Suggested-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xabier Marquiegui authored
On systems with multiple timestamp event channels, some readers might want to receive only a subset of those channels. Add the necessary modifications to support timestamp event channel filtering, including two IOCTL operations: - Clear all channels - Enable one channel The mask modification operations will be applied exclusively on the event queue assigned to the file descriptor used on the IOCTL operation, so the typical procedure to have a reader receiving only a subset of the enabled channels would be: - Open device file - ioctl: clear all channels - ioctl: enable one channel - start reading Calling the enable one channel ioctl more than once will result in multiple enabled channels. Signed-off-by: Xabier Marquiegui <reibax@gmail.com> Suggested-by: Richard Cochran <richardcochran@gmail.com> Suggested-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xabier Marquiegui authored
Use linked lists to create one event queue per open file. This enables simultaneous readers for timestamp event queues. Signed-off-by: Xabier Marquiegui <reibax@gmail.com> Suggested-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xabier Marquiegui authored
Introduce linked lists to access the timestamp event queue. Signed-off-by: Xabier Marquiegui <reibax@gmail.com> Suggested-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Xabier Marquiegui authored
Add the necessary structure to support custom private-data per posix-clock user. The previous implementation of posix-clock assumed all file open instances need access to the same clock structure on private_data. The need for individual data structures per file open instance has been identified when developing support for multiple timestamp event queue users for ptp_clock. Signed-off-by: Xabier Marquiegui <reibax@gmail.com> Suggested-by: Richard Cochran <richardcochran@gmail.com> Suggested-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Arkadiusz Kubalewski says: ==================== dpll: add phase-offset and phase-adjust Improve monitoring and control over dpll devices. Allow user to receive measurement of phase difference between signals on pin and dpll (phase-offset). Allow user to receive and control adjustable value of pin's signal phase (phase-adjust). v4->v5: - rebase series on top of net-next/main, fix conflict - remove redundant attribute type definition in subset definition v3->v4: - do not increase do version of uAPI header as it is not needed (v3 did not have this change) - fix spelling around commit messages, argument descriptions and docs - add missing extack errors on failure set callbacks for pin phase adjust and frequency - remove ice check if value is already set, now redundant as checked in the dpll subsystem v2->v3: - do not increase do version of uAPI header as it is not needed v1->v2: - improve handling for error case of requesting the phase adjust set - align handling for error case of frequency set request with the approach introduced for phase adjust ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arkadiusz Kubalewski authored
Align the approach of pin frequency set behavior with the approach introduced with pin phase adjust set. Fail the request if any of devices did not registered the callback ops. If callback op on any pin's registered device fails, return error and rollback the value to previous one. Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arkadiusz Kubalewski authored
Implement new callback ops related to measurement and adjustment of signal phase for pin-dpll in ice driver. Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arkadiusz Kubalewski authored
Add callback ops for pin-dpll phase measurement. Add callback for pin signal phase adjustment. Add min and max phase adjustment values to pin proprties. Invoke callbacks in dpll_netlink.c when filling the pin details to provide user with phase related attribute values. Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arkadiusz Kubalewski authored
Add attributes for providing the user with: - measurement of signals phase offset between pin and dpll - ability to adjust the phase of pin signal Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arkadiusz Kubalewski authored
Add documentation on: - measurement of phase of signal between pin and dpll - adjustment of pin signal phase Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ivan Vecera says: ==================== i40e: Add basic devlink support The series adds initial support for devlink to i40e driver. Patch-set overview: Patch 1: Adds initial devlink support (devlink and port registration) Patch 2: Refactors and split i40e_nvm_version_str() Patch 3: Adds support for 'devlink dev info' Patch 4: Refactors existing helper function to read PBA ID Patch 5: Adds 'board.id' to 'devlink dev info' using PBA ID ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ivan Vecera authored
Expose stored PBA ID string as unique board identifier via devlink's .info_get command. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ivan Vecera authored
Function i40e_read_pba_string() is currently unused but will be used by subsequent patch to provide board ID via devlink device info. The function reads PBA block from NVM so it cannot be called during adapter reset and as we would like to provide PBA ID via devlink info it is better to read the PBA ID during i40e_probe() and cache it in i40e_hw structure to avoid a waiting for potential adapter reset in devlink info callback. So... - Remove pba_num and pba_num_size arguments from the function, allocate resource managed buffer to store PBA ID string and save resulting pointer to i40e_hw->pba_id field - Make the function void as the PBA ID can be missing and in this case (or in case of NVM reading failure) the i40e_hw->pba_id will be NULL - Rename the function to i40e_get_pba_string() to align with other functions like i40e_get_oem_version() i40e_get_port_mac_addr()... - Call this function on init during i40e_probe() Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ivan Vecera authored
Provide devlink .info_get callback to allow the driver to report detailed version information. The following info is reported: "serial_number" -> The PCI DSN of the adapter "fw.mgmt" -> The version of the firmware "fw.mgmt.api" -> The API version of interface exposed over the AdminQ "fw.psid" -> The version of the NVM image "fw.bundle_id" -> Unique identifier for the combined flash image "fw.undi" -> The combo image version With this, 'devlink dev info' provides at least the same amount information as is reported by ETHTOOL_GDRVINFO: $ ethtool -i enp2s0f0 | egrep '(driver|firmware)' driver: i40e firmware-version: 9.30 0x8000e5f3 1.3429.0 $ devlink dev info pci/0000:02:00.0 pci/0000:02:00.0: driver i40e serial_number c0-de-b7-ff-ff-ef-ec-3c versions: running: fw.mgmt 9.130.73618 fw.mgmt.api 1.15 fw.psid 9.30 fw.bundle_id 0x8000e5f3 fw.undi 1.3429.0 Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ivan Vecera authored
The function formats NVM version string according adapter's EETrackID value. If this value OEM specific (0xffffffff) then the reported version is with format: "<gen>.<snap>.<release>" and in other case "<nvm_maj>.<nvm_min> <eetrackid> <cvid_maj>.<cvid_bld>.<cvid_min>" These versions are reported in the subsequent patch in this series that implements devlink .info_get but separately. So split the function into separate ones, refactor it to use them and remove ugly static string buffer. Additionally convert NVM/OEM version mask macros to use GENMASK and use FIELD_GET/FIELD_PREP for them in i40e_nvm_version_str() and i40e_get_oem_version(). This makes code more readable and allows us to remove related shift macros. Signed-off-by: Ivan Vecera <ivecera@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-