- 01 Jun, 2023 14 commits
-
-
Jakub Kicinski authored
Mengyuan Lou says: ==================== Wangxun netdev features support Implement tx_csum and rx_csum to support hardware checksum offload. Implement ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid. Implement ndo_set_features. Enable macros in netdev features which wangxun can support. ==================== Link: https://lore.kernel.org/r/20230530022632.17938-1-mengyuanlou@net-swift.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Mengyuan Lou authored
txgbe add ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid. Signed-off-by:
Mengyuan Lou <mengyuanlou@net-swift.com> Signed-off-by:
-
Mengyuan Lou authored
Add features and hw_features that ngbe can support. Signed-off-by:
-
Mengyuan Lou authored
ngbe add ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid. Signed-off-by:
-
Mengyuan Lou authored
Add features and hw_features that ngbe can support. Signed-off-by:
-
Mengyuan Lou authored
Implement wx_set_features function which to support ndo_set_features. Signed-off-by:
-
Mengyuan Lou authored
Implement vlan add/kill functions which add and remove vlan id in hardware. Signed-off-by:
-
Mengyuan Lou authored
Add rx offload functions for wx_clean_rx_irq which supports ngbe and txgbe to implement rx offload function. Signed-off-by:
-
Mengyuan Lou authored
Add tx offload functions for wx_xmit_frame_ring which includes wx_encode_tx_desc_ptype, wx_tso and wx_tx_csum. which supports ngbe and txgbe to implement tx offload function. Signed-off-by:
-
Jakub Kicinski authored
Devlink health is involved in error recovery. Machines in bad state tend to be fairly unreliable, and occasionally get stuck in error loops. Even with a reasonable grace period devlink health may get a thousand reports in an hour. In case of reporting on an unregistered devlink instance the subsequent reports don't add much value. Switch to WARN_ON_ONCE() to avoid flooding dmesg and fleet monitoring dashboards. Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20230531015523.48961-1-kuba@kernel.orgSigned-off-by:
-
Jakub Kicinski authored
Harini Katakam says: ==================== Add support for VSC85xx DT RGMII delays Provide an option to change RGMII delay value via devicetree. ==================== Link: https://lore.kernel.org/r/20230529122017.10620-1-harini.katakam@amd.comSigned-off-by:
-
Harini Katakam authored
Add support for optional rx/tx-internal-delay-ps from devicetree. - When rx/tx-internal-delay-ps is/are specified, these take priority - When either is absent, 1) use 2ns for respective settings if rgmii-id/rxid/txid is/are present 2) use 0.2ns for respective settings if mode is rgmii Signed-off-by:
Harini Katakam <harini.katakam@amd.com> Signed-off-by:
-
Harini Katakam authored
All the PHY devices variants specified have the same mask and hence can be simplified to one vendor look up for 0x00070400. Any individual config can be identified by PHY_ID_MATCH_EXACT in the respective structure. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Heiner Kallweit authored
If PREEMPT_RT is set, then assume that the user focuses on minimum latency. Therefore don't set sw irq coalescing defaults. This affects the defaults only, users can override these settings via sysfs. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/f9439c7f-c92c-4c2c-703e-110f96d841b7@gmail.comSigned-off-by:
-
- 31 May, 2023 26 commits
-
-
David S. Miller authored
Vladimir Oltean says: ==================== xstats for tc-taprio As a result of this discussion: https://lore.kernel.org/intel-wired-lan/20230411055543.24177-1-muhammad.husaini.zulkifli@intel.com/ it became apparent that tc-taprio should make an effort to standardize statistics counters related to the 802.1Qbv scheduling as implemented by the NIC. I'm presenting here one counter suggested by the standard, and one counter defined by the NXP ENETC controller from LS1028A. Both counters are reported globally and per traffic class - drivers get different callbacks for reporting both of these, and get to choose what to report in both cases. The iproute2 counterpart is available here for testing: https://github.com/vladimiroltean/iproute2/commits/taprio-xstats ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
Report the "win_drop" counter from the unstructured ethtool -S as TCA_TAPRIO_OFFLOAD_STATS_WINDOW_DROPS to the Qdisc layer. It is available both as a global counter as well as a per-TC one. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
Make enetc_setup_tc_taprio() more amenable to future extensions, like reporting statistics. Signed-off-by:
-
Vladimir Oltean authored
Offloading drivers may report some additional statistics counters, some of them even suggested by 802.1Q, like TransmissionOverrun. In my opinion we don't have to limit ourselves to reporting counters only globally to the Qdisc/interface, especially if the device has more detailed reporting (per traffic class), since the more detailed info is valuable for debugging and can help identifying who is exceeding its time slot. But on the other hand, some devices may not be able to report both per TC and global stats. So we end up reporting both ways, and use the good old ethtool_put_stat() strategy to determine which statistics are supported by this NIC. Statistics which aren't set are simply not reported to netlink. For this reason, we need something dynamic (a nlattr nest) to be reported through TCA_STATS_APP, and not something daft like the fixed-size and inextensible struct tc_codel_xstats. A good model for xstats which are a nlattr nest rather than a fixed struct seems to be cake. # Global stats $ tc -s qdisc show dev eth0 root # Per-tc stats $ tc -s class show dev eth0 Signed-off-by:
Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by:
-
Vladimir Oltean authored
Inspired from struct flow_cls_offload :: cmd, in order for taprio to be able to report statistics (which is future work), it seems that we need to drill one step further with the ndo_setup_tc(TC_SETUP_QDISC_TAPRIO) multiplexing, and pass the command as part of the common portion of the muxed structure. Since we already have an "enable" variable in tc_taprio_qopt_offload, refactor all drivers to check for "cmd" instead of "enable", and reject every other command except "replace" and "destroy" - to be future proof. Signed-off-by:
Muhammad Husaini Zulkifli <muhammad.husaini.zulkifli@intel.com> Reviewed-by:
Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by:
-
Vladimir Oltean authored
In taprio_dump_class_stats() we don't need a reference to the root Qdisc once we get the reference to the child corresponding to this traffic class, so it's okay to overwrite "sch". But in a future patch we will need the root Qdisc too, so create a dedicated "child" pointer variable to hold the child reference. This also makes the code adhere to a more conventional coding style. Signed-off-by:
-
David S. Miller authored
Lukasz Majewski says: ==================== dsa: marvell: Add support for mv88e6071 and 6020 switches After the commit (SHA1: 7e951737); "net: dsa: mv88e6xxx: fix max_mtu of 1492 on 6165, 6191, 6220, 6250, 6290" the error when mv88e6020 or mv88e6071 is used is not present anymore. As a result patches for adding max frame size are not required to provide working setup with aforementioned switches. ==================== Signed-off-by:
-
Lukasz Majewski authored
A mv88e6250 family switch with 5 internal PHYs, 2 RMIIs and no PTP support. Signed-off-by:
Lukasz Majewski <lukma@denx.de> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Matthias Schiffer authored
A mv88e6250 family switch with 2 PHY and RMII ports and no PTP support. Signed-off-by:
Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Signed-off-by:
-
Lukasz Majewski authored
Switches from mv88e6250 family (including mv88e6020 and mv88e6071) need the possibility to setup the maximal frame size, as they support frames up to 2048 bytes. Signed-off-by:
-
Uwe Kleine-König authored
After commit b8a1a4cd ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f4 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
-
Parav Pandit authored
tcp_gro_complete() function only updates the skb fields related to GRO and it always returns zero. All the 3 drivers which are using it do not check for the return value either. Change it to return void instead which simplifies its callers as error handing becomes unnecessary. Signed-off-by:
Parav Pandit <parav@nvidia.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
David S. Miller authored
Christian Marangi says: ==================== leds: introduce new LED hw control APIs Since this series is cross subsystem between LED and netdev, a stable branch was created to facilitate merging process. This is based on top of branch ib-leds-netdev-v6.5 present here [1] and rebased on top of net-next since the LED stable branch got merged. This is a continue of [2]. 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 is the main part of the series, the one that actually implement the hw control API. Some history about this feature and why ======================================= This proposal is highly requested by the entire net community but the API is not strictly designed for net usage but for a more generic usage. Initial version were very flexible and designed to try to support every aspect of the LED driver with many complex function that served multiple purpose. There was an idea to have sw only and hw only LEDs and sw only and hw only LEDs. With some heads up from Andrew from the net mailing list, it was suggested to implement a more basic yet easy to implement system. These API strictly work with a designated trigger to offload their function. This may be confused with hw blink offload but LED may have an even more advanced configuration where the entire aspect of the trigger is offloaded and completely handled by the hardware. An example of this usage are PHY or switch port LEDs. Almost every of these kind of device have multiple LED attached and provide info of the current port state. Currently we lack any support of them but these device always provide a way to configure them, from basic feature like turning the LED off or no (implemented in previous series related to this feature) or even entirely driven by the hw and power on/off/blink based on some events, like tx/rx traffic, ethernet cable attached, link speed of 10mbps, 100mbps, 1000mbps or more. They can also support multiple logic like blink with traffic only if a particular link speed is attached. (an example of this is when a LED is designated to be turned on only with 100mbps link speed and configured to blink on traffic and a secondary LED of a different color is present to serve the same function but only when the link speed is 1000mbps) These case are very common for a PHY or a switch but they were never standardized so OEM support all kind of variant and configuration. Again with Andrew we compared some feature and we reached a common set of modes that are for sure present in every kind of devices. And this concludes history and why. What is present in this series ============================== This patch contain the required API to support this feature, I decided on the name of hw control to quickly describe this feature. I documented each require API in the related Documentation for leds-class so I think it might me redundant to expose them here. Feel free to tell me how to improve it if anything is not clear. On an abstract idea, this feature require this: - The trigger needs to make use of it, this is currently implemented for the netdev trigger but other trigger can be expanded if the device expose these function. An idea might be a anything that handle a storage disk and have the LED configurable to blink when there is any activity to the disk. - The LED driver needs to expose and implement these new API. Currently a LED driver supports only a trigger. The trigger should use the related helper to check if the LED can be driven hy hardware. The different modes a trigger support are exposed in the kernel include leds.h header and are used by the LED driver to understand what to do. From a user standpoint, he should enable modes as usual from sysfs and if anything is not supported warned. Final words and missing piece from this series ============================================== I honestly hope this feature can finally be implemented. This series originally had also additional modes and logic to add to the netdev trigger, but I decided to strip them and implement only the API and support basic tx and rx. After this is merged, I will quickly propose these additional modes. Currently this is limited to tx and rx and this is what the current user qca8k use. Marvell PHY support link and a generic blink with any kind of traffic (both rx and tx). qca8k switch supports keeping the LED on based on link speed. The next series will add the concept of hw control only modes to the netdev trigger and support for these additional modes: - link_10 - link_100 - link_1000 - activity The current implementation is voluntary basic and limited to put the ground work and have something easy to implement and usable. 99% part of the logic is done on the trigger side, leaving to the LED driver only the validating and the apply part. As shown for the PHY led binding, people are really intrested in this feature as quickly after they were merged, people were already working on adding support for it. [1] https://git.kernel.org/pub/scm/linux/kernel/git/lee/leds.git/?h=ib-leds-netdev-6.5 [2] https://lore.kernel.org/lkml/20230216013230.22978-1-ansuelsmth@gmail.com/ Changes in v4: - Added review tag from Andrew. - Move default interval to a define to keep them synced. - Apply suggested reword to improve Documentation rst. Changes in v3: - Rebased on top of net-next Changes in v2: - Drop helper as currently used only by one trigger - Improve Documentation and document return error of some functions - Squash some patch to reduce series size - Drop trigger mode mask as currently not used - Rework hw control validating function to a simple implementation Changes from previous v8 series: - Rewrite Documentation from scratch and move to separate commit - Strip additional trigger modes (to propose in a different series) - Strip from qca8k driver additional modes (to implement in the different series) - Split the netdev chages to smaller piece to permit easier review Changelog in the previous v8 series: (stripped of unrelated changes) v8: - Improve the documentation of the new feature - Rename to a more symbolic name - Fix some bug in netdev trigger (not using BIT()) - Add more define for qca8k-leds driver - Drop interval support - Fix many bugs in the validate option in the netdev trigger v7: - Fix qca8k leds documentation warning - Remove RFC tag v6: - Back to RFC. - Drop additional trigger - Rework netdev trigger to support common modes used by switch and hardware only triggers - Refresh qca8k leds logic and driver v5: - Move out of RFC. (no comments from Andrew this is the right path?) - Fix more spelling mistake (thx Randy) - Fix error reported by kernel test bot - Drop the additional HW_CONTROL flag. It does simplify CONFIG handling and hw control should be available anyway to support triggers as module. v4: - Rework implementation and drop hw_configure logic. We now expand blink_set. - Address even more spelling mistake. (thx a lot Randy) - Drop blink option and use blink_set delay. v3: - Rework start/stop as Andrew asked. - Use test_bit API to check flag passed to hw_control_configure. - Added a new cmd to hw_control_configure to reset any active blink_mode. - Refactor all the patches to follow this new implementation. v2: - Fix spelling mistake (sorry) - Drop patch 02 "permit to declare supported offload triggers". Change the logic, now the LED driver declare support for them using the configure_offload with the cmd TRIGGER_SUPPORTED. - Rework code to follow this new implementation. - Update Documentation to better describe how this offload implementation work. ==================== Signed-off-by: -
Andrew Lunn authored
In order that the LED trigger can blink the switch MAC ports LED, it needs to know the netdev associated to the port. Add the callback to return the struct device of the netdev. Add an helper function qca8k_phy_to_port() to convert the phy back to dsa_port index, as we reference LED port based on the internal PHY index and needs to be converted back. Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Signed-off-by:
-
Christian Marangi authored
Implement hw_control ops to drive Switch LEDs based on hardware events. Netdev trigger is the declared supported trigger for hw control operation and supports the following mode: - tx - rx When hw_control_set is called, LEDs are set to follow the requested mode. Each LEDs will blink at 4Hz by default. Signed-off-by:
-
Christian Marangi authored
Expose netdev trigger modes to make them accessible by LED driver that will support netdev trigger for hw control. Signed-off-by:
-
Christian Marangi authored
On netdev trigger activation, hw control may be already active by default. If this is the case and a device is actually provided by hw_control_get_device(), init the already active mode and set the bool to hw_control bool to true to reflect the already set mode in the trigger_data. Co-developed-by:
-
Andrew Lunn authored
The netdev which the LED should blink for is configurable in /sys/class/led/foo/device_name. Ensure when offloading that the configured netdev is the same as the netdev the LED is associated with. If it is not, only perform software blinking. Signed-off-by:
-
Christian Marangi authored
Add support for LED hw control for the netdev trigger. The trigger on calling set_baseline_state to configure a new mode, will do various check to verify if hw control can be used for the requested mode in can_hw_control() function. It will first check if the LED driver supports hw control for the netdev trigger, then will use hw_control_is_supported() and finally will call hw_control_set() to apply the requested mode. To use such mode, interval MUST be set to the default value and net_dev MUST be set. If one of these 2 value are not valid, hw control will never be used and normal software fallback is used. The default interval value is moved to a define to make sure they are always synced. Signed-off-by:
-
Christian Marangi authored
Reject interval store with hw_control enabled. It's are currently not supported and MUST be set to the default value with hw control enabled. Signed-off-by:
-
Christian Marangi authored
Add basic check for hw control support. Check if the required API are defined and check if the defined trigger supported in hw control for the LED driver match netdev. Signed-off-by:
-
Christian Marangi authored
Introduce function to check if the requested mode can use hw control in preparation for hw control support. Currently everything is handled in software so can_hw_control will always return false. Add knob with the new value hw_control in trigger_data struct to set hw control possible. Useful for future implementation to implement in set_baseline_state() the required function to set the requested mode using LEDs hw control ops and in other function to reject set if hw control is currently active. Signed-off-by:
-
Andrew Lunn authored
Move the code into a helper, ready for it to be called at other times. No intended behaviour change. Signed-off-by:
-
Christian Marangi authored
Document new Hardware driven LEDs APIs. Some LEDs can be programmed to be driven by hardware. This is not limited to blink but also to turn off or on autonomously. To support this feature, a LED needs to implement various additional ops and needs to declare specific support for the supported triggers. Add documentation for each required value and API to make hw control possible and implementable by both LEDs and triggers. Signed-off-by:
-
Andrew Lunn authored
Some specific LED triggers blink the LED based on events from a device or subsystem. For example, an LED could be blinked to indicate a network device is receiving packets, or a disk is reading blocks. To correctly enable and request the hw control of the LED, the trigger has to check if the network interface or block device configured via a /sys/class/led file match the one the LED driver provide for hw control for. Provide an API call to get the device which the LED blinks for. Signed-off-by:
-
Christian Marangi authored
Add an option to permit LED driver to declare support for a specific trigger to use hw control and setup the LED to blink based on specific provided modes. Add APIs for LEDs hw control. These functions will be used to activate hardware control where a LED will use the provided flags, from an unique defined supported trigger, to setup the LED to be driven by hardware. Add hw_control_is_supported() to ask the LED driver if the requested mode by the trigger are supported and the LED can be setup to follow the requested modes. Deactivate hardware blink control by setting brightness to LED_OFF via the brightness_set() callback. Signed-off-by:
-
