Adding support in existing mttcan driver to control T264 FSI
CAN controllers from CCPLEX whether FSI firmware is loaded on
system or not. FSI CAN clocks will be enabled by FSI crystal clock
upon boot. SW does not need to enable or control clocks. CCPLEX cannot
control FSI controller resets, reset can be handled during boot, thus
disabled clocks and reset for T264 SOC.
Bug 4317516
Change-Id: I8e6b20640c8763ebc0a9d9192e3212a49902f9b4
Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
Issue: 1. Not able to launch supplicant on second VF
2. When launching supplicant on VF1, MACSec link on VF0 is getting lost
Fix: Do not program CAR registers as part of OSD as the same is being
taken care by Server and also do not register for MACSec interrupts.
Same is being handled in Server
2. Enabled packet duplication for MultiCast frames when launching
supplicant
Bug 4824402
Change-Id: I7b26298da8c94df2da823e36476bc37acf6123cd
Signed-off-by: Sanath Kumar Gampa <sgampa@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3201116
Reviewed-by: Mahesh Patil <maheshp@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Nagaraj Annaiah <nannaiah@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
[Issue]: CAN freezes/stops to send messages after restart from bus-off state.
Throws following log from kernel: "write: No buffer space available"
[Reason]: When message txfer starts, tx_object (which keeps track of active tx)
gets filled. If CAN goes to bus-off state, txfer remains incomplete for some
messages. In such case, tx_object bits will not get cleared. It will stop
adding more messages in controller RAM.
Along with tx_object, from network layer, there are socket echo buffers.
When CAN is initialized and up on network, netif_start_queue is pushed to start
transmission. When msg txfer starts, socket buffer gets filled and freed only
when txfer completes. During bus-off, since network queue remains ON, all the
queued msgs get filled in socket buffers and does not allow upcoming msgs.
Therefore we see "write: No buffer space available".
[Fix]: Clear tx_object when device goes to bus-off state and stop network queue.
Start network queue again during restart from bus-off.
Bug 4438223
Change-Id: I3cbc6529a90f357372c8b0095bdce4217b133e9b
Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3142091
(cherry picked from commit f902d95962)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3144103
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Release Notes:
1. Add extra queue to handle EAPOL
Mark include/autoconf.h RTW_EAPOL_QUEUE to disable it
2. Use xmit_ext queue to TX eapol packet
3. Flush roam_buf_pkt after roaming is fail
4. Do NOT roam if previous roam does NOT finish
5. Report to WPS after all roam retries are failed
6. Support 11K beacon report fragmentation
7. Fix compile error on Kernel 5.19.2
Bug 4556940
Change-Id: I2137a24a1eadb1b5eac8e53126909863cec4747b
Signed-off-by: Shobek Attupurath <sattupurath@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3202805
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
In Linux v6.11, the structure 'kernel_ethtool_ts_info' was added as a
copy of the existing 'ethtool_ts_info' for the kernel and the various
kernel functions were updated to use the new structure. This broke the
build for the nvethernet driver, so add a test to the conftest script to
detect the presence of this new strucutue and update the nvethernet
driver accordingly.
Bug 4749580
Change-Id: I2c5daa0132edee8c98eec3a66e19144484325ab0
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3176868
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
The RealTek drivers do not build against all Linux distributions because
some Linux distributions have back-ported upstream changes and so the
KERNEL_VERSION checks in the driver do not work for these distributions.
Add compilation flags for these drivers so that we can skip the building
of these drivers for certain Linux distributions.
Please note that the RealTek drivers build fine against Linux v5.14 and
so we should not prevent these driver being built against all Linux
v5.14 kernels.
Bug 4729493
Change-Id: I004d61a884c6f01b4629de56ecc17b55d4fa2cd1
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3171274
(cherry picked from commit 408ef72fb9)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3152308
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Tested-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
- Remove restriction to allow multicast addresses to be added to byp_lut
and sci_lut
- Also update the usage of macsec_enable node to enable/disable both Tx
and Rx traffic
- Fix the issue of generating same Hkey for differet SAK by moving the Hey
key generation logic post obtaining SAK
Bug 4715173
Bug 4715001
Change-Id: I7d3088a1f58203a474b659c7197bacc05e8510dd
Signed-off-by: Sanath Kumar Gampa <sgampa@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3164153
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
- Adding WAR to ignore lane bringup restart task
as it is causing lane bring up failures in SLT EQOS/MGBE
- Populate RSS hash table with enabled num_of_dma channels
Bug 4709627
Change-Id: I195db0371f69dfcedc1c67023c1279af426dd7e6
Signed-off-by: Mahesh Patil <maheshp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3162313
Reviewed-by: Nagaraj Annaiah <nannaiah@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
When nvethernet was updated to support Linux v6.9 kernels, the code that
checks if the variable 'eee_req->advertised' is zero or non-zero was not
updated correctly. For Linux v6.9, the variable 'eee_req->advertised' is
a bitmask and so cannot be checked directly to see if it is zero or
non-zero. Building the nvethernet driver with the flag '-Werror=address'
exposed this issue. Fix this by using the 'linkmode_empty()' function to
determine if 'eee_req->advertised' is zero or non-zero for Linux v6.9
kernels.
Bug 4471899
Bug 4662166
Change-Id: Id4080d62006226648cd398dc8652578c74dd8158
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3158064
Tested-by: Shanker Donthineni <sdonthineni@nvidia.com>
Reviewed-by: Rohit Khanna <rokhanna@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Shanker Donthineni <sdonthineni@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Tested-by: Rohit Khanna <rokhanna@nvidia.com>
Issue: IOCTLs from supplicanta pplication are not reaching Nvidia
Ethernet driver in kernel 6.1
Fix: Filled the correct policy while registering with netlink. Added
Cipher Suite attribute to genl macsec policy
Ported from -
https://git-master.nvidia.com/r/c/nvethernet-docs/+/3126784
Bug 4316709
Change-Id: I7d0b86d14b1d5bb9aff34b79d635bfccd7443ebf
