- 19 Apr, 2023 40 commits
-
-
Jakub Kicinski authored
SCTP is not universally deployed, allow hiding its bit from the skb. Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jakub Kicinski authored
Datacenter kernel builds will very likely not include WIRELESS, so let them shave 2 bits off the skb by hiding the wifi fields. Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
David S. Miller authored
Christian Marangi says: ==================== net: Add basic LED support for switch/phy This is a continue of [1]. It was decided to take a more gradual approach to implement LEDs support for switch and phy starting with basic support and then implementing the hw control part when we have all the prereq done. This series implements only the brightness_set() and blink_set() ops. An example of switch implementation is done with qca8k. For PHY a more generic approach is used with implementing the LED support in PHY core and with the user (in this case marvell) adding all the required functions. Currently we set the default-state as "keep" to not change the default configuration of the declared LEDs since almost every switch have a default configuration. [1] https://lore.kernel.org/lkml/20230216013230.22978-1-ansuelsmth@gmail.com/ Changes in new series v7: - Drop ethernet-leds schema and add unevaluatedProperties to ethernet-controller and ethernet-phy schema - Drop function-enumerator binding from schema example and DT - Set devname_mandatory for qca8k leds and assign better name to LEDs using the format {slave_mii_bus id}:0{port number}:{color}:{function} - Add Documentation patch for Correct LEDs naming from Andrew - Changes in Andrew patch: - net: phy: Add a binding for PHY LEDs - Convert index from u32 to u8 - net: phy: phy_device: Call into the PHY driver to set LED brightness - Fixup kernel doc - Convert index from u32 to u8 - net: phy: marvell: Add software control of the LEDs - Convert index from u32 to u8 - net: phy: phy_device: Call into the PHY driver to set LED blinking - Kernel doc fix - Convert index from u32 to u8 - net: phy: marvell: Implement led_blink_set() - Convert index from u32 to u8 Changes in new series v6: - Add leds-ethernet.yaml to document reg in led node - Update ethernet-controller and ethernet-phy to follow new leds-ethernet schema - Fix comments in qca8k-leds.c (at least -> at most) (wrong GENMASK for led phy 0 and 4) - Add review and ack tag from Pavel Machek - Changes in Andrew patch: - leds: Provide stubs for when CLASS_LED & NEW_LEDS are disabled - Change LED_CLASS to NEW_LEDS for led_init_default_state_get() - net: phy: Add a binding for PHY LEDs - Add dependency on LED_CLASS - Drop review tag from Michal Kubiak (patch modified) Changes in new series v5: - Rebase everything on top of net-next/main - Add more info on LED probe fail for qca8k - Drop some additional raw number and move to define in qca8k header - Add additional info on LED mapping on qca8k regs - Checks port number in qca8k switch port parse - Changes in Andrew patch: - Add additional patch for stubs when CLASS_LED disabled - Drop CLASS_LED dependency for PHYLIB (to fix kbot errors reported) Changes in new series v4: - Changes in Andrew patch: - net: phy: Add a binding for PHY LEDs: - Rename phy_led: led_list to list - Rename phy_device: led_list to leds - Remove phy_leds_remove() since devm_ should do what is needed - Fixup documentation for struct phy_led - Fail probe on LED errors - net: phy: phy_device: Call into the PHY driver to set LED brightness - Moved phy_led::phydev from previous patch to here since it is first used here. - net: phy: marvell: Implement led_blink_set() - Use int instead of unsigned - net: phy: marvell: Add software control of the LEDs - Use int instead of unsigned - Add depends on LED_CLASS for qca8k Kconfig - Fix Makefile for qca8k as suggested - Move qca8k_setup_led_ctrl to separate header - Move Documentation from dsa-port to ethernet-controller - Drop trailing . from Andrew patch fro consistency Changes in new series v3: - Move QCA8K_LEDS Kconfig option from tristate to bool - Use new helper led_init_default_state_get for default-state in qca8k - Drop cled_qca8k_brightness_get() as there isn't a good way to describe the mode the led is currently in - Rework qca8k_led_brightness_get() to return true only when LED is set to always ON Changes in new series v2: - Add LEDs node for rb3011 - Fix rb3011 switch node unevaluated properties while running make dtbs_check - Fix a copypaste error in qca8k-leds.c for port 4 required shift - Drop phy-handle usage for qca8k and use qca8k_port_to_phy() - Add review tag from Andrew - Add Christian Marangi SOB in each Andrew patch - Add extra description for dsa-port stressing that PHY have no access and LED are controlled by the related MAC - Add missing additionalProperties for dsa-port.yaml and ethernet-phy.yaml Changes from the old v8 series: - Drop linux,default-trigger set to netdev. - Dropped every hw control related patch and implement only blink_set and brightness_set - Add default-state to "keep" for each LED node example ==================== Signed-off-by:
-
Andrew Lunn authored
Network LEDs can exist in both the MAC and the PHY. Naming is difficult because the netdev name is neither stable or unique, do to commands like ip link set name eth42 dev eth0, and network namesspaces. Give some example names where the MAC and the PHY have unique names based on device tree nodes, or PCI bus addresses. Since the LED can be used for anything which Linux supports for LEDs, avoid using names like activity or link, rather describe the location on the RJ-45, of what the RJ-45 is expected to be used for, WAN/LAN etc. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Signed-off-by:
-
Andrew Lunn authored
The WAN port of the 370-RD has a Marvell PHY, with one LED on the front panel.y List this LED in the device tree. Signed-off-by:
-
Christian Marangi authored
Document support for LEDs node in phy and add an example for it. PHY LED will have to match led pattern and should be treated as a generic led. Signed-off-by:
-
Christian Marangi authored
Add Switch LED for each port for MikroTik RB3011UiAS-RM. MikroTik RB3011UiAS-RM is a 10 port device with 2 qca8337 switch chips connected. It was discovered that in the hardware design all 3 Switch LED trace of the related port is connected to the same LED. This was discovered by setting to 'always on' the related led in the switch regs and noticing that all 3 LED for the specific port (for example for port 1) cause the connected LED for port 1 to turn on. As an extra test we tried enabling 2 different LED for the port resulting in the LED turned off only if every led in the reg was off. Aside from this funny and strange hardware implementation, the device itself have one green LED for each port, resulting in 10 green LED one for each of the 10 supported port. Cc: Jonathan McDowell <noodles@earth.li> Signed-off-by:
-
Christian Marangi authored
IPQ8064 MikroTik RB3011UiAS-RM DT have currently unevaluted properties in the 2 switch nodes. The bindings #address-cells and #size-cells are redundant and cause warning for 'Unevaluated properties are not allowed'. Drop these bindings to mute these warning as they should not be there from the start. Cc: Jonathan McDowell <noodles@earth.li> Signed-off-by:
Jonathan McDowell <noodles@earth.li> Tested-by:
-
Christian Marangi authored
Add LEDs definition example for qca8k Switch Family to describe how they should be defined for a correct usage. Signed-off-by:
-
Christian Marangi authored
Document support for LEDs node in ethernet-controller. Ethernet Controller may support different LEDs that can be configured for different operation like blinking on traffic event or port link. Also add some Documentation to describe the difference of these nodes compared to PHY LEDs, since ethernet-controller LEDs are controllable by the ethernet controller regs and the possible intergated PHY doesn't have control on them. Signed-off-by:
-
Andrew Lunn authored
The Marvell PHY can blink the LEDs, simple on/off. All LEDs blink at the same rate, and the reset default is 84ms per blink, which is around 12Hz. Signed-off-by:
-
Andrew Lunn authored
Linux LEDs can be requested to perform hardware accelerated blinking. Pass this to the PHY driver, if it implements the op. Signed-off-by:
-
Andrew Lunn authored
Add a brightness function, so the LEDs can be controlled from software using the standard Linux LED infrastructure. Signed-off-by:
-
Andrew Lunn authored
Linux LEDs can be software controlled via the brightness file in /sys. LED drivers need to implement a brightness_set function which the core will call. Implement an intermediary in phy_device, which will call into the phy driver if it implements the necessary function. Signed-off-by:
-
Andrew Lunn authored
Define common binding parsing for all PHY drivers with LEDs using phylib. Parse the DT as part of the phy_probe and add LEDs to the linux LED class infrastructure. For the moment, provide a dummy brightness function, which will later be replaced with a call into the PHY driver. This allows testing since the LED core might otherwise reject an LED whose brightness cannot be set. Add a dependency on LED_CLASS. It either needs to be built in, or not enabled, since a modular build can result in linker errors. Signed-off-by:
-
Andrew Lunn authored
Provide stubs for devm_led_classdev_register_ext() and led_init_default_state_get() so that LED drivers embedded within other drivers such as PHYs and Ethernet switches still build when LEDS_CLASS or NEW_LEDS are disabled. This also helps with Kconfig dependencies, which are somewhat hairy for phylib and mdio and only get worse when adding a dependency on LED_CLASS. Signed-off-by:
-
Christian Marangi authored
Add LEDs blink_set() support to qca8k Switch Family. These LEDs support hw accellerated blinking at a fixed rate of 4Hz. Reject any other value since not supported by the LEDs switch. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Reviewed-by:
-
Christian Marangi authored
Add LEDs basic support for qca8k Switch Family by adding basic brightness_set() support. Since these LEDs refelect port status, the default label is set to ":port". DT binding should describe the color and function of the LEDs using standard LEDs api. Each LED always have the device name as prefix. The device name is composed from the mii bus id and the PHY addr resulting in example names like: - qca8k-0.0:00:amber:lan - qca8k-0.0:00:white:lan - qca8k-0.0:01:amber:lan - qca8k-0.0:01:white:lan These LEDs supports only blocking variant of the brightness_set() function since they can sleep during access of the switch leds to set the brightness. While at it add to the qca8k header file each mode defined by the Switch Documentation for future use. Signed-off-by:
-
Christian Marangi authored
Move qca8k_port_to_phy() to qca8k header as it's useful for future reference in Switch LEDs module since the same logic is applied to get the right index of the switch port. Make it inline as it's simple function that just decrease the port. Signed-off-by:
Michal Kubiak <michal.kubiak@intel.com> Reviewed-by:
-
Jaime Breva authored
Our use-case needs two AT ports available: One for running a ppp daemon, and another one for management This patch enables a second AT port on DATA1 Signed-off-by:
Jaime Breva <jbreva@nayarsystems.com> Signed-off-by:
-
David S. Miller authored
Tariq Toukan says: ==================== net/mlx5e: Extend XDP multi-buffer capabilities This series extends the XDP multi-buffer support in the mlx5e driver. Patchset breakdown: - Infrastructural changes and preparations. - Add XDP multi-buffer support for XDP redirect-in. - Use TX MPWQE (multi-packet WQE) HW feature for non-linear single-segmented XDP frames. - Add XDP multi-buffer support for striding RQ. In Striding RQ, we overcome the lack of headroom and tailroom between the RQ strides by allocating a side page per packet and using it for the xdp_buff descriptor. We structure the xdp_buff so that it contains nothing in the linear part, and the whole packet resides in the fragments. Performance highlight: Packet rate test, 64 bytes, 32 channels, MTU 9000 bytes. CPU: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz. NIC: ConnectX-6 Dx, at 100 Gbps. +----------+-------------+-------------+---------+ | Test | Legacy RQ | Striding RQ | Speedup | +----------+-------------+-------------+---------+ | XDP_DROP | 101,615,544 | 117,191,020 | +15% | +----------+-------------+-------------+---------+ | XDP_TX | 95,608,169 | 117,043,422 | +22% | +----------+-------------+-------------+---------+ Series generated against net commit: e61caf04 Merge branch 'page_pool-allow-caching-from-safely-localized-napi' I'm submitting this directly as Saeed is traveling. ==================== Signed-off-by:
-
Tariq Toukan authored
Here we add support for multi-buffer XDP handling in Striding RQ, which is our default out-of-the-box RQ type. Before this series, loading such an XDP program would fail, until you switch to the legacy RQ (by unsetting the rx_striding_rq priv-flag). To overcome the lack of headroom and tailroom between the strides, we allocate a side page to be used for the descriptor (xdp_buff / skb) and the linear part. When an XDP program is attached, we structure the xdp_buff so that it contains no data in the linear part, and the whole packet resides in the fragments. In case of XDP_PASS, where an SKB still needs to be created, we copy up to 256 bytes to its linear part, to match the current behavior, and satisfy functions that assume finding the packet headers in the SKB linear part (like eth_type_trans). Performance testing: Packet rate test, 64 bytes, 32 channels, MTU 9000 bytes. CPU: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz. NIC: ConnectX-6 Dx, at 100 Gbps. +----------+-------------+-------------+---------+ | Test | Legacy RQ | Striding RQ | Speedup | +----------+-------------+-------------+---------+ | XDP_DROP | 101,615,544 | 117,191,020 | +15% | +----------+-------------+-------------+---------+ | XDP_TX | 95,608,169 | 117,043,422 | +22% | +----------+-------------+-------------+---------+ Reviewed-by:
Saeed Mahameed <saeedm@nvidia.com> Signed-off-by:
Tariq Toukan <tariqt@nvidia.com> Signed-off-by:
-
Tariq Toukan authored
In preparation for supporting XDP multi-buffer in striding RQ, use xdp_buff struct to describe the packet. Make its skb_shared_info collide the one of the allocated SKB, then add the fragments using the xdp_buff API. Signed-off-by:
-
Tariq Toukan authored
Make the function more generic. Let it get an additional frame_sz parameter instead of deriving it from the RQ struct. No functional change here, just a preparation for a downstream patch. Reviewed-by:
-
Tariq Toukan authored
Introduce mlx5e_add_skb_shared_info_frag(), a function dedicated for adding a fragment into a struct skb_shared_info object. Use it in the Legacy RQ flow. Similar usage will be added in a downstream patch by the corresponding Striding RQ flow. Reviewed-by:
-
Tariq Toukan authored
Under a few restrictions, TX MPWQE feature can serve multiple TX packets in a single TX descriptor. It requires each of the packets to have a single scatter entry / segment. Today we allow only linear frames to use this feature, although there's no real problem with non-linear ones where the whole packet reside in the first fragment. Expand the XDP TX MPWQE feature support to include such frames. This is in preparation for the downstream patch, in which we will generate such non-linear frames. Signed-off-by:
-
Tariq Toukan authored
Remove the assumption of non-zero linear length in the XDP xmit function, used to serve both internal XDP_TX operations as well as redirected-in requests. Do not apply the MLX5E_XDP_MIN_INLINE check unless necessary. Reviewed-by:
-
Tariq Toukan authored
Function mlx5e_rx_get_linear_stride_sz() returns PAGE_SIZE immediately in case an XDP program is attached. The more accurate formula is ALIGN(sz, PAGE_SIZE), to prevent two packets from residing on the same page. The assumption behind the current code is that sz <= PAGE_SIZE holds for all cases with XDP program set. This is true because it is being called from: - 3 times from Striding RQ flows, in which XDP is not supported for such large packets. - 1 time from Legacy RQ flow, under the condition mlx5e_rx_is_linear_skb(). No functional change here, just removing the implied assumption in preparation for supporting XDP multi-buffer in Striding RQ. Reviewed-by:
-
Tariq Toukan authored
Change mlx5e_xdp_allowed() so it gets the params structure with the xdp_prog applied, rather than creating a local copy based on the current params in priv. This reduces the amount of memory on the stack, and acts on the exact params instance that's about to be applied. Reviewed-by:
-
Tariq Toukan authored
Non-linear mem scheme of Striding RQ does not yet support XDP at this point. Take the check where it belongs, inside the params validation function mlx5e_params_validate_xdp(). Reviewed-by:
Gal Pressman <gal@nvidia.com> Reviewed-by:
-
Tariq Toukan authored
Handle multi-buffer XDP redirect-in requests coming through mlx5e_xdp_xmit. Extend struct mlx5e_xmit_data_frags with an additional dma_arr field, to point to the fragments dma mapping, as they cannot be retrieved via the page_pool_get_dma_addr() function. Push a dma_addr xdpi instance per each fragment, and use them in the completion flow to dma_unmap the frags. Finally, remove the restriction in mlx5e_open_xdpsq, and set the flag in xdp_features. Reviewed-by:
-
Tariq Toukan authored
Here we fix the current wi->num_pkts abuse, as it was used to indicate multiple xdpi entries in the xdpi_fifo. Instead, reduce mlx5e_xdp_info to the size of a single field, making it a union of unions. Per packet, use as many instances as needed to provide the information needed at the time of completion. The sequence of xdpi instances pushed is well defined, derived by the xmit_mode. Reviewed-by:
-
Tariq Toukan authored
It is not likely nor unlikely that the xdp buff has fragments, it depends on the program loaded and size of the packet received. Reviewed-by:
-
Tariq Toukan authored
Introduce struct mlx5e_xmit_data_frags to be used for non-linear xmit buffers. Let it include sinfo pointer. Take one bit from the len field to indicate if the descriptor has fragments and can be casted-up into the extended version. Zero-init to make sure has_frags, and potentially future fields, are zero when not explicitly assigned. Another field will be added in a downstream patch to indicate and point to dma addresses of the different frags, for redirect-in requests. This simplifies the mlx5e_xmit_xdp_frame/mlx5e_xmit_xdp_frame_mpwqe functions params. Signed-off-by:
-
Tariq Toukan authored
Move TX datapath struct from the generic en.h to the datapath txrx.h header, where it belongs. Reviewed-by:
-
Tariq Toukan authored
Move struct mlx5e_xdp_info and enum mlx5e_xdp_xmit_mode from the generic en.h to the XDP header, where they belong. Reviewed-by:
-
Alain Volmat authored
Remove no more supported platforms (stih415/stih416 and stid127) Signed-off-by:
Alain Volmat <avolmat@me.com> Acked-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20230416195523.61075-1-avolmat@me.comSigned-off-by:
-
Arnd Bergmann authored
The types for the register argument changed recently, but there are still incompatible prototypes that got left behind, and gcc-13 warns about these: In file included from drivers/net/ethernet/mscc/ocelot.c:13: drivers/net/ethernet/mscc/ocelot.h:97:5: error: conflicting types for 'ocelot_port_readl' due to enum/integer mismatch; have 'u32(struct ocelot_port *, u32)' {aka 'unsigned int(struct ocelot_port *, unsigned int)'} [-Werror=enum-int-mismatch] 97 | u32 ocelot_port_readl(struct ocelot_port *port, u32 reg); | ^~~~~~~~~~~~~~~~~ Just remove the two prototypes, and rely on the copy in the global header. Fixes: 9ecd0579 ("net: mscc: ocelot: strengthen type of "u32 reg" in I/O accessors") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20230417205531.1880657-1-arnd@kernel.orgSigned-off-by:
-
Corinna Vinschen authored
stmmac_dev_probe doesn't propagate feature flags to VLANs. So features like offloading don't correspond with the general features and it's not possible to manipulate features via ethtool -K to affect VLANs. Propagate feature flags to vlan features. Drop TSO feature because it does not work on VLANs yet. Signed-off-by:
Corinna Vinschen <vinschen@redhat.com> Link: https://lore.kernel.org/r/20230417192845.590034-1-vinschen@redhat.comSigned-off-by:
-
Hangbin Liu authored
Currently, bonding only obtain the timestamp (ts) information of the active slave, which is available only for modes 1, 5, and 6. For other modes, bonding only has software rx timestamping support. However, some users who use modes such as LACP also want tx timestamp support. To address this issue, let's check the ts information of each slave. If all slaves support tx timestamping, we can enable tx timestamping support for the bond. Add a note that the get_ts_info may be called with RCU, or rtnl or reference on the device in ethtool.h> Suggested-by:
Miroslav Lichvar <mlichvar@redhat.com> Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Acked-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Link: https://lore.kernel.org/r/20230418034841.2566262-1-liuhangbin@gmail.comSigned-off-by:
-
