- 23 Oct, 2023 16 commits
-
-
Eric Dumazet authored
Before adding usec TS support, add tcp_rtt_tsopt_us() helper to factorize code. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
This helper returns a TSval from a TCP socket. It currently calls tcp_time_stamp_ms() but will soon be able to return a usec based TSval, depending on an upcoming tp->tcp_usec_ts field. Signed-off-by:
-
Eric Dumazet authored
tcp_ns_to_ts() is only used once from cookie_init_timestamp(). Also add the 'bool usec_ts' parameter to enable usec TS later. Signed-off-by:
-
Eric Dumazet authored
This helper returns a 32bit TCP TSval from skb->tstamp. As we are going to support usec or ms units soon, rename it to tcp_skb_timestamp_ts() and add a boolean to select the unit. Signed-off-by:
-
Eric Dumazet authored
In preparation of usec TCP TS support, remove tcp_time_stamp_raw() in favor of tcp_clock_ts() helper. This helper will return a suitable 32bit result to feed TS values, depending on a socket field. Also add tcp_tw_tsval() and tcp_rsk_tsval() helpers to factorize the details. We do not yet support usec timestamps. Signed-off-by:
-
Eric Dumazet authored
It delivers current TCP time stamp in ms unit, and is used in place of confusing tcp_time_stamp_raw() It is the same family than tcp_clock_ns() and tcp_clock_ms(). tcp_time_stamp_raw() will be replaced later for TSval contexts with a more descriptive name. Signed-off-by:
-
Eric Dumazet authored
In preparation of adding usec TCP TS values, add tcp_time_stamp_ms() for contexts needing ms based values. Signed-off-by:
-
Eric Dumazet authored
cookie_init_timestamp() is supposed to return a 64bit timestamp suitable for both TSval determination and setting of skb->tstamp. Unfortunately it uses 32bit fields and overflows after 2^32 * 10^6 nsec (~49 days) of uptime. Generated TSval are still correct, but skb->tstamp might be set far away in the past, potentially confusing other layers. tcp_ns_to_ts() is changed to return a full 64bit value, ts and ts_now variables are changed to u64 type, and TSMASK is removed in favor of shifts operations. While we are at it, change this sequence: ts >>= TSBITS; ts--; ts <<= TSBITS; ts |= options; to: ts -= (1UL << TSBITS); Fixes: 9a568de4 ("tcp: switch TCP TS option (RFC 7323) to 1ms clock") Signed-off-by:
-
Eric Dumazet authored
tp->rcv_tstamp should be set to tcp_jiffies, not tcp_time_stamp(). Fixes: cc35c88a ("crypto : chtls - CPL handler definition") Signed-off-by:
-
David S. Miller authored
Beniamino Galvani says: ==================== net: consolidate IPv6 route lookup for UDP tunnels At the moment different UDP tunnels rely on different functions for IPv6 route lookup, and those functions all implement the same logic. Extend the generic lookup function so that it is suitable for all UDP tunnel implementations, and then adapt bareudp, geneve and vxlan to use it. This is similar to what already done for IPv4. ==================== Signed-off-by: -
Beniamino Galvani authored
The route lookup can be done now via generic function udp_tunnel6_dst_lookup() to replace the custom implementation in vxlan6_get_route(). This is similar to what already done for IPv4 in commit 6f19b2c1 ("vxlan: use generic function for tunnel IPv4 route lookup"). 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:
-
Beniamino Galvani authored
The route lookup can be done now via generic function udp_tunnel6_dst_lookup() to replace the custom implementation in geneve_get_v6_dst(). This is similar to what already done for IPv4 in commit daa2ba7e ("geneve: use generic function for tunnel IPv4 route lookup"). Suggested-by:
-
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). This is similar to what already done for IPv4 in commit 72fc68c6 ("ipv4: add new arguments to udp_tunnel_dst_lookup()"). Suggested-by:
-
Beniamino Galvani authored
The function is now UDP-specific, the protocol is always IPPROTO_UDP. This is similar to what already done for IPv4 in commit 78f3655a ("ipv4: remove "proto" argument from udp_tunnel_dst_lookup()"). Suggested-by:
-
Beniamino Galvani authored
At the moment ip6_dst_lookup_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_tunnel6_dst_lookup() and move it to file net/ipv6/ip6_udp_tunnel.c. This is similar to what already done for IPv4 in commit bf3fcbf7 ("ipv4: rename and move ip_route_output_tunnel()"). Suggested-by:
-
Gavrilov Ilia authored
Checking the 'adev' variable is unnecessary, because 'cdev' has already been checked earlier. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 656d98b0 ("[ATM]: basic sysfs support for ATM devices") Signed-off-by:
Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru> Signed-off-by:
-
- 22 Oct, 2023 9 commits
-
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Update for net-next The first 2 patches are fixes for the recently added hwmon changes. The next 6 patches are enhancements to support ethtool lanes and all the proper supported and advertised link modes. Before these patches, the driver was only supporting the link modes for copper media. ==================== Signed-off-by: -
Edwin Peer authored
The current driver code does not accurately report the supported and advertised link modes. It basically always assumes the media type is copper for any particular speed. Utilize the recently added link mode mappings to accurately report fully qualified ethtool link modes for advertised and supported speeds. If the media type is known, we will report the supported link modes for that media only. If the media is not known, we will report all possible supported link modes. The user can now specify any supported link modes (including NRZ and PAM4) to advertise for autoneg. It used to only accept copper NRZ modes. Signed-off-by:
Edwin Peer <edwin.peer@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Edwin Peer authored
Barring the BNXT_FW_TO_ETHTOOL speed macros, which will be removed in the next patch, update code to use the newer API. No functional change. Signed-off-by:
-
Michael Chan authored
Refactor some NRZ/PAM4 link speed related logic into helper functions. The NRZ and PAM4 link parameters are stored in separate structure fields. The driver logic has to check whether it is in NRZ or PAM4 mode and then use the appropriate field. Refactor this logic into helper functions for better readability. Reviewed-by:
Damodharam Ammepalli <damodharam.ammepalli@broadcom.com> Reviewed-by:
Ajit Khaparde <ajit.khaparde@broadcom.com> Reviewed-by:
Andy Gospodarek <andrew.gospodarek@broadcom.com> Signed-off-by:
-
Edwin Peer authored
A future patch in this series will change the algorithm used to determine ethtool speed and media modes. Extract the handling of the unrelated pause, autoneg modes into an independent function. Also separate FEC handling out of bnxt_fw_to_ethtool_*_spds(). No functional change. Signed-off-by:
-
Edwin Peer authored
Recent kernels support changing the number of link lanes via ethtool. This is useful for determining the appropriate signal mode to use when a given link speed can be achieved using different lane configurations. Accept the ethtool lanes parameter when configuring forced speed. If there is no lanes parameter, select a default. Signed-off-by:
-
Edwin Peer authored
Add infrastructure to look up the enum ethtool_link_mode_bit_indices from link information provided by the firmware. The link speed, signal mode, and media type returned by firmware will be used to look up the ethtool link mode. The immediate benefit is that once the link mode is determined, we can now use ethtool_params_from_link_mode() to fill the basic ethtool parameters including the number of lanes. Lanes will be fully supported in the next patch. Signed-off-by:
-
Kalesh AP authored
FW sends the async event to the driver when the device temperature goes above or below the threshold values. Only notify hwmon if the temperature is increasing to the next alert level, not when it is decreasing. Cc: Guenter Roeck <linux@roeck-us.net> Reviewed-by:
Kashyap Desai <kashyap.desai@broadcom.com> Reviewed-by:
Somnath Kotur <somnath.kotur@broadcom.com> Signed-off-by:
Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by:
-
Kalesh AP authored
Defer hwmon_notify_event() to bnxt_sp_task() workqueue because hwmon_notify_event() can try to acquire a mutex shown in the stack trace below. Modify bnxt_event_error_report() to return true if we need to schedule bnxt_sp_task() to notify hwmon. __schedule+0x68/0x520 hwmon_notify_event+0xe8/0x114 schedule+0x60/0xe0 schedule_preempt_disabled+0x28/0x40 __mutex_lock.constprop.0+0x534/0x550 __mutex_lock_slowpath+0x18/0x20 mutex_lock+0x5c/0x70 kobject_uevent_env+0x2f4/0x3d0 kobject_uevent+0x10/0x20 hwmon_notify_event+0x94/0x114 bnxt_hwmon_notify_event+0x40/0x70 [bnxt_en] bnxt_event_error_report+0x260/0x290 [bnxt_en] bnxt_async_event_process.isra.0+0x250/0x850 [bnxt_en] bnxt_hwrm_handler.isra.0+0xc8/0x120 [bnxt_en] bnxt_poll_p5+0x150/0x350 [bnxt_en] __napi_poll+0x3c/0x210 net_rx_action+0x308/0x3b0 __do_softirq+0x120/0x3e0 Cc: Guenter Roeck <linux@roeck-us.net> Fixes: a19b4801 ("bnxt_en: Event handler for Thermal event") Signed-off-by:
-
- 21 Oct, 2023 5 commits
-
-
Shinas Rasheed authored
Clean up structure defines related to hardware data to be asserted to fixed sizes, as padding is not allowed by hardware. Signed-off-by:
Shinas Rasheed <srasheed@marvell.com> Signed-off-by:
-
Su Hui authored
mv88e6xxx_tai_write() can return error code (-EOPNOTSUPP ...) if failed. So check the value of 'ret' after calling mv88e6xxx_tai_write(). Signed-off-by:
Su Hui <suhui@nfschina.com> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Pedro Tammela authored
Add a test to check if inner rt curves are upgraded to sc curves. Signed-off-by:
Pedro Tammela <pctammela@mojatatu.com> Signed-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 chinfo.name to be NUL-terminated based on its use with format strings and sprintf: rpmsg/rpmsg_char.c 165: dev_err(dev, "failed to open %s\n", eptdev->chinfo.name); 368: return sprintf(buf, "%s\n", eptdev->chinfo.name); ... and with strcmp(): | static struct rpmsg_endpoint *qcom_glink_create_ept(struct rpmsg_device *rpdev, | rpmsg_rx_cb_t cb, | void *priv, | struct rpmsg_channel_info | chinfo) | ... | const char *name = chinfo.name; | ... | if (!strcmp(channel->name, name)) Since chinfo is initialized as such (just above the strscpy()): | struct rpmsg_channel_info chinfo = { | .src = rpwwan->rpdev->src, | .dst = RPMSG_ADDR_ANY, | }; ... we know other members are zero-initialized. This means no NUL-padding is required (as any NUL-byte assignments are redundant). Considering the above, a suitable replacement is `strscpy` 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://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/20231019-strncpy-drivers-net-wwan-rpmsg_wwan_ctrl-c-v2-1-ecf9b5a39430@google.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Su Hui authored
check the value of 'ret' after call 'devlink_info_version_stored_put'. Signed-off-by:
Shannon Nelson <shannon.nelson@amd.com> Link: https://lore.kernel.org/r/20231019083351.1526484-1-suhui@nfschina.comSigned-off-by:
-
- 20 Oct, 2023 10 commits
-
-
David S. Miller authored
Jacob Keller says: ==================== Intel Wired LAN Driver Updates 2023-10-19 (ice, igb, ixgbe) This series contains improvements to the ice driver related to VF MSI-X resource tracking, as well as other minor cleanups. Dan fixes code in igb and ixgbe where the conversion to list_for_each_entry failed to account for logic which assumed a NULL pointer after iteration. Jacob makes ice_get_pf_c827_idx static, and refactors ice_find_netlist_node based on feedback that got missed before the function merged. Michal adds a switch rule to drop all traffic received by an inactive LAG port. He also implements ops to allow individual control of MSI-X vectors for SR-IOV VFs. Przemek removes some unused fields in struct ice_flow_entry, and modifies the ice driver to cache the VF PCI device inside struct ice_vf rather than performing lookup at run time. ==================== Signed-off-by: -
Dan Carpenter authored
The list iterator in a list_for_each_entry() loop can never be NULL. If the loop exits without hitting a break then the iterator points to an offset off the list head and dereferencing it is an out of bounds access. Before we transitioned to using list_for_each_entry() loops, then it was possible for "entry" to be NULL and the comments mention this. I have updated the comments to match the new code. Fixes: c1fec890 ("ethernet/intel: Use list_for_each_entry() helper") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Simon Horman <horms@kernel.org> Reviewed-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Signed-off-by:
-
Dan Carpenter authored
When we exit a list_for_each_entry() without hitting a break statement, the list iterator isn't NULL, it just point to an offset off the list_head. In that situation, it wouldn't be too surprising for entry->free to be true and we end up corrupting memory. The way to test for these is to just set a flag. Fixes: c1fec890 ("ethernet/intel: Use list_for_each_entry() helper") Signed-off-by:
-
Jacob Keller authored
The ice_find_netlist_node function was introduced in commit 8a3a565f ("ice: add admin commands to access cgu configuration"). Variations of this function were reviewed concurrently on both intel-wired-lan[1][2], and netdev [3][4] [1]: https://lore.kernel.org/intel-wired-lan/20230913204943.1051233-7-vadim.fedorenko@linux.dev/ [2]: https://lore.kernel.org/intel-wired-lan/20230817000058.2433236-5-jacob.e.keller@intel.com/ [3]: https://lore.kernel.org/netdev/20230918212814.435688-1-anthony.l.nguyen@intel.com/ [4]: https://lore.kernel.org/netdev/20230913204943.1051233-7-vadim.fedorenko@linux.dev/ The variant I posted had a few changes due to review feedback which were never incorporated into the DPLL series: * Replace the references to ancient and long removed ICE_SUCCESS and ICE_ERR_DOES_NOT_EXIST status codes in the function comment. * Return -ENOENT instead of -ENOTBLK, as a more common way to indicate that an entry doesn't exist. * Avoid the use of memset() and use simple static initialization for the cmd variable. * Use FIELD_PREP to assign the node_type_ctx. * Remove an unnecessary local variable to keep track of rec_node_handle, just pass the node_handle pointer directly into ice_aq_get_netlist_node. Signed-off-by:
Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by:
-
Jacob Keller authored
The ice_get_pf_c827_idx function is only called inside of ice_ptp_hw.c, so there is no reason to export it. Mark it static and remove the declaration from ice_ptp_hw.h Signed-off-by:
-
Michal Swiatkowski authored
Track MSI-X for VFs using bitmap, by setting and clearing bitmap during allocation and freeing. Try to linearize irqs usage for VFs, by freeing them and allocating once again. Do it only for VFs that aren't currently running. Signed-off-by:
Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by:
-
Michal Swiatkowski authored
Implement ops needed to set MSI-X vector count on VF. sriov_get_vf_total_msix() should return total number of MSI-X that can be used by the VFs. Return the value set by devlink resources API (pf->req_msix.vf). sriov_set_msix_vec_count() will set number of MSI-X on particular VF. Disable VF register mapping, rebuild VSI with new MSI-X and queues values and enable new VF register mapping. For best performance set number of queues equal to number of MSI-X. Signed-off-by:
-
Michal Swiatkowski authored
Create a bitamp to track MSI-X usage for VFs. The bitmap has the size of total MSI-X amount on device, because at init time the amount of MSI-X used by VFs isn't known. The bitmap is used in follow up patchset to provide a block of continuous block of MSI-X indexes for each created VF. Signed-off-by:
-
Michal Swiatkowski authored
Store the amount of MSI-X per VF instead of storing it in pf struct. It is used to calculate number of q_vectors (and queues) for VF VSI. This is necessary because with follow up changes the number of MSI-X can be different between VFs. Use it instead of using pf->vf_msix value in all cases. Signed-off-by:
-
Przemek Kitszel authored
Extend struct ice_vf by vfdev. Calculation of vfdev falls more nicely into ice_create_vf_entries(). Caching of vfdev enables simplification of ice_restore_all_vfs_msi_state(). Reviewed-by:
Mateusz Polchlopek <mateusz.polchlopek@intel.com> Signed-off-by:
-
