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>
In Linux v6,15, a 'speed' argument was added to the phy_loopback()
function. Add a conftest test to detect this change and update the
nvethernet driver accordingly. Note that if 'speed' is set to 0 when
calling phy_loopback(), then phy_loopback() behaves the same way as it
did before this argument was added. So by default set speed to 0 for the
nvethernet driver.
JIRA LINQPJ14-47
Change-Id: I55f775e672bfa1a00c9ccbd825c82be1868b0b52
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3330685
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
This patch ensures that the Maximum Payload Size (MPS) and Maximum Read Request Size (MRRS) settings of the root port associated with r8168 ethernet endpoint are properly configured after overwritten by kernel when pcie_bus_perf is enabled.
Bug 4607316
Change-Id: I7f7b83f74e4ac2104345bd568d9d2e7c03a1441e
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3273562
Reviewed-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Issue: on resume the mac set speed is not called due
to which the data transmissions are not happening in
alternate suspend resume cycles.
This is because the oldlink status is not set to 1 during
the successful resume, in set_speed_work_func retries
Fix: set oldlink to 1 once setspeed is successful in
function set_speed_work_func, so that next time
ether_adjust_link will call the set speed after resume
Bug 4891730
Change-Id: Iadb426f2cada99387ce180dfa2d0c9ee57e7ccd5
Signed-off-by: Bibhay Ranjan <bibhayr@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3260342
Reviewed-by: Bhadram Varka <vbhadram@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
issue: PHY ID allocation is failing during the
stress test of insmod and rmmod of nvethernet
module, since PHYIDs were exhausing during the
module insertion.
fix: deregister fixed link in remove for
freeing up the PHYIDs which were allocated during
probe.
Bug 4754744
Signed-off-by: Narayan Reddy <narayanr@nvidia.com>
Change-Id: I6e71c684d4fcc5bb99a971c7d4d41726998cd8ec
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3245742
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: Bhadram Varka <vbhadram@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Mohan Thadikamalla <mohant@nvidia.com>
Transmit: Add test_tx_bandwidth_dump_enable support to
transmit packets from the driver which helps measure
line rate for 25G and 10G.
pkt1500, pkt8192, pkt64 packet sizes can be configured.
Receive- Drop Packets at the driver level.
Bug 4742868
Change-Id: I52fe1b73b169dfedc06afea5fb62d7bc21fd9ba1
Signed-off-by: Nagaraj Annaiah <nannaiah@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3197198
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Building the rtl8852ce driver with various different Linux v6.x kernels
fail for various reasons.
For Linux v6.6 the build fails with errors such as ...
drivers/net/wireless/realtek/rtl8852ce/phl/phl_sta.c: In function
'phl_cmd_set_seciv_hdl':
drivers/net/wireless/realtek/rtl8852ce/phl/phl_sta.c:4907:16: error:
implicit conversion from 'enum rtw_hal_status' to
'enum rtw_phl_status' [-Werror=enum-conversion]
4907 | return rtw_hal_set_dctrl_tbl_seciv((void*)phl_info->hal,
| sta, sta->sec_iv);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For Linux v6.8 the build fails with the above and the following ...
drivers/net/wireless/realtek/rtl8852ce/phl/phl_sta.c:301:5: error:
no previous declaration for '_phl_get_macid'
[-Werror=missing-declarations]
301 | u16 _phl_get_macid(struct phl_info_t *phl_info,
| ^~~~~~~~~~~~~~
For Linux v6.10 the build fails with the above and the following ...
drivers/net/wireless/realtek/rtl8852ce/core/rtw_ap.c:6265:9: error:
suggest braces around empty body in an 'else' statement
[-Werror=empty-body]
6265 | ;
| ^
drivers/net/wireless/realtek/rtl8852ce/core/rtw_sta_mgt.c:742:1: error:
'static' is not at beginning of declaration
[-Werror=old-style-declaration]
742 | u32 static _rtw_free_core_stainfo(_adapter *padapter , struct
| sta_info *psta, u8 aid,
| const u8 *hwaddr)
| ^~~
For Linux v6.12, the driver build is completely broken because of the
following build error ...
drivers/net/wireless/realtek/rtl8852ce/os_dep/linux/wifi_regd.c:1007:17:
error: too few arguments to function 'cfg80211_cac_event'
1007 | cfg80211_cac_event(evt->netdev, &evt->chandef,
| evt->event, GFP_KERNEL);
| ^~~~~~~~~~~~~~~~~~
For Linux v6.6+ mark the driver as broken and do not build this for
Linux v6.6+ kernels until these issues are addressed.
Bug 4667769
Change-Id: Id6b060f6b39ba4ef64d6388e06ef1e038c19206f
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3226276
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3242573
Reviewed-by: svcacv <svcacv@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Shobek Attupurath <sattupurath@nvidia.com>
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>
