- 15 Oct, 2023 26 commits
-
-
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:
-
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: -
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:
-
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 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 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 authored
Add an initial support for devlink interface to i40e driver. Similarly to ice driver the implementation doe not enable devlink to manage device-wide configuration and devlink instance is created for each physical function of PCIe device. Signed-off-by:
-
Pavan Chebbi authored
When we are trying to timestamp a TX packet, there may be occasions when the TX timestamp register is still not updated with the latest timestamp even if the timestamp packet descriptor is marked as complete. This usually happens in cases where the system is under stress or flow control is affecting the transmit side. We will solve this problem by saving the snapshot of the timestamp register when we are posting the TX descriptor. At this time, the register contains previously timestamped packet's value and valid timestamp of the current packet must be different than this. Upon completion of the current descriptor, we will check if the timestamp register is updated or not before timestamping the skb. If not updated, we will schedule the ptp worker to fetch the updated time later and timestamp the skb. Also now we restrict number of outstanding PTP TX packet requests to 1. Reported-by:
Simon White <Simon.White@viavisolutions.com> Link: https://lore.kernel.org/netdev/CACKFLikGdN9XPtWk-fdrzxdcD=+bv-GHBvfVfSpJzHY7hrW39g@mail.gmail.com/Signed-off-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Reviewed-by:
Andy Gospodarek <gospo@broadcom.com> Reviewed-by:
Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by:
-
Jakub Kicinski authored
Add a section to netdev maintainer doc encouraging reviewers to chime in on the mailing list. The questions about "when is it okay to share feedback" keep coming up (most recently at netconf) and the answer is "pretty much always". Extend the section of 7.AdvancedTopics.rst which deals with reviews a little bit to add stuff we had been recommending locally. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by:
Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by:
-
David S. Miller authored
Edward Cree says: ==================== sfc: support conntrack NAT offload The EF100 MAE supports performing NAT (and NPT) on packets which match in the conntrack table. This series adds that capability to the driver. ==================== Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
-
Edward Cree authored
If an IP address and/or L4 port for NAPT is available from a CT match, the MAE will perform the edits; if no CT lookup has been performed for this packet, the CT lookup did not return a match, or the matched CT entry did not include NAPT, the action will have no effect. Reviewed-by:
Pieter Jansen van Vuuren <pieter.jansen-van-vuuren@amd.com> Signed-off-by:
Edward Cree <ecree.xilinx@gmail.com> Signed-off-by:
-
Edward Cree authored
The MAE can edit either address, L4 port, or both, for either source or destination. These can't be mixed; i.e. it can edit source addr and source port, but not (say) source addr and dest port. Reviewed-by:
-
David S. Miller authored
Arseniy Krasnov says: ==================== vsock/virtio/vhost: MSG_ZEROCOPY preparations this patchset is first of three parts of another big patchset for MSG_ZEROCOPY flag support: https://lore.kernel.org/netdev/20230701063947.3422088-1-AVKrasnov@sberdevices.ru/ During review of this series, Stefano Garzarella <sgarzare@redhat.com> suggested to split it for three parts to simplify review and merging: 1) virtio and vhost updates (for fragged skbs) <--- this patchset 2) AF_VSOCK updates (allows to enable MSG_ZEROCOPY mode and read tx completions) and update for Documentation/. 3) Updates for tests and utils. This series enables handling of fragged skbs in virtio and vhost parts. Newly logic won't be triggered, because SO_ZEROCOPY options is still impossible to enable at this moment (next bunch of patches from big set above will enable it). I've included changelog to some patches anyway, because there were some comments during review of last big patchset from the link above. Head for this patchset is: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=f2fa1c812c91e99d0317d1fc7d845e1e05f39716 Link to v1: https://lore.kernel.org/netdev/20230717210051.856388-1-AVKrasnov@sberdevices.ru/ Link to v2: https://lore.kernel.org/netdev/20230718180237.3248179-1-AVKrasnov@sberdevices.ru/ Link to v3: https://lore.kernel.org/netdev/20230720214245.457298-1-AVKrasnov@sberdevices.ru/ Link to v4: https://lore.kernel.org/netdev/20230727222627.1895355-1-AVKrasnov@sberdevices.ru/ Link to v5: https://lore.kernel.org/netdev/20230730085905.3420811-1-AVKrasnov@sberdevices.ru/ Link to v6: https://lore.kernel.org/netdev/20230814212720.3679058-1-AVKrasnov@sberdevices.ru/ Link to v7: https://lore.kernel.org/netdev/20230827085436.941183-1-avkrasnov@salutedevices.com/ Link to v8: https://lore.kernel.org/netdev/20230911202234.1932024-1-avkrasnov@salutedevices.com/ Changelog: v3 -> v4: * Patchset rebased and tested on new HEAD of net-next (see hash above). v4 -> v5: * See per-patch changelog after ---. v5 -> v6: * Patchset rebased and tested on new HEAD of net-next (see hash above). * See per-patch changelog after ---. v6 -> v7: * Patchset rebased and tested on new HEAD of net-next (see hash above). * See per-patch changelog after ---. v7 -> v8: * Patchset rebased and tested on new HEAD of net-next (see hash above). * See per-patch changelog after ---. v8 -> v9: * Patchset rebased and tested on new HEAD of net-next (see hash above). * See per-patch changelog after ---. ==================== Signed-off-by:
-
Arseniy Krasnov authored
This adds set of tests which use io_uring for rx/tx. This test suite is implemented as separated util like 'vsock_test' and has the same set of input arguments as 'vsock_test'. These tests only cover cases of data transmission (no connect/bind/accept etc). Signed-off-by:
Arseniy Krasnov <avkrasnov@salutedevices.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
Arseniy Krasnov authored
To use this option pass '--zerocopy' parameter: ./vsock_perf --zerocopy --sender <cid> ... With this option MSG_ZEROCOPY flag will be passed to the 'send()' call. Signed-off-by:
-
Arseniy Krasnov authored
This adds three tests for MSG_ZEROCOPY feature: 1) SOCK_STREAM tx with different buffers. 2) SOCK_SEQPACKET tx with different buffers. 3) SOCK_STREAM test to read empty error queue of the socket. Patch also works as preparation for the next patches for tools in this patchset: vsock_perf and vsock_uring_test: 1) Adds several new functions to util.c - they will be also used by vsock_uring_test. 2) Adds two new functions for MSG_ZEROCOPY handling to a new source file - such source will be shared between vsock_test, vsock_perf and vsock_uring_test, thus avoiding code copy-pasting. Signed-off-by:
-
Arseniy Krasnov authored
This adds description of MSG_ZEROCOPY flag support for AF_VSOCK type of socket. Signed-off-by:
-
Arseniy Krasnov authored
For AF_VSOCK, zerocopy tx mode depends on transport, so this option must be set in AF_VSOCK implementation where transport is accessible (if transport is not set during setting SO_ZEROCOPY: for example socket is not connected, then SO_ZEROCOPY will be enabled, but once transport will be assigned, support of this type of transmission will be checked). To handle SO_ZEROCOPY, AF_VSOCK implementation uses SOCK_CUSTOM_SOCKOPT bit, thus handling SOL_SOCKET option operations, but all of them except SO_ZEROCOPY will be forwarded to the generic handler by calling 'sock_setsockopt()'. Signed-off-by:
-
Arseniy Krasnov authored
Add 'msgzerocopy_allow()' callback for loopback transport. Signed-off-by:
-
Arseniy Krasnov authored
Add 'msgzerocopy_allow()' callback for virtio transport. Signed-off-by:
-
Arseniy Krasnov authored
Add 'msgzerocopy_allow()' callback for vhost transport. Signed-off-by:
-
Arseniy Krasnov authored
This bit is used by io_uring in case of zerocopy tx mode. io_uring code checks, that socket has this feature. This patch sets it in two places: 1) For socket in 'connect()' call. 2) For new socket which is returned by 'accept()' call. Signed-off-by:
-
Arseniy Krasnov authored
This feature totally depends on transport, so if transport doesn't support it, return error. Signed-off-by:
-
Arseniy Krasnov authored
This adds handling of MSG_ERRQUEUE input flag in receive call. This flag is used to read socket's error queue instead of data queue. Possible scenario of error queue usage is receiving completions for transmission with MSG_ZEROCOPY flag. This patch also adds new defines: 'SOL_VSOCK' and 'VSOCK_RECVERR'. Signed-off-by:
-
Arseniy Krasnov authored
If socket's error queue is not empty, EPOLLERR must be set. Otherwise, reader of error queue won't detect data in it using EPOLLERR bit. Currently for AF_VSOCK this is actual only with MSG_ZEROCOPY, as this feature is the only user of an error queue of the socket. Signed-off-by:
-
- 14 Oct, 2023 14 commits
-
-
Lukas Bulwahn authored
After commit 1dab4713 ("appletalk: remove ipddp driver") removes the config IPDDP, there is some minor code clean-up possible in the appletalk network layer. Remove some code in appletalk layer after the ipddp driver is gone. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
-
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. This patch eliminates three uses of strncpy(): Firstly, `dest` is expected to be NUL-terminated which is evident by the manual setting of a NUL-byte at size - 1. For this use specifically, strscpy() is a viable replacement due to the fact that it guarantees NUL-termination on the destination buffer. The next two cases should simply be memcpy() as the size of the src string is always 3 and the destination string just wants the first 3 bytes changed. To be clear, there are no buffer overread bugs in the current code as the sizes and offsets are carefully managed such that buffers are NUL-terminated. However, with these changes, the code is now more robust and less ambiguous (and hopefully easier to read). 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:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20231012-strncpy-drivers-net-ethernet-qlogic-qed-qed_debug-c-v2-1-16d2c0162b80@google.comSigned-off-by:
-
Heiner Kallweit authored
In very rare cases (I've seen two reports so far about different RTL8125 chip versions) it seems the MAC locks up when link goes down and requires a software reset to get revived. Realtek doesn't publish hw errata information, therefore the root cause is unknown. Realtek vendor drivers do a full hw re-initialization on each link-up event, the slimmed-down variant here was reported to fix the issue for the reporting user. It's not fully clear which parts of the NIC are reset as part of the software reset, therefore I can't rule out side effects. Fixes: f1bce4ad ("r8169: add support for RTL8125") Reported-by:
Martin Kjær Jørgensen <me@lagy.org> Link: https://lore.kernel.org/netdev/97ec2232-3257-316c-c3e7-a08192ce16a6@gmail.com/T/Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/9edde757-9c3b-4730-be3b-0ef3a374ff71@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Breno Leitao says: ==================== net: netconsole: configfs entries for boot target There is a limitation in netconsole, where it is impossible to disable or modify the target created from the command line parameter. (netconsole=...). "netconsole" cmdline parameter sets the remote IP, and if the remote IP changes, the machine needs to be rebooted (with the new remote IP set in the command line parameter). This allows the user to modify a target without the need to restart the machine. This functionality sits on top of the dynamic target reconfiguration that is already implemented in netconsole. The way to modify a boot time target is creating special named configfs directories, that will be associated with the targets coming from `netconsole=...`. Example: Let's suppose you have two netconsole targets defined at boot time:: netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc;4444@10.0.0.1/eth1,9353@10.0.0.3/12:34:56:78:9a:bc You can modify these targets in runtime by creating the following targets:: $ mkdir cmdline1 $ cat cmdline1/remote_ip 10.0.0.3 $ echo 0 > cmdline1/enabled $ echo 10.0.0.4 > cmdline1/remote_ip $ echo 1 > cmdline1/enabled ==================== Link: https://lore.kernel.org/r/20231012111401.333798-1-leitao@debian.orgSigned-off-by:
-
Breno Leitao authored
With the previous patches, there is no more limitation at modifying the targets created at boot time (or module load time). Document the way on how to create the configfs directories to be able to modify these netconsole targets. The design discussion about this topic could be found at: https://lore.kernel.org/all/ZRWRal5bW93px4km@gmail.com/Signed-off-by:
Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/r/20231012111401.333798-5-leitao@debian.orgSigned-off-by:
-
Breno Leitao authored
Enable the attachment of a dynamic target to the target created during boot time. The boot-time targets are named as "cmdline\d", where "\d" is a number starting at 0. If the user creates a dynamic target named "cmdline0", it will attach to the first target created at boot time (as defined in the `netconsole=...` command line argument). `cmdline1` will attach to the second target and so forth. If there is no netconsole target created at boot time, then, the target name could be reused. Relevant design discussion: https://lore.kernel.org/all/ZRWRal5bW93px4km@gmail.com/Suggested-by:
Joel Becker <jlbec@evilplan.org> Signed-off-by:
-
Breno Leitao authored
For netconsole targets allocated during the boot time (passing netconsole=... argument), netconsole_target->item is not initialized. That is not a problem because it is not used inside configfs. An upcoming patch will be using it, thus, initialize the targets with the name 'cmdline' plus a counter starting from 0. This name will match entries in the configfs later. Suggested-by:
-
Breno Leitao authored
Move alloc_param_target() and its counterpart (free_param_target()) to the bottom of the file. These functions are called mostly at initialization/cleanup of the module, and they should be just above the callers, at the bottom of the file. From a practical perspective, having alloc_param_target() at the bottom of the file will avoid forward declaration later (in the following patch). Nothing changed other than the functions location. Suggested-by:
-
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. `desc` is expected to be NUL-terminated as evident by the manual NUL-byte assignment. Moreover, NUL-padding does not seem to be necessary. The only caller of efx_mcdi_nvram_metadata() is efx_devlink_info_nvram_partition() which provides a NULL for `desc`: | rc = efx_mcdi_nvram_metadata(efx, partition_type, NULL, version, NULL, 0); Due to this, I am not sure this code is even reached but we should still favor something other than strncpy. 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. 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 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 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. NUL-padding is not needed due to `ident` being memset'd to 0 just before the copy. 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. 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:
Shannon Nelson <shannon.nelson@amd.com> Reviewed-by:
-
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 more robust and easier to understand interface. 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 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. We expect `dst` to be NUL-terminated based on its use with format strings: | mlx4_dbg(dev, "Reporting Driver Version to FW: %s\n", dst); Moreover, NUL-padding is not required. 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. 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:
Saeed Mahameed <saeedm@nvidia.com> Link: https://lore.kernel.org/r/20231011-strncpy-drivers-net-ethernet-mellanox-mlx4-fw-c-v1-1-4d7b5d34c933@google.comSigned-off-by:
-
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. We expect res->name to be NUL-terminated based on its usage with format strings: | dev_err(cpp->dev.parent, "Dangling area: %d:%d:%d:0x%0llx-0x%0llx%s%s\n", | NFP_CPP_ID_TARGET_of(res->cpp_id), | NFP_CPP_ID_ACTION_of(res->cpp_id), | NFP_CPP_ID_TOKEN_of(res->cpp_id), | res->start, res->end, | res->name ? " " : "", | res->name ? res->name : ""); ... and with strcmp() | if (!strcmp(res->name, NFP_RESOURCE_TBL_NAME)) { Moreover, NUL-padding is not required as `res` is already zero-allocated: | res = kzalloc(sizeof(*res), GFP_KERNEL); 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. Let's also opt to use the more idiomatic strscpy() usage of (dest, src, sizeof(dest)) rather than (dest, src, SOME_LEN). Typically the pattern of 1) allocate memory for string, 2) copy string into freshly-allocated memory is a candidate for kmemdup_nul() but in this case we are allocating the entirety of the `res` struct and that should stay as is. As mentioned above, simple 1:1 replacement of strncpy -> strscpy :) 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:Louis Peens <louis.peens@corigine.com> Link: https://lore.kernel.org/r/20231011-strncpy-drivers-net-ethernet-netronome-nfp-nfpcore-nfp_resource-c-v1-1-7d1c984f0eba@google.comSigned-off-by:
-
