linux.git/drivers/accel, branch v6.6-rc2 Linux kernel source tree Merge tag 'drm-misc-next-fixes-2023-09-01' of git://anongit.freedesktop.org/drm/drm-misc into drm-next 2023-09-07T20:36:36+00:00 Dave Airlie airlied@redhat.com 2023-09-07T20:36:29+00:00 d9809d242ff501734e716634e0b3f3e0dce823ec Short summary of fixes pull: * ivpu: Replace strncpy * nouveau: Fix fence state in nouveau_fence_emit() Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230901070123.GA6987@linux-uq9g 
Short summary of fixes pull:

 * ivpu: Replace strncpy
 * nouveau: Fix fence state in nouveau_fence_emit()

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230901070123.GA6987@linux-uq9g
accel/ivpu: refactor deprecated strncpy 2023-08-25T09:09:40+00:00 Justin Stitt justinstitt@google.com 2023-08-24T21:20:25+00:00 4b2fd81f2af7147e844ecec0c5c07a16bca6b86e `strncpy` is deprecated for use on NUL-terminated destination strings [1]. A suitable replacement is `strscpy` [2] due to the fact that it guarantees NUL-termination on its destination buffer argument which is _not_ the case for `strncpy`! Also remove extraneous if-statement as it can never be entered. The return value from `strncpy` is it's first argument. In this case, `...dyndbg_cmd` is an array: | char dyndbg_cmd[VPU_DYNDBG_CMD_MAX_LEN]; ^^^^^^^^^^ This can never be NULL which means `strncpy`'s return value cannot be NULL here. Just use `strscpy` which is more robust and results in simpler and less ambiguous code. Moreover, remove needless `... - 1` as `strscpy`'s implementation ensures NUL-termination and we do not need to carefully dance around ending boundaries with a "- 1" anymore. Fixes: 5d7422cfb498 ("accel/ivpu: Add IPC driver and JSM messages") Link: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230824-strncpy-drivers-accel-ivpu-ivpu_jsm_msg-c-v1-1-12d9b52d2dff@google.com 
`strncpy` is deprecated for use on NUL-terminated destination strings [1].

A suitable replacement is `strscpy` [2] due to the fact that it
guarantees NUL-termination on its destination buffer argument which is
_not_ the case for `strncpy`!

Also remove extraneous if-statement as it can never be entered. The
return value from `strncpy` is it's first argument. In this case,
`...dyndbg_cmd` is an array:
| 	char dyndbg_cmd[VPU_DYNDBG_CMD_MAX_LEN];
             ^^^^^^^^^^
This can never be NULL which means `strncpy`'s return value cannot be
NULL here. Just use `strscpy` which is more robust and results in
simpler and less ambiguous code.

Moreover, remove needless `... - 1` as `strscpy`'s implementation
ensures NUL-termination and we do not need to carefully dance around
ending boundaries with a "- 1" anymore.

Fixes: 5d7422cfb498 ("accel/ivpu: Add IPC driver and JSM messages")
Link: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230824-strncpy-drivers-accel-ivpu-ivpu_jsm_msg-c-v1-1-12d9b52d2dff@google.com
BackMerge tag 'v6.5-rc7' into drm-next 2023-08-23T21:26:06+00:00 Dave Airlie airlied@redhat.com 2023-08-23T21:26:06+00:00 fdebffeba8b877368ddcc139c26278c1c97931a4 Linux 6.5-rc7 This is needed for the CI stuff and the msm pull has fixes in it. Signed-off-by: Dave Airlie <airlied@redhat.com> 
Linux 6.5-rc7

This is needed for the CI stuff and the msm pull has fixes in it.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Merge tag 'drm-misc-fixes-2023-08-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes 2023-08-17T20:08:58+00:00 Dave Airlie airlied@redhat.com 2023-08-17T20:08:54+00:00 be48306f764dc84906a5054e60e6cfa9889fb44d One EPROBE_DEFER handling fix for the JDI LT070ME05000, a timing fix for the AUO G121EAN01 panel, an integer overflow and a memory leak fixes for the qaic accel, a use-after-free fix for nouveau and a revert for an alleged fix in EDID parsing. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/3olqt33em5uhxzjbqghwcwnvmw73h7bxkbdxookmnkecymd4vc@7ogm6gewpprq 
One EPROBE_DEFER handling fix for the JDI LT070ME05000, a timing fix for
the AUO G121EAN01 panel, an integer overflow and a memory leak fixes for
the qaic accel, a use-after-free fix for nouveau and a revert for an
alleged fix in EDID parsing.

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Maxime Ripard <mripard@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/3olqt33em5uhxzjbqghwcwnvmw73h7bxkbdxookmnkecymd4vc@7ogm6gewpprq
accel/qaic: Clean up integer overflow checking in map_user_pages() 2023-08-15T15:51:13+00:00 Dan Carpenter dan.carpenter@linaro.org 2023-08-10T12:23:06+00:00 96d3c1cadedb6ae2e8965e19cd12caa244afbd9c The encode_dma() function has some validation on in_trans->size but it would be more clear to move those checks to find_and_map_user_pages(). The encode_dma() had two checks: if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size) return -EINVAL; The in_trans->addr variable is the starting address. The in_trans->size variable is the total size of the transfer. The transfer can occur in parts and the resources->xferred_dma_size tracks how many bytes we have already transferred. This patch introduces a new variable "remaining" which represents the amount we want to transfer (in_trans->size) minus the amount we have already transferred (resources->xferred_dma_size). I have modified the check for if in_trans->size is zero to instead check if in_trans->size is less than resources->xferred_dma_size. If we have already transferred more bytes than in_trans->size then there are negative bytes remaining which doesn't make sense. If there are zero bytes remaining to be copied, just return success. The check in encode_dma() checked that "addr + size" could not overflow and barring a driver bug that should work, but it's easier to check if we do this in parts. First check that "in_trans->addr + resources->xferred_dma_size" is safe. Then check that "xfer_start_addr + remaining" is safe. My final concern was that we are dealing with u64 values but on 32bit systems the kmalloc() function will truncate the sizes to 32 bits. So I calculated "total = in_trans->size + offset_in_page(xfer_start_addr);" and returned -EINVAL if it were >= SIZE_MAX. This will not affect 64bit systems. Fixes: 129776ac2e38 ("accel/qaic: Add control path") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/24d3348b-25ac-4c1b-b171-9dae7c43e4e0@moroto.mountain 
The encode_dma() function has some validation on in_trans->size but it
would be more clear to move those checks to find_and_map_user_pages().

The encode_dma() had two checks:

	if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size)
		return -EINVAL;

The in_trans->addr variable is the starting address.  The in_trans->size
variable is the total size of the transfer.  The transfer can occur in
parts and the resources->xferred_dma_size tracks how many bytes we have
already transferred.

This patch introduces a new variable "remaining" which represents the
amount we want to transfer (in_trans->size) minus the amount we have
already transferred (resources->xferred_dma_size).

I have modified the check for if in_trans->size is zero to instead check
if in_trans->size is less than resources->xferred_dma_size.  If we have
already transferred more bytes than in_trans->size then there are negative
bytes remaining which doesn't make sense.  If there are zero bytes
remaining to be copied, just return success.

The check in encode_dma() checked that "addr + size" could not overflow
and barring a driver bug that should work, but it's easier to check if
we do this in parts.  First check that "in_trans->addr +
resources->xferred_dma_size" is safe.  Then check that "xfer_start_addr +
remaining" is safe.

My final concern was that we are dealing with u64 values but on 32bit
systems the kmalloc() function will truncate the sizes to 32 bits.  So
I calculated "total = in_trans->size + offset_in_page(xfer_start_addr);"
and returned -EINVAL if it were >= SIZE_MAX.  This will not affect 64bit
systems.

Fixes: 129776ac2e38 ("accel/qaic: Add control path")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com>
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/24d3348b-25ac-4c1b-b171-9dae7c43e4e0@moroto.mountain
accel/qaic: Fix slicing memory leak 2023-08-15T15:50:07+00:00 Pranjal Ramajor Asha Kanojiya quic_pkanojiy@quicinc.com 2023-08-02T14:59:37+00:00 2d956177b7c96e62fac762a3b7da4318cde27a73 The temporary buffer storing slicing configuration data from user is only freed on error. This is a memory leak. Free the buffer unconditionally. Fixes: ff13be830333 ("accel/qaic: Add datapath") Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230802145937.14827-1-quic_jhugo@quicinc.com 
The temporary buffer storing slicing configuration data from user is only
freed on error.  This is a memory leak.  Free the buffer unconditionally.

Fixes: ff13be830333 ("accel/qaic: Add datapath")
Signed-off-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com>
Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230802145937.14827-1-quic_jhugo@quicinc.com
Merge tag 'drm-misc-fixes-2023-08-10' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes 2023-08-11T03:56:27+00:00 Dave Airlie airlied@redhat.com 2023-08-11T03:56:20+00:00 8ba371c778cbb3f0399b8ba8919bf89e462cdda3 Multiple fixes for nouveau around memory safety and DisplayPort, one fix to reduce the log level of rockchip, a power state fix for the it6505 bridge, a timing fix for the lt9611 bridge, a cache maintenance fix for ivpu and one to reset vma->vm_ops on mmap for shmem-helper. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/fwed6gzdtkse5ocrgd37elhyw7qirfptsvfp5mqqverdzifhxj@4da3vesxcqp2 
Multiple fixes for nouveau around memory safety and DisplayPort, one fix
to reduce the log level of rockchip, a power state fix for the it6505
bridge, a timing fix for the lt9611 bridge, a cache maintenance fix for
ivpu and one to reset vma->vm_ops on mmap for shmem-helper.

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Maxime Ripard <mripard@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fwed6gzdtkse5ocrgd37elhyw7qirfptsvfp5mqqverdzifhxj@4da3vesxcqp2
accel/ivpu: Add initial support for VPU 4 2023-08-09T11:55:21+00:00 Stanislaw Gruszka stanislaw.gruszka@linux.intel.com 2023-07-31T16:12:58+00:00 79cdc56c4a542526d5b4e255d297ab842887e02b Add support VPU 4 - new generation of VPU IP with various hardware design improvements. From driver point of view, it differs in register set, initialization process and MMU memory ranges. Co-developed-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Co-developed-by: Krystian Pradzynski <krystian.pradzynski@linux.intel.com> Signed-off-by: Krystian Pradzynski <krystian.pradzynski@linux.intel.com> Co-developed-by: Karol Wachowski <karol.wachowski@linux.intel.com> Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230731161258.2987564-7-stanislaw.gruszka@linux.intel.com 
Add support VPU 4 - new generation of VPU IP with various
hardware design improvements. From driver point of view, it differs
in register set, initialization process and MMU memory ranges.

Co-developed-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Signed-off-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Co-developed-by: Krystian Pradzynski <krystian.pradzynski@linux.intel.com>
Signed-off-by: Krystian Pradzynski <krystian.pradzynski@linux.intel.com>
Co-developed-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230731161258.2987564-7-stanislaw.gruszka@linux.intel.com
accel/ivpu: Refactor memory ranges logic 2023-08-09T11:52:15+00:00 Karol Wachowski karol.wachowski@linux.intel.com 2023-07-31T16:12:57+00:00 162f17b2d97a848586340694e64eff14e60a85a8 Add new dma range and change naming convention for virtual address memory ranges managed by KMD. New available ranges are named as follows: * global range - global context accessible by FW * aliased range - user context accessible by FW * dma range - user context accessible by DMA * shave range - user context accessible by shaves * global shave range - global context accessible by shave nn Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com> Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230731161258.2987564-6-stanislaw.gruszka@linux.intel.com 
Add new dma range and change naming convention for virtual address
memory ranges managed by KMD.

New available ranges are named as follows:
 * global range - global context accessible by FW
 * aliased range - user context accessible by FW
 * dma range - user context accessible by DMA
 * shave range - user context accessible by shaves
 * global shave range - global context accessible by shave nn

Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230731161258.2987564-6-stanislaw.gruszka@linux.intel.com
accel/ivpu: Extend get_param ioctl to identify capabilities 2023-08-09T11:48:56+00:00 Stanislaw Gruszka stanislaw.gruszka@linux.intel.com 2023-07-31T16:12:56+00:00 aa5f04d2e5a842351449034e619913e1c721a37c Add DRM_IVPU_PARAM_CAPABILITIES parameters to get_param ioctl to query driver capabilities. For now use it for identify metric streamer and new dma memory range features. Currently upstream version of intel_vpu does not have those, they will be added it the future. Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230731161258.2987564-5-stanislaw.gruszka@linux.intel.com 
Add DRM_IVPU_PARAM_CAPABILITIES parameters to get_param ioctl to query
driver capabilities. For now use it for identify metric streamer and
new dma memory range features. Currently upstream version of intel_vpu
does not have those, they will be added it the future.

Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230731161258.2987564-5-stanislaw.gruszka@linux.intel.com