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>
The nvethernet driver fails to build for Linux v5.14 and Linux v5.17+
kernels. In Linux v5.15 the return type of the get/set_coalesce
callbacks were updated. In Linux v5.17 the parameters for the
get/set_ringparam callbacks were updated. In Linux v6.1 the
weight parameter for the netif_napi_add() function was removed and the
function netif_napi_add_weight() was added for passing the weight
parameter. Add the necessary kernel version checks to ensure that the
drivers build with the different versions of the Linux kernel.
Bug 3793131
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Change-Id: I56738eddd27eb4ebf7db5a2d0d031a64379482e8
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/2820712
Reviewed-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Issue: If OSI_RX_SWCX_REUSE flag is set in OSI then
OSD will not reallocate the buffer for that descriptor
index. It will re-use the same buffer virt/physical
addresses. If that buffer is a reserved buffer then OSI
will not process that so it will result in packet drops.
Fix: Reuse the buffer is OSI_RX_SWCX_REUSE flag is set
and the buffer is not a reserved buffer.
Bug 3727058
Change-Id: I3331604a90b2cbe902d91f2082e1fe36f830decc
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2745194
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Issue:
1) dev_queue_xmit acquired the per queue tx lock and called driver
transmit routine.
2) During the transmit - common interrupt asserted which tries to
acquire the same tx lock which resulted in lock recursion.
Fix: Move the lock acquire to tasklet context under common isr.
Bug 3773016
Change-Id: I7cfd49beb1238286d3bccd9e4b9ccc054c4f6d30
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2770227
Reviewed-by: Narayan Reddy <narayanr@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
GVS: Gerrit_Virtual_Submit <buildbot_gerritrpt@nvidia.com>
Issue: In the current scenrio, when the remote
interface is brought down and up. There is no way
of getting the link up again with the remote device
which in turn fails the data transfers even though
interface from other end is brought up.
Fix: When interface is gone down on the other side,
MAC receives local faults and in this scenario
no data should be sent to MAC, so disable network
queues and initiate the lane bring up process for
monitoring the link status. Once the link is up,
re enable the network queues for data transfers.
Also added support for enabling driver logs using
msglvl of ethtool
Bug 3744088
Bug 3654543
Bug 3665378
Change-Id: I16cdee74e4e3ff6cd176924575f5005f385d4c5d
Signed-off-by: Narayan Reddy <narayanr@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2730876
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Rakesh Goyal <rgoyal@nvidia.com>
Reviewed-by: Bhadram Varka <vbhadram@nvidia.com>
Reviewed-by: Srinivas Ramachandran <srinivasra@nvidia.com>
GVS: Gerrit_Virtual_Submit
Issue: If WOL is enabled after running "./ethtool -s eth0 wol g"
command there will not be any eapol frames transaction, hence macsec
will be disabled. As macsec is disabled before suspend we are not
enabling it back once resumed. Because of this eapol frames are also
sent with sec-tag as byp_lut is not programmed.
Fix: Instead of depending on the macsec state, check if there is any
supplicant running, if there is any supplicant then enable the macsec
post resume.
Bug 3577131
Change-Id: I6018b94411034eebba34f5f0a9520907305c573e
Signed-off-by: Sanath Kumar Gampa <sgampa@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2694446
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Bhadram Varka <vbhadram@nvidia.com>
Reviewed-by: Mahesh Patil <maheshp@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc-mobile-cert <svc-mobile-cert@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
GVS: Gerrit_Virtual_Submit
Issue: Observed Tx timestamp timeout from application since
workqueue is not getting scheduled at the driver layer to consume
the Tx timestamp from the OSI layer which resulted in tx_timeout
from APP layer.
Fix: Invoke the timestamp consume function in tx done instead
of scheduling through workqueue. Schedule the work queue only
if the timestamp is not found.
Bug 3658701
Change-Id: If97aebc1980f685e3cc34f135ace91298ee78657
Signed-off-by: Bhadram Varka <vbhadram@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2732444
Reviewed-by: Troy Kong <troyk@nvidia.com>
Reviewed-by: Narayan Reddy <narayanr@nvidia.com>
Reviewed-by: svc-mobile-coverity <svc-mobile-coverity@nvidia.com>
Reviewed-by: svc_kernel_abi <svc_kernel_abi@nvidia.com>
Reviewed-by: Rakesh Goyal <rgoyal@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Tested-by: Troy Kong <troyk@nvidia.com>
GVS: Gerrit_Virtual_Submit
Issue: Name of the nl_family is nv_macsec for all the interfaces
hence even if the macsec is enabled for one interface and disabled for
other interfaces, supplicant can be launched for all the interfaces.
Fix: Use the interface name for the nl_family name hence supplicant can
check if macsec is enabled in DT before initializing supplicant for that
particular interface
Bug 3673434
Change-Id: I33d62a0ab2b74f7f53abcd8e6629c1b013eede86
Signed-off-by: Sanath Kumar Gampa <sgampa@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nvidia/+/2726483
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
