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>
Upstream commit 99d5fe9c7f3d ("net: mdio: Remove support for building C45
muxed addresses") removed the definition MII_ADDR_C45 breaking the build
for the nvethernet driver for Linux v6.3. Update the driver to use the
OSI_MII_ADDR_C45 instead.
Bug 4014315
Bug 4075345
Change-Id: I98f8d10ce1a093d458d293b286a4e5a544d48d04
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2889876
Reviewed-by: Rohit Khanna <rokhanna@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Issue: MACSEC is not enabled in DT for eqos_1 and mgbe2_1
interfaces which makes macsec_pdata pointer to NULL.
During suspend/resume macsec_pdata pointer accessed without
NULL check which resulted in crash.
Fix:
o Add NULL pointer checks for macsec_pdata in suspend and resume.
o Remove unnecessary checks for macsec in suspend and resume.
Bug 4060718
Change-Id: I00e042d979e115c088696a8964496ed0054360e5
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2888289
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
1.There is a switch-case where one case is falling to the
next case. This is creating the compilation warning.
Make this fall through as intentional by adding
compiler attribute as "fallthrough".
2.Remove redefinition of macro MII_ADDR_C45
Bug 4055275
Change-Id: I99193b225e97c414588bb306cb48e472ae079f9f
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2882027
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
The functions eth_hw_addr_set() and dev_addr_mod() do not exist for
Linux v5.14 and so compiling the marvell oak driver fails for Linux
v5.14. Fix this by calling memcpy() instead of eth_hw_addr_set() and
dev_addr_mod() for Linux v5.14. Note that both eth_hw_addr_set() and
dev_addr_mod() internally call memcpy() and so this is equivalent.
Bug 3820317
Change-Id: I4b49e031383adf62a55f1d01e8de2fcc0ad47862
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2875022
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
List of changes squashed in this
* From previous commits
- Marvell: oak: Assign random MAC address
- Clear filters to support port mirroring
* New changes to be reviewed
- Terminate pci_device_id table
Jira ESDP-14058
Bug 200702607
Bug 3604084
Change-Id: Ice076a0c8d897292b098ac841f5636b5251db40d
Signed-off-by: Sheetal Tigadoli <stigadoli@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2856989
Reviewed-by: Sumeet Gupta <sumeetg@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Using this patch we are removing the support for
tegra hvnet driver since this is not needed any longer
becasue L+L support has been deprecated.
1. drivers/net/tegra_hv_net.c:361:1: warning: symbol
'tegra_hv_net_get_stats64' was not declared.
Should it be static?
2. drivers/net/tegra_hv_net.c:704:19: warning: assignment
to ‘const void *’ from ‘int’ makes pointer from integer
without a cast [-Wint-conversion]
3. drivers/net/tegra_hv_net.c:704:26: warning: incorrect
type in assignment (different base types)
Bug 3954363
Signed-off-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
Change-Id: I73e7071c1ec4c64072b409e46948aa2e75364be6
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2863099
Reviewed-by: Suresh Venkatachalam <skathirampat@nvidia.com>
Reviewed-by: Sandeep Trasi <strasi@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Ethernet driver expect the VM IRQ configuration. The VM IRQ
is provided with the property "interrupt" which have multiple
VM irq numbers and their configurations via the vm irq
configuration node which is referred by property
"nvidia,vm-irq-config".
The vm irq configuration node have the configuration of
all VM IRQ and each configuration is separated with the
child node like below.
ethernet@6800000 {
nvidia,vm-irq-config = <&mgbe_vm_irq_config>;
}
mgbe_vm_irq_config: mgbe-vm-irq-config {
nvidia,num-vm-irqs = <5>;
vm_irq1 {
nvidia,num-vm-channels = <2>;
nvidia,vm-channels = <0 1>;
nvidia,vm-num = <0>;
nvidia,vm-irq-id = <0>;
};
vm_irq2 {
nvidia,num-vm-channels = <2>;
nvidia,vm-channels = <2 3>;
nvidia,vm-num = <1>;
nvidia,vm-irq-id = <1>;
};
vm_irq3 {
nvidia,num-vm-channels = <2>;
nvidia,vm-channels = <4 5>;
nvidia,vm-num = <2>;
nvidia,vm-irq-id = <2>;
};
vm_irq4 {
nvidia,num-vm-channels = <2>;
nvidia,vm-channels = <6 7>;
nvidia,vm-num = <3>;
nvidia,vm-irq-id = <3>;
};
vm_irq5 {
nvidia,num-vm-channels = <2>;
nvidia,vm-channels = <8 9>;
nvidia,vm-num = <4>;
nvidia,vm-irq-id = <4>;
};
};
};
The child 1(vm_irq1) is link with the VM IRQ 1 listed in
interrupt property, next child which is vm_irq2 is link
with the 2nd VM irq. So, the order of VM configuration
child must be in same order as VM IRQ provided in the
property interrupt.
If the irq configuration order i..e child order is not
matching with VM irq number then there is interrupt issue.
Now, if the VM IRQ config child nodes are provided in base
DT file in same order then the ethernet works fine.
But when applying via overlay, it does not work.
This is because of overlay technique. The overlay logic is
such that it iterates all child node in overlay and
apply the child as first child of target node.
Hence the child sequence provided in overlay fragment
is applied in reverse order in target node. This causes
the irq configuration order not matching with VM IRQs.
To address the overlay issue, read the sequence of
interrupt in property "interrupt" from the newly added property
"nvidia,vm-irq-id" of each child. This way child node
sequence does not matter, and sequence is identified
by property.
Bug 3956724
Change-Id: I5c08edcd8a7e8d3112618dd23050d8b5c10ddc59
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2855639
Reviewed-by: Bhadram Varka <vbhadram@nvidia.com>
Reviewed-by: Narayan Reddy <narayanr@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
When kernel command line debugfs=off is specified instead of
disabling CONFIG_DEBUG_FS in defconfig to disable Debug-FS,
debugfs functions like debugfs_create_dir will fail.
Use function debugfs_initialized() to check if debugfs
functionality is enabled before calling any debugfs functions.
This allows us to by-pass debugfs initialization if debugfs
is not enabled.
Bug 3752450
Change-Id: I17390c2d9928638d940454c2ea1b3abf00ed4264
Signed-off-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2855128
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Building the mttcan driver currently fails for Linux v5.14 with the
following error ...
drivers/net/can/mttcan/native/m_ttcan_linux.c:1535:2: error: unknown
field 'ndo_eth_ioctl' specified in initializer
.ndo_eth_ioctl = mttcan_ioctl,
Fix this by using the appropriate field name for Linux v5.14.
Bug 3820317
Bug 3896592
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Change-Id: I822d988b097350538fbf4a568181e9fde9928ea3
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2836716
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
