The build of device tree is moved to new folder/repo and hence
it is not required to have build support file for device-tree.
Remove the unused file.
Bug 4654821
Change-Id: Id01d634d551d36bc9b36c8971b13ed27f7b6b6d6
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3165347
The execution of conftest currently relies on the GNU toolchain located
in the P4ROOT path. However, since kleaf is a hermetic build, the P4ROOT
environment variable is cleaned up during the kleaf setup. To address
this, we create a symlink to connect the original P4ROOT path to the
kleaf build path.
Bug 4344670
Change-Id: I7877fd5d5543f73001dd1a017dfd0cc552802658
Signed-off-by: Jian-Min Liu <jianminl@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3161994
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Use the kernel-source folder name to hide the kernel version path,
and this folder will be created as symlink. Before building kernel,
the script will build the symlink based on the kernel version of
environment variable. The advantage of this is that there is no need
to change the path whenever the version is updated, and the build
can be switched between different kernel version.
Bug 4344670
Change-Id: Idfc285fee7472bb3d76b6a6cdc1334df5958f4a0
Signed-off-by: Jian-Min Liu <jianminl@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3158772
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Most of the code in the file pci-epf-tegra-vnet.c is written
to support the linux kernel version 5.14.x (x != 0), all minor
version above 0.
Make the condition of linux version check such that 5.14.0 is
also part of 5.14.x i.e. (5.14).
Jira HOSTX-5375
Change-Id: Ib3d7ca619497761b8bc77796c9fe0f59c2ab9cf8
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3166767
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Add conftest to determine if the pci_epc_write_header() has the vfn
argument or not.
Commit 53fd3cbe5e9d791("PCI: endpoint: Add virtual function number
in pci_epc ops") added virtual function number as argument in the
APIs in Linux 5.14.
Jira HOSTX-5375
Change-Id: Ib0b1fbc2a33f9159f3497374d253e264a90f7b4d
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3166765
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Add conftest to determine if the MODULE_IMPORT_NS macro present.
This macro is added in commit 80140a81f7f833 ("module.h: simplify
MODULE_IMPORT_NS") in Linux 5.18.
Jira HOSTX-5375
Change-Id: Ie61dd169d21a0169c44060eb0e3f3fe4a9c149e8
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3166547
- 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>
In Linux v6.10, commit b1ae92dcfa8e ("thermal: core: Make struct
thermal_zone_device definition internal") made the structure
'thermal_zone_device' internal and so the 'devdata' member is no longer
directly accessible. The function thermal_zone_device_priv() was added
in Linux v6.4 for retrieving the 'devdata' and so update the various
thermal drivers to use this function if present.
Bug 4593750
Change-Id: Ic53de9bbd5459c99a3ac26759aa8a966cd775fe5
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3123221
(cherry picked from commit d95c0d0add)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3141886
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
The `cfg_list_item` struct previously defined the `data` array with a zero-length,
which can lead to buffer overflow issues detected by the `fortify_memcpy_chk` function.
So change the zero-length array to a flexible array length.
Bug 4701669
Change-Id: I3c4575efbab681fa8b6039793c410b23c4179106
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3159595
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@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>
Add additional HW SEQ validation checks
- Validate all frames with different addressing modes in a
HW SEQ blob
- Validate multiple frames on a single channel in RDF
frame-linking mode
- Validate each column/row within a given frame since
multiple column/rows are supported in next chip
Bug 4588239
Signed-off-by: Amruta Bhamidipati<abhamidipati@nvidia.com>
Change-Id: Ic30c8c1982c5ac21a960f0546c39e5a28cc7d4bd
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3153297
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Tested-by: Amruta Sai Anusha Bhamidipati <abhamidipati@nvidia.com>
Reviewed-by: Krish Agarwal <krisha@nvidia.com>
Reviewed-by: Sreehari Mohan <sreeharim@nvidia.com>
Reviewed-by: Omar Nemri <onemri@nvidia.com>
NvRmMemHandleAllocAttr can be called with multiple input heaps, if
allocation from first heap fails, then allocation from next heap is
attempted and so on. In case of GPU carveout, the handle size is aligned
to next 2MB while for other heaps, it is aligned to 4KB. If the user
provides an array of heaps, where first one is GPU carveout, then the
handle size is aligned to 2MB and then if the enough memory is not
available in GPU carveout the allocation call fails, but the handle size
is not restored back to 4KB aligned size. So the next allocation attempt
from the second heap would request for incorrect buffer size. Correct
this behavior by restoring the handle size back to 4KB aligned size, if
allocation from GPU carveout fails.
Bug 4661684
Change-Id: I6d93eb96b21e384554df888d9819dcfc2f3565fa
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3159925
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Tested-by: Ashish Mhetre <amhetre@nvidia.com>
In function nvmap_ioctl_get_fd_from_list, the return pointer from nvmap_handle_get_from_id is being dereferenced without checking if it is valid. This is causing a kernel panic crash in syzkaller. Fix this by checking whether the pointer is valid or not before dereferencing it.
Bug 4479038
Change-Id: Ia65341e9eb12873e660baae44d28966e71317377
Signed-off-by: Yash Bhatt <ybhatt@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3154940
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Remove WARN_ON macro invocation and exit gracefully from the nvmap_query_heap_params function when the heap_mask parameter is not a power of two. This is because if two or more bits are set in heap_mask, then it's an invalid parameter because NvMap can allocate buffer from only one heap at a time.
Bug 4479038
Change-Id: I6cfca911115f7f29e2c4e46816a89fa1869adae4
Signed-off-by: Yash Bhatt <ybhatt@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3154939
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
As part of profiler show operation triggered through sysfs,
profiler data is only seen in the kernel log.
Add a change to copy the profiler contents in the profiler
buffer as well so that the buffer content is visible at the
place where sysfs read is issued.
Note that there is a limitation in buffer size used in sysfs
read and write operations, which is equal to PAGE_SIZE.
And so, checks are added to detect buffer overflow while
writing profiler data in the buffer.
Jira ASSA-934
Change-Id: Ice3eccdfffbd7734ac7a20a0a8ca52ba00af865e
Signed-off-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3154262
(cherry picked from commit b619de032dfd58ffc385b08d26353991e2ae3d9b)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3158713
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Tested-by: Bitan Biswas <bbiswas@nvidia.com>
The L4T packaging needs the soc specific dummy driver to be
available always. However, it is not available in generic build and
it creates the packaging/configuration fail.
Add soc specific dummy driver for pcie so that the respective binary
should be available always.
Bug 4695516
Change-Id: Ic40e60a12de35cebc7e9acec9b09e39aa267276b
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3154314
Tested-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Tested-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
