Age | Commit message (Collapse) | Author |
|
Add functions for creation/destruction of the new type of general object.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Reviewed-by: Alex Vesker <valex@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
|
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Reviewed-by: Alex Vesker <valex@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
|
This way we are able to allocate chunk for modify_headers from 2 types:
STEv0 that is allocated from the action area, and STEv1 that is allocating
the chunks from the special area for patterns.
Signed-off-by: Muhammad Sammar <muhammads@nvidia.com>
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Reviewed-by: Alex Vesker <valex@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
|
Starting with ConnectX-6 Dx, we use new design of modify_header FW object.
The current modify_header object allows for having only limited number
of FW objects, so the new design of pattern and argument allows pattern
reuse, saving memory, and having a large number of modify_header objects.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Reviewed-by: Alex Vesker <valex@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
|
Move ACTION_CACHE_LINE_SIZE macro to header to be used by
the pattern functions as well.
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Reviewed-by: Alex Vesker <valex@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"These add two ACPI-related quirks:
- Add a quirk to force StorageD3Enable on AMD Picasso systems (Mario
Limonciello)
- Add an ACPI IRQ override quirk for ASUS ExpertBook B1502CBA (Paul
Menzel)"
* tag 'acpi-6.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: resource: Skip IRQ override on ASUS ExpertBook B1502CBA
ACPI: x86: utils: Add Picasso to the list for forcing StorageD3Enable
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fix from Rafael Wysocki:
"Make the amd-pstate cpufreq driver take all of the possible
combinations of the 'old' and 'new' status values correctly while
changing the operation mode via sysfs (Wyes Karny)"
* tag 'pm-6.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
amd-pstate: Fix amd_pstate mode switch
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull thermal control fix from Rafael Wysocki:
"Modify the Intel thermal throttling code to avoid updating unsupported
status clearing mask bits which causes the kernel to complain about
unchecked MSR access (Srinivas Pandruvada)"
* tag 'thermal-6.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thermal: intel: Avoid updating unsupported THERM_STATUS_CLEAR mask bits
|
|
Pull rdma fixes from Jason Gunthorpe:
"We had a fairly slow cycle on the rc side this time, here are the
accumulated fixes, mostly in drivers:
- irdma should not generate extra completions during flushing
- Fix several memory leaks
- Do not get confused in irdma's iwarp mode if IPv6 is present
- Correct a link speed calculation in mlx5
- Increase the EQ/WQ limits on erdma as they are too small for big
applications
- Use the right math for erdma's inline mtt feature
- Make erdma probing more robust to boot time ordering differences
- Fix a KMSAN crash in CMA due to uninitialized qkey"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/core: Fix GID entry ref leak when create_ah fails
RDMA/cma: Allow UD qp_type to join multicast only
RDMA/erdma: Defer probing if netdevice can not be found
RDMA/erdma: Inline mtt entries into WQE if supported
RDMA/erdma: Update default EQ depth to 4096 and max_send_wr to 8192
RDMA/erdma: Fix some typos
IB/mlx5: Add support for 400G_8X lane speed
RDMA/irdma: Add ipv4 check to irdma_find_listener()
RDMA/irdma: Increase iWARP CM default rexmit count
RDMA/irdma: Fix memory leak of PBLE objects
RDMA/irdma: Do not generate SW completions for NOPs
|
|
Merge a quirk to force StorageD3Enable on AMD Picasso systems (Mario
Limonciello).
* acpi-x86:
ACPI: x86: utils: Add Picasso to the list for forcing StorageD3Enable
|
|
bcma/main.c uses of_dma_configure() which is declared in of_device.h.
of_device.h gets implicitly included by of_platform.h, but that is going
to be removed soon.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230410232701.1561613-1-robh@kernel.org
|
|
Handle them the same way as the devices with 3-4 USB out endpoints.
This is needed for the RTL8192FU.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/ef4bc66d-84f5-4021-efd7-1787d097519c@gmail.com
|
|
Add some new members to rtl8xxxu_fileops and use them instead of
checking priv->rtl_chip.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/e24a5534-6e33-cfb9-0634-0caf4646513f@gmail.com
|
|
Add SDIO ids for use with the muRata 1YN (Cypress CYW43439).
The odd thing about this is that the previous 1YN populated
on M.2 card for evaluation purposes had BRCM SDIO vendor ID,
while the chip populated on real hardware has a Cypress one.
The device ID also differs between the two devices. But they
are both 43439 otherwise, so add the IDs for both.
On-device 1YN (43439), the new one, chip label reads "1YN":
```
/sys/.../mmc_host/mmc2/mmc2:0001 # cat vendor device
0x04b4
0xbd3d
```
EA M.2 evaluation board 1YN (43439), the old one, chip label reads "1YN ES1.4":
```
/sys/.../mmc_host/mmc0/mmc0:0001/# cat vendor device
0x02d0
0xa9a6
```
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230407203752.128539-1-marex@denx.de
|
|
In AP mode, 'sta' could be NULL if sending broadcast/multicast packets,
so we should check before accessing, or it causes crash:
BUG: kernel NULL pointer dereference, address: 0000000000000004
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 2 PID: 92 Comm: kworker/u33:0 Tainted: G OE
Workqueue: rtw89_tx_wq rtw89_core_txq_work [rtw89_core]
RIP: 0010:rtw89_core_tx_update_desc_info+0x2cc/0x7d0 [rtw89_core]
Code: e2 01 41 be 04 00 00 00 41 8b 84 c4 0c 01 00 00 75 0d 45 31 f6 ...
RSP: 0018:ffffb4cf807afce0 EFLAGS: 00010297
RAX: 0000000000000001 RBX: ffffb4cf807afd48 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
RBP: ffffb4cf807afd30 R08: ffff9b28c1e59808 R09: ffff9b28c0297100
R10: 00000000052cf7c4 R11: 00000000052cf7c4 R12: ffff9b28c1602040
R13: ffff9b28c07b3000 R14: 0000000000000004 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff9b2a73280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000004 CR3: 00000001ca410003 CR4: 00000000000606e0
Call Trace:
<TASK>
rtw89_core_tx_write+0x7c/0x100 [rtw89_core]
rtw89_core_txq_work+0x1b4/0x530 [rtw89_core]
process_one_work+0x222/0x3f0
worker_thread+0x50/0x3f0
kthread+0x16b/0x190
? rescuer_thread+0x3a0/0x3a0
? set_kthread_struct+0x50/0x50
ret_from_fork+0x22/0x30
</TASK>
Fixes: e5307c9cd7ee ("wifi: rtw89: set data lowest rate according to AP supported rate")
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230406093009.5869-1-pkshih@realtek.com
|
|
Use primary channel index to determine which 5 MHz mask should be enable.
This mask is used to prevent noise from channel edge to effect CCA
threshold in wide bandwidth (>= 40 MHZ).
Fixes: 1b00e9236a71 ("rtw89: 8852c: add set channel of BB part")
Fixes: 6b0698984eb0 ("wifi: rtw89: 8852b: add chip_ops::set_channel")
Cc: stable@vger.kernel.org
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230406072841.8308-1-pkshih@realtek.com
|
|
These tables are used by RF calibrations to assist to configure PHY and
RF registers.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230401142548.55466-4-pkshih@realtek.com
|
|
These tables contain BB and RF parameters that driver will load them into
registers. It also contains TX power according to country, band, rate and
so on. Increasing thermal can cause TX power degraded, so power tracking
tables are defined to compensate TX power.
Internal version of these tables:
- HALBB_029_106_15 (V17)
- HALRF_029_00_089
* Radio A 0x22
* NCTL 0x5
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230401142548.55466-3-pkshih@realtek.com
|
|
These tables contain BB and RF parameters that driver will load them into
registers. It also contains TX power according to country, band, rate and
so on. Increasing thermal can cause TX power degraded, so power tracking
tables are defined to compensate TX power.
Internal version of these tables:
- HALBB_029_106_15 (V17)
- HALRF_029_00_089
* Radio A 0x22
* NCTL 0x5
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230401142548.55466-2-pkshih@realtek.com
|
|
Many settings of 8851B are like 8852A or 8852B. Change them to proper
settings as hardware design.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230330133324.19538-5-pkshih@realtek.com
|
|
Many settings of 8851B are the same as 8852B or 8852A, like DLE (Data link
engine), security engine and so on. Update them according to hardware
design.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230330133324.19538-4-pkshih@realtek.com
|
|
For two RF paths chips, we normally set path B as main path by default.
8851B has single one RF path, so set TX path to A and set mapping of
path B to 0.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230330133324.19538-3-pkshih@realtek.com
|
|
The chip contains digital and analog parts, and each of them has its own
version number. This is used by BT coexistence mechanism to make strategy
decision for different analog version.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230330133324.19538-2-pkshih@realtek.com
|
|
Turn on hardware CFO (central frequency offset) compensation based on IC
capability, and improve digital CFO compensation accuracy by using
more fixed points number.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230330132352.13647-1-pkshih@realtek.com
|
|
One chip can have different RFE (RF front end) types which we will judge
at runtime. And, different RFE types may use different RF parameter tables.
Though we didn't really meet this case previously, we are going to meet it
on upcoming chip RTL8851B. So, this commit handles parameter tables for
runtime RFE type.
We now encapsulate rtw89_txpwr_rule_<2/5/6>ghz tables into rtw89_rfe_parms.
Then, each chip defines its default parameter tables, and if needed, it can
configure extra parameter tables by RFE type. Finally we determine runtime
parameter tables by RFE type if one is configured. Otherwise, we use the
default parameter tables.
For now, we just move all settings under default parameter tables. We will
configure parameter tables by RFE types in separate commits afterwards.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230330080331.37155-1-pkshih@realtek.com
|
|
drivers
In the discuss threads [1] [2], new firmware format break user space
because older drivers can't recognize new firmware format. To avoid this,
the new format will be named rtw89/rtw8852b_fw-1.bin and only new driver
try to load it. Old drivers only load original and understandable firmware
rtw89/rtw8852b_fw.bin.
More, new driver will be still backward compatible with old firmware, so
original firmware can be used by new driver.
If there is newer firmware format is introduced, rtw89/rtw8852b_fw-2.bin
will be given. The same rules will be applied like above. So, we will have
firmware like below in linux-firmware in the future.
rtw89/rtw8852b_fw-2.bin
rtw89/rtw8852b_fw-1.bin
rtw89/rtw8852b_fw.bin
After this patch, MODULE_FIRMWARE() of 8852A/B/C become
rtw89/rtw8852a_fw.bin
rtw89/rtw8852b_fw-1.bin
rtw89/rtw8852c_fw.bin
[1] https://lore.kernel.org/linux-wireless/df1ce994-3368-a57e-7078-8bdcccf4a1fd@gmail.com/T/#m24cb43be31a762d0ea70bf07f27ae96c59f6931b
[2] https://bugzilla.kernel.org/show_bug.cgi?id=217207
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230320130606.20777-4-pkshih@realtek.com
|
|
Since we are going to load more than one firmware and some are not
presented or optional, using asynchronous API request_firmware_nowait()
will become complicated. Also, we want to use firmware_request_nowarn()
to avoid warning messages when loading optional files. So, use
schedule_work to be simpler.
To abstract loading a firmware or file, define a struct rtw89_fw_req_info
containing a struct firmware and a completion to ensure this firmware is
loaded completely.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230320130606.20777-3-pkshih@realtek.com
|
|
In early feature bitmap obtained from rtw89_early_fw_feature_recognize(),
the bits needed to check get increased. It's more friendly to work with
RTW89_CHK_FW_FEATURE(). So, we concentrate the flow of iterating FW feature
configures and calling RTW89_SET_FW_FEATURE() for various uses. And then,
we adjust rtw89_early_fw_feature_recognize() for RTW89_CHK_FW_FEATURE().
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230320130606.20777-2-pkshih@realtek.com
|
|
We used to store operating channel info after associated. However, scan
might happen before that. Without switching back to operating channel,
authentication or association might fail. Therefore, we switch back to
operating channel when the scanning vif's BSSID is non-zero, which
implies connected or during attempt to connect.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230411124832.14965-6-pkshih@realtek.com
|
|
Use POWER_ON flag to make sure power on/off is symmetric. Since both
remain_on_channel and hw_scan both alter the power state, this makes
sure that we don't enter/leave IPS mode twice.
Also, replace IPS related functions with inline function that does
similar logic so we can track it more easily.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230411124832.14965-5-pkshih@realtek.com
|
|
Add support of remain on channel ops. Since channel context is
required to enable multi-channel concurrent(MCC) and the current
ROC in mac80211 don't support more than 1 channel context, add this
to let P2P and other protocols relying on this work as expected.
The off-channel duration and cancel timing is purely controlled by
upper layers.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230411124832.14965-4-pkshih@realtek.com
|
|
Allocate a per-skb completion to track those skbs we are interested in
and wait for them to complete transmission with TX status.
Normally, the completion object is freed by wait side, but it could be
timeout result that complete side should free the object instead. Add a
owner field with RCU to determine which side should free the object.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230411124832.14965-3-pkshih@realtek.com
|
|
Adding this supports beacon filter and connection quality monitor.
To make host CPU wake up less, let firmware perform signal
monitoring and beacon processing, then notify driver upon signal
changes or beacon loss.
This feature needs firmware 0.27.56 or newer to support it.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230411124832.14965-2-pkshih@realtek.com
|
|
On some Qualcomm platforms, like SC8280XP, the attempt to set PC mode
during boot fails with PSCI_RET_DENIED and since commit 998fcd001feb
("firmware/psci: Print a warning if PSCI doesn't accept PC mode") this
is now logged at warning level:
psci: failed to set PC mode: -3
As there is nothing users can do about the firmware behaving this way,
demote the warning to info level and clearly mark it as a firmware bug:
psci: [Firmware Bug]: failed to set PC mode: -3
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The if statement here is misleading, we return zero anyway
since we just checked the 'ret' variable, simplify the code
to remove the condition entirely.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.57c1eb58e655.I1b47a7771cd66306931089c150c6b5b240bdcba5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The setting of the rate used for non station cases did not take into
consideration the interface type etc., thus when probe responses
are transmitted on P2P Device interface etc. CCK rates were used
which is not allowed.
Modify the code so the non station case would consider the
interface type etc. For HWs/FWs that do not support rate control,
preserve the previous behavior, i.e., take the rate from the
skb metadata and adjust as needed.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.fa0e4d42205d.Iab4784560c77b965fec070d4d0a1ec84171d94ff@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If we have MLO, then the deflink.ap_sta_id cannot be used.
However, we can use the new mvmvif->ap_sta pointer for the
validation instead.
Also don't do it multiple times for different FW instances
of the same AP STA (TDLS STAs are only on a single link).
Note that this isn't really working right yet since the
underlying flush code hasn't been updated yet to know of
multiple link STAs.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.7d747df44d65.Ie5392859fab4cfb73c20b49bfee2caadef5fd8ec@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Implement the full STA mask and selecting the correct link
for key installation.
While at it, catch errors if this function returns a bad
zero station mask, rather than waiting for the firmware to
crash on it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.cedae2f21829.Iae07b736c3109d085ad5b74ec8282ce45020da39@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If adding a key to firmware fails we leak the allocated ptk_pn.
This shouldn't happen in practice, but we should still fix it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.99446ffd02bc.I82a2ad6ec1395f188e0a1677cc619e3fcb1feac9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We never needed this to be non-static, that was just an
artifact of the development process. Make it static.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.3c018c15f948.I87fd1aee288f33312a7206492608002d4e8e213e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Instead of relying on the AP STA ID and dereferencing our
firmware -> mac80211 STA array when we really only need
the STA, not the per-link information (and might not have
it, e.g. for a pairwise key installation where this is
relevant), keep track of the AP STA as a pointer to the
mac80211 STA, protected by the mutex. Then use it here in
the key code instead.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.7db01b1508de.I88e6d252cdb0a6e4581d7c5fd7cbc037b4fd40ae@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
An integer overflow occurs in the iwl_write_to_user_buf() function,
which is called by the iwl_dbgfs_monitor_data_read() function.
static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count,
void *buf, ssize_t *size,
ssize_t *bytes_copied)
{
int buf_size_left = count - *bytes_copied;
buf_size_left = buf_size_left - (buf_size_left % sizeof(u32));
if (*size > buf_size_left)
*size = buf_size_left;
If the user passes a SIZE_MAX value to the "ssize_t count" parameter,
the ssize_t count parameter is assigned to "int buf_size_left".
Then compare "*size" with "buf_size_left" . Here, "buf_size_left" is a
negative number, so "*size" is assigned "buf_size_left" and goes into
the third argument of the copy_to_user function, causing a heap overflow.
This is not a security vulnerability because iwl_dbgfs_monitor_data_read()
is a debugfs operation with 0400 privileges.
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.2d80ace81532.Iecfba549e0e0be21bbb0324675392e42e75bd5ad@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Clang static analysis reports this representative issue
dbg.c:1455:6: warning: Branch condition evaluates to
a garbage value
if (!rxf_data.size)
^~~~~~~~~~~~~~
This check depends on iwl_ini_get_rxf_data() to clear
rxf_data but the function can return early without
doing the clear. So move the memset before the early
return.
Fixes: cc9b6012d34b ("iwlwifi: yoyo: use hweight_long instead of bit manipulating")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.872a7175f1ff.I33802a77a91998276992b088fbe25f61c87c33ac@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Clang static analysis reports this issue
d3.c:567:22: warning: The left operand of '>' is
a garbage value
if (seq.tkip.iv32 > cur_rx_iv32)
~~~~~~~~~~~~~ ^
seq is never initialized. Call ieee80211_get_key_rx_seq() to
initialize seq.
Fixes: 0419e5e672d6 ("iwlwifi: mvm: d3: separate TKIP data from key iteration")
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.6dd372f84f93.If1f708c90e6424a935b4eba3917dfb7582e0dd0a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
There is a spelling mistake in a IWL_DEBUG_SCAN debug message. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.eac55cbef8f1.I15cc5d3f1489759bf915bfb3cbbb72b67b18f8b6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
There is a spelling mistake in a IWL_ERR error message. Fix it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.a00965734d02.I760cb43829b3d7a0f567f0958059f2fae0aa8a93@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Enable the new FW API with MLD based on FW TLV.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.5dc66b08539e.I1c65024c879346b0349e1e431d36ec2b5fd85dd7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add support for a new PCI device ID 0x272b once registering with PCIe.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.56342664110d.I5aa6f2858fdcf69fdea4f1a873115a48bd43764e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add RF step id handling and handle for BZ device.
Read CNV Aux register and uses for no OTP case.
Add missing rf support for Bz/Bnj device and correct/add
the mapping for rf-type if OTP not present.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230414130637.8f2e2fff7bbc.Iee5554178bc5f134dcc28591db0968e619afbdca@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In case of UHB scan that follows a scan on legacy bands,
consider both scan commands as part of the same scan cycle,
and thus configure them to use the same antenna configuration.
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230413213309.fd582c423ad8.I35239f94cb3ee1642d16936199c336a07ec2df8f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|