WLAN_AKM_SUITE_FT_OVER_SAE(0x000FAC09) is not processed in
rtw_cfg80211_set_key_mgt, which makes rtw_ft_validate_akm_type not set
RTW_FT_PEER_EN to ft_flags, and thus MDIE is not built in
rtw_ft_build_assoc_req_ies
Fix:
- Add WLAN_AKM_SUITE_FT_OVER_SAE into rtw_cfg80211_set_key_mgt check condition
- Add 9 into rtw_ft_valid_akm check condition
- Update driver version number to 277-9-6
Bug 5580277
Change-Id: I7cc987a9141dc65577dc20e804e92def10e9412e
Signed-off-by: Shaofu <shaofu@realtek.com>
Signed-off-by: Narayana Reddy P <narayanr@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3485741
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
Reviewed-by: Shobek Attupurath <sattupurath@nvidia.com>
----------------------------------
rtl8852ce release notes for Nvidia
----------------------------------
v1.19.16_nv-277-9-0-g3c314be22.20251020_Certified_Module
- same as v1.19.16_nv-277-9-g3c314be22.20250903_Certified_Module_beta
- just remove "beta" string for formal release
==================================================================
v1.19.16_nv-277-9-1-gc6d0f2e20.20251015_Certified_Module_beta
* If ROAM CMD (wpa_cli roam), do scan if bssid not found even in busy traffic
Tested:
- simple connection test: PASS
- wpa_cli roam command is work and show prev_bssid in log: PASS
==================================================================
v1.19.16_nv-277-14-ga7d65c4a9.20251002_Certified_Module_beta
* fix the deauth reason 7 caused by roaming racing
* downgrade the fwstate debug level
==================================================================
v1.19.16_nv-277-12-g1a8402802.20250926_Certified_Module_beta
* add fwstate debug log
==================================================================
v1.19.16_nv-277-11-g3b6c1d36e.20250925_Certified_Module_beta
* default enable ACS and RSSI debug
* add reauth and reassoc timeout config via insmod or /proc/
==================================================================
Bug 5504994
Change-Id: I3ecd41fdb28de12bf6e37d9dfaca5c7f40e2fe1d
Signed-off-by: Narayana Reddy P <narayanr@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3473467
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Shobek Attupurath <sattupurath@nvidia.com>
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
During system shutdown, a kernel crash could occur because the r8126
driver's tally counter update routine (`rtl8126_dump_tally_counter`)
was still accessing PCIe address space after the device was already
stopped or powered down.
To prevent this, introduce a new driver flag `R8126_FLAG_SHUTDOWN`
that is set in `rtl8126_shutdown()`. This flag is checked
now before accessing tally counters, ensuring no further
crash during shutdown.
Bug 5620576
Change-Id: I2bb74fc52e712198bfe15b109a2136dc8a2affcd
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3482325
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Ninad Malwade <nmalwade@nvidia.com>
Tested-by: Ninad Malwade <nmalwade@nvidia.com>
Reviewed-by: Shobek Attupurath <sattupurath@nvidia.com>
In the previous release for T264 platforms,the restart lane bringup
logic was controlled through the device tree flag
'nvidia,pcs-rx-eq-sw-ovrd'.
In incremental releases, the flag has been renamed
'nvidia,force-restart-lane-bringup'.
To maintain backward compatibility with older device trees,
the driver now checks for both flags.If either flag is present,
restart lane bringup is executed.
The legacy flag 'nvidia,pcs-rx-eq-sw-ovrd' is deprecated.
Bug 5017313
Change-Id: I24040f508ef776e29a0bb0c1f07d4a74fa4cc8cc
Signed-off-by: Revanth Kumar Uppala <ruppala@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3471233
Reviewed-by: Srinivas Ramachandran <srinivasra@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
When BWMGR is unavailable, BWMGR could be either unsupported and
disabled in BPMP firmware.
For unsupported state, MRQ_BWMGR_INT is not available to use.
For disabled state, MRQ_BWMGR_INT is available but sending any
MRQ_BWMGR_INT request will just get -BPMP_NODEV error code.
Add error handling logic to make min_freq and max_freq devfreq sysfs
nodes as read-only but still expose devfreq nodes, such as
available_frequencies, min_freq, and max_freq, to allow user space
apps to read information from.
Bug 5555075
Change-Id: Id7c2695765d3dfee148a0d1bc1f7b0552fe4b343
Signed-off-by: Johnny Liu <johnliu@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3467128
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Rajkumar Kasirajan <rkasirajan@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Replace struct hack pattern with flexible array members in msgq_t
and msgq_message_t to resolve UBSAN warnings.
The message queue implementation was using the old "struct hack"
pattern with single-element arrays (int32_t queue[1] and
int32_t payload[1]) to create variable-length structures. While
functionally correct, this triggers UBSAN array-index-out-of-bounds
errors when accessing elements beyond index 0, even though the
memory is properly allocated.
UBSAN errors observed:
- msgq.c:64: index 2045 out of range for type 'int32_t [1]'
- msgq.c:69: index 153 out of range for type 'int32_t [1]'
- msgq.c:124: index 53 out of range for type 'int32_t [1]'
- msgq.c:148: index 53 out of range for type 'int32_t [1]'
- msgq.c:149: index 2045 out of range for type 'int32_t [1]'
Changes:
1. Convert queue[1] to queue[] in msgq_t structure
2. Convert payload[1] to payload[] in msgq_message_t structure
3. Update MSGQ_HEADER_SIZE and MSGQ_MESSAGE_HEADER_SIZE macros
to use sizeof() directly, as flexible array members have zero
size and cannot be used with sizeof()
The flexible array member (FAM) approach is:
- C99 standard compliant
- Linux kernel best practice for variable-length structures
- Binary compatible with the previous implementation
- Eliminates UBSAN false positives without functional changes
Bug 4831393
Change-Id: I243d4a1b1f091bf17cfc10337e75dbd1b878042f
Signed-off-by: Asha Talambedu <atalambedu@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3464624
Reviewed-by: Mohan kumar <mkumard@nvidia.com>
Reviewed-by: Viswanath L <viswanathl@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
The MTTCAN controller uses different core clock frequencies depending on
the SoC variant: 40MHz for T264 and 50MHz for T194/T234. The 8Mbps data
bitrate needs to be an exact divisor of the clock frequency for proper
operation.
For 40MHz clock: 8Mbps = 8000000 bps (40MHz / 5)
For 50MHz clock: 8Mbps = 8333333 bps (50MHz / 6)
The previous single MTTCAN_SPEED_8MBPS definition (8333333) only worked
correctly for 50MHz clocks and would not divide evenly for 40MHz clocks.
Split MTTCAN_SPEED_8MBPS into two separate defines:
- MTTCAN_SPEED_8MBPS_40MHZ: 8000000 for exact 8Mbps on 40MHz clock
- MTTCAN_SPEED_8MBPS_50MHZ: 8333333 for closest 8Mbps on 50MHz clock
Both values use the same production settings (prod_c_can_8m) and will be
selected based on the chip's configured clock frequency. The 5Mbps rate
remains unchanged as it divides evenly for both clock frequencies.
Bug 5497458
Change-Id: I17190ae6821f89d33e76114f20b91dbd65ba25f2
Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3469194
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
Tested-by: Kevin Fu <chunhuaif@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
We cannot use enum definitions in '#if defined()' statements because the
'#if defined()' is a preprocessor macro that is evaluated prior to
compilation. Fix this by adding a test to conftest to detect if
CMD_PCIE_RP_CONTROLLER_OFF is defined.
Bug 5551652
Change-Id: I71826a58e428f1a335e8e0d895f25f3cea46a65e
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3467641
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Prakhar Srivastava (SW-TEGRA) <prasrivastav@nvidia.com>
Upstream commit a55893133830 ("gpiolib: Remove unused
devm_gpio_request()") removed the devm_gpio_request() function and this
breaks the Tegra USS IO Proxy driver. The devm_gpiod_get() function has
been supported in the Linux kernel since v4.3 and now that the legacy
GPIO functions are being removed, migrate the Tegra USS IO Proxy driver
over to using GPIO descriptors.
Bug 4387902
Bug 5420210
Change-Id: I0c62977dc4ec829e14f105babdd08bbd64113fa2
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3423827
(cherry picked from commit e4572a5ff434f778178b1dfb39b4c1cf7923db6d)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3462463
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Currently the wakeup source is configured if only the 'ext_wake' is
valid. However, the bluedroid_pm_timer and proc interface that are
configured when 'ext_wake' is valid, also assumes that 'host_wake' is
also valid. Therefore, update the code to only configure the
bluedroid_pm_timer and proc interface if both of these are valid.
Bug 4958861
Change-Id: I16ef55359c36acc9dc50464f43816ae2ef3c3123
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3397252
(cherry picked from commit b1e18d66aa0ab6d491b88caac5fa9abddb69d0e4)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3462461
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
The structure returned from the function wakeup_source_register() is not
currently checked to see that a valid structure is returned. If
wakeup_source_register fails to register the wake-up source, then this
function will return a NULL pointer and this will lead to a crash when
defereferencing this pointer. Therefore, check that a valid structure is
returned from wakeup_source_register() and if not then return an error
from the probe function.
JIRA LINQPJ14-60
Bug 4958861
Change-Id: I03356700ab03d6c25080b3806ea8b7da3983a302
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3394894
(cherry picked from commit 14286052fb9dd496b243221fa1066f828451b294)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3405519
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
The function devm_gpiod_get_optional() will return an error code encoded
as a pointer type if the GPIO requested is not found. Therefore, we need
to use the IS_ERR() macro to determine if the GPIO is valid, otherwise
we could incorrectly attempt to dereference an invalid pointer. This bug
was introduced when migrating the bluedroid driver to use the gpiod
functions.
Bug 4387902
Bug 4958861
Change-Id: Ib9e7494c92226454d93506c2c0d4c80bd6a7493c
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3397231
(cherry picked from commit b461fa1a87f9beb5faa1dc917956603430b12df7)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3405518
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
There are 2 timer defined. One statically and one in the
bluedroid_pm_data struct. Both timers call the same function on expiration. In the case of the statically defined timer this is a problem because it assumes that the timer is part of the bluedroid_pm_data and so calling timer_container_of() or from_timer() results in an invalid pointer and hence kernel panic. Fix this by
removing the statically defined timer.
Bug 4958861
Change-Id: I08f9dc3a032f84ca3350fbec5fb97062da8d6795
Signed-off-by: Bruce Xu <brucex@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3400991
(cherry picked from commit 61490c6a2a65e24068cd33a92d8730260ad83f95)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3405517
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
In Linux v6.16, the 'of_node' structure was removed from the
'i2c_board_info' structure and the 'cdi-mgr' driver fails to build.
Although it is possible to detect whether the 'i2c_board_info' structure
has the 'of_node' structure using conftest, the 'cdi-mgr' driver does
not even use this. Therefore, it is simpler to fix this by using memset
and strncpy to initialize the 'i2c_board_info' structure and this also
aligns the camera 'cdi-mgr' driver with the camera 'isc-mgr' driver that
initializes the 'i2c_board_info' structure in this way.
JIRA LINQPJ14-60
Change-Id: I1d9df0fb1ccea3d303f256f65d187a131b7352ad
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3374654
(cherry picked from commit 30cad15a2e832ad445003911a76627fb18f91b49)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3461876
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
In Linux v6.16, the structure 'data_bittiming_params' was added to the
'can_priv' structure and all the related data bittiming parameters were
moved under this new structure. Add a test to conftest to determine if
this new structure is present and update the Tegra MTTCAN driver
accordingly.
JIRA LINQPJ14-60
Change-Id: Ibd8f6bd81a903b15a55d837023dada835a1e72ca
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3374645
(cherry picked from commit 86396ec47b78a7716a5faa8d492d74efc7f23dce)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3461874
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
In Linux v6.16, commit 41cb08555c41 ("treewide, timers: Rename
from_timer() to timer_container_of()") renamed 'from_timer()' to
'timer_container_of()'. Given that this is a macro we can simplfy see if
the macro 'timer_container_of' is defined and if so use this otherwise
fall back to 'from_timer()'. Update the necessary drivers to fix the
build for Linux v6.16.
JIRA LINQPJ14-60
Change-Id: I7f622b5d046a92da2ade755e6a697c1810f61275
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3383387
(cherry picked from commit 320ec84efd492c0c2711c69104fabc30b4f15ecb)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3461850
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
When NV_TEGRA264_BWMGR_DEBUG_MACRO_PRESENT is not defined the build
fails and the following errors are seen ...
drivers/platform/tegra/tegra-bpmp-bwmgr.c:101:12: error:
‘tegra_bpmp_bwmgr_devfreq_target’ defined but not used
[-Werror=unused-function]
101 | static int tegra_bpmp_bwmgr_devfreq_target(struct device *dev,
unsigned long *freq, u32 flags)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/platform/tegra/tegra-bpmp-bwmgr.c:37:12: error:
‘tegra_bpmp_bwmgr_max_freq_notifier’ defined but not used
[-Werror=unused-function]
37 | static int tegra_bpmp_bwmgr_max_freq_notifier(struct
notifier_block *nb, unsigned long action, void *ptr)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fix this by ensuring the above functions are not defined if
NV_TEGRA264_BWMGR_DEBUG_MACRO_PRESENT is not defined.
Bug 5483386
Bug 5196455
Change-Id: Ie2b069d163a32220c95ffaba217ddea3686ba92b
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3461865
Reviewed-by: Johnny Liu <johnliu@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
This driver exposes EMC frequency control interface to user space via
linux devfreq framework.
Users could change EMC frequency to the frequency value from the
available frequencies of EMC clock:
$ /sys/class/devfreq/bwmgr# cat available_frequencies
665600000 2750000000 3200000000 4266000000
and update the EMC floor frequency by writing into the min_freq QoS
sysfs node:
$ /sys/class/devfreq/bwmgr# echo 4266000000 > min_freq
and update the EMC max frequency by writing into the max_rate QoS
sysfs node to cap the EMC frequency:
$ /sys/class/devfreq/bwmgr# echo 4266000000 > max_freq
This driver does not directly manage the EMC clock rate. Instead it
just delivers the min/max frequency information to BPMP, and BPMP is
still the only entity that has the full control of EMC and other
related memory clocks.
Bug 5483386
Bug 5196455
Change-Id: I6124eeb7411a13bde5c51582064534063abca8d3
Signed-off-by: Johnny Liu <johnliu@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3453755
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: Rajkumar Kasirajan <rkasirajan@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
----------------------------------
rtl8852ce release notes for Nvidia
----------------------------------
v1.19.16_nv-126-16-gbf1934e39.20250910_Certified_Module_beta
* fix scan issue in roaming test
==================================================================
v1.19.16_nv-126-15-ge5204803f.20250827_Certified_Module_beta
* Fix bug of 802.11d CC scan mechanism
[Description]
The 11d CC scan result may sometimes be overwritten by other scans.
==================================================================
v1.19.16_nv-126-14-g196875f8d.20250821_Certified_Module_beta
* fix 6G MBSSID disconnect problem
[Description]
Fix the issue where RSSI was not updated in non-transmitted BSSID, which could
cause disconnection due to incorrect RSSI values.
==================================================================
v1.19.16_nv-126-13-g7a2b96406.20250813_Certified_Module_beta
* fix 6G Enhanced open mode not work
[Description]
(1) Parse capabilities in MBSSID
e.g. Vendor Specific OUI WMM IE
Non-Inheritance IE
(2) Handle MBSSID sets
(3) Adjust MAX IE size from 768 to 1840 defined in WIFI Alliance
Bug 5422314
Bug 5226667
Change-Id: I63802c34fdc6e189566843d11992ff64b8e404fa
Signed-off-by: Narayana Reddy P <narayanr@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3450784
Reviewed-by: Shobek Attupurath <sattupurath@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Bitan Biswas <bbiswas@nvidia.com>
Account NvMap allocated memory into both RSS and CG tracking to make
efficient OOM kill decisions during memory pressure.
NvMap allocates memory via kernel APIs like alloc_pages, the kernel
memory is not accounted on behalf of process who requests the
allocation. Hence in case OOM, the OOM killer never kills the process
who has allocated memory via NvMap even though this process might be
holding most of the memory.
Solve this issue using following approach:
- Use __GFP_ACCOUNT and __GFP_NORETRY flag
- __GFP_NORETRY will not let the current allocation flow to go into OOM
path, so that it will never trigger OOM.
- __GFP_ACCOUNT causes the allocation to be accounted to kmemcg. So any
allocation done by NvMap will be definitely accounted to kmemcg and
cgroups can be used to define memory limits.
- Add RSS counting for the process which allocates by NvMap, so that OOM
score for that process will get updated and OOM killer can pick this
process based upon the OOM score.
- Every process that has a reference to NvMap Handle would have the
memory size accounted into its RSS. On releasing the reference to
handle, the RSS would be reduced.
Bug 5222690
Change-Id: I3fa9b76ec9fc8d7f805111cb96e11e2ab1db42ce
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3447072
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Ajay Nandakumar Mannargudi <anandakumarm@nvidia.com>
The camera-diagnostic driver is missing a release function for the IVC
channel device that it is creating. This causes the following WARNING to
be observed when probing the camera-diagnostic driver fails ...
------------[ cut here ]------------
Device 'camera-diag' does not have a release() function, it is broken
and must be fixed. See Documentation/core-api/kobject.rst.
WARNING: CPU: 8 PID: 756 at drivers/base/core.c:2517 device_release+0x88/0xa8
...
Call trace:
device_release+0x88/0xa8
kobject_put+0xac/0x150
put_device+0x14/0x34
__mod_of__camera_diag_of_match_device_table+0x602514/0x6033a0
[camera_diagnostics]
tegra_ivc_bus_boot_sync+0x204/0x28c [ivc_bus]
really_probe+0x150/0x2c8
__driver_probe_device+0x78/0x134
driver_probe_device+0x3c/0x164
__driver_attach+0x98/0x1c4
bus_for_each_dev+0x7c/0xf4
driver_attach+0x24/0x38
bus_add_driver+0xec/0x218
driver_register+0x5c/0x13c
tegra_ivc_driver_register+0x10/0x1c [ivc_bus]
init_module+0x18/0x1000
[camera_diagnostics]
do_one_initcall+0x58/0x318
do_init_module+0x58/0x1ec
load_module+0x1f04/0x2000
init_module_from_file+0x88/0xd4
__arm64_sys_finit_module+0x148/0x330
invoke_syscall+0x48/0x134
el0_svc_common.constprop.0+0x40/0xf0
do_el0_svc+0x1c/0x30
el0_svc+0x30/0xb8
el0t_64_sync_handler+0x130/0x13c
el0t_64_sync+0x194/0x198
---[ end trace 0000000000000000 ]---
Ideally we would use the 'tegra_ivc_channel_release()' function as the
release function but because the camera-diagnostic driver does not call
'tegra_ivc_channel_create()' to create the channel and does not actually
need to free any memory, simply define a new empty function that can be
called.
Bug 5489551
Change-Id: I6a7de9893af0167409af79599b61faf005047b0e
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3443095
(cherry picked from commit f75c0f228ca4f1a4c17266cb97be2db63b25a592)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3453753
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
