- 10 May, 2023 39 commits
-
-
Liang Li authored
"ip link set dev "$devbond1" nomaster" This line code in bond-eth-type-change.sh is unnecessary. Because $devbond1 was not added to any master device. Signed-off-by:
Liang Li <liali@redhat.com> Acked-by:
Hangbin Liu <liuhangbin@gmail.com> Reviewed-by:
Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Lorenzo Bianconi authored
Since veth is very likely to be enabled and there are some drivers (e.g. mlx5) where CONFIG_PAGE_POOL_STATS is optional, make CONFIG_PAGE_POOL_STATS optional for veth too in order to keep it optional instead of required. Suggested-by:
Jiri Benc <jbenc@redhat.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Toke Høiland-Jørgensen <toke@redhat.com> Signed-off-by:
-
David S. Miller authored
Horatiu Vultur says: ==================== net: lan966x: Add support for ES0 VCAP Provide the Egress Stage 0 (ES0) VCAP (Versatile Content-Aware Processor) support for the lan966x platform. The ES0 VCAP has only 1 lookup which is accessible with a TC chain id 10000000. Currently only one action is support which is vlan pop. Also it is possible to link the IS1 to ES0 using 'goto chain 10000000'. ==================== Signed-off-by: -
Horatiu Vultur authored
Enable the TC command to use the lan966x ES0 VCAP. Currently support only one action which is vlan pop, other will be added later. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
Add ES0 VCAP port keyset configuration for lan966x and also update debugfs to show the keyset configuration. Signed-off-by:
-
Horatiu Vultur authored
Provide ES0 (egress stage 0) VCAP model for lan966x. This provides rewriting functionality in the gress path. Signed-off-by:
-
Martin Wetterwald authored
Some DHCP server implementations only send the important requested DHCP options in the final BOOTP reply (DHCPACK). One example is systemd-networkd. However, RFC2131, in section 4.3.1 states: > The server MUST return to the client: > [...] > o Parameters requested by the client, according to the following > rules: > > -- IF the server has been explicitly configured with a default > value for the parameter, the server MUST include that value > in an appropriate option in the 'option' field, ELSE I've reported the issue here: https://github.com/systemd/systemd/issues/27471 Linux PNP DHCP client implementation only takes into account the DNS servers received in the first BOOTP reply (DHCPOFFER). This usually isn't an issue as servers are required to put the same values in the DHCPOFFER and DHCPACK. However, RFC2131, in section 4.3.2 states: > Any configuration parameters in the DHCPACK message SHOULD NOT > conflict with those in the earlier DHCPOFFER message to which the > client is responding. The client SHOULD use the parameters in the > DHCPACK message for configuration. When making Linux PNP DHCP client (cmdline ip=dhcp) interact with systemd-networkd DHCP server, an interesting "protocol misunderstanding" happens: Because DNS servers were only specified in the DHCPACK and not in the DHCPOFFER, Linux will not catch the correct DNS servers: in the first BOOTP reply (DHCPOFFER), it sees that there is no DNS, and sets as fallback the IP of the DHCP server itself. When the second BOOTP reply comes (DHCPACK), it's already too late: the kernel will not overwrite the fallback setting it has set previously. This patch makes the kernel overwrite its DNS fallback by DNS servers specified in the DHCPACK if any. Signed-off-by:
Martin Wetterwald <martin@wetterwald.eu> Signed-off-by:
-
Lorenzo Bianconi authored
Since veth_convert_skb_to_xdp_buff routine runs in veth_poll() NAPI, rely on napi_build_skb() instead of build_skb() to reduce skb allocation cost. Signed-off-by:
Yunsheng Lin <linyunsheng@huawei.com> Link: https://lore.kernel.org/r/0f822c0b72f8b71555c11745cb8fb33399d02de9.1683578488.git.lorenzo@kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Teoh Ji Sheng authored
Commit af9bf701 ("net: stmmac: add ethtool per-queue irq statistic support") introduced ethtool per-queue statistics support to display number of interrupts generated by DMA tx and DMA rx for DWMAC4 core. This patch extend the support to XGMAC core. Signed-off-by:
Teoh Ji Sheng <ji.sheng.teoh@intel.com> Reviewed-by:
-
Jakub Kicinski authored
Uwe Kleine-König says: ==================== net: stmmac: Convert to platform remove callback returning void (implicit) v1 of this series is available at https://lore.kernel.org/netdev/20230402143025.2524443-1-u.kleine-koenig@pengutronix.de Changes since then: - Added various Reviewed-by: and Acked-by: tags received for v1 - Removed a variable in an earlier patch to make all intermediate steps compilable, spotted by Simon Horman - Rebased to v6.4-rc1 (which needed a slight adaption to cope for 4bd3bb7b ("net: stmmac: Add glue layer for StarFive JH7110 SoC")) ==================== Link: https://lore.kernel.org/r/20230508142637.1449363-1-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Michal Kubiak <michal.kubiak@intel.com> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by:
Bhupesh Sharma <bhupesh.sharma@linaro.org> Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by:
Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Reviewed-by:
-
Uwe Kleine-König authored
The remove callback is only ever called after .probe() returned successfully. After that get_stmmac_bsp_priv() always return non-NULL. Side note: The early exit would also be a bug because the return value of qcom_ethqos_remove() is ignored by the device core and the device is unbound unconditionally. So exiting early resulted in a dangerous resource leak as all devm allocated resources (some memory and the register mappings) are freed but the network device stays around. Using the network device afterwards probably oopses. Reviewed-by:
-
Uwe Kleine-König authored
The function returns zero unconditionally. Change it to return void instead which simplifies one caller as error handing becomes unnecessary. Signed-off-by:
-
Uwe Kleine-König authored
The function returns zero unconditionally. Change it to return void instead which simplifies some callers as error handing becomes unnecessary. The function is also used for some drivers as remove callback. Switch these to the .remove_new() callback. For some others no error can happen in the remove callback now, convert them to .remove_new(), too. Acked-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by:
-
Jakub Kicinski authored
Xuan Zhuo says: ==================== virtio_net: refactor xdp codes Due to historical reasons, the implementation of XDP in virtio-net is relatively chaotic. For example, the processing of XDP actions has two copies of similar code. Such as page, xdp_page processing, etc. The purpose of this patch set is to refactor these code. Reduce the difficulty of subsequent maintenance. Subsequent developers will not introduce new bugs because of some complex logical relationships. In addition, the supporting to AF_XDP that I want to submit later will also need to reuse the logic of XDP, such as the processing of actions, I don't want to introduce a new similar code. In this way, I can reuse these codes in the future. ==================== Link: https://lore.kernel.org/r/20230508061417.65297-1-xuanzhuo@linux.alibaba.comSigned-off-by:
-
Xuan Zhuo authored
This logic is used in multiple places, now we separate it into a helper. Signed-off-by:
Xuan Zhuo <xuanzhuo@linux.alibaba.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Xuan Zhuo authored
Simplifying receive_small() function. Bringing the logic relating to build_skb together. Signed-off-by:
-
Xuan Zhuo authored
Because the skb build code is not shared between xdp and non-xdp, and the xdp code in receive_small() is simpler, so "skip_xdp" is not needed. We can remove it. Signed-off-by:
-
Xuan Zhuo authored
Avoid the problem that some variables(headroom and so on) will repeat the calculation when process xdp. Signed-off-by:
-
Xuan Zhuo authored
In the case of XDP-PASS, skb_reserve uses the "delta" to compatible non-XDP, now that is not shared between xdp and non-xdp, so we can remove this logic. Signed-off-by:
-
Xuan Zhuo authored
The purpose of this patch is to simplify the receive_small(). Separate all the logic of XDP of small into a function. Signed-off-by:
-
Xuan Zhuo authored
Now, the logic of merge xdp process is simple, we can remove the skip_xdp. Signed-off-by:
-
Xuan Zhuo authored
The purpose of this patch is to simplify the receive_mergeable(). Separate all the logic of XDP into a function. Signed-off-by:
-
Xuan Zhuo authored
virtnet_build_xdp_buff_mrg() auto release xdp shinfo then the caller no need to careful the xdp shinfo. Signed-off-by:
-
Xuan Zhuo authored
This patch introduce a new function that frees the rest mergeable buf. The subsequent patch will reuse this function. Signed-off-by:
-
Xuan Zhuo authored
This patch introduce a new function that releases the xdp shinfo. The subsequent patch will reuse this function. Signed-off-by:
-
Xuan Zhuo authored
At present, we have two similar logic to perform the XDP prog. Therefore, this patch separates the code of executing XDP, which is conducive to later maintenance. Signed-off-by:
-
Xuan Zhuo authored
The previous patch, in order to facilitate review, I do not do any modification. This patch has made some optimization on the top. * remove some repeated logics in this function. * add fast check for passing without any alloc. Signed-off-by:
-
Xuan Zhuo authored
Separating the logic of preparation for xdp from receive_mergeable. The purpose of this is to simplify the logic of execution of XDP. The main logic here is that when headroom is insufficient, we need to allocate a new page and calculate offset. It should be noted that if there is new page, the variable page will refer to the new page. Signed-off-by:
-
Xuan Zhuo authored
In the xdp implementation of virtio-net mergeable, it always checks whether two page is used and a page is selected to release. This is complicated for the processing of action, and be careful. In the entire process, we have such principles: * If xdp_page is used (PASS, TX, Redirect), then we release the old page. * If it is a drop case, we will release two. The old page obtained from buf is release inside err_xdp, and xdp_page needs be relased by us. But in fact, when we allocate a new page, we can release the old page immediately. Then just one is using, we just need to release the new page for drop case. On the drop path, err_xdp will release the variable "page", so we only need to let "page" point to the new xdp_page in advance. Signed-off-by:
-
Lukas Bulwahn authored
Commit c9929f0e ("mm/slob: remove CONFIG_SLOB") removes CONFIG_SLOB. Now, we can also remove special handling for socket buffers with the SLOB allocator. The code with HAVE_SKB_SMALL_HEAD_CACHE=1 is now the default behavior for all allocators. Remove an unnecessary distinction between SLOB and SLAB/SLUB allocator after the SLOB allocator is gone. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20230509071207.28942-1-lukas.bulwahn@gmail.comSigned-off-by:
-
Yinjun Zhang authored
Avoid reading link modes from management firmware every time when `ethtool_get_link_ksettings` is called, only communicate with management firmware when necessary like we do for eth_table info. This change can ease the situation that when large number of vlan sub-interfaces are created and their information is requested by some monitoring process like PCP [1] through ethool ioctl frequently. [1] https://pcp.ioSigned-off-by:
Yinjun Zhang <yinjun.zhang@corigine.com> Acked-by:
Louis Peens <louis.peens@corigine.com> Reviewed-by:
-
- 09 May, 2023 1 commit
-
-
Grygorii Strashko authored
The DP83869 PHY on TI's k3-am642-evm supports both MII and RGMII interfaces and is configured by default to use RGMII interface (strap). However, the board design allows switching dynamically to MII interface for testing purposes by applying different set of pinmuxes. To support switching to MII interface, update the DP83869 PHY driver to configure OP_MODE_DECODE.RGMII_MII_SEL(bit 5) properly when MII PHY interface mode is requested. Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230508070359.357474-1-s-vadapalli@ti.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
