In Linux v6.12, commit 8c045ca534d0 ("gpiolib: legacy: Kill GPIOF_DIR_*
definitions") removed the GPIOF_DIR_* definitions and updated drivers to
use the equivalent GPIOF_* definitions instead. The GPIOF_* definitions
were added in Linux v3.0 and so update the appropriate drivers to use
these definitions.
Note that when calling devm_gpio_request_one() with GPIOF_DIR_OUT for
the flags, then because no explicit output level is specified, the GPIO
driver core defaults to low. Hence, in this case we replace
GPIOF_DIR_OUT with GPIOF_OUT_INIT_LOW.
Bug 4593750
Change-Id: I05664fd4e0abf5755c9514dffe64b239266c92fa
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3217397
Reviewed-by: Prafull Suryawanshi <prafulls@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
In Linux v6.12, commit f9ecc2febf6f ("pwm: Don't export pwm_capture()")
made pwm_capture an internal function and this broke the build for the
Tegra Tachometer driver. The pwm_capture() function simply calls the
drivers '.capture' callback and so fix this by directly calling the
function pwm_tegra_tacho_capture() instead. Note that the rpm_show()
function is also moved to after the declaration of the
pwm_tegra_tacho_capture() function.
Bug 4876974
Change-Id: Idf7fbc16382a9077c651755d9907ded7652610cc
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3217391
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Yi-Wei Wang <yiweiw@nvidia.com>
- Query heap functionality belongs to nvmap_alloc unit, as heap is
managed by it. Hence move the function to query the heap to nvmap_alloc
unit.
- Move nvmap_get_user_pages function to nvmap_alloc unit as it is
relevant for nvmap_alloc unit.
- Move nvmap_dma_alloc_attrs/free_attrs functions to nvmap_alloc unit
as they are more relevant for nvmap_alloc unit.
- Move dma_coherent_mem_replica, nvmap_carveout_node structs to
nvmap_alloc unit.
- Cleanup unused macros from nvmap_priv.h
JIRA TMM-5694
Change-Id: I8884831771443de7db0e95c3b2dfc43c03f7c48e
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3214196
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
ISP channels are not released cleanly if the IVC send for
CAPTURE_CHANNEL_ISP_RELEASE_REQ were to fail, leaving the
rest of the release steps undone, including unregistering
the capture and control callbacks. This will prevent any
new channel setups, e.g., after an app restart, because
the channel is deemed busy.
Another problem with ISP channel release is that were the
aforementioned IVC sends to fail, the driver will not
attempt an RCE reboot to recover the IVC communications.
Similarly, if the channel reset IVC request fails or
returns an error, the pending capture and program buffers
won't be unpinned and their related waits won't be
completed.
This fix always performs the cleanups regardless of the
fate of the control channel requests.
Bug 4623451
Bug 4765177
Change-Id: I41ada4bc7dcc72676170d3d30515b5e741120252
Signed-off-by: Aki Niemi <aniemi@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3192586
(cherry picked from commit feb2be84d1077bec942825bf3cbffc58729f0560)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3219711
Reviewed-by: Ganesh Ram Savithri Sreenivas Murthy <ganeshrams@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Vincent Chung <vincentc@nvidia.com>
Reviewed-by: Mohit Ingale <mohiti@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Reviewed-by: Frank Chen <frankc@nvidia.com>
Tested-by: Mohit Ingale <mohiti@nvidia.com>
For some of the kernel tegra_bpmp is part of core kernel and
hence it is nto required to use the OOT tegra_bpmp driver.
However, some packaging still expect the tegra_bpmp.ko from
the OOT path. To trick the packaging file, add dummy tegra_bpmp
driver which does not have anything other than module_init/module_exit.
Bug 4551265
Change-Id: Ifae52acb63be009029c820b0ba7b15da6ea7a12e
Signed-off-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3198304
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
For some of the kernel tegra_hv is part of core kernel and
hence it is nto required to use the OOT tegra_hv driver.
However, some packaging still expect the tegra_hv.ko from
the OOT path. To trick the packaging file, add dummy tegra_hv
driver which does not have anything other than module_init/module_exit.
Bug 4551265
Change-Id: I59f6233705e2cfb510470ae3b9c1ce7d39618330
Signed-off-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3197802
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
For some of the kernel ivc_ext is part of core kernel and
hence it is nto required to use the OOT ivc_ext driver.
However, some packaging still expect the ivc_ext.ko from
the OOT path. To trick the packaging file, add dummy ivc_ext
driver which does not have anything other than module_init/module_exit.
Bug 4551265
Change-Id: I315c9f302e65b4cdc1376815a7bc23e4b7ca3e00
Signed-off-by: Manish Bhardwaj <mbhardwaj@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3214053
Reviewed-by: Laxman Dewangan <ldewangan@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Fix for: Sparse defects
Sparse defect stated that "symbol 'debug_free_size_fops' was not declared. Should it be static?"
-Since carveouts also have free_size debugfs and it is directly using
the field from heap struct.
-So to make free_size_fops static we are changing DEBUGFS_OPEN_FOPS to DEBUGFS_OPEN_FOPS_STATIC
Bug 4513982
Change-Id: I296bf95a421a9c751cc11266a896d2806bfc82b4
Signed-off-by: Surbhi Singh <surbhis@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3205061
Reviewed-by: Ketan Patil <ketanp@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
Issue: 1. Not able to launch supplicant on second VF
2. When launching supplicant on VF1, MACSec link on VF0 is getting lost
Fix: Do not program CAR registers as part of OSD as the same is being
taken care by Server and also do not register for MACSec interrupts.
Same is being handled in Server
2. Enabled packet duplication for MultiCast frames when launching
supplicant
Bug 4824402
Change-Id: I7b26298da8c94df2da823e36476bc37acf6123cd
Signed-off-by: Sanath Kumar Gampa <sgampa@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3201116
Reviewed-by: Mahesh Patil <maheshp@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Nagaraj Annaiah <nannaiah@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
- Files for nvmap_handle unit: nvmap_handle.c, nvmap_sci_ipc.c,
nvmap_id_array.c.
- Define external header for nvmap_handle unit as nvmap_handle.h and
move declarations of all external APIs of nvmap_handle unit to this
header.
- Define internal header for nvmap_handle unit as nvmap_handle_int.h and
move declarations of all internally called APIs to this header.
JIRA TMM-5651
Change-Id: Ie4922c0839070491f9893f23744eb700cabb9828
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3211591
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
nvmap uses pid of group_leader task to indicate a client process. During
create_client operation, whenever any client with the same group_leader
pid already exists in clients list of nvmap_device, then nvmap
increments the count field of nvmap_client struct. Otherwise, create a
new nvmap_client. Both of the operations i.e. checking the list for
client and incrementing the counter happen inside lock. On the other
hand, during nvmap_release, first the counter is decremented and checked
if it's zero or not. If it's zero then the lock is taken and client is
removed from client list of nvmap_device. As both the operations i.e.
decrementing the counter value and removing client from list (if the
counter becomes 0) are not happening inside a lock, it's resulting into
the following data race scenario.
1) nvmap_release on existing client process 1
- decrement client's counter
- counter value has become zero
- client is yet to be removed from the dev->clients list
- context switch happen to __nvmap_create_client as another
namespace/thread with same with same group_leader pid is created.
2) __nvmap_create_client
- as the client with same pid exists in dev->client list, it
increments counter value to 1, instead of creating a new client struct.
- context switch happen to nvmap_release from step 1
3) nvmap_release
- It calls destroy_client and remove the client from dev->client
list.
- Completes rest of the operations in destroy_client and returns.
- Context switch to remaining operations from step 2
4) nvmap_release
- Now, when the nvmap_release will be called for the thread/namespace
which was created in step 2, then list_del operation would fail as the
client struct was already removed from dev->client list.
Fix the above issue by doing both operations i.e. decrementing the
counter value and removing the client struct from dev->client list in a
single lock.
Bug 4829958
Change-Id: I87ebbcb45b18114d0ec75520443bee010f88d59e
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3209794
(cherry picked from commit cc74d1fe1b)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3207520
Reviewed-by: Brad Griffis <bgriffis@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
[Issue]: CAN freezes/stops to send messages after restart from bus-off state.
Throws following log from kernel: "write: No buffer space available"
[Reason]: When message txfer starts, tx_object (which keeps track of active tx)
gets filled. If CAN goes to bus-off state, txfer remains incomplete for some
messages. In such case, tx_object bits will not get cleared. It will stop
adding more messages in controller RAM.
Along with tx_object, from network layer, there are socket echo buffers.
When CAN is initialized and up on network, netif_start_queue is pushed to start
transmission. When msg txfer starts, socket buffer gets filled and freed only
when txfer completes. During bus-off, since network queue remains ON, all the
queued msgs get filled in socket buffers and does not allow upcoming msgs.
Therefore we see "write: No buffer space available".
[Fix]: Clear tx_object when device goes to bus-off state and stop network queue.
Start network queue again during restart from bus-off.
Bug 4438223
Change-Id: I3cbc6529a90f357372c8b0095bdce4217b133e9b
Signed-off-by: Shubhi Garg <shgarg@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3142091
(cherry picked from commit f902d95962)
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3144103
Reviewed-by: Bibek Basu <bbasu@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
This change includes
1. First version of nvdisp serdes driver.
2. Opcode parsing and implementation as per nvdisp serdes opcode specification.
3. ERRB generic interrupt handler with ERRB specific opcode parsing.
4. Suspend-Resume functionality.
5. Device tree binding documentation.
Verification:
* It is verified with MAX96851 DP serializer on P3710 and P3960.
* GMSL2 and GMSL3, MST like features verified.
* Suspend/Resume functionality verified.
* Internal and Remote video CRC error detection verified.
JIRA TDS-15967
Signed-off-by: prafulls <prafulls@nvidia.com>
Change-Id: I61b9c216b5a7d4bd402dfe55e31f652824c8cc43
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3175316
Reviewed-by: Shu Zhong <shuz@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
- Move macro definitions from nvmap_priv.h to nvmap_alloc unit wherever
required.
- Cleanup unnecessary macros.
- Add function to cleanup the memory allocated for debugfs_info for
iovmm. This was missed in the previous patch where the allocation for
debugfs_info is moved to dynamic memory allocation.
- Move nvmap page pool related data structs from nvmap_priv to
nvmap_alloc unit.
JIRA TMM-5621
Change-Id: I3b668b2d6182da1bf0d2034c66834efc02d3179f
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3203118
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Fix for Rule: Misra-C 2012 Rule 10.1
- Data type of client is a pointer, hence compare it with NULL.
- Data type of co is a pointer, hence compare it with NULL.
- h is a pointer, hence compare with NULL.
- size is of data type size_t, hence compare it with OU.
- Data type of node is a pointer, hence compare it with NULL.
- Data type of priv, priv->handle is a pointer,
hence compare with NULL.
- Data value of Kzalloc is pointer not a boolean, hence compare new with NULL.
- Data type of vma is a pointer, hence compare it with NULL.
- Data type of elem_size and count is unsigned long, hence compare it
with 0.
- Data type of nr is u32, hence compare it with 0U.
- Data type of ret is int, hence compare it with 0.
- Data type of heap is pointer, hence compare it with NULL.
CID 1675220
CID 1677129
CID 1680522
CID 1680855
CID 1682355
CID 1684748
CID 1685031
CID 1688104
CID 1691439
CID 1691492
CID 1697576
CID 1700206
CID 1703733
CID 1705732
CID 1713149
CID 1713881
CID 1715301
CID 1716395
CID 1718186
CID 1724356
CID 1736224
CID 1737251
CID 1742375
CID 1742507
CID 1743460
CID 1747820
CID 1751065
CID 1753197
CID 1754913
CID 1756020
CID 1758334
CID 1761585
CID 1762790
CID 1763725
JIRA TMM-5594
Change-Id: Iec045c45555b364b5869de856b9bb8a8586dfe02
Signed-off-by: Surbhi Singh <surbhis@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3201341
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Release Notes:
1. Add extra queue to handle EAPOL
Mark include/autoconf.h RTW_EAPOL_QUEUE to disable it
2. Use xmit_ext queue to TX eapol packet
3. Flush roam_buf_pkt after roaming is fail
4. Do NOT roam if previous roam does NOT finish
5. Report to WPS after all roam retries are failed
6. Support 11K beacon report fragmentation
7. Fix compile error on Kernel 5.19.2
Bug 4556940
Change-Id: I2137a24a1eadb1b5eac8e53126909863cec4747b
Signed-off-by: Shobek Attupurath <sattupurath@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3202805
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Ashutosh Jha <ajha@nvidia.com>
- Move all data structures from nvmap_heap.h header file to
nvmap_alloc_int.h file as they are owned by nvmap_alloc unit.
- Provide getter and setter functions to get or set the members of these
data structures.
- Provide forward declaration of such data structures.
- Remove nvmap_heap.h header file as nvmap_heap is part of the
nvmap_alloc unit and nvmap_alloc unit exposes nvmap_alloc.h as header
file to other units.
JIRA TMM-5621
Change-Id: I2c4dd95a1a1011e4a7c1b425aa7521c6f13202da
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3201354
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
As part of the nvmap_refactoring, add nvmap_alloc.h file which include
declaration for functions which are exposed by nvmap_alloc unit to other
units. Also, add nvmap_alloc_int.h file which include declaration for
functions which are internal to nvmap_alloc unit that can be called by
files within nvmap_alloc unit.
JIRA TMM-5621
Change-Id: Ie30e5e8a4f87591eb9c49a0a349f837a22726fa5
Signed-off-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3198546
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Accessing queue and payload fields of MSGQ via array index
causes out-of-bound warnings in new kernel version as they
are initialized as arrays of size 1:
index 53 is out of range for type 'int32_t [1]'
index 2045 is out of range for type 'int32_t [1]'
Addressing this by accessing the fields via pointer
increment instead of array index.
Bug 4420795
Change-Id: I873dbe08a894d1eea8866bb8a16018816d0e4db3
Signed-off-by: Viswanath L <viswanathl@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3199294
Reviewed-by: Asha T <atalambedu@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Reviewed-by: Dara Ramesh <dramesh@nvidia.com>
Reviewed-by: svcacv <svcacv@nvidia.com>
Fix for Rule: Misra-C 2012 Rule 10.1
-In nvmap_alloc.c h is of type pointer, hence compare with NULL.
-In nvmap_handle.c
-the return type of kzalloc is pointer, hence compare it with NULL.
-Client is a pointer, hence compare it with NULL.
-In nvmap_ioctl.c vaddr is a pointer, hence compare it with NULL.
-In nvmap_pp.c
- the data type of nvmap_root is pointer, hence compare with NULL.
- the data type of page is pointer, hence compare with NULL.
-In nvmap_dmabuf.c
- the return type of kzalloc is pointer, hence compare it with NULL.
- the data type of dev is a pointer, hence compare with NULL.
-In nvmap_priv.c pages are pointer, hence compare it with NULL.
-In nvmap_dev.c dev is a pointer, hence compare it with NULL.
CID 1634656
CID 1637713
CID 1647382
CID 1654006
CID 1657629
CID 1668126
CID 1668779
CID 1671917
CID 1672384
CID 1672959
CID 1653291
JIRA TMM-5627
Change-Id: I2ca971d7957040bf0fbef60b58497c509ca1153f
Signed-off-by: Surbhi Singh <surbhis@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3198648
Tested-by: mobile promotions <svcmobile_promotions@nvidia.com>
Reviewed-by: mobile promotions <svcmobile_promotions@nvidia.com>
Fix for Rule: Misra-C 2012 Rule 10.1
-In nvmap_pp.c return type of non_zero_cnt is integer not boolean, hence
compare it with 0.
-In nvmap_dmabuf.c the result for & operation would be 0 or 1, hence
compare it with 0.
-In nvmap_core.c the return type of kzalloc is pointer, hence compare it
with NULL.
-In nvmap_dev.c priv is a pointer, hence compare it with NULL.
CID 1608945
CID 1617267
CID 1622229
CID 1625991
CID 1630899
JIRA TMM-5627
Change-Id: Ib40286f852cdade2e115384d18f615ae52134bdd
Signed-off-by: Surbhi Singh <surbhis@nvidia.com>
Reviewed-on: https://git-master.nvidia.com/r/c/linux-nv-oot/+/3197795
Reviewed-by: Ketan Patil <ketanp@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Reviewed-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Pritesh Raithatha <praithatha@nvidia.com>
GVS: buildbot_gerritrpt <buildbot_gerritrpt@nvidia.com>
Tested-by: Sachin Nikam <snikam@nvidia.com>
