- 24 Jan, 2023 3 commits
-
-
Jakub Kicinski authored
Merge tag 'wireless-next-2023-01-23' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.3 First set of patches for v6.3. The most important change here is that the old Wireless Extension user space interface is not supported on Wi-Fi 7 devices at all. We also added a warning if anyone with modern drivers (ie. cfg80211 and mac80211 drivers) tries to use Wireless Extensions, everyone should switch to using nl80211 interface instead. Static WEP support is removed, there wasn't any driver using that anyway so there's no user impact. Otherwise it's smaller features and fixes as usual. Note: As mt76 had tricky conflicts due to the fixes in wireless tree, we decided to merge wireless into wireless-next to solve them easily. There should not be any merge problems anymore. Major changes: cfg80211 - remove never used static WEP support - warn if Wireless Extention interface is used with cfg80211/mac80211 drivers - stop supporting Wireless Extensions with Wi-Fi 7 devices - support minimal Wi-Fi 7 Extremely High Throughput (EHT) rate reporting rfkill - add GPIO DT support bitfield - add FIELD_PREP_CONST() mt76 - per-PHY LED support rtw89 - support new Bluetooth co-existance version rtl8xxxu - support RTL8188EU * tag 'wireless-next-2023-01-23' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (123 commits) wifi: wireless: deny wireless extensions on MLO-capable devices wifi: wireless: warn on most wireless extension usage wifi: mac80211: drop extra 'e' from ieeee80211... name wifi: cfg80211: Deduplicate certificate loading bitfield: add FIELD_PREP_CONST() wifi: mac80211: add kernel-doc for EHT structure mac80211: support minimal EHT rate reporting on RX wifi: mac80211: Add HE MU-MIMO related flags in ieee80211_bss_conf wifi: mac80211: Add VHT MU-MIMO related flags in ieee80211_bss_conf wifi: cfg80211: Use MLD address to indicate MLD STA disconnection wifi: cfg80211: Support 32 bytes KCK key in GTK rekey offload wifi: cfg80211: Fix extended KCK key length check in nl80211_set_rekey_data() wifi: cfg80211: remove support for static WEP wifi: rtl8xxxu: Dump the efuse only for untested devices wifi: rtl8xxxu: Print the ROM version too wifi: rtw88: Use non-atomic sta iterator in rtw_ra_mask_info_update() wifi: rtw88: Use rtw_iterate_vifs() for rtw_vif_watch_dog_iter() wifi: rtw88: Move register access from rtw_bf_assoc() outside the RCU wifi: rtl8xxxu: Use a longer retry limit of 48 wifi: rtl8xxxu: Report the RSSI to the firmware ... ==================== Link: https://lore.kernel.org/r/20230123103338.330CBC433EF@smtp.kernel.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Krzysztof Kozlowski authored
The AX88796C device node on SPI bus can use SPI peripheral properties in certain configurations: exynos3250-artik5-eval.dtb: ethernet@0: 'controller-data' does not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230120144329.305655-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Eric Dumazet authored
In commit 72653ae5 ("selftests: net: tcp_mmap: Use huge pages in send path") I made a change to use hugepages for the buffer used by the client (tx path) Today, I understood that the cause for poor zerocopy performance was that after a mmap() for a 512KB memory zone, kernel uses a single zeropage, mapped 128 times. This was really the reason for poor tx path performance in zero copy mode, because this zero page refcount is under high pressure, especially when TCP ACK packets are processed on another cpu. We need either to force a COW on all the memory range, or use MAP_POPULATE so that a zero page is not abused. Signed-off-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20230120181136.3764521-1-edumazet@google.comSigned-off-by:
-
- 23 Jan, 2023 23 commits
-
-
Heiner Kallweit authored
Use devm_clk_get_enabled() to simplify the code. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Andy Shevchenko authored
Replace open coded fwnode_device_is_compatible() in the driver. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
-
David S. Miller authored
Signed-off-by: -
David S. Miller authored
Vladimir Oltean says: ==================== ENETC MAC Merge cleanup This is a preparatory patch set for MAC Merge layer support in enetc via ethtool. It does the following: - consolidates a software lockstep register write procedure for the pMAC - detects per-port frame preemption capability and only writes pMAC registers if a pMAC exists - stops enabling the pMAC by default Additionally, I noticed some build warnings in the driver which are new in this kernel version, so patch 1/6 fixes those. ==================== Signed-off-by: -
Vladimir Oltean authored
The pMAC (ENETC_PFPMR_PMACE) is probably unconditionally enabled in the enetc driver to allow RX of preemptible packets and not see them as error frames. I don't know why TX preemption (ENETC_MMCSR_ME) is enabled though. With no way to say which traffic classes are preemptible (all are express by default), no preemptible frames would be transmitted anyway. Lastly, it may have been believed that the register write lock-step mode (now deleted) needed the pMAC to be enabled at all times. I don't know if that's true. However, I've checked that driver writes to PM1 registers do propagate through to the ENETC IP even when the pMAC is disabled. With such incomplete support for frame preemption, it's best to just remove whatever exists right now and come with something more coherent later. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
Currently the enetc driver duplicates its writes to the PM0 registers also to PM1, but it doesn't do this consistently - for example we write to ENETC_PM0_MAXFRM but not to ENETC_PM1_MAXFRM. Create enetc_port_mac_wr() which writes both the PM0 and PM1 register with the same value (if frame preemption is supported on this port). Also create enetc_port_mac_rd() which reads from PM0 - the assumption being that PM1 contains just the same value. This will be necessary when we enable the MAC Merge layer properly, and the pMAC becomes operational. Signed-off-by:
-
Vladimir Oltean authored
The MWLM bit (MAC write lock-step mode) allows register writes to the pMAC to be auto-performed whenever the corresponding eMAC register is written by the driver. This allows their configuration to remain in sync. The driver has set this bit since the initial commit, but it doesn't do anything, since the hardware feature doesn't work (and the bit has been removed from more recent versions of the documentation). The driver does attempt, more or less, to keep those MAC registers in sync by writing the same value once to e.g. ENETC_PM0_CMD_CFG (eMAC) and once to ENETC_PM1_CMD_CFG (pMAC). Because the lockstep feature doesn't work, that's what it will stick to. Signed-off-by:
-
Vladimir Oltean authored
This is a preliminary patch which replaces the hardcoded 0x1000 present in other PM1 (port MAC 1, aka pMAC) register definitions, which is an offset to the PM0 (port MAC 0, aka eMAC) equivalent register. This definition will be used in more places by future code. Signed-off-by:
-
Vladimir Oltean authored
Similar to other TSN features, query the Station Interface capability register to see whether preemption is supported on this port or not. On LS1028A, preemption is available on ports 0 and 2, but not on 1 and 3. This will allow us in the future to write the pMAC registers only on the ENETC ports where a pMAC actually exists. Signed-off-by:
-
Vladimir Oltean authored
The build system is complaining about the following: enetc.o is added to multiple modules: fsl-enetc fsl-enetc-vf enetc_cbdr.o is added to multiple modules: fsl-enetc fsl-enetc-vf enetc_ethtool.o is added to multiple modules: fsl-enetc fsl-enetc-vf Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== ethtool support for IEEE 802.3 MAC Merge layer Change log ---------- v3->v4: - add missing opening bracket in ocelot_port_mm_irq() - moved cfg.verify_time range checking so that it actually takes place for the updated rather than old value v3 at: https://patchwork.kernel.org/project/netdevbpf/cover/20230117085947.2176464-1-vladimir.oltean@nxp.com/ v2->v3: - made get_mm return int instead of void - deleted ETHTOOL_A_MM_SUPPORTED - renamed ETHTOOL_A_MM_ADD_FRAG_SIZE to ETHTOOL_A_MM_TX_MIN_FRAG_SIZE - introduced ETHTOOL_A_MM_RX_MIN_FRAG_SIZE - cleaned up documentation - rebased on top of PLCA changes - renamed ETHTOOL_STATS_SRC_* to ETHTOOL_MAC_STATS_SRC_* v2 at: https://patchwork.kernel.org/project/netdevbpf/cover/20230111161706.1465242-1-vladimir.oltean@nxp.com/ v1->v2: I've decided to focus just on the MAC Merge layer for now, which is why I am able to submit this patch set as non-RFC. v1 (RFC) at: https://patchwork.kernel.org/project/netdevbpf/cover/20220816222920.1952936-1-vladimir.oltean@nxp.com/ What is being introduced ------------------------ TL;DR: a MAC Merge layer as defined by IEEE 802.3-2018, clause 99 (interspersing of express traffic). This is controlled through ethtool netlink (ETHTOOL_MSG_MM_GET, ETHTOOL_MSG_MM_SET). The raw ethtool commands are posted here: https://patchwork.kernel.org/project/netdevbpf/cover/20230111153638.1454687-1-vladimir.oltean@nxp.com/ The MAC Merge layer has its own statistics counters (ethtool --include-statistics --show-mm swp0) as well as two member MACs, the statistics of which can be queried individually, through a new ethtool netlink attribute, corresponding to: $ ethtool -I --show-pause eno2 --src aggregate $ ethtool -S eno2 --groups eth-mac eth-phy eth-ctrl rmon -- --src pmac The core properties of the MAC Merge layer are described in great detail in patches 02/12 and 03/12. They can be viewed in "make htmldocs" format. Devices for which the API is supported -------------------------------------- I decided to start with the Ethernet switch on NXP LS1028A (Felix) because of the smaller patch set. I also have support for the ENETC controller pending. I would like to get confirmation that the UAPI being proposed here will not restrict any use cases known by other hardware vendors. Why is support for preemptible traffic classes not here? -------------------------------------------------------- There is legitimate concern whether the 802.1Q portion of the standard (which traffic classes go to the eMAC and which to the pMAC) should be modeled in Linux using tc or using another UAPI. I think that is stalling the entire series, but should be discussed separately instead. Removing FP adminStatus support makes me confident enough to submit this patch set without an RFC tag (meaning: I wouldn't mind if it was merged as is). What is submitted here is sufficient for an LLDP daemon to do its job. I've patched openlldp to advertise and configure frame preemption: https://github.com/vladimiroltean/openlldp/tree/frame-preemption-v3 In case someone wants to try it out, here are some commands I've used. # Configure the interfaces to receive and transmit LLDP Data Units lldptool -L -i eno0 adminStatus=rxtx lldptool -L -i swp0 adminStatus=rxtx # Enable the transmission of certain TLVs on switch's interface lldptool -T -i eno0 -V addEthCap enableTx=yes lldptool -T -i swp0 -V addEthCap enableTx=yes # Query LLDP statistics on switch's interface lldptool -S -i swp0 # Query the received neighbor TLVs lldptool -i swp0 -t -n -V addEthCap Additional Ethernet Capabilities TLV Preemption capability supported Preemption capability enabled Preemption capability active Additional fragment size: 60 octets So using this patch set, lldpad will be able to advertise and configure frame preemption, but still, no data packet will be sent as preemptible over the link, because there is no UAPI to control which traffic classes are sent as preemptible and which as express. Preemptable or preemptible? --------------------------- IEEE 802.3 uses "preemptable" throughout. IEEE 802.1Q uses "preemptible" throughout. Because the definition of "preemptible" falls under 802.1Q's jurisdiction and 802.3 just references it, I went with the 802.1Q naming even where supporting an 802.3 feature. Also, checkpatch agrees with this. ==================== Signed-off-by:
-
Vladimir Oltean authored
Felix (VSC9959) has a DEV_GMII:MM_CONFIG block composed of 2 registers (ENABLE_CONFIG and VERIF_CONFIG). Because the MAC Merge statistics and pMAC statistics are already in the Ocelot switch lib even if just Felix supports them, I'm adding support for the whole MAC Merge layer in the common Ocelot library too. There is an interrupt (shared with the PTP interrupt) which signals changes to the MM verification state. This is done because the preemptible traffic classes should be committed to hardware only once the verification procedure has declared the link partner of being capable of receiving preemptible frames. We implement ethtool getters and setters for the MAC Merge layer state. The "TX enabled" and "verify status" are taken from the IRQ handler, using a mutex to ensure serialized access. Signed-off-by:
-
Vladimir Oltean authored
The Felix VSC9959 switch supports frame preemption and has a MAC Merge layer. In addition to the structured stats that exist for the eMAC, export the counters associated with its pMAC (pause, RMON, MAC, PHY, control) plus the high-level MAC Merge layer stats. The unstructured ethtool counters, as well as the rtnl_link_stats64 were left to report only the eMAC counters. Because statistics processing is quite self-contained in ocelot_stats.c now, I've opted for introducing an ocelot->mm_supported bool, based on which the common switch lib does everything, rather than pushing the TSN-specific code in felix_vsc9959.c, as happens for other TSN stuff. Signed-off-by:
-
Vladimir Oltean authored
Some hardware instances of the ocelot driver support the MAC Merge layer, which gives access to an extra preemptible MAC. This has implications upon the statistics. There will be a stats layout when MM isn't supported, and a different one when it is. The ocelot_stats_layout() helper will return the correct one. In preparation of that, refactor the existing code to use this helper. Signed-off-by:
-
Vladimir Oltean authored
We will add support for pMAC counters and MAC merge layer counters, which are only reported via the structured stats, and the current ocelot_get_strings() stands in our way, because it expects that the statistics should be placed in the data array at the same index as found in the ocelot_stats_layout array. That is not true. Statistics which don't have a name should not be exported to the unstructured ethtool -S, so we need to have different indices into the ocelot_stats_layout array (i) and into the data array (data itself). Signed-off-by:
-
Vladimir Oltean authored
The DSA core is in charge of the ethtool_ops of the net devices associated with switch ports, so in case a hardware driver supports the MAC merge layer, DSA must pass the callbacks through to the driver. Add support for precisely that. Signed-off-by:
-
Vladimir Oltean authored
We deliberately make the Linux UAPI pass the minimum fragment size in octets, even though IEEE 802.3 defines it as discrete values, and addFragSize is just the multiplier. This is because there is nothing impossible in operating with an in-between value for the fragment size of non-final preempted fragments, and there may even appear hardware which supports the in-between sizes. For the hardware which just understands the addFragSize multiplier, create two helpers which translate back and forth the values passed in octets. Signed-off-by:
-
Vladimir Oltean authored
When a pMAC exists but the driver is unable to atomically query the aggregate eMAC+pMAC statistics, the user should be given back at least the sum of eMAC and pMAC counters queried separately. This is a generic problem, so add helpers in ethtool to do this operation, if the driver doesn't have a better way to report aggregate stats. Do this in a way that does not require changes to these functions when new stats are added (basically treat the structures as an array of u64 values, except for the first element which is the stats source). In include/linux/ethtool.h, there is already a section where helper function prototypes should be placed. The trouble is, this section is too early, before the definitions of struct ethtool_eth_mac_stats et.al. Move that section at the end and append these new helpers to it. Signed-off-by:
-
Vladimir Oltean authored
Two new netlink attributes were added to PAUSE_GET and STATS_GET and their replies. Document them. Signed-off-by:
-
Vladimir Oltean authored
IEEE 802.3-2018 clause 99 defines a MAC Merge sublayer which contains an Express MAC and a Preemptible MAC. Both MACs are hidden to higher and lower layers and visible as a single MAC (packet classification to eMAC or pMAC on TX is done based on priority; classification on RX is done based on SFD). For devices which support a MAC Merge sublayer, it is desirable to retrieve individual packet counters from the eMAC and the pMAC, as well as aggregate statistics (their sum). Introduce a new ETHTOOL_A_STATS_SRC attribute which is part of the policy of ETHTOOL_MSG_STATS_GET and, and an ETHTOOL_A_PAUSE_STATS_SRC which is part of the policy of ETHTOOL_MSG_PAUSE_GET (accepted when ETHTOOL_FLAG_STATS is set in the common ethtool header). Both of these take values from enum ethtool_mac_stats_src, defaulting to "aggregate" in the absence of the attribute. Existing drivers do not need to pay attention to this enum which was added to all driver-facing structures, just the ones which report the MAC merge layer as supported. Signed-off-by:
-
Vladimir Oltean authored
Show details about the structures passed back and forth related to MAC Merge layer configuration, state and statistics. The rendered htmldocs will be much more verbose due to the kerneldoc references. Signed-off-by:
-
Vladimir Oltean authored
The MAC merge sublayer (IEEE 802.3-2018 clause 99) is one of 2 specifications (the other being Frame Preemption; IEEE 802.1Q-2018 clause 6.7.2), which work together to minimize latency caused by frame interference at TX. The overall goal of TSN is for normal traffic and traffic with a bounded deadline to be able to cohabitate on the same L2 network and not bother each other too much. The standards achieve this (partly) by introducing the concept of preemptible traffic, i.e. Ethernet frames that have a custom value for the Start-of-Frame-Delimiter (SFD), and these frames can be fragmented and reassembled at L2 on a link-local basis. The non-preemptible frames are called express traffic, they are transmitted using a normal SFD, and they can preempt preemptible frames, therefore having lower latency, which can matter at lower (100 Mbps) link speeds, or at high MTUs (jumbo frames around 9K). Preemption is not recursive, i.e. a P frame cannot preempt another P frame. Preemption also does not depend upon priority, or otherwise said, an E frame with prio 0 will still preempt a P frame with prio 7. In terms of implementation, the standards talk about the presence of an express MAC (eMAC) which handles express traffic, and a preemptible MAC (pMAC) which handles preemptible traffic, and these MACs are multiplexed on the same MII by a MAC merge layer. To support frame preemption, the definition of the SFD was generalized to SMD (Start-of-mPacket-Delimiter), where an mPacket is essentially an Ethernet frame fragment, or a complete frame. Stations unaware of an SMD value different from the standard SFD will treat P frames as error frames. To prevent that from happening, a negotiation process is defined. On RX, packets are dispatched to the eMAC or pMAC after being filtered by their SMD. On TX, the eMAC/pMAC classification decision is taken by the 802.1Q spec, based on packet priority (each of the 8 user priority values may have an admin-status of preemptible or express). The MAC Merge layer and the Frame Preemption parameters have some degree of independence in terms of how software stacks are supposed to deal with them. The activation of the MM layer is supposed to be controlled by an LLDP daemon (after it has been communicated that the link partner also supports it), after which a (hardware-based or not) verification handshake takes place, before actually enabling the feature. So the process is intended to be relatively plug-and-play. Whereas FP settings are supposed to be coordinated across a network using something approximating NETCONF. The support contained here is exclusively for the 802.3 (MAC Merge) portions and not for the 802.1Q (Frame Preemption) parts. This API is sufficient for an LLDP daemon to do its job. The FP adminStatus variable from 802.1Q is outside the scope of an LLDP daemon. I have taken a few creative licenses and augmented the Linux kernel UAPI compared to the standard managed objects recommended by IEEE 802.3. These are: - ETHTOOL_A_MM_PMAC_ENABLED: According to Figure 99-6: Receive Processing state diagram, a MAC Merge layer is always supposed to be able to receive P frames. However, this implies keeping the pMAC powered on, which will consume needless power in applications where FP will never be used. If LLDP is used, the reception of an Additional Ethernet Capabilities TLV from the link partner is sufficient indication that the pMAC should be enabled. So my proposal is that in Linux, we keep the pMAC turned off by default and that user space turns it on when needed. - ETHTOOL_A_MM_VERIFY_ENABLED: The IEEE managed object is called aMACMergeVerifyDisableTx. I opted for consistency (positive logic) in the boolean netlink attributes offered, so this is also positive here. Other than the meaning being reversed, they correspond to the same thing. - ETHTOOL_A_MM_MAX_VERIFY_TIME: I found it most reasonable for a LLDP daemon to maximize the verifyTime variable (delay between SMD-V transmissions), to maximize its chances that the LP replies. IEEE says that the verifyTime can range between 1 and 128 ms, but the NXP ENETC stupidly keeps this variable in a 7 bit register, so the maximum supported value is 127 ms. I could have chosen to hardcode this in the LLDP daemon to a lower value, but why not let the kernel expose its supported range directly. - ETHTOOL_A_MM_TX_MIN_FRAG_SIZE: the standard managed object is called aMACMergeAddFragSize, and expresses the "additional" fragment size (on top of ETH_ZLEN), whereas this expresses the absolute value of the fragment size. - ETHTOOL_A_MM_RX_MIN_FRAG_SIZE: there doesn't appear to exist a managed object mandated by the standard, but user space clearly needs to know what is the minimum supported fragment size of our local receiver, since LLDP must advertise a value no lower than that. Signed-off-by:
-
Peilin Ye authored
As suggested by Cong, introduce a tracepoint for all ->sk_data_ready() callback implementations. For example: <...> iperf-609 [002] ..... 70.660425: sk_data_ready: family=2 protocol=6 func=sock_def_readable iperf-609 [002] ..... 70.660436: sk_data_ready: family=2 protocol=6 func=sock_def_readable <...> Suggested-by:
Cong Wang <cong.wang@bytedance.com> Signed-off-by:
Peilin Ye <peilin.ye@bytedance.com> Signed-off-by:
-
- 21 Jan, 2023 14 commits
-
-
Jakub Kicinski authored
Petr Machata says: ==================== mlxsw: Add support of latency TLV Amit Cohen writes: Ethernet Management Datagrams (EMADs) are Ethernet packets sent between the driver and device's firmware. They are used to pass various configurations to the device, but also to get events (e.g., port up) from it. After the Ethernet header, these packets are built in a TLV format. This is the structure of EMADs: * Ethernet header * Operation TLV * String TLV (optional) * Latency TLV (optional) * Reg TLV * End TLV The latency of each EMAD is measured by firmware. The driver can get the measurement via latency TLV which can be added to each EMAD. This TLV is optional, when EMAD is sent with this TLV, the EMAD's response will include the TLV and will contain the firmware measurement. Add support for Latency TLV and use it by default for all EMADs (see more information in commit messages). The latency measurements can be processed using BPF program for example, to create a histogram and average of the latency per register. In addition, it is possible to measure the end-to-end latency, so then the latency of the software overhead can be calculated. This information can be useful to improve the driver performance. See an example of output of BPF tool which presents these measurements: $ ./emadlatency -f -a Tracing EMADs... Hit Ctrl-C to end. Register write = RALUE (0x8013) E2E Measurements: average = 23 usecs, total = 32052693 usecs, count = 1337061 usecs : count distribution 0 -> 1 : 0 | | 2 -> 3 : 0 | | 4 -> 7 : 0 | | 8 -> 15 : 0 | | 16 -> 31 : 1290814 |*********************************| 32 -> 63 : 45339 |* | 64 -> 127 : 532 | | 128 -> 255 : 247 | | 256 -> 511 : 57 | | 512 -> 1023 : 26 | | 1024 -> 2047 : 33 | | 2048 -> 4095 : 0 | | 4096 -> 8191 : 10 | | 8192 -> 16383 : 1 | | 16384 -> 32767 : 1 | | 32768 -> 65535 : 1 | | Firmware Measurements: average = 10 usecs, total = 13884128 usecs, count = 1337061 usecs : count distribution 0 -> 1 : 0 | | 2 -> 3 : 0 | | 4 -> 7 : 0 | | 8 -> 15 : 1337035 |*********************************| 16 -> 31 : 17 | | 32 -> 63 : 7 | | 64 -> 127 : 0 | | 128 -> 255 : 2 | | Diff between measurements: 13 usecs Patch set overview: Patches #1-#3 add support for querying MGIR, to know if string TLV and latency TLV are supported Patches #4-#5 add some relevant fields to support latency TLV Patch #6 adds support of latency TLV ==================== Link: https://lore.kernel.org/r/cover.1674123673.git.petrm@nvidia.comSigned-off-by: -
Amit Cohen authored
The latency of each EMAD can be measured by firmware. The driver can get the measurement via latency TLV which can be added to each EMAD. This TLV is optional, when EMAD is sent with this TLV, the EMAD's response will include the TLV and the field 'latency_time' will contain the firmware measurement. This information can be processed using BPF program for example, to create a histogram and average of the latency per register. In addition, it is possible to measure the end-to-end latency, and then reduce firmware measurement, which will result in the latency of the software overhead. This information can be useful to improve the driver performance. Add support for latency TLV by default for all EMADs. First we planned to enable latency TLV per demand, using devlink-param. After some tests, we know that the usage of latency TLV does not impact the end-to-end latency, so it is OK to enable it by default. Note that similar to string TLV, the latency TLV is not supported in all firmware versions. Enable the usage of this TLV only after verifying it is supported by the current firmware version by querying the Management General Information Register (MGIR). Signed-off-by:
Danielle Ratson <danieller@nvidia.com> Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by:
-
Amit Cohen authored
The next patch will add support for latency TLV as part of EMAD (Ethernet Management Datagrams) packets. As preparation, add the relevant fields. Signed-off-by:
-
Amit Cohen authored
The next patches will add support for latency TLV as part of EMAD (Ethernet Management Datagrams) packets. As preparation, add the relevant values. Signed-off-by:
-
Amit Cohen authored
Till now, the field 'mlxsw_core->emad.enable_string_tlv' is set as part of mlxsw_sp_init(), this means that it can be changed during emad_reg_access(). To avoid such change, this field is read once in emad_reg_access() and the value is used all the way. The previous patch sets this value according to MGIR output, as part of mlxsw_emad_init(), so now it cannot be changed while sending EMADs. Do not save 'enable_string_tlv' and do not pass it to functions, just pass 'struct mlxsw_core' and use the value directly from it. Signed-off-by:
-
Amit Cohen authored
String TLV is not supported by old firmware versions, therefore 'struct mlxsw_core' stores the field 'emad.enable_string_tlv', which is set to true only after firmware version check. Instead of assuming that firmware version check is enough to enable string TLV, a better solution is to query if this TLV is supported from MGIR register. Add such query and initialize 'emad.enable_string_tlv' accordingly. Signed-off-by:
-
Amit Cohen authored
MGIR (Management General Information Register) allows software to query the hardware and firmware general information. As part of firmware information, the driver can query if string TLV and latency TLV are supported. These TLVs are part of EMAD's header and are used to provide information per EMAD packet to software. Currently, string TLV is already used by the driver, but it does not query if this TLV is supported from MGIR. The next patches will add support of latency TLV. Add the relevant fields to MGIR, so then the driver will query them to know if the TLVs are supported before using them. Signed-off-by:
-
Nikhil Gupta authored
1588 driver loses about 1us in adjtime operation at PTP slave This is because adjtime operation uses a slow non-atomic tmr_cnt_read() followed by tmr_cnt_write() operation. In the above sequence, since the timer counter operation keeps incrementing, it leads to latency. The tmr_offset register (which is added to TMR_CNT_H/L register giving the current time) must be programmed with the delta nanoseconds. Signed-off-by:
Nikhil Gupta <nikhil.gupta@nxp.com> Reviewed-by:
-
Yang Yingliang authored
Use kmemdup() helper instead of open-coding to simplify the code when allocating newckf and newcaf. Generated by: scripts/coccinelle/api/memdup.cocci Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Reviewed-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Reviewed-by:
Steen Hegelund <Steen.Hegelund@microchip.com> Link: https://lore.kernel.org/r/20230119092210.3607634-1-yangyingliang@huawei.comSigned-off-by:
-
Jakub Kicinski authored
Michael Walle says: ==================== net: mdio: Remove support for building C45 muxed addresses I've picked this older series from Andrew up and rebased it onto the latest net-next. With all drivers which support c45 now being converted to a seperate c22 and c45 access op, we can now remove the old MII_ADDR_C45 flag. ==================== Link: https://lore.kernel.org/r/20230119130700.440601-1-michael@walle.ccSigned-off-by:
-
Andrew Lunn authored
The old way of performing a C45 bus transfer created a special register value and passed it to the MDIO bus driver, in the hope it would see the MII_ADDR_C45 bit set, and perform a C45 transfer. Now that there is a clear separation of C22 and C45, this scheme is no longer used. Remove all the #defines and helpers, to prevent any code being added which tries to use it. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Andrew Lunn authored
The MDIO core should not pass a C45 request via the C22 API call any more. So remove the tests from the drivers. Signed-off-by:
-
Michael Walle authored
With the new C45 MDIO access API, there is no encoding of the register number anymore and thus the masking isn't necessary anymore. Remove it. Signed-off-by:
-
Andrew Lunn authored
Now that all MDIO bus drivers which support C45 implement the c45 specific ops, remove the fallback to the old method. Signed-off-by:
-
