- 17 Mar, 2022 18 commits
-
-
Eyal Birger authored
This patch adds support for encapsulating IPv4/IPv6 within GENEVE. In order to use this, a new IFLA_GENEVE_INNER_PROTO_INHERIT flag needs to be provided at device creation. This property cannot be changed for the time being. In case IP traffic is received on a non-tun device the drop count is increased. Signed-off-by:
Eyal Birger <eyal.birger@gmail.com> Link: https://lore.kernel.org/r/20220316061557.431872-1-eyal.birger@gmail.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Paolo Abeni authored
Chris Packham says: ==================== net: mvneta: Armada 98DX2530 SoC This is split off from [1] to let it go in via net-next rather than waiting for the rest of the series to land. [1] - https://lore.kernel.org/lkml/20220314213143.2404162-1-chris.packham@alliedtelesis.co.nz/ ==================== Link: https://lore.kernel.org/r/20220315215207.2746793-1-chris.packham@alliedtelesis.co.nzSigned-off-by:
-
Chris Packham authored
The 98DX2530 SoC is similar to the Armada 3700 except it needs a different MBUS window configuration. Add a new compatible string to identify this device and the required MBUS window configuration. Signed-off-by:
Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Chris Packham authored
The out of band port on the 98DX2530 SoC is similar to the armada-3700 except it requires a slightly different MBUS window configuration. Add a new compatible string so this difference can be accounted for. Signed-off-by:
-
Jonathan Lemon authored
Update and check functionality for pin configuration requests: PTP_PF_NONE: requests "IN: None", disabling the pin. # testptp -d /dev/ptp3 -L3,0 -i1 set pin function okay # cat sma4 IN: None PTP_PF_EXTTS: should configure external timestamps, but since the timecard can steer inputs to multiple inputs as well as timestamps, allow the request, but don't change configurations. # testptp -d /dev/ptp3 -L3,1 -i1 set pin function okay (no functional or configuration change here yet) PTP_PF_PEROUT: Channel 0 is the PHC, at 1PPS. Channels 1-4 are the programmable frequency generators. # fails because period is not 1PPS. # testptp -d /dev/ptp3 -L3,2 -i0 -p 500000000 PTP_PEROUT_REQUEST: Invalid argument # testptp -d /dev/ptp3 -L3,2 -i0 -p 1000000000 periodic output request okay # cat sma4 OUT: PHC # testptp -d /dev/ptp3 -L3,2 -i1 -p 500000000 -w 200000000 periodic output request okay # cat sma4 OUT: GEN1 # cat gen1/signal 500000000 40 0 1 2022-03-10T23:55:26 TAI # cat gen1/running 1 # testptp -d /dev/ptp3 -L3,2 -i1 -p 0 periodic output request okay # cat gen1/running 0 Signed-off-by:
Jonathan Lemon <jonathan.lemon@gmail.com> Link: https://lore.kernel.org/r/20220315194626.1895-1-jonathan.lemon@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Roi Dayan says: ==================== flow_offload: add tc vlan push_eth and pop_eth actions Offloading vlan push_eth and pop_eth actions is needed in order to correctly offload MPLSoUDP encap and decap flows, this series extends the flow offload API to support these actions and updates mlx5 to parse them. ==================== Link: https://lore.kernel.org/r/20220315110211.1581468-1-roid@nvidia.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Maor Dickman authored
Currently the MPLSoUDP encap offload does the L2 pop implicitly while adding such action explicitly (vlan eth_push) will cause the rule to not be offloaded. Solve it by adding offload support for vlan eth_push in case of MPLSoUDP decap case. Flow example: filter root protocol ip pref 1 flower chain 0 filter root protocol ip pref 1 flower chain 0 handle 0x1 eth_type ipv4 dst_ip 2.2.2.22 src_ip 2.2.2.21 in_hw in_hw_count 1 action order 1: vlan pop_eth pipe index 1 ref 1 bind 1 used_hw_stats delayed action order 2: mpls push protocol mpls_uc label 555 tc 3 ttl 255 pipe index 1 ref 1 bind 1 used_hw_stats delayed action order 3: tunnel_key set src_ip 8.8.8.21 dst_ip 8.8.8.22 dst_port 6635 csum tos 0x4 ttl 6 pipe index 1 ref 1 bind 1 used_hw_stats delayed action order 4: mirred (Egress Redirect to device bareudp0) stolen index 1 ref 1 bind 1 used_hw_stats delayed Signed-off-by:Maor Dickman <maord@nvidia.com> Reviewed-by:
Roi Dayan <roid@nvidia.com> Signed-off-by:
-
Maor Dickman authored
Currently action pedit of source and destination MACs is used to fill the MACs in L2 push step in MPLSoUDP decap offload, this isn't aligned to tc SW which use vlan eth_push action to do this. To fix that, offload support for vlan veth_push action is added together with mpls pop action, and deprecate the use of pedit of MACs. Flow example: filter protocol mpls_uc pref 1 flower chain 0 filter protocol mpls_uc pref 1 flower chain 0 handle 0x1 eth_type 8847 mpls_label 555 enc_dst_port 6635 in_hw in_hw_count 1 action order 1: tunnel_key unset pipe index 2 ref 1 bind 1 used_hw_stats delayed action order 2: mpls pop protocol ip pipe index 2 ref 1 bind 1 used_hw_stats delayed action order 3: vlan push_eth dst_mac de:a2:ec:d6:69:c8 src_mac de:a2:ec:d6:69:c8 pipe index 2 ref 1 bind 1 used_hw_stats delayed action order 4: mirred (Egress Redirect to device enp8s0f0_0) stolen index 2 ref 1 bind 1 used_hw_stats delayed Signed-off-by: -
Maor Dickman authored
Add vlan push_eth and pop_eth action to the hardware intermediate representation model which would subsequently allow it to be used by drivers for offload. Signed-off-by:
-
Tobias Waldekranz authored
If a port joins a bridge that it can't offload, it will fallback to standalone mode and software bridging. In this case, we never want to offload any FDB entries to hardware either. Previously, for host addresses, we would eventually end up in dsa_port_bridge_host_fdb_add, which would unconditionally dereference dp->bridge and cause a segfault. Fixes: c2693363 ("net: dsa: request drivers to perform FDB isolation") Signed-off-by:
Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20220315233033.1468071-1-tobias@waldekranz.comSigned-off-by:
-
Yang Li authored
Fix following includecheck warning: ./drivers/phy/freescale/phy-fsl-lynx-28g.c: linux/workqueue.h is included more than once. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20220315235603.59481-1-yang.lee@linux.alibaba.comSigned-off-by:
-
Minghao Chi authored
Cannot directly return platform_get_irq return irq, there are operations that need to be undone. Fixes: bf2b8342 ("net: mv643xx_eth: use platform_get_irq() instead of platform_get_resource()") Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Reviewed-by:
-
Colin Ian King authored
There is a spelling mistake in a dev_warn message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20220315222914.2960786-1-colin.i.king@gmail.comSigned-off-by:
-
Colin Ian King authored
There is a spelling mistake in a netdev_warn warning. Fix it. Signed-off-by:
-
wujunwen authored
remove the static next_jiffies variable, and reinitialize next_jiffies to simplify netdev_open Signed-off-by:
wujunwen <wudaemon@163.com> Link: https://lore.kernel.org/r/20220315122857.78601-1-wudaemon@163.comSigned-off-by:
-
Meng Tang authored
In file hamradio/baycom_epp.c, the baycom_setmode interface, there is a problem with improper use of strstr. Suppose that when modestr="noloopback", both conditions which are 'strstr(modestr,"noloopback")' and 'strstr(modestr,"loopback")' will be true(not NULL), this lead the bc->cfg.loopback variable will be first assigned to 0, and then reassigned to 1. This will cause 'bc->cfg.loopback = 0' will never take effect. That obviously violates the logic of the code, so adjust the order of their execution to solve the problem. Signed-off-by:
Meng Tang <tangmeng@uniontech.com> Reviewed-by:
Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/20220315074851.6456-1-tangmeng@uniontech.comSigned-off-by:
-
Hangbin Liu authored
bareudp_create_sock() use AF_INET6 by default if IPv6 CONFIG enabled. But if user start kernel with ipv6.disable=1, the bareudp sock will created failed, which cause the interface open failed even with ethertype ip. e.g. # ip link add bareudp1 type bareudp dstport 2 ethertype ip # ip link set bareudp1 up RTNETLINK answers: Address family not supported by protocol Fix it by using ipv6_mod_enabled() to check if IPv6 enabled. There is no need to check IS_ENABLED(CONFIG_IPV6) as ipv6_mod_enabled() will return false when CONFIG_IPV6 no enabled in include/linux/ipv6.h. Reported-by:
Jianlin Shi <jishi@redhat.com> Fixes: 571912c6 ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Link: https://lore.kernel.org/r/20220315062618.156230-1-liuhangbin@gmail.comSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-5.18-20220316' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2022-03-16 the first 3 patches are by Oliver Hartkopp target the CAN ISOTP protocol and fix a problem found by syzbot in isotp_bind(), return -EADDRNOTAVAIL in unbound sockets in isotp_recvmsg() and add support for MSG_TRUNC to isotp_recvmsg(). Amit Kumar Mahapatra converts the xilinx,can device tree bindings to yaml. The last patch is by Julia Lawall and fixes typos in the ucan driver. * tag 'linux-can-next-for-5.18-20220316' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: can: ucan: fix typos in comments dt-bindings: can: xilinx_can: Convert Xilinx CAN binding to YAML can: isotp: support MSG_TRUNC flag when reading from socket can: isotp: return -EADDRNOTAVAIL when reading from unbound socket can: isotp: sanitize CAN ID checks in isotp_bind() ==================== Link: https://lore.kernel.org/r/20220316204710.716341-1-mkl@pengutronix.deSigned-off-by:
-
- 16 Mar, 2022 22 commits
-
-
Julia Lawall authored
Various spelling mistakes in comments. Detected with the help of Coccinelle. Link: https://lore.kernel.org/all/20220314115354.144023-28-Julia.Lawall@inria.frSigned-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Acked-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Amit Kumar Mahapatra authored
Convert Xilinx CAN binding documentation to YAML. Link: https://lore.kernel.org/all/20220316171105.17654-1-amit.kumar-mahapatra@xilinx.comSigned-off-by:
Amit Kumar Mahapatra <amit.kumar-mahapatra@xilinx.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by:
-
Oliver Hartkopp authored
When providing the MSG_TRUNC flag via recvmsg() syscall the return value provides the real length of the packet or datagram, even when it was longer than the passed buffer. Fixes: e057dd3f ("can: add ISO 15765-2:2016 transport protocol") Link: https://github.com/linux-can/can-utils/issues/347#issuecomment-1065932671 Link: https://lore.kernel.org/all/20220316164258.54155-3-socketcan@hartkopp.netSuggested-by:
Derek Will <derekrobertwill@gmail.com> Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
-
Oliver Hartkopp authored
When reading from an unbound can-isotp socket the syscall blocked indefinitely. As unbound sockets (without given CAN address information) do not make sense anyway we directly return -EADDRNOTAVAIL on read() analogue to the known behavior from sendmsg(). Fixes: e057dd3f ("can: add ISO 15765-2:2016 transport protocol") Link: https://github.com/linux-can/can-utils/issues/349 Link: https://lore.kernel.org/all/20220316164258.54155-2-socketcan@hartkopp.netSuggested-by:
-
Oliver Hartkopp authored
Syzbot created an environment that lead to a state machine status that can not be reached with a compliant CAN ID address configuration. The provided address information consisted of CAN ID 0x6000001 and 0xC28001 which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. Sanitize the SFF/EFF CAN ID values before performing the address checks. Fixes: e057dd3f ("can: add ISO 15765-2:2016 transport protocol") Link: https://lore.kernel.org/all/20220316164258.54155-1-socketcan@hartkopp.net Reported-by: syzbot+2339c27f5c66c652843e@syzkaller.appspotmail.com Signed-off-by:
-
Jakub Kicinski authored
Jakub Kicinski says: ==================== devlink: expose instance locking and simplify port splitting This series puts the devlink ports fully under the devlink instance lock's protection. As discussed in the past it implements my preferred solution of exposing the instance lock to the drivers. This way drivers which want to support port splitting can lock the devlink instance themselves on the probe path, and we can take that lock in the core on the split/unsplit paths. nfp and mlxsw are converted, with slightly deeper changes done in nfp since I'm more familiar with that driver. Now that the devlink port is protected we can pass a pointer to the drivers, instead of passing a port index and forcing the drivers to do their own lookups. Both nfp and mlxsw can container_of() to their own structures. ==================== Link: https://lore.kernel.org/r/20220315060009.1028519-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Now that devlink ports are protected by the instance lock it seems natural to pass devlink_port as an argument to the port_split / port_unsplit callbacks. This should save the drivers from doing a lookup. In theory drivers may have supported unsplitting ports which were not registered prior to this change. Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Tested-by:
-
Jakub Kicinski authored
Let the core take the devlink instance lock around port splitting and remove the now redundant locking in the drivers. Reviewed-by:
-
Jakub Kicinski authored
Explicitly lock the devlink instance and use devl_ API. This will be used by the subsequent patch to invoke .port_split / .port_unsplit callbacks with devlink instance lock held. Reviewed-by:
-
Jakub Kicinski authored
The whole reason for existence of the pf mutex is that we could not lock the devlink instance around port splitting. There are more types of reconfig which can make ports appear or disappear. Now that the devlink instance lock is exposed to drivers and "locked" helpers exist we can switch to using the devlink lock directly. Next patches will move the locking inside .port_(un)split to the core. Signed-off-by: -
Jakub Kicinski authored
We can replace the PF lock with devlink instance lock in subsequent changes. To make the patches easier to comprehend and limit line lengths - factor out the existing locking assertions. No functional changes. Signed-off-by: -
Jakub Kicinski authored
It should be familiar and beneficial to expose devlink instance lock to the drivers. This way drivers can block devlink from calling them during critical sections without breakneck locking. Add port helpers, port splitting callbacks will be the first target. Use 'devl_' prefix for "explicitly locked" API. Initial RFC used '__devlink' but that's too much typing. devl_lock_is_held() is not defined without lockdep, which is the same behavior as lockdep_is_held() itself. Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Signed-off-by:
-
David S. Miller authored
Biao Huang says: ==================== MediaTek Ethernet Patches on MT8195 Changes in v13: 1. add reviewed-by in "net: dt-bindings: dwmac: add support for mt8195" as Rob's comments. 2. drop num_clks defined in mediatek_dwmac_plat_data struct in "stmmac: dwmac-mediatek: Reuse more common features" as Angelo's comments. Changes in v12: 1. add a new patch "stmmac: dwmac-mediatek: re-arrange clock setting" to this series, to simplify clock handling in driver, which benefits to binding file mediatek-dwmac.yaml. 2. modify dt-binding description in patch "net: dt-bindings: dwmac: add support for mt8195" as Rob's comments in v10 series, put mac_cg to the end of clock list. 3. there are small changes in patch "stmmac: dwmac-mediatek: add support for mt8195", @AngeloGioacchino, please review it kindly. Changes in v11: 1. add reivewed-by in "net: dt-bindings: dwmac: Convert mediatek-dwmac to DT schema" as Rob's comments. 2. fall back "net: dt-bindings: dwmac: add support for mt8195" to v8 version as mentioned in previous reply(https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20211216055328.15953-7-biao.huang@mediatek.com/): 2.1 there is already a special clock named "rmii_internal", which need to be put to the end of the clock list(driver special handling), so we can't simply put new "mac_cg" for mt8195 to the end of the clock list. 2.2 we prefer the if-then schema, which will make mt8195 clock list clearer with some duplicated information. 2.3 we expect the future IC will follow mt2712 or mt8195, so we only need add new IC name to compatible list for future IC, and will not make the clock list binding files worse. Changes in v10: 1. add detailed description in "arm64: dts: mt2712: update ethernet device node" to make the modifications clearer as Matthias's comments. 2. modify dt-binding description as Rob's comments, and "make dtbs_check" runs pass locally with "arm64: dts: mt2712: update ethernet device node" in this series. Changes in v9: 1. remove oneOf for 1 entry as Rob's comments. 2. add new clocks to the end of existing clocks to simplify the binding as Rob's comments. Changes in v8: 1. add acked-by in "stmmac: dwmac-mediatek: add platform level clocks management" patch Changes in v7: 1. fix uninitialized warning as Jakub's comments. Changes in v6: 1. update commit message as Jakub's comments. 2. split mt8195 eth dts patch("arm64: dts: mt8195: add ethernet device node") from this series, since mt8195 dtsi/dts basic patches is still under reviewing. https://patchwork.kernel.org/project/linux-mediatek/list/?series=579071 we'll resend mt8195 eth dts patch once all the dependent patches are accepted. Changes in v5: 1. remove useless inclusion in dwmac-mediatek.c as Angelo's comments. 2. add acked-by in "net-next: stmmac: dwmac-mediatek: add support for mt8195" patch Changes in v4: 1. add changes in commit message in "net-next: dt-bindings: dwmac: Convert mediatek-dwmac to DT schema" patch. 2. remove ethernet-controller.yaml since snps,dwmac.yaml already include it. Changes in v3: 1. Add prefix "net-next" to support new IC as Denis's suggestion. 2. Split dt-bindings to two patches, one for conversion, and the other for new IC. 3. add a new patch to update device node in mt2712-evb.dts to accommodate to changes in driver. 4. remove unnecessary wrapper as Angelo's suggestion. 5. Add acked-by in "net-next: stmmac: dwmac-mediatek: Reuse more common features" patch. Changes in v2: 1. fix errors/warnings in mediatek-dwmac.yaml with upgraded dtschema tools Changes in v1: This series include 5 patches: 1. add platform level clocks management for dwmac-mediatek 2. resue more common features defined in stmmac_platform.c 3. add ethernet entry for mt8195 ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Biao Huang authored
Add binding document for the ethernet on mt8195. Signed-off-by:
Biao Huang <biao.huang@mediatek.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Biao Huang authored
Add Ethernet support for MediaTek SoCs from the mt8195 family. Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Biao Huang authored
Convert mediatek-dwmac to DT schema, and delete old mediatek-dwmac.txt. And there are some changes in .yaml than .txt, others almost keep the same: 1. compatible "const: snps,dwmac-4.20". 2. delete "snps,reset-active-low;" in example, since driver remove this property long ago. 3. add "snps,reset-delay-us = <0 10000 10000>" in example. 4. the example is for rgmii interface, keep related properties only. Signed-off-by: -
Biao Huang authored
Since there are some changes in ethernet driver: update ethernet device node in dts to accommodate to it. 1. stmmac_probe_config_dt() in stmmac_platform.c will initialize specified parameters according to compatible string "snps,dwmac-4.20a", then, dwmac-mediatek.c can skip the initialization if add compatible string "snps,dwmac-4.20a" in eth device node. 2. commit 882007ed ("net-next: dt-binding: dwmac-mediatek: add more description for RMII") added rmii internal support, we should add corresponding clocks/clocks-names in eth device node. 3. add "snps,reset-delays-us = <0 10000 10000>;" to ensure reset delay can meet PHY requirement. Signed-off-by:
-
Biao Huang authored
The rmii_internal clock is needed only when PHY interface is RMII, and reference clock is from MAC. Re-arrange the clock setting as following: 1. the optional "rmii_internal" is controlled by devm_clk_get(), 2. other clocks still be configured by devm_clk_bulk_get(). Signed-off-by:
-
Biao Huang authored
This patch makes dwmac-mediatek reuse more features supported by stmmac_platform.c. Signed-off-by:
-
Biao Huang authored
This patch implements clks_config callback for dwmac-mediatek platform, which could support platform level clocks management. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== 100GbE Intel Wired LAN Driver Updates 2022-03-15 Jacob Keller says: The ice_sriov.c file now houses almost all of the virtualization code in the ice driver. This includes both Single Root specific implementation as well as generic functionality such as the virtchnl interface. We are planning to implement support for Scalable IOV in the ice driver in the future. This implementation will want to use the generic functionality in ice_sriov.c Rather than dump the Scalable IOV code into ice_sriov.c, we will want to implement it in a separate file, ice_siov.c To help with this, refactor the code in ice_sriov.c and split the generic functionality out into separate files. Reorganize code to make the non-implementation specific bits into new files with the following general guidelines: * ice_vf_lib.[ch] Basic VF structures and accessors. This is where scheme-independent code will reside. * ice_virtchnl.[ch] Virtchnl message handling. This is where the bulk of the logic for processing messages from VFs using the virtchnl messaging scheme will reside. This is separated from ice_vf_lib.c because it is somewhat distinct and stand alone. * ice_sriov.[ch] Single Root IOV implementation, including initialization and the routines for interacting with SR-IOV based netdev operations. * (future) ice_siov.[ch] Scalable IOV implementation. The end goal is to make it easier to re-use the generic parts of the virtualization logic while keeping separate the concerns of the Single Root implementation. In addition to the pure code moves, this series has a reset refactor which clean up the functionality to make it easier to reuse the reset code. A new ops table is introduced to make the VF reset logic more generic. The Single Root specific details are implemented in ice_sriov.c. A future series implementing Scalable IOV support will use this ops table to allow re-use of the reset logic which is now in ice_vf_lib.c ==================== Signed-off-by: -
Casper Andersson authored
Changes the handling of fdb entries to use Switchdev events, instead of the previous "sync_bridge" and "sync_port" which only run when adding or removing VLANs on the bridge. Signed-off-by:
Casper Andersson <casper.casan@gmail.com> Link: https://lore.kernel.org/r/20220314160918.4rfrrfgmbsf2pxl3@wse-c0155Signed-off-by:
-
