| Age | Commit message (Collapse) | Author |
|---|
|
As mlx4 has implemented skb_tx_timestamp() in mlx4_en_xmit(), the
SOFTWARE flag is surely needed when users are trying to get timestamp
information.
Signed-off-by: Jason Xing <kernelxing@tencent.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20250510093442.79711-1-kerneljasonxing@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/linux
Tony Nguyen says:
====================
Prepare for Intel IPU E2000 (GEN3)
This is the first part in introducing RDMA support for idpf.
----------------------------------------------------------------
Tatyana Nikolova says:
To align with review comments, the patch series introducing RDMA
RoCEv2 support for the Intel Infrastructure Processing Unit (IPU)
E2000 line of products is going to be submitted in three parts:
1. Modify ice to use specific and common IIDC definitions and
pass a core device info to irdma.
2. Add RDMA support to idpf and modify idpf to use specific and
common IIDC definitions and pass a core device info to irdma.
3. Add RDMA RoCEv2 support for the E2000 products, referred to as
GEN3 to irdma.
This first part is a 5 patch series based on the original
"iidc/ice/irdma: Update IDC to support multiple consumers" patch
to allow for multiple CORE PCI drivers, using the auxbus.
Patches:
1) Move header file to new name for clarity and replace ice
specific DSCP define with a kernel equivalent one in irdma
2) Unify naming convention
3) Separate header file into common and driver specific info
4) Replace ice specific DSCP define with a kernel equivalent
one in ice
5) Implement core device info struct and update drivers to use it
----------------------------------------------------------------
v1: https://lore.kernel.org/20250505212037.2092288-1-anthony.l.nguyen@intel.com
IWL reviews:
[v5] https://lore.kernel.org/20250416021549.606-1-tatyana.e.nikolova@intel.com
[v4] https://lore.kernel.org/20250225050428.2166-1-tatyana.e.nikolova@intel.com
[v3] https://lore.kernel.org/20250207194931.1569-1-tatyana.e.nikolova@intel.com
[v2] https://lore.kernel.org/20240824031924.421-1-tatyana.e.nikolova@intel.com
[v1] https://lore.kernel.org/20240724233917.704-1-tatyana.e.nikolova@intel.com
* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/linux:
iidc/ice/irdma: Update IDC to support multiple consumers
ice: Replace ice specific DSCP mapping num with a kernel define
iidc/ice/irdma: Break iidc.h into two headers
iidc/ice/irdma: Rename to iidc_* convention
iidc/ice/irdma: Rename IDC header file
====================
Link: https://patch.msgid.link/20250509200712.2911060-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The function mse102x_rx_pkt_spi is used in two cases:
* initial polling to re-arm RX interrupt
* level based RX interrupt handler
Both of them doesn't need an open-coded retry mechanism.
In the first case the function can be called again, if the return code
is IRQ_NONE. This keeps the error behavior during netdev open.
In the second case the proper retry would be handled implicit by
the SPI interrupt. So drop the retry code and simplify the receive path.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Link: https://patch.msgid.link/20250509120435.43646-7-wahrenst@gmx.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The MSE102x doesn't provide any interrupt register, so the only way
to handle the level interrupt is to fetch the whole packet from
the MSE102x internal buffer via SPI. So in cases the interrupt
handler fails to do this, it should return IRQ_NONE. This allows
the core to disable the interrupt in case the issue persists
and prevent an interrupt storm.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Link: https://patch.msgid.link/20250509120435.43646-6-wahrenst@gmx.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
After removal of the invalid command counter only a relevant debug
message is left, which can be cumbersome. So add a new flag to debugfs,
which indicates whether the driver has ever received a valid CMD.
This helps to differentiate between general and temporary receive
issues.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250509120435.43646-5-wahrenst@gmx.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
There are several reasons for an invalid command response
by the MSE102x:
* SPI line interferences
* MSE102x is in reset or has no firmware
* MSE102x is busy
* no packet in MSE102x receive buffer
So the counter for invalid command isn't very helpful without
further context. So drop the confusing statistics counter,
but keep the debug messages about "unexpected response" in order
to debug possible hardware issues.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250509120435.43646-4-wahrenst@gmx.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The example of the initial DT binding of the Vertexcom MSE 102x suggested
a IRQ_TYPE_EDGE_RISING, which is wrong. So warn everyone to fix their
device tree to level based IRQ.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20250509120435.43646-3-wahrenst@gmx.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
It has been reported that when under a bridge with stp_state=1, the logs
get spammed with this message:
[ 251.734607] fsl_dpaa2_eth dpni.5 eth0: Couldn't decode source port
Further debugging shows the following info associated with packets:
source_port=-1, switch_id=-1, vid=-1, vbid=1
In other words, they are data plane packets which are supposed to be
decoded by dsa_tag_8021q_find_port_by_vbid(), but the latter (correctly)
refuses to do so, because no switch port is currently in
BR_STATE_LEARNING or BR_STATE_FORWARDING - so the packet is effectively
unexpected.
The error goes away after the port progresses to BR_STATE_LEARNING in 15
seconds (the default forward_time of the bridge), because then,
dsa_tag_8021q_find_port_by_vbid() can correctly associate the data plane
packets with a plausible bridge port in a plausible STP state.
Re-reading IEEE 802.1D-1990, I see the following:
"4.4.2 Learning: (...) The Forwarding Process shall discard received
frames."
IEEE 802.1D-2004 further clarifies:
"DISABLED, BLOCKING, LISTENING, and BROKEN all correspond to the
DISCARDING port state. While those dot1dStpPortStates serve to
distinguish reasons for discarding frames, the operation of the
Forwarding and Learning processes is the same for all of them. (...)
LISTENING represents a port that the spanning tree algorithm has
selected to be part of the active topology (computing a Root Port or
Designated Port role) but is temporarily discarding frames to guard
against loops or incorrect learning."
Well, this is not what the driver does - instead it sets
mac[port].ingress = true.
To get rid of the log spam, prevent unexpected data plane packets to
be received by software by discarding them on ingress in the LISTENING
state.
In terms of blame attribution: the prints only date back to commit
d7f9787a763f ("net: dsa: tag_8021q: add support for imprecise RX based
on the VBID"). However, the settings would permit a LISTENING port to
forward to a FORWARDING port, and the standard suggests that's not OK.
Fixes: 640f763f98c2 ("net: dsa: sja1105: Add support for Spanning Tree Protocol")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20250509113816.2221992-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Most PHY drivers default to a 2ns delay if internal delay is requested
and no value is specified. Having a default value makes sense, as it
allows a Device Tree to only care about board design (whether there are
delays on the PCB or not), and not whether the delay is added on the MAC
or the PHY side when needed.
Whether the delays are actually applied is controlled by the
DP83867_RGMII_*_CLK_DELAY_EN flags, so the behavior is only changed in
configurations that would previously be rejected with -EINVAL.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Link: https://patch.msgid.link/e2509b248a11ee29ea408a50c231da4c1fa0863b.1746612711.git.matthias.schiffer@ew.tq-group.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The check that intended to handle "rgmii" PHY mode differently to the
RGMII modes with internal delay never worked as intended:
- added in commit 2a10154abcb7 ("net: phy: dp83867: Add TI dp83867 phy"):
logic error caused the condition to always evaluate to true
- changed in commit a46fa260f6f5 ("net: phy: dp83867: Fix warning check
for setting the internal delay"): now the condition incorrectly
evaluates to false for rgmii-txid
- removed in commit 2b892649254f ("net: phy: dp83867: Set up RGMII TX
delay")
Around the time of the removal, commit c11669a2757e ("net: phy: dp83867:
Rework delay rgmii delay handling") started clearing the delay enable
flags in RGMIICTL. The change attempted to preserve the historical
behavior of not disabling internal delays with "rgmii" PHY mode and also
documented this in a comment, but due to a conflict between "Set up
RGMII TX delay" and "Rework delay rgmii delay handling", the behavior
dp83867_verify_rgmii_cfg() warned about (and that was also described in
a comment in dp83867_config_init()) disappeared in the following merge
of net into net-next in commit b4b12b0d2f02
("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net").
While is doesn't appear that this breaking change was intentional, it
has been like this since 2019, and the new behavior to disable the delays
with "rgmii" PHY mode is generally desirable - in particular with MAC
drivers that have to fix up the delay mode, resulting in the PHY driver
not even seeing the same mode that was specified in the Device Tree.
Remove the obsolete check and comment.
Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Link: https://patch.msgid.link/8a286207cd11b460bb0dbd27931de3626b9d7575.1746612711.git.matthias.schiffer@ew.tq-group.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
There is a situation where after THALT is set high, TGO stays high as
well. Because jiffies are never updated, as we are in a context with
interrupts disabled, we never exit that loop and have a deadlock.
That deadlock was noticed on a sama5d4 device that stayed locked for days.
Use retries instead of jiffies so that the timeout really works and we do
not have a deadlock anymore.
Fixes: e86cd53afc590 ("net/macb: better manage tx errors")
Signed-off-by: Mathieu Othacehe <othacehe@gnu.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250509121935.16282-1-othacehe@gnu.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
New timestamping API was introduced in commit 66f7223039c0 ("net: add
NDOs for configuring hardware timestamping") from kernel v6.6. It is
time to convert the intel ixp4xx ethernet driver to the new API, so that
the ndo_eth_ioctl() path can be removed completely.
hwtstamp_get() and hwtstamp_set() are only called if netif_running()
when the code path is engaged through the legacy ioctl. As I don't
want to make an unnecessary functional change which I can't test,
preserve that restriction when going through the new operations.
When cpu_is_ixp46x() is false, the execution of SIOCGHWTSTAMP and
SIOCSHWTSTAMP falls through to phy_mii_ioctl(), which may process it in
case of a timestamping PHY, or may return -EOPNOTSUPP. In the new API,
the core handles timestamping PHYs directly and does not call the netdev
driver, so just return -EOPNOTSUPP directly for equivalent logic.
A gratuitous change I chose to do anyway is prefixing hwtstamp_get() and
hwtstamp_set() with the driver name, ipx4xx. This reflects modern coding
sensibilities, and we are touching the involved lines anyway.
The remainder of eth_ioctl() is exactly equivalent to
phy_do_ioctl_running(), so use that.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patch.msgid.link/20250508211043.3388702-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Having a software timestamp (along with existing hardware one) is
useful to trace how the packets flow through the stack.
mlx5e_tx_skb_update_hwts_flags is called from tx paths
to setup HW timestamp; extend it to add software one as well.
Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Signed-off-by: Stanislav Fomichev <stfomichev@gmail.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20250508235109.585096-1-stfomichev@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
We don't need the configs that won't end up being used, such as
the "br" config for discrete devices, remove them. Also remove
the module firmware for test chips, that's never needed.
For now keep the iwl_dr_mac_cfg even if it's unused, we'll add
platforms with it once we have their PCI IDs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250511195137.15e2056ec40f.I75a6ce4ad0b14d2b4413615f05523a8f62f08954@changeid
|
|
Add iwl_trans_get_device_id() to extract the device ID
from the hw_id member in the iwl_trans structure.
hw_id member contains both sub-device ID and device ID,
with the device ID occupying bits 16 to 31.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250511195137.4411402701f2.I81cde20de05e3bb993977f8d4bbf90707819347f@changeid
|
|
Looks like these were never marked discrete, since they always
used the iwl_so_mac_cfg (earlier iwl_so_trans_cfg). Mark them
as discrete since they are.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
PerCI-Ready: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Tested-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250511195137.f3a75ae80f28.I79964f4426389f04798b70841a9e847be48bf9c3@changeid
|
|
Now that it's all split into MAC and RF configs, remove
the matching on MAC type and step. If we ever need to do
something based on the MAC step, we'll have to find some
new mechanism (since the MAC type is known already from
the PCI IDs table, but not the step), or just handle the
(likely small) differences in code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.fca99a5ab315.Iae27b781221fd29845493adf2c29d9e4f7a9c33b@changeid
|
|
There are some devices that are misidentified, such as 7265-N
and Killer 1435 variants. Add their names, and for some of them
also add the PCI IDs to match at all.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.ca03a90c294e.I04d64964c664d49ab16760d754968f09c607f36a@changeid
|
|
There are a couple of variants of this, match them correctly
to their names and clean up a bit.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.d03eaad5be56.I276a09f0cad364e51ed4730ca81fbe504e61f2c7@changeid
|
|
We only need a few entries, and there don't seem to be any
such devices actually limited to 160 MHz.
Also add PCI IDs for the new Killer device on LNL platforms.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.ba2964bee671.If7aaaf10b236115e39b17d37296341de6c821069@changeid
|
|
Again some names don't actually exist, and we only need a
few entries to cover Ty (discrete) and AX211/AX411.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.8888f6798581.If332ebfc3b3f4a335a79ccee13e90f93b1ee4df7@changeid
|
|
This really only needs to be distinguished based on the
RF type, bandwidth limit and possibly diversity (JF1).
Some of the names that are defined don't even exist.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.bca83604aa92.I35301d2d8b57c072284fff7bf6682b4a9424e56c@changeid
|
|
It's OK to match with subdevice_mask as long as that doesn't
overlap the RF ID/BW limit/cores fields in that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.87cc0ad360a8.I9be361caedd7258e8e817d4100c549681396f307@changeid
|
|
We only need a few entries on top of the Killer ones.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.fa0cde465de0.I6a3f9ed9a7341e2c58c69af50a9f126992a745f2@changeid
|
|
Unify a number of Killer devices now that we no longer
need to distinguish the MAC type, and add a few more
that wouldn't have gotten the right name before.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.a16b1c2740f8.I147b97ef2c8e99451806ea0e34a9eb5bff37c326@changeid
|
|
All of these should be 160 MHz, and they can be recognised
by just the subdevice ID. Unify all the Killer/JF entries.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.a93788f159ec.I114f09a0f61849ac3b75d12d7def35be842e5b7c@changeid
|
|
These should be according to their RF type, not just use
GF unconditionally. Fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.4dd365eb76cd.I91f368df691a3ce6c545d9cdc44676e7883efa16@changeid
|
|
Officially, the device names have dashes ("Wireless-N"),
so add them.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.4f7bbd57680f.Ida19b5e696723db5839c13341d6ca7085e8c2568@changeid
|
|
There are a couple of old names that don't actually get used.
Remove them.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.1ed5fc197ba0.I52d7bb49db24523ad93ad83a89c8e846d9a43241@changeid
|
|
During link selection if the links does not meet the valid grade
criteria then add debug log instead of warning.
Signed-off-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.2593268ca988.I9786126cd1078caec8587b166a7f8735300c951d@changeid
|
|
Evidently, I confused the fields here, apply_policy should
be checked for IWL_FW_INI_APPLY_POLICY_SPLIT_DUMP_RESET.
Fix that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Eilon Rinat <eilon.rinat@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250510214621.c802d5cc1312.I0cf5d74f91349499ab35eef0ebdc604961e492ef@changeid
|
|
Handle soc servicing events which require the rdma auxiliary device resources to
be cleaned up during a suspend, and re-initialized during a resume.
Signed-off-by: Shiraz Saleem <shirazsaleem@microsoft.com>
Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com>
Link: https://patch.msgid.link/1746633545-17653-5-git-send-email-kotaranov@linux.microsoft.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
Initialize gdma device for rdma inside mana module.
For each gdma device, initialize an auxiliary ib device.
Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com>
Link: https://patch.msgid.link/1746633545-17653-2-git-send-email-kotaranov@linux.microsoft.com
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
It was decided this was supported after all, so remove
the restriction.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-15-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
add support for remain on channel on BSS vif for iwlmld.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-14-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
If one of the stages in starting a ROC failed,
the ROC will not start nor end so EMLSR will stay blocked forever.
Block EMLSR once all ROC conditions are validated and
clear EMLSR blocked reasons in mld_vif cleanup.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-13-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
This change reflects the correct ownership of aux_sta,
as it is not a property of the link but rather of the virtual interface.
Updated the initialization, cleanup and access logic for the aux_sta member
to align with its new location within iwl_mld_vif.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-12-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
The roc_activity member in the iwl_mld_vif structure was previously
set to zero during cleanup as was present in struct_group, which
incorrectly indicated ROC_ACTIVITY_HOTSPOT.
To fix this issue, remove roc_activity member from struct_group.
Notify mac80211 of ROC expiration during vif cleanup to maintain
synchronization between the driver and mac80211.
While on it, update it's type to enum iwl_roc_activity.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-11-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Update comments to accurately reflect the purpose of the
iwl_mld_cleanup_link and iwl_cleanup_mld functions.
Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Reviewed-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-10-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
With all the cleanups now, we can rename the structure to
better indicate the functionality. For older devices this
isn't quite accurate, of course, but it's better to have a
name that reflects future use for maintenance.
Add some kernel-doc while at it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-9-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
For now, the WH and PE radios require the same config as
FM, so just add a #define for those instead of copying
the data. Since this is true, Sc/Dr/Br all used the same
configs for all RF types, but that's confusing, so now
use the defined WH/PE names for the correct combinations.
We can also now enable the unit test that ensures we have
no duplicate RF configs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-8-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
The Bz configs really should be FM for the RF, so
move that around.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-7-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
This is equivalent to just the previous iwl_cfg_ma, but
really should also be used for Bz/Gf and Sc/Gf, instead
of those using EHT sizes.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-6-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Unify the HR configs to just one HR RF config. All the fields
were the same already, so this doesn't do anything.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-5-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
Unify the JF configs to just one JF RF config. This can be
done because the differing fields (thermal and DCCM offsets)
won't be used for Qu MACs (and up) due to firmware support.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-4-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
This should depend on both the RF (VHT/HE/EHT support) and
the MAC (<=22000 can put multiple frames into one buffer),
so unify the config in the struct iwl_cfg to just have it
sized according to the RF, and then double it for all the
MACs starting from AX210 (So/Ty).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-3-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
In some older devices, the min/max firmware API supported by
the driver depends on the specific device, when sharing the
the same MAC (config). For most newer devices, it really is
dependent on the MAC instead, since the firmware was frozen
for certain MAC types. However, in the future we expect also
freezes for RF types there.
To handle this most generally, add an API min/max to the MAC
config and then use the narrowest range prescribed by both,
if set.
For the newer MACs since 9000, move the configuration, there
was only a freeze on MAC+RF lines so far.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250509104454.2582160-2-miriam.rachel.korenblit@intel.com
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
|
|
When the following prerequisites are met, driver will enable support_mlo.
It means that driver will declare WIPHY_FLAG_SUPPORTS_MLO, and then deal
with MLO related things.
The main prerequisites are as below.
1. all prerequisites for running with chanctx
2. FW feature NOTIFY_AP_INFO
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250505072440.45113-12-pkshih@realtek.com
|
|
Add an dbgfs mlo_mode to get/set MLO mode. And, support to trigger MLSR
switching. Setting it will automatically disable MLO Dynamic Mechanism
(DM). Then MLO things can follow commands via dbgfs mlo_mode instead of
MLO DM. The disabled DM(s) can be checked/cleared via dbgfs disable_dm.
The following is an use example.
Read it to show current MLD status.
$ cat mlo_mode
MLD(s) status: (MLO DM: enable)
#0: MLO mode 0, valid 0x6, active 0x2
Write it to switch to MLSR on link id 2.
$ echo 0 2 > mlo_mode
$ cat mlo_mode
MLD(s) status: (MLO DM: disable)
#0: MLO mode 0, valid 0x6, active 0x4
Besides, to be safer, add RWLOCK attribute to dbgfs disable_dm.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250505072440.45113-11-pkshih@realtek.com
|
|
This allows showing MLO related logs when FW debug mode is on.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250505072440.45113-10-pkshih@realtek.com
|
