ccplex side sees two interrupts. The first one is handled
properly while the second one does not have bit MBOX_OUT_VAID
being set.
Fixing this by reading psc_ext_ctrl register after writing.
Bug 4741744
Change-Id: I22ac1619b7f88a96658c8d197f09daccf3bb40d8
Signed-off-by: Liang Cheng <licheng@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3174350
Reviewed-by: David Pu <dpu@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
- Integrate calibration data structure from
Leopard Imaging hawk driver into NVIDIA
hawk driver
- Rearrange EEPROM calibration data structure to
maintain backward compatibility with HAWK, OWL
modules with EEPROMs programmed using earlier
calibration data structure
- Use separate structures for tracking imu noise
parameters and place it after the module
serial number.
- Change module serial number length used for
reading the serial number from EEPROM data
L4T-4649
Change-Id: I17613905e63fef3fc690dca42a0a10bd1f4fc24d
Signed-off-by: Praveen AC <pac@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3072846
(cherry picked from commit 518ae94bb4)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3073820
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
In Linux v6.11, commit d6f66e292676 ("pwm: Make pwm_request_from_chip()
private to the core") made the function pwm_request_from_chip() a
private function to the PWM core driver. This function is used by both
the CDI and ISC camera drivers and so these driver no longer build
against Linux v6.11.
Fix this by updating the CDI and ISC drivers to use the function
of_pwm_xlate_with_flags() which has been supported since Linux v3.8.
This function internally calls pwm_request_from_chip() and configures
the pwm->args.period parameter and is therefore, equivalent to the
existing code.
Bug 4749580
Change-Id: Id1381ebc08730aaaa6c3591d90bcc4cc95a6c235
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3176063
Reviewed-by: Frank Chen <frankc@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
This patch allows CPU to read and mmap VPR buffers by restricting CPU
VPR read restrictions for pre-si platforms. The knob for controlling the
access is /sys/kernel/debug/nvmap/vpr/vpr_cpu_acces and by default VPR
CPU read is disallowed.
This change is necessary to support pre-si VPR validation for platforms
where there may not be a HW engine that supports CRC computation for VPR
buffers.
Bug 4670086
Change-Id: Ic0d575abbda3cdda10f075a2c7092ced09723333
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3145680
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
When CONFIG_V4L2_ASYNC is not enabled and CONFIG_DEBUG_LIST is enabled
then the following kernel panic is observed ...
imx219: probe of 9-0010 failed with error -524
list_add corruption. next->prev should be prev (ffffb2b2e95dad78),
but was 0000000000000000. (next=ffff000088baf508).
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:23!
Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
If CONFIG_V4L2_ASYNC is not enabled in the kernel, then the function
tegracam_v4l2subdev_register() will return -ENOTSUPP and this will cause
the probe of the sensor drivers to fail. Although failing to probe the
driver is expected in this case, it is not expected that this will
trigger a kernel panic if CONFIG_DEBUG_LIST is enabled. The panic is
caused because tegracam_device_unregister() is not being called in the
exit path of the probe function when tegracam_v4l2subdev_register()
returns an error.
Bug 4704110
Change-Id: I4875a31e55c24b5ab0932a683f16a7a74695a6b6
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3162389
(cherry picked from commit 118cd4e0a6)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3173737
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
During EP deinit, BAR is cleared. However, For T26x, this notification
is triggered from stop() ops callback. Both stop and clear bar executes
on EPC mutex lock, resulting in deadlock.
Since during EP deinit all EP registers are cleared, clear_bar execution
is not needed.
Bug 4567932
Change-Id: I7b28a85a4da51bdaf5228b6462fb723758c46753
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3171420
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
In Linux v6.10, the 'core_init_notifier' flag has been removed and
dw_pcie_ep_init_notify() is now called by the designware endpoint driver
so it is not necessary to call from the EPF DMA test driver. Add a test
to the conftest script to detect the presence of the
'core_init_notifier' flag and update the EPF DMA test driver as
necessary.
Bug 4593750
Change-Id: I1c3862df2c673fcb2d7c19ebbf5e7d1cbdefea1f
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3152309
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
When booting Linux v6.10-rc5 on Tegra234 the CDI MGR driver was failing
to setup the GPIOs. If the driver fails to setup the GPIOs then we
expect the probe of the driver to fail. However, in this case when the
probe failed, it then crashed the kernel completely and the following
crash log was observed ...
cdi-mgr sipl_devblk_3: cdi_mgr_configure_gpios Failed to allocate gpio
desc
cdi-mgr sipl_devblk_3: cdi_mgr_probe(): GPIO setup failed
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000300
...
Call trace:
rt_spin_lock+0x24/0xa8
devres_remove+0x38/0x174
devres_release+0x1c/0x80
devm_gpiod_put+0x24/0x4c
cdi_delete_lst+0x18c/0x1200 [cdi_mgr]
cdi_mgr_debugfs_init+0x608/0x11b0 [cdi_mgr]
platform_probe+0x64/0xec
really_probe+0xb8/0x284
__driver_probe_device+0x74/0x12c
driver_probe_device+0x38/0x114
__driver_attach+0x74/0x13c
bus_for_each_dev+0x74/0xf0
driver_attach+0x20/0x30
bus_add_driver+0xe4/0x20c
driver_register+0x5c/0x130
__platform_driver_register+0x24/0x34
init_module+0x1c/0x1000 [cdi_mgr]
do_one_initcall+0x44/0x2e8
do_init_module+0x58/0x1f8
load_module+0x1b94/0x1cf8
init_module_from_file+0x84/0xc8
__arm64_sys_finit_module+0x1b8/0x270
invoke_syscall+0x40/0x11c
el0_svc_common.constprop.0+0xc4/0xe4
do_el0_svc+0x18/0x28
el0_svc+0x30/0xe0
el0t_64_sync_handler+0xc8/0xcc
el0t_64_sync+0x16c/0x170
Code: b9447420 d503201f 91006262 d2800000 (c8e07c41)
---[ end trace 0000000000000000]---
The problem is that the CDI MGR allocated the gpio descriptors by
calling the function devm_fwnode_gpiod_get_index(). This function
returns an ERR_PTR() on failure. When this does fail and cdi_mgr_del()
is called to clean-up, this does not check to see if the descriptor
IS_ERR(), but simply check if it is NULL or not, which is not correct.
Hence, we end up calling devm_gpiod_put() for an invalid descriptor and
the above crash is observed. Given that we are calling
devm_fwnode_gpiod_get_index() to allocate the descriptor, it is not
necessary to call devm_gpiod_put() at all, because the kernel will
automtically call this for us. Therefore, fix this by removing the call
to devm_gpiod_put() completely.
Please note that although this was caught with Linux v6.10-rc5, this is
applicable to all kernel versions.
Bug 4627271
Change-Id: I576a984ebaaeea590c5acea1b489284379832ae9
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3148004
Reviewed-by: Frank Chen <frankc@nvidia.com>
The RealTek drivers do not build against all Linux distributions because
some Linux distributions have back-ported upstream changes and so the
KERNEL_VERSION checks in the driver do not work for these distributions.
Add compilation flags for these drivers so that we can skip the building
of these drivers for certain Linux distributions.
Please note that the RealTek drivers build fine against Linux v5.14 and
so we should not prevent these driver being built against all Linux
v5.14 kernels.
Bug 4729493
Change-Id: I004d61a884c6f01b4629de56ecc17b55d4fa2cd1
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3171274
(cherry picked from commit 408ef72fb9)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3152308
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Tested-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Syncpoint IRQs are currently requested in a code path that runs
during resume. Due to this, we get multiple overlapping registered
interrupt handlers as host1x is suspended and resumed.
Rearrange interrupt code to only request IRQs during initialization.
Bug 4658418
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Change-Id: I25e129452aeb39c23aa2d6f6a54729f60390d088
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3145171
Reviewed-by: Santosh BS <santoshb@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@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>
- 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>
