- 10 Sep, 2020 38 commits
-
-
Krzysztof Kozlowski authored
Two functions accept pointer to struct s3fwrn5_fw_info but do not modify the contents. Make them const so the code is a little bit safer. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Krzysztof Kozlowski authored
The driver uses crypto hash functions so it needs to select CRYPTO_HASH. This fixes build errors: arc-linux-ld: drivers/nfc/s3fwrn5/firmware.o: in function `s3fwrn5_fw_download': firmware.c:(.text+0x152): undefined reference to `crypto_alloc_shash' Signed-off-by:
-
Krzysztof Kozlowski authored
The local variable 'ret' can be removed: drivers/nfc/s3fwrn5/i2c.c:167:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable] Signed-off-by:
-
Krzysztof Kozlowski authored
The device tree property prefix describes the vendor, which in case of S3FWRN5 chip is Samsung. Therefore the "s3fwrn5" prefix for "en-gpios" and "fw-gpios" is not correct and should be deprecated. Introduce properly named properties for these GPIOs but still support deprecated ones. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Krzysztof Kozlowski authored
The device tree property prefix describes the vendor, which in case of S3FWRN5 chip is Samsung. Therefore the "s3fwrn5" prefix for "en-gpios" and "fw-gpios" is not correct and should be deprecated. Introduce properly named properties for these GPIOs and rename the fw-gpios" to "wake-gpios" to better describe its purpose. Signed-off-by:
-
Krzysztof Kozlowski authored
Convert the Samsung S3FWRN5 NCI NFC controller bindings to dtschema. This is conversion only so it includes properties with invalid prefixes (s3fwrn5,en-gpios) which should be addressed later. Signed-off-by:
-
David S. Miller authored
Wang Hai says: ==================== Fix some kernel-doc warnings for hns. ==================== Signed-off-by: -
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/huawei/hinic/hinic_hw_eqs.c:115: warning: Excess function parameter 'hw_handler' description in 'hinic_aeq_register_hw_cb' Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/huawei/hinic/hinic_hw_api_cmd.c:382: warning: Excess function parameter 'size' description in 'api_cmd' Reported-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/hisilicon/hns/hns_enet.c:1841: warning: Excess function parameter 'netdev' description in 'hns_set_multicast_list' drivers/net/ethernet/hisilicon/hns/hns_enet.c:1841: warning: Excess function parameter 'p' description in 'hns_set_multicast_list' Reported-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c:137: warning: Excess function parameter 'drv' description in 'hns_xgmac_enable' drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c:497: warning: Excess function parameter 'cmd' description in 'hns_xgmac_get_regs' Reported-by:
-
Wang Hai authored
Rename cdev to hdev. Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/hisilicon/hns/hnae.c:444: warning: Excess function parameter 'cdev' description in 'hnae_ae_unregister' Reported-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/huawei/hinic/hinic_hw_io.c:373: warning: Excess function parameter 'sq_msix_entry' description in 'hinic_io_create_qps' drivers/net/ethernet/huawei/hinic/hinic_hw_io.c:373: warning: Excess function parameter 'rq_msix_entry' description in 'hinic_io_create_qps' Rename these wrong names. Reported-by:
-
Alex Dewar authored
In the functions mvpp2_isr_handle_xlg() and mvpp2_isr_handle_gmac_internal(), the bool variable link is assigned a true value in the case that a given bit of val is set. However, if the bit is unset, no value is assigned to link and it is then passed to mvpp2_isr_handle_link() without being initialised. Fix by assigning to link the value of the bit test. Build-tested on x86. Fixes: 36cfd3a6 ("net: mvpp2: restructure "link status" interrupt handling") Signed-off-by:
Alex Dewar <alex.dewar90@gmail.com> Signed-off-by:
-
Wang Hai authored
Fixes the following W=1 kernel build warning(s): drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:2209: warning: Excess function parameter 'adapter' description in 'clear_sge_ctxt' drivers/net/ethernet/chelsio/cxgb3/t3_hw.c:2975: warning: Excess function parameter 'adapter' description in 't3_set_proto_sram' Reported-by:
-
David S. Miller authored
Sameeh Jubran says: ==================== Enhance current features in ena driver This series adds the following: * Exposes new device stats using ethtool. * Adds and exposes the stats of xdp TX queues through ethtool. ==================== Signed-off-by: -
Sameeh Jubran authored
When using XDP every ingress packet is passed to an eBPF (xdp) program which returns an action for this packet. This patch adds counters for the number of times each such action was received. It also counts all the invalid actions received from the eBPF program. Signed-off-by:
Shay Agroskin <shayagr@amazon.com> Signed-off-by:
Sameeh Jubran <sameehj@amazon.com> Signed-off-by:
-
Sameeh Jubran authored
Added statistics for TX queues that are used for XDP TX. The statistics are the same as the ones printed for regular non-XDP TX queues. The XDP queue statistics can be queried using `ethtool -S <ifname>` Signed-off-by:
-
Sameeh Jubran authored
The new metrics provide granular visibility along multiple network dimensions and enable troubleshooting and remediation of issues caused by instances exceeding network performance allowances. The new statistics can be queried using ethtool command. Signed-off-by:
Guy Tzalik <gtzalik@amazon.com> Signed-off-by:
-
Sameeh Jubran authored
The type of all stat fields is u64, therefore when iterating over stat fields in a stats struct, it makes sense to use an offset in 64 bit resolution. Doing so allows us to drop some of the casting that is currently used when referencing stats. Signed-off-by:
-
Christoph Paasch authored
The delay was intended to be configured to "simulate" a high(er) BDP link. As such, it needs to be set as part of the loss-configuration and not as part of the netem reordering configuration. The reordering-config also requires a delay but that delay is the reordering-extend. So, a good approach is to set the reordering-extend as a function of the configured latency. E.g., 25% of the overall latency. To speed up the selftests, we limit the delay to 50ms maximum to avoid having the selftests run for too long. Finally, the intention of tc_reorder was that when it is unset, the test picks a random configuration. However, currently it is always initialized and thus the random config won't be picked up. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/6Reported-and-reviewed-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Christoph Paasch <cpaasch@apple.com> Signed-off-by:
-
David S. Miller authored
Wei Wang says: ==================== tcp: add tos reflection feature This patch series adds a new tcp feature to reflect TOS value received in SYN, and send it out in SYN-ACK, and eventually set the TOS value of the established socket with this reflected TOS value. This provides a way to set the traffic class/QoS level for all traffic in the same connection to be the same as the incoming SYN. It could be useful for datacenters to provide equivalent QoS according to the incoming request. This feature is guarded by /proc/sys/net/ipv4/tcp_reflect_tos, and is by default turned off. ==================== Signed-off-by: -
Wei Wang authored
This commit adds a new TCP feature to reflect the tos value received in SYN, and send it out on the SYN-ACK, and eventually set the tos value of the established socket with this reflected tos value. This provides a way to set the traffic class/QoS level for all traffic in the same connection to be the same as the incoming SYN request. It could be useful in data centers to provide equivalent QoS according to the incoming request. This feature is guarded by /proc/sys/net/ipv4/tcp_reflect_tos, and is by default turned off. Signed-off-by:
Wei Wang <weiwan@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Wei Wang authored
This commit adds tos as a new passed in parameter to ip_build_and_send_pkt() which will be used in the later commit. This is a pure restructure and does not have any functional change. Signed-off-by:
-
Wei Wang authored
A new field is added to the request sock to record the TOS value received on the listening socket during 3WHS: When not under syn flood, it is recording the TOS value sent in SYN. When under syn flood, it is recording the TOS value sent in the ACK. This is a preparation patch in order to do TOS reflection in the later commit. Signed-off-by:
-
Lorenzo Bianconi authored
Remove mvneta_stats from mvneta_swbm_rx_frame signature since now stats are accounted in mvneta_run_xdp routine Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== netpoll: make sure napi_list is safe for RCU traversal This series is a follow-up to the fix in commit 96e97bc0 ("net: disable netpoll on fresh napis"). To avoid any latent race conditions convert dev->napi_list to a proper RCU list. We need minor restructuring because it looks like netif_napi_del() used to be idempotent, and it may be quite hard to track down everyone who depends on that. ==================== Signed-off-by:
-
Jakub Kicinski authored
netpoll needs to traverse dev->napi_list under RCU, make sure it uses the right iterator and that removal from this list is handled safely. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Jakub Kicinski authored
To RCUify napi->dev_list we need to replace list_del_init() with list_del_rcu(). There is no _init() version for RCU for obvious reasons. Up until now netif_napi_del() was idempotent so to make sure it remains such add a bit which is set when NAPI is listed, and cleared when it removed. Since we don't expect multiple calls to netif_napi_add() to be correct, add a warning on that side. Now that napi_hash_add / napi_hash_del are only called by napi_add / del we can actually steal its bit. We just need to make sure hash node is initialized correctly. Signed-off-by:
-
Jakub Kicinski authored
We allow drivers to call napi_hash_del() before calling netif_napi_del() to batch RCU grace periods. This makes the API asymmetric and leaks internal implementation details. Soon we will want the grace period to protect more than just the NAPI hash table. Restructure the API and have drivers call a new function - __netif_napi_del() if they want to take care of RCU waits. Note that only core was checking the return status from napi_hash_del() so the new helper does not report if the NAPI was actually deleted. Some notes on driver oddness: - veth observed the grace period before calling netif_napi_del() but that should not matter - myri10ge observed normal RCU flavor - bnx2x and enic did not actually observe the grace period (unless they did so implicitly) - virtio_net and enic only unhashed Rx NAPIs The last two points seem to indicate that the calls to napi_hash_del() were a left over rather than an optimization. Regardless, it's easy enough to correct them. This patch may introduce extra synchronize_net() calls for interfaces which set NAPI_STATE_NO_BUSY_POLL and depend on free_netdev() to call netif_napi_del(). This seems inevitable since we want to use RCU for netpoll dev->napi_list traversal, and almost no drivers set IFF_DISABLE_NETPOLL. Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: ==================== mlx4: avoid devlink port type not set warnings This small set addresses the issue of mlx4 potentially not setting devlink port type when Ethernet or IB driver is not built, but port has that type. v2: - add patch 1 ==================== Signed-off-by: -
Jakub Kicinski authored
Even tho mlx4_core registers the devlink ports, it's mlx4_en and mlx4_ib which set their type. In situations where one of the two is not built yet the machine has ports of given type we see the devlink warning from devlink_port_type_warn() trigger. Having ports of a type not supported by the kernel may seem surprising, but it does occur in practice - when the unsupported port is not plugged in to a switch anyway users are more than happy not to see it (and potentially allocate any resources to it). Set the type in mlx4_core if type-specific driver is not built. Signed-off-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Jakub Kicinski authored
Following change will add support for a corner case where we may not have a netdev to pass to devlink_port_type_eth_set() but we still want to set port type. This is definitely a corner case, and drivers should not normally pass NULL netdev - print a warning message when this happens. Sadly for other port types (ib) switches don't have a device reference, the way we always do for Ethernet, so we can't put the warning in __devlink_port_type_set(). Signed-off-by:
-
Lorenzo Bianconi authored
In order to easily change the rx buffer size, rely on MVNETA_MAX_RX_BUF_SIZE instead of PAGE_SIZE in mvneta_swbm_rx_frame routine for rx buffer split. Currently this is not an issue since we set MVNETA_MAX_RX_BUF_SIZE to PAGE_SIZE - MVNETA_SKB_PAD but it is a good to have to configure a different rx buffer size. Signed-off-by:
-
David S. Miller authored
Paul Davey says: ==================== Allow more than 255 IPv4 multicast interfaces Currently it is not possible to use more than 255 multicast interfaces for IPv4 due to the format of the igmpmsg header which only has 8 bits available for the VIF ID. There is space available in the igmpmsg header to store the full VIF ID in the form of an unused byte following the VIF ID field. There is also enough space for the full VIF ID in the Netlink cache notifications, however the value is currently taken directly from the igmpmsg header and has thus already been truncated. Adding the high byte of the VIF ID into the unused3 byte of igmpmsg allows use of more than 255 IPv4 multicast interfaces. The full VIF ID is also available in the Netlink notification by assembling it from both bytes from the igmpmsg. Additionally this reveals a deficiency in the Netlink cache report notifications, they lack any means for differentiating cache reports relating to different multicast routing tables. This is easily resolved by adding the multicast route table ID to the cache reports. changes in v2: - Added high byte of VIF ID to igmpmsg struct replacing unused3 member. - Assemble VIF ID in Netlink notification from both bytes in igmpmsg header. ==================== Signed-off-by: -
Paul Davey authored
Insert the full 16 bit VIF ID into ipmr Netlink cache reports. The VIF_ID attribute has 32 bits of space so can store the full VIF ID extracted from the high and low byte fields in the igmpmsg. Signed-off-by:
Paul Davey <paul.davey@alliedtelesis.co.nz> Signed-off-by:
-
Paul Davey authored
Use the unused3 byte in struct igmpmsg to hold the high 8 bits of the VIF ID. If using more than 255 IPv4 multicast interfaces it is necessary to have access to a VIF ID for cache reports that is wider than 8 bits, the VIF ID present in the igmpmsg reports sent to mroute_sk was only 8 bits wide in the igmpmsg header. Adding the high 8 bits of the 16 bit VIF ID in the unused byte allows use of more than 255 IPv4 multicast interfaces. Signed-off-by:
-
Paul Davey authored
Insert the multicast route table ID as a Netlink attribute to Netlink cache report notifications. When multiple route tables are in use it is necessary to have a way to determine which route table a given cache report belongs to when receiving the cache report. Signed-off-by:
-
- 09 Sep, 2020 2 commits
-
-
Florian Fainelli authored
We already maintain an array of VLANs used by the switch so we can simply iterate over it to report the occupancy via devlink. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
David S. Miller authored
Russell King says: ==================== Marvell PP2.2 PTP support This series adds PTP support for PP2.2 hardware to the mvpp2 driver. Tested on the Macchiatobin eth1 port. Note that on the Macchiatobin, eth0 uses a separate TAI block from eth1, and there is no hardware synchronisation between the two. ==================== Signed-off-by:
-
