Issue:
L4T platforms on boot comes up with MTU as 1500.
However on changing the MTU to jumbo, the final
MTU which gets set accounts the MACSEC ICV tag
len and reduces the MTU by 34 bytes even though
the platform does not support MACSEC.
Fix:
Assign macsec allocated private data to NULL and
use the NULL check in ndo mtu change ioctl call
to reject MTU reduction if macsec is not supported.
Bug 4137597
Change-Id: Ica3003b54762dd5d240c9b0c5c012049b4e503b2
Signed-off-by: Sushil Kumar Singh <sushilkumars@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2928569
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Tested-by: Revanth Kumar Uppala <ruppala@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Upstream Linux kernel commit b48b89f9c189 ("net: drop the weight
argument from netif_napi_add") removes the weight argument from the
netif_napi_add() function and this is breaking the build of a few
drivers that use this function. Fix this by updating these drivers
to use the netif_napi_add_weight() function instead for Linux v6.1.
Finally, allow building the realtek wireless driver for kernels other
than v5.15 so that we can ensure it will build against other kernel
versions.
Bug 3750163
Change-Id: If179d044c00bfa83c9902973c642717263d9e3de
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2942057
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Issue:
Ethernet mplan stability tests at -20C for 10Mbps fails with rate 15%
Basically the GPHY 10M power saving includes the below parameters,
clock speed down, pll off and reference voltage off.
During debugging it was found that enable/disable pll circuit
frequently when in 10M low data traffic (such as idle mode) may have
a corner case and plays a part in this issue repro.
Fix:
So plloff saving function should be disable (do not have to open it) for nvidia -20C mplan test case.
Bug 3946623
Change-Id: I87ab9b487fe5924ee9ee16bbb14d7f8c19f3a4e7
Signed-off-by: Sushil Kumar Singh <sushilkumars@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2939046
Tested-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
(cherry picked from commit 80f6470d40821bfbad8f8166d22442e949b47173)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2942039
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
ether_get_tx_ts, pdata->tx_ts_ref_cnt is an atomic variable
that is used as a mutex in this function and should not return 0
if the function fails to acquire the mutex.
The workqueue is scheduled when the return value of the
judgment function is <0. If one CPU core execution softirq
is running in ether_get_tx_ts function and another CPU core
softirq also calls ether_get_tx_ts function to get hardware
timestamp, then the acquisition of mutex fails and return 0.
After returning 0, the workqueue is not scheduled.
The timestamp cannot be obtained in time. So ether_get_tx_ts
should returns -1 on failure to acquire the mutex.
Bug 4150416
Change-Id: Icffd409b349d8bb8dbf5a483124b3bd3d7ef6cc8
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2934350
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
If DEBUGFS is not enabled, then the following warning is observed ...
drivers/net/ethernet/nvidia/nvethernet/sysfs.c:3321:6:
error: unused variable [-Werror=unused-variable]
3321 | int ret = 0;
| ^~~
Fix this by ensuring that 'ret' is only defined if the DEBUGFS is
enabled.
Bug 4190165
Change-Id: I0182874592f20abe8d53b7bfdcfd099518b23f9c
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2938450
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Compiling the nvethernet driver without the ccflag CONFIG_TEGRA_NVPPS
defined generates the following warning ...
drivers/net/ethernet/nvidia/nvethernet/ether_linux.c:2936:5:
warning: "CONFIG_TEGRA_NVPPS" is not defined, evaluates to 0 [-Wundef]
2936 | #if CONFIG_TEGRA_NVPPS
| ^~~~~~~~~~~~~~~~~~
Fix this by using '#ifdef' to determine if CONFIG_TEGRA_NVPPS is
defined instead of '#if'.
Bug 4190030
Change-Id: Id1523de6f9ef9f4c72669584efb77ffd9ddf20f3
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2938375
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Building the nvethernet driver generates the following warning ...
drivers/net/ethernet/nvidia/nvethernet/ether_linux.c:6730:1: warning:
the frame size of 3664 bytes is larger than 2048 bytes
[-Wframe-larger-than=]
For now allow the frame size to be 4096 bytes to resolve the warning
while a proper fix is implemented.
Bug 4190030
Change-Id: I5460ec04c80458174c2c51dd0058b7cc191fe808
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2934698
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Building the realtek wireless driver generates various warnings due to
incorrect indentation or missing curly braces. For example, the
following warnings are seen ...
drivers/net/wireless/realtek/rtl8822ce/core/rtw_mlme.c: In function
‘rtw_drv_scan_by_self’:
drivers/net/wireless/realtek/rtl8822ce/core/rtw_mlme.c:3167:17:
warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
3167 | else
| ^~~~
drivers/net/wireless/realtek/rtl8822ce/core/rtw_mlme.c:3170:25:
note: ...this statement, but the latter is misleadingly indented as if
it were guarded by the ‘else’
3170 | goto exit;
| ^~~~
drivers/net/wireless/realtek/rtl8822ce/core/efuse/rtw_efuse.c:917:17:
warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
917 | if (i % 16 == 0)
| ^~
Fix the indentation and add the necessary curly braces to resolve these
warnings.
Bug 4190030
Change-Id: Ic13f1470043190ffd8401581cb97c908070c2940
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2934697
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-by: Shobek Attupurath <sattupurath@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Issue:
MGBE0 ASID is getting programmed for all the MAC instances
which inturn causing the data transfer failures.Macsec is not enable
and hence instance_id is not getting updated to the corresponding mac
instance number and hence all mac instance_id's are initialized with 0.
Since ASID programming is based on mac instance_id, all MACs are
programmed with MGBE0 MAC instance id.
Fix:
Moved reading of instance_id from DT out of macsec_probe and hence the
instance_id gets updated irrespective of MAC sec enable/disable.
Bug 4124937
Change-Id: I500ed8d3db402995488260af99ad190217ff6dd2
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2925252
Reviewed-by: Narayan Reddy <narayanr@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Commit db1a63aed89c ("net: phy: Remove fallback to old C45 method")
removes a fallback C45 method in the MDIO bus driver. This breaks
nvethernet support for Linux v6.3 and the following errors are observed.
failed to register MDIO bus (nvethernet_mdio_bus)
net eth0: failed to register MDIO bus
Fix this by adding the necessary read/write_c45 callbacks in the
nvethernet driver. Note these callbacks are only supported for Linux
v6.3+ kernels.
Bug 4014315
Change-Id: Ia6ab753941db0515799657da8522f32996d0852a
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2924619
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-by: Narayan Reddy <narayanr@nvidia.com>
When mttcan
- is set into DAR (Disable Automatic Retransmission) mode
- and Protocol Exception Handling is enabled
- and PXE (Protocol Exeception Event) is generated
then no TCF (Transmission cancellation Finished) event is generated.
This leads to mismatch between internal driver state and mttcan HW
state. This results in "no buffer space available" error.
This patch clears the driver internal state in close callback to
handle this situation.
Bug 200502350
Change-Id: Ie9f8fcc902a8d9b6c65662888904be5ad9aae49e
Signed-off-by: Abhijit <abhijit@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2854706
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2921328
Tested-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
Reviewed-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
Reviewed-by: Suresh Venkatachalam <skathirampat@nvidia.com>
Reviewed-by: Sandeep Trasi <strasi@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Adding unmodified Lan7431 driver to nvidia-oot
This is the unmodified driver from
K5.15.110
from commit cd612ec8f71740b0fc9f47d3356b23561b5761dc
For future kernels we'll need to add the driver sources
from the respective kernel
Bug 3956901
Change-Id: I376c63ceeb6aeab9ce5d17dcd3c09401217c576a
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2920947
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Tested-by: Jeremy Alves <jalves@nvidia.com>
Reviewed-by: Jeremy Alves <jalves@nvidia.com>
Reviewed-by: Sumeet Gupta <sumeetg@nvidia.com>
The nvethernet driver has a dependency on the NVPPS driver which in
turn has a dependency on the GTE driver. The GTE driver is being
transitioned to the new upstream HTE driver and while this transition is
on-going, allow the nvethernet driver to be distributed and built
without NVPPS and GTE.
Note that by default the dependency on the NVPPS driver is enabled by
setting CONFIG_TEGRA_NVPPS to 'y'. Only if the user sets
CONFIG_TEGRA_NVPPS to 'n' will it be disabled.
Bug 3918941
Bug 3961133
Change-Id: I019e5ebfddfcb158b0a684d2eacc404231577166
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2913273
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-by: Bhadram Varka <vbhadram@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Issue:
Observed below compilation issues
on the nvethernet driver for DRIVE Linux safety
builds as some macros/functions are defined with
"OSI_STRIPPED_LIB" protection but they are used
directly without any protection.
1./automotive-dev-main-20230516T005516255/out/embedded-linux-generic-release-safety/nvidia/kernel-rt_patches-nvidia-oot/nvidia-oot/drivers/net/ethernet/nvidia/nvethernet/sysfs.c:2641:33: error: ‘OSI_INSTANCE_ID_EQOS’ undeclared (first use in this function)
2641 | if (osi_core->instance_id == OSI_INSTANCE_ID_EQOS)
| ^~~~~~~~~~~~~~~~~~~~
2./automotive-dev-main-20230516T005516255/out/embedded-linux-generic-release-safety/nvidia/kernel-rt_patches-nvidia-oot/nvidia-oot/drivers/net/ethernet/nvidia/nvethernet/sysfs.c:2733:3: error: ‘dev_attr_hsi_enable’ undeclared here (not in a function)
2733 | &dev_attr_hsi_enable.attr,
| ^~~~~~~~~~~~~~~~~~~
Fix:
Add OSI_STRIPPED_LIB macro protection
for required functions.
Bug 3959085
Change-Id: Ifef1c72b5ddedc4d550280eace305bbade290bbf
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2905357
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Issue: skb_vlan_tag_get gives only the VLAN_ID for
the earlier kernel versions (K4.9) and hence added
a logic to take care of adding the VLAN priority
explicitly and hence the VLAN priority getting
modified in a newer kernel version where VLAN PRIO is
already included
Fix: remove the logic of explicit adding of VLAN
priority.
Bug 3788862
Bug 4088361
Change-Id: I0ac9ebfe21d3e696ac1b0f6ba540c010928f775f
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2806468
(cherry picked from commit 799b17fc35f3bc3ec75ea93452c03bd52ed28527)
Signed-off-by: Narayan Reddy <narayanr@nvidia.com>
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2895043
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Issue:
During eth0 down case, the link change gets called twice,
1. due to ndo close
2. due to interrupt generated by phy.
The ether_adjust_link callback also configures the EEE settings
and calls phy_init_eee (a phy framework API) for the same.
Here a race condition occur, when ether_close sets phydev to NULL
before the phy_init_eee gets called (from ether_conf_eee) which tries
to deference the phydev causing kernel panic.
[35779.541305] Call trace:
[35779.544018] phy_init_eee+0x24/0x290
[35779.547455] ether_conf_eee+0x110/0x1310 [nvethernet]
[35779.552525] ether_conf_eee+0x4e0/0x1310 [nvethernet]
[35779.557840] phy_link_change+0x40/0x90
[35779.561603] phy_state_machine+0x190/0x240
[35779.565643] process_one_work+0x1c4/0x4d0
[35779.569396] worker_thread+0x54/0x430
[35779.573072] kthread+0x148/0x180
[35779.576586] ret_from_fork+0x10/0x34
[35779.580069] Code: a90153f3 d5384113 a9025bf5 12001c36 (f941b801)
[35779.586195] ---[ end trace 2ea5b6492f36b0cb ]---
[35779.590737] Kernel panic - not syncing: Oops: Fatal exception
Fix:
Add a NULL check and return -ENODEVICE in EEE configuration
Bug 3877272
Bug 3920560
Bug 3865666
Bug 4088361
Change-Id: I2b26c6eeabb7a109b9d14b3bd2a035f5c3b3c6fa
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2854404
(cherry picked from commit 40606dc247eacf2a8987687777874575d9037058)
Signed-off-by: Sushil Kumar Singh <sushilkumars@nvidia.com>
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2855237
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Issue: If the supplicant is killed for some reason Data would flow
plain on that interface, this needs to be avoided
Fix: Update bypass LUT such that if the frames from the VF(on which
supplicant is launched) is received on MACSEC either authenticate the
same or drop. Along with this handles below items as well. All the VFs MACIDs
are obtained in OSI to update the bypass LUTs to decide on which VF frames
to be authenticated and which VF frames needs to be bypassed.
1. Remove osi_macsec_en API and have single API to init and deinit
2. Remove explicit command from supplicant to set control port and
set protected frames. Handle the same in osi_macsec_init
Bug 3984665
Change-Id: I8bc8aa95d1e21e99e992b471fb70ed58073163f7
Signed-off-by: Sanath Kumar Gampa <sgampa@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2878515
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
