| Age | Commit message (Collapse) | Author |
|---|
|
In theory, this should be 12 bits, but in practice all the
values we use now fit into 8 bits, so change the mac_type to
make room in struct iwl_dev_info.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.c17d56f4ae0f.I487c8df18aa33c46aa6813bf5aebb5a23da67600@changeid
|
|
We don't need the same name multiple times in the binary,
add a check for 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/20250502155404.9adf2790122e.Ia85152c072c7944f0b80e819cf59a51d6adeb49a@changeid
|
|
Move all the names into dev info structs and remove
the pointer from the configs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.1538369bffde.Id430ff71f57cbb37c19ecc5b41c831e5ba9b0695@changeid
|
|
A long time ago, when transport vs. device configs were
introduced, we wanted to eventually have a list of PCI
IDs and a separate list of devices, but for simplicity
embedded the transport config in the whole config, and
it all got confusing.
Finish splitting that out. Doing so requires having more
IWL_DEV_INFO() entries, but the whole trans/cfg aliasing
goes away and the code becomes a lot simpler.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.e03f65c0f693.I076a997f800db455b575008f9488b151738ad7ec@changeid
|
|
Remove the erroneously named IWL_DEVICE_BZ_COMMON macro
from the Sc file and fix some indentation. Also bump the
minimum FW version since it's not released yet anyway,
right now this is mostly to make the config different
from iwl_bz_cfg which would otherwise be the same with
the upcoming transport config cleanups.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.b313d54b8809.Ia975b6d5460996f2a2761dd3d0fef4a56f1f3e24@changeid
|
|
The alloc function iwl_trans_pcie_alloc() doesn't use the
'ent' argument, so remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.0351805072bc.Id309b38817edc116bf9a921608a93b7734f21b05@changeid
|
|
It's not clear that it makes sense to have any matches
for IWL_CFG_ANY for this bit, but let's assume for now
that this makes sense. Then, it's clearer to call this
BW_NOT_LIMITED rather than BW_NO_LIMIT, since the last
change.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.9b39693b505c.Ib47aa6a072a0e61bbba28383ce54764cd859f19c@changeid
|
|
The BW limit, cores and RF ID are matched in the subdevice ID,
so it doesn't really make sense to have both SUBDEV() match and
a match on any of those three. In particular, for Killer devices
the subdevice ID doesn't even follow the layout, so no matching
should be on those three values at all, only with SUBDEV().
Change the logic around the BW limit to have it more like all
the other things: only a bw_limit match in the dev_info, and
put the actual bandwidth into struct iwl_cfg. This duplicates a
number of those values, but that way the logic is clearer.
Add a test that checks that the three matches mentioned above
are not used in conjunction with SUBDEV(), and check that if
the bw_limit is matched, a BW limit is provided in the config.
Also check that the "Killer" devices have a SUBDEV() match.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.a185eac2736c.I87ee87300c92518a1d3296d3eda9fd4163e9085e@changeid
|
|
Add a kunit test to check that all (used) transport config structs
are not duplicated, since there's no value in having the same info
in two places in memory.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.a151af19aaba.Id57f099a899e09318c6218ed1859151f00232b41@changeid
|
|
Add a kunit test to check that all (used) config structs
are not duplicated, ignoring the name since that can be
handled differently via the dev-info list.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.0cfd9fb8322e.I9567b839405be8d1e4be0bfca7a17b5d222b0158@changeid
|
|
This is the same as iwl_cfg_dr, just different by the MAC,
so no need to keep a separate config; remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502155404.83b86e8a182b.Iec7f3027e7058005a98ff6d05cc224ab61b7c44a@changeid
|
|
The configurations for Sc, Sc2 and Sc2f are all the same,
so keep just a single config struct.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.2bab15a21306.I079987bc4a1679789bacc1078952aa90c805ffe0@changeid
|
|
This really is the same device as covered by iwl_cfg_bz,
just the discrete version. Since discrete vs integrated
is handled in the transport config, there's no need to
have both. Remove iwl_cfg_gl.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.fbb78183dc85.Ic5429009677ae1023cf1f43a655e90409a30c493@changeid
|
|
We can handle the name differently, so do that and remove
the extra config entry.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.17fc47c72232.I2cb4476b9bca6e770bd375ad6ce650553dbde0f1@changeid
|
|
This was used in some really old devices, and then got
carried forward to Qu devices, even though on those we
don't need it at all since the TX aggregation start is
offloaded to the firmware. Remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.9c2689e2ca8e.I8274b29ca64d9ef9d1e357bbe34ca3a4b97aeb7a@changeid
|
|
There are two killer configs that no longer exist,
remove the externs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.64977630101f.I9997a72027d37249620a78091759fa44f9d32c87@changeid
|
|
These configs are the same except for the name, but we
can use a separate per-device name to override the name.
So do that, and remove the separate configs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.a0a8ebbd473a.Iad8bff04138538a8bc9f7920077ea24a699b1ed4@changeid
|
|
Now that the fw_name_mac is no longer around and derived
from the MAC type automatically, we no longer need to have
different configurations for Qu/QuZ. Combine them. For the
killer AX1650s/i, also fix the names, there was a mixup.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.957fbb5437ce.If51ad0b2c8afaaa131208125af3bc292793613bb@changeid
|
|
Instead of having fw_name_mac in the config, derive it
from the MAC type instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.8dba9a2d3546.I41fa594d6a0be163444b90c1ed4b441a949d3899@changeid
|
|
Add a unit test that checks that each device has a name,
either via the specific name entry or the config's name.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.c04287134280.Iedc7c05a41dc8bfe04dc8b95fea38543513eac2d@changeid
|
|
On AdL-P, we're missing an entry for the Killer(R) Wi-Fi 6
AX1650i 160 MHz adapter. Add an entry to fix that.
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219114
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.483214386aa4.Iad4d2041bfe544875fe9f5c051e23a765f862786@changeid
|
|
Rather than having individual entries for different MAC
and RF steps, unify the entries by using fw_name_mac and
remove the now duplicated 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/20250502151751.b93f34a65822.I57b8235acb675cb6b4e97df2f4a7365f3d9bff18@changeid
|
|
This line was duplicated by mistake, remove one occurrence.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.a2601e0a08e0.Ie72fadec40e41b8197bfdae16eaa430c64a3e62d@changeid
|
|
Add device support for PeP on ScP
Signed-off-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.a66928fcc82a.Icbbc7c28855f8de232cb3916901a4da3ac286117@changeid
|
|
There are the same values as JF2/JF1 respectively, and
that really matches the code names. Remove TH/TH1.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.7677cffdfae2.Idd76734c310cf5f27de43d24e71b27467ab5905a@changeid
|
|
The IWL_DEV_INFO() macro has far too many arguments, and most
of the time they're just "ANY". Use C99 initializers in the
macro to clean that up.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250502151751.42318bb31f0e.Ic3a40afcd182b6e1802bb8f8a1a845b20608e328@changeid
|
|
This was used in the past for NoA and/or beacon filter
testing, but these days everything is tested via debugfs
or special FW commands, so remove the testmode.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430155443.751018e0ed8e.I21557a9a3d57234187f1b0b2182a1714ecc66b9a@changeid
|
|
Set rx_mpdu_cmd_hdr_size so that tracing will correctly include
the frame header.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430155443.caf1d8e2bae3.I82d89bc8d128f78159a8a11b1573574dacdeb99e@changeid
|
|
Fix warnings occurring with W=1, mostly const and one about
pointer arithmetic.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430155443.3ef1e4f1cccb.Ic41d3f3721e8bd9df9cd50242232110c4a93e873@changeid
|
|
When a soft AP is started, it may not use the full configured
bandwidth (e.g. if no station is connected). As a result, the
responder will not support the configured bandwidth. Since the
responder supports ranging with unassociated stations, there is
no indication to the driver when the full bandwidth should be enabled.
Fix it by configuring the AP to always use the full bandwidth when a
responder is supported.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430155443.620fe8099fff.Id50675f4d4c524b0a7ee602c48af538a327010e0@changeid
|
|
When a channel context is added, it is still not assigned to the link
and the link is not yet active. As a result, the channel context
min_def is used when the AP is started, even when the full bandwidth
should be used.
Fix it by updating the PHY channel context when the link is already
active so the full bandwidth is used when needed.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430155443.30b043b10fb1.I62c2aa58687e4796b759fa68132122119a337b49@changeid
|
|
This is needed for TX injection over monitor interface.
Signed-off-by: Daniel Gabay <daniel.gabay@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430155443.5ec460d3f1c2.Ic8456efb4cdd722dcd9c4910a1569ef9d3e4e066@changeid
|
|
The rate format changed but since we don't use the rate, just claim
support for this new API.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430155443.c4be90e242ff.Ie8a0f0d6320613bd8c5cb6c82a063069fffa3b67@changeid
|
|
This version fixes the issue that was worked around by
iwl_mvm_smps_workaround. So for FWs with the new version don't do the
workaround, and set new bit added in this version when appropriate.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20250430155443.5c9a0181a84b.I9a03bc07a7b3f6e37cc1c0c1af5719e765a05897@changeid
|
|
Implement TOP reset (new in the SC family), which resets much
of the (shared) hardware without resetting the bus interfaces.
Use it to recover from TOP fatal error, or if manually used;
we'll need to add using it for FSEQ updates later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430155443.12f38024a3b4.I9c22f6c4f6de64f3b34ccd898370ec1859ab7dbf@changeid
|
|
defragmentation
Currently during the multi-link element defragmentation process, the
multi-link element length added to the total IEs length when calculating
the length of remaining IEs after the multi-link element in
cfg80211_defrag_mle(). This could lead to out-of-bounds access if the
multi-link element or its corresponding fragment elements are the last
elements in the IEs buffer.
To address this issue, correctly calculate the remaining IEs length by
deducting the multi-link element end offset from total IEs end offset.
Cc: stable@vger.kernel.org
Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe responses")
Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Link: https://patch.msgid.link/20250424-fix_mle_defragmentation_oob_access-v1-1-84412a1743fa@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The vfio-pci huge_fault handler doesn't make any attempt to insert a
mapping containing the faulting address, it only inserts mappings if the
faulting address and resulting pfn are aligned. This works in a lot of
cases, particularly in conjunction with QEMU where DMA mappings linearly
fault the mmap. However, there are configurations where we don't get
that linear faulting and pages are faulted on-demand.
The scenario reported in the bug below is such a case, where the physical
address width of the CPU is greater than that of the IOMMU, resulting in a
VM where guest firmware has mapped device MMIO beyond the address width of
the IOMMU. In this configuration, the MMIO is faulted on demand and
tracing indicates that occasionally the faults generate a VM_FAULT_OOM.
Given the use case, this results in a "error: kvm run failed Bad address",
killing the VM.
The host is not under memory pressure in this test, therefore it's
suspected that VM_FAULT_OOM is actually the result of a NULL return from
__pte_offset_map_lock() in the get_locked_pte() path from insert_pfn().
This suggests a potential race inserting a pte concurrent to a pmd, and
maybe indicates some deficiency in the mm layer properly handling such a
case.
Nevertheless, Peter noted the inconsistency of vfio-pci's huge_fault
handler where our mapping granularity depends on the alignment of the
faulting address relative to the order rather than aligning the faulting
address to the order to more consistently insert huge mappings. This
change not only uses the page tables more consistently and efficiently, but
as any fault to an aligned page results in the same mapping, the race
condition suspected in the VM_FAULT_OOM is avoided.
Reported-by: Adolfo <adolfotregosa@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220057
Fixes: 09dfc8a5f2ce ("vfio/pci: Fallback huge faults for unaligned pfn")
Cc: stable@vger.kernel.org
Tested-by: Adolfo <adolfotregosa@gmail.com>
Co-developed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: Peter Xu <peterx@redhat.com>
Link: https://lore.kernel.org/r/20250502224035.3183451-1-alex.williamson@redhat.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
|
|
Call Trace:
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xc3/0x670 mm/kasan/report.c:521
kasan_report+0xe0/0x110 mm/kasan/report.c:634
strlen+0x93/0xa0 lib/string.c:420
__fortify_strlen include/linux/fortify-string.h:268 [inline]
get_kobj_path_length lib/kobject.c:118 [inline]
kobject_get_path+0x3f/0x2a0 lib/kobject.c:158
kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545
ib_register_device drivers/infiniband/core/device.c:1472 [inline]
ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393
rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552
rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550
rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225
nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796
rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195
rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450
netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339
netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883
sock_sendmsg_nosec net/socket.c:712 [inline]
__sock_sendmsg net/socket.c:727 [inline]
____sys_sendmsg+0xa95/0xc70 net/socket.c:2566
___sys_sendmsg+0x134/0x1d0 net/socket.c:2620
__sys_sendmsg+0x16d/0x220 net/socket.c:2652
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
This problem is similar to the problem that the
commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name")
fixes.
The root cause is: the function ib_device_rename() renames the name with
lock. But in the function kobject_uevent(), this name is accessed without
lock protection at the same time.
The solution is to add the lock protection when this name is accessed in
the function kobject_uevent().
Fixes: 779e0bf47632 ("RDMA/core: Do not indicate device ready when device enablement fails")
Link: https://patch.msgid.link/r/20250506151008.75701-1-yanjun.zhu@linux.dev
Reported-by: syzbot+e2ce9e275ecc70a30b72@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=e2ce9e275ecc70a30b72
Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
For the upcoming TOP reset, the sw_reset() method may be
called without nic_error() before it. In this case, also
abort any still pending scans and set in_hw_restart.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430155443.b732ff4e9f31.I3948c2d892f1ee82b3a6bf9f123be02a1eaa82e5@changeid
|
|
This was suppsed to be supported only in iwlmld, but turns out that it
will be needed also in iwlmvm. Add support for it.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20250430155443.d118ee63aca4.I12ea349ca6587d8ea606f6ece4a9f3c0c2bb1494@changeid
|
|
This version fixes the issue that was worked around by
iwl_mld_smps_wa. So for FWs with the new version don't do the
workaround, and set new bit added in this version when appropriate.
While at it, rename iwl_mld_smps_wa to iwl_mld_smps_workaround.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Link: https://patch.msgid.link/20250430155443.77fdb18d1ee0.I93688612ac4f6ec99da9bc54bee16554ef40a40b@changeid
|
|
The firmware added a field to describe the platform Id.
Just print it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430155443.dc387ae36e0f.Iafd364c6b23749597b658015be97295ad0c1730d@changeid
|
|
add kunit test to validate entering and exiting
emlsr scenarios when the bt is on with certain
penalty on wifi.
Signed-off-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430155443.6621494fa412.If89b4b2dab308d825ca02284dd8e0030675d7af5@changeid
|
|
PPAG command version 7 will send exact data read from BIOS to
firmware without filtering/altering BIOS data. This enables the
driver to become purely a pipe for this feature.
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/20250430151952.88ed7b2cadef.Iad78f6cec617d1f111b704352795dde81af71a99@changeid
|
|
PPAG revision 4 data has more supported bits than supported in
version 6 of PPAG command. So, adjust by masking accordingly to
firmware acceptance.
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/20250430151952.f1cb31f9f6ab.I56d6887866f76fd02b2cd298e3de1189c6d3890e@changeid
|
|
ppag_ver variable is holding PPAG BIOS revision but name misleading
as PPAG command API version, So rename to ppag_bios_rev.
This will improve code readability but doesn't alter behaviour.
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/20250430151952.be51850947df.If81d88cd2d38299faf1e2a3db5efbc021650f907@changeid
|
|
If iwl_mld_change_vif_links failed to add the requested link(s)
because the FW is dead (error before recovery), there is no point
in returning an error value, as the reconfig will re-add the link(s)
after the FW is started.
Return 0 in that case, and WARN in the others.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250430151952.c549c72b1f37.I445bf723e9befc9541b4abd0ec7c72db8f1ff177@changeid
|
|
Errors can happen, and it is better not to risk with a NULL pointer
dereference.
Make sure that the links-to-remove pointers are not NULL before
dereferencing it.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20250430151952.408652d45cda.I1bb72836dab17895a2e39910e4493d667db0fa80@changeid
|
|
When BT is ON, EMLSR with one of the links operating on 2.4 GHz
is allowed only if it meets following conditions.
In this patch:
1. during link selection, when BT is ON, allow emlsr only if BT
pentalty is < 7%.
2. exit EMLSR if BT is turned ON and one of the links is operating
on 2.4 GHz with BT penalty > 7%
Signed-off-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430151952.d30212ec3901.I48e3d5bd6b0b8583f98057c38d2ee30fff5abd8a@changeid
|
|
For the upcoming SC hardware, a new reset mode "(silent) TOP
reset" will be available. When BT initiates that reset, it'll
negotiate with the WiFi firmware which makes it appear to the
driver as the reset interrupt. To distinguish it from all the
other reasons for the reset interrupt, there's (now) a status
field in CSR 0x110.
Implement the part of TOP reset where we react to BT doing it.
This requires disambiguating the interrupt, depending on the
state of the device, since we can even get TOP reset from BT
while waiting for the reset handshake.
If TOP reset is done by BT while we're not trying to do reset
anyway, then simply reprobe, since we cannot keep the state
of the device as it's being reset, after waiting the needed
180ms to let the device reset/settle.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20250430151952.fb86bfbdca40.Ibe40bf54003e3f8929b671324a395e76eb64a4d8@changeid
|
