WLAN_AKM_SUITE_FT_OVER_SAE(0x000FAC09) is not processed in
rtw_cfg80211_set_key_mgt, which makes rtw_ft_validate_akm_type not set
RTW_FT_PEER_EN to ft_flags, and thus MDIE is not built in
rtw_ft_build_assoc_req_ies
Fix:
- Add WLAN_AKM_SUITE_FT_OVER_SAE into rtw_cfg80211_set_key_mgt check condition
- Add 9 into rtw_ft_valid_akm check condition
- Update driver version number to 277-9-6
Bug 5580277
Change-Id: I7cc987a9141dc65577dc20e804e92def10e9412e
Signed-off-by: Shaofu <shaofu@realtek.com>
Signed-off-by: Narayana Reddy P <narayanr@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3485741
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
Reviewed-by: Shobek Attupurath <sattupurath@nvidia.com>
----------------------------------
rtl8852ce release notes for Nvidia
----------------------------------
v1.19.16_nv-277-9-0-g3c314be22.20251020_Certified_Module
- same as v1.19.16_nv-277-9-g3c314be22.20250903_Certified_Module_beta
- just remove "beta" string for formal release
==================================================================
v1.19.16_nv-277-9-1-gc6d0f2e20.20251015_Certified_Module_beta
* If ROAM CMD (wpa_cli roam), do scan if bssid not found even in busy traffic
Tested:
- simple connection test: PASS
- wpa_cli roam command is work and show prev_bssid in log: PASS
==================================================================
v1.19.16_nv-277-14-ga7d65c4a9.20251002_Certified_Module_beta
* fix the deauth reason 7 caused by roaming racing
* downgrade the fwstate debug level
==================================================================
v1.19.16_nv-277-12-g1a8402802.20250926_Certified_Module_beta
* add fwstate debug log
==================================================================
v1.19.16_nv-277-11-g3b6c1d36e.20250925_Certified_Module_beta
* default enable ACS and RSSI debug
* add reauth and reassoc timeout config via insmod or /proc/
==================================================================
Bug 5504994
Change-Id: I3ecd41fdb28de12bf6e37d9dfaca5c7f40e2fe1d
Signed-off-by: Narayana Reddy P <narayanr@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3473467
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Shobek Attupurath <sattupurath@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
During system shutdown, a kernel crash could occur because the r8126
driver's tally counter update routine (`rtl8126_dump_tally_counter`)
was still accessing PCIe address space after the device was already
stopped or powered down.
To prevent this, introduce a new driver flag `R8126_FLAG_SHUTDOWN`
that is set in `rtl8126_shutdown()`. This flag is checked
now before accessing tally counters, ensuring no further
crash during shutdown.
Bug 5620576
Change-Id: I2bb74fc52e712198bfe15b109a2136dc8a2affcd
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3482325
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Ninad Malwade <nmalwade@nvidia.com>
Tested-by: Ninad Malwade <nmalwade@nvidia.com>
Reviewed-by: Shobek Attupurath <sattupurath@nvidia.com>
In the previous release for T264 platforms,the restart lane bringup
logic was controlled through the device tree flag
'nvidia,pcs-rx-eq-sw-ovrd'.
In incremental releases, the flag has been renamed
'nvidia,force-restart-lane-bringup'.
To maintain backward compatibility with older device trees,
the driver now checks for both flags.If either flag is present,
restart lane bringup is executed.
The legacy flag 'nvidia,pcs-rx-eq-sw-ovrd' is deprecated.
Bug 5017313
Change-Id: I24040f508ef776e29a0bb0c1f07d4a74fa4cc8cc
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3471233
Reviewed-by: Srinivas Ramachandran <srinivasra@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
The MTTCAN controller uses different core clock frequencies depending on
the SoC variant: 40MHz for T264 and 50MHz for T194/T234. The 8Mbps data
bitrate needs to be an exact divisor of the clock frequency for proper
operation.
For 40MHz clock: 8Mbps = 8000000 bps (40MHz / 5)
For 50MHz clock: 8Mbps = 8333333 bps (50MHz / 6)
The previous single MTTCAN_SPEED_8MBPS definition (8333333) only worked
correctly for 50MHz clocks and would not divide evenly for 40MHz clocks.
Split MTTCAN_SPEED_8MBPS into two separate defines:
- MTTCAN_SPEED_8MBPS_40MHZ: 8000000 for exact 8Mbps on 40MHz clock
- MTTCAN_SPEED_8MBPS_50MHZ: 8333333 for closest 8Mbps on 50MHz clock
Both values use the same production settings (prod_c_can_8m) and will be
selected based on the chip's configured clock frequency. The 5Mbps rate
remains unchanged as it divides evenly for both clock frequencies.
Bug 5497458
Change-Id: I17190ae6821f89d33e76114f20b91dbd65ba25f2
Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3469194
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Tested-by: Kevin Fu <chunhuaif@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
In Linux v6.16, the structure 'data_bittiming_params' was added to the
'can_priv' structure and all the related data bittiming parameters were
moved under this new structure. Add a test to conftest to determine if
this new structure is present and update the Tegra MTTCAN driver
accordingly.
JIRA LINQPJ14-60
Change-Id: Ibd8f6bd81a903b15a55d837023dada835a1e72ca
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3374645
(cherry picked from commit 86396ec47b78a7716a5faa8d492d74efc7f23dce)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3461874
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
----------------------------------
rtl8852ce release notes for Nvidia
----------------------------------
v1.19.16_nv-126-16-gbf1934e39.20250910_Certified_Module_beta
* fix scan issue in roaming test
==================================================================
v1.19.16_nv-126-15-ge5204803f.20250827_Certified_Module_beta
* Fix bug of 802.11d CC scan mechanism
[Description]
The 11d CC scan result may sometimes be overwritten by other scans.
==================================================================
v1.19.16_nv-126-14-g196875f8d.20250821_Certified_Module_beta
* fix 6G MBSSID disconnect problem
[Description]
Fix the issue where RSSI was not updated in non-transmitted BSSID, which could
cause disconnection due to incorrect RSSI values.
==================================================================
v1.19.16_nv-126-13-g7a2b96406.20250813_Certified_Module_beta
* fix 6G Enhanced open mode not work
[Description]
(1) Parse capabilities in MBSSID
e.g. Vendor Specific OUI WMM IE
Non-Inheritance IE
(2) Handle MBSSID sets
(3) Adjust MAX IE size from 768 to 1840 defined in WIFI Alliance
Bug 5422314
Bug 5226667
Change-Id: I63802c34fdc6e189566843d11992ff64b8e404fa
Signed-off-by: Narayana Reddy P <narayanr@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3450784
Reviewed-by: Shobek Attupurath <sattupurath@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
A function called hrtimer_setup() was added in Linux v6.13 with the
intent that it would eventually replace hrtimer_init(). In Linux v6.15
the hrtimer_init() function was removed.
Use conftest to call the appropriate API based on what is defined
in the kernel.
Bug 5466808
Change-Id: I1c1c4e81c840a058d8c4c0b1616c87cb8a8a8beb
Signed-off-by: Brad Griffis <bgriffis@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3436079
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Issue - When WiFi operating channel is switched, at times the wifi
role index and role bitmap show that there is already a role
assigned for the channel context and this causes a failure in association. Kernel warning is shown when this occurs.
Fix - Update driver to v126-10 that fixes this issue.
[ 57.590860] Call trace:
[ 57.590861] rtw_phl_chanctx_add+0x528/0x8f4 [rtl8852ce]
[ 57.590947] rtw_clear_is_accepted_status+0x4a4/0xbb8 [rtl8852ce]
[ 57.591033] cur_req_hdl+0x3c/0x4c [rtl8852ce]
[ 57.591118] msg_dispatch+0x2dc/0x3f8 [rtl8852ce]
[ 57.591204] dispr_thread_loop_hdl+0x270/0x2dc [rtl8852ce]
[ 57.591289] dispr_share_thread_loop_hdl+0x10/0x1c [rtl8852ce]
[ 57.591374] share_thread_hdl+0xb8/0x1a0 [rtl8852ce]
[ 57.591459] kthread+0x110/0x124
[ 57.591466] ret_from_fork+0x10/0x20
Bug 5440351
Bug 5442104
Change-Id: Ie78c70c1ea7a789351a2ba4ad445c4d0062281da
Signed-off-by: Shobek Attupurath <sattupurath@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3426784
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
Problem:
- When a Downstream Port Containment (DPC) software trigger is issued, the LTR_EN bit in the Root Port (RP) is cleared as per PCIe spec.
- However, LTR_EN bit of RTL8126 endpoint (EP) which is being expected to reset is still active and sends Latency Tolerance Reports (LTR) to RP.
- This behavior violates the PCIe spec, as LTR_EN is a non-sticky bit and should be cleared automatically on reset.
- As the RP has LTR disabled but the EP still sends LTR messages, it results in Unsupported Request (UR) errors on the RP.
- These UR errors trigger AER (Advanced Error Reporting) recovery, which includes a Secondary Bus Reset (SBR).
- The SBR causes the PCIe link to go down and come back up, but the EP again starts sending LTRs, leading to a infinite error-recovery loop.
Workaround:
- As a temporary fix, disable the LTR_EN bit in the RTL8126 EP during its probe.
- This prevents the EP from sending LTR messages, thereby avoiding UR errors and breaking the loop of AER recovery.
Impact:
- Disabling LTR prevents the EP from entering the L1.2 low power state.
- However, ASPM is currently not enabled in the system, so this workaround has no impact.
Bug 4869463
Change-Id: Ibf7effaeb0f22e952645ef7bf6a18287264e1463
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3420019
Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Previously, this option was disabled because the clang version
used was too old (clang-r370808, clang 10). This option has been
supported since clang-r416183b, clang 12. In order to avoid potential
build errors, this option is re-enabled.
Bug 5289423
Change-Id: I1d0fd5a3dfdff06e95eeca13f85a263922c6ecaf
Signed-off-by: Jian-Min Liu <jianminl@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3371014
Reviewed-by: Ankita Garg <ankitag@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
In Linux v6.15, the timer APIs hrtimer_init() and del_timer() have been
removed. The hrtimer_setup() was added in Linux v6.13 to replace
hrtimer_init() and hrtimer_init() have finally been removed. The
functions del_timer()/del_timer_sync() were renamed to
timer_delete()/timer_delete_sync() in Linux v6.15. Use conftest to
detect these changes and update the drivers as necessary.
JIRA LINQPJ14-47
Change-Id: Id3994900384aad4b91155507cda91e04898ab12c
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3336168
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Issue: Below issue observed while running TCP_TX perf test
for longer duration.
nvethernet a808a10000.ethernet: [validate_ctx][1082][type:0x2][loga-0x84d2] dma_txrx: Invalid frame len
nvethernet a808a10000.ethernet mgbe0_0: Tx ring[0] is full
nvethernet a808a10000.ethernet mgbe0_0: Tx ring[0] is full
nvethernet a808910000.ethernet eqos_0: Tx ring[0] is full
This is a regression due to the below change -
https://git-master.nvidia.com/r/c/linux-nv-oot/+/3258684
The issue is that TSO packet is being treated as Non-TSO packet.
pskb_expand_head return code is returned directly where it can
return zero for TSO packet.
Fix:
Removed pskb_expand_head since headers are not getting updated in SW.
HW takes care performing the TSO handling. Also optimized the checks
in TSO path code.
Bug 5175569
Change-Id: I7f48ed32898fec51581bf034b953f0ef7a9913f0
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3322354
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Srinivas Ramachandran <srinivasra@nvidia.com>
