Add a new ioctl called TEE_IOC_SHM_REGISTER_FD to register a
shared memory from a dmabuf file descriptor.
This new ioctl will allow the Linux Kernel to register a buffer
to be used by the Secure Data Path OPTEE OS feature.
Please find more information here:
https://static.linaro.org/connect/san19/presentations/san19-107.pdf
Patch tested on Hikey 6220.
Etienne Carriere (1):
tee: new ioctl to a register tee_shm from a dmabuf file descriptor
drivers/tee/tee_core.c | 38 +++++++++++++++
drivers/tee/tee_shm.c | 99 +++++++++++++++++++++++++++++++++++++++-
include/linux/tee_drv.h | 11 +++++
include/uapi/linux/tee.h | 29 ++++++++++++
4 files changed, 175 insertions(+), 2 deletions(-)
--
2.25.0
Hi guys,
after finding that we essentially have two separate worlds for coherent sharing
of buffer through DMA-buf I thought I will tackle that problem a bit and at
least allow the framework to reject attachments which won't work.
So those patches here add a new dma_coherent flag to each DMA-buf object
telling the framework that dev_is_dma_coherent() needs to return true for an
importing device to be able to attach. Since we should always have a fallback
path this should give userspace the chance to still keep the use case working,
either by doing a CPU copy instead or reversing the roles of exporter and
importer.
For DRM and most V4L2 devices I then fill in the dma_coherent flag based on the
return value of dev_is_dma_coherent(). Exporting drivers are allowed to clear
the flag for their buffers if special handling like the USWC flag in amdgpu or
the uncached allocations for radeon/nouveau are in use.
Additional to that importers can also check the flag if they have some
non-snooping operations like the special scanout case for amdgpu for example.
The patches are only smoke tested and the solution isn't ideal, but as far as
I can see should at least keep things working.
Please review and/or comment,
Christian.
Smatch report warning as follows:
drivers/dma-buf/dma-buf.c:681 dma_buf_export() warn:
'&dmabuf->list_node' not removed from list
If dma_buf_stats_setup() fails in dma_buf_export(), goto err_sysfs
and dmabuf will be freed, but dmabuf->list_node will not be removed
from db_list.head, then list traversal may cause UAF.
Fix by removeing it from db_list.head before free().
Fixes: ef3a6b70507a ("dma-buf: call dma_buf_stats_setup after dmabuf is in valid list")
Signed-off-by: Gaosheng Cui <cuigaosheng1(a)huawei.com>
---
drivers/dma-buf/dma-buf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index b809513b03fe..6848f50226d5 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -675,6 +675,9 @@ struct dma_buf *dma_buf_export(const struct dma_buf_export_info *exp_info)
return dmabuf;
err_sysfs:
+ mutex_lock(&db_list.lock);
+ list_del(&dmabuf->list_node);
+ mutex_unlock(&db_list.lock);
/*
* Set file->f_path.dentry->d_fsdata to NULL so that when
* dma_buf_release() gets invoked by dentry_ops, it exits
--
2.25.1
Hi,
This series introduce Kunit tests to the vc4 KMS driver, but unlike what we
have been doing so far in KMS, it actually tests the atomic modesetting code.
In order to do so, I've had to improve a fair bit on the Kunit helpers already
found in the tree in order to register a full blown and somewhat functional KMS
driver.
It's of course relying on a mock so that we can test it anywhere. The mocking
approach created a number of issues, the main one being that we need to create
a decent mock in the first place, see patch 22. The basic idea is that I
created some structures to provide a decent approximation of the actual
hardware, and that would support both major architectures supported by vc4.
This is of course meant to evolve over time and support more tests, but I've
focused on testing the HVS FIFO assignment code which is fairly tricky (and the
tests have actually revealed one more bug with our current implementation). I
used to have a userspace implementation of those tests, where I would copy and
paste the kernel code and run the tests on a regular basis. It's was obviously
fairly suboptimal, so it seemed like the perfect testbed for that series.
It can be run using:
./tools/testing/kunit/kunit.py run \
--kunitconfig=drivers/gpu/drm/vc4/tests/.kunitconfig \
--cross_compile aarch64-linux-gnu- --arch arm64
Let me know what you think,
Maxime
To: David Airlie <airlied(a)gmail.com>
To: Daniel Vetter <daniel(a)ffwll.ch>
To: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
To: Maxime Ripard <mripard(a)kernel.org>
To: Thomas Zimmermann <tzimmermann(a)suse.de>
Cc: Dave Stevenson <dave.stevenson(a)raspberrypi.com>
Cc: Javier Martinez Canillas <javierm(a)redhat.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Maíra Canal <mairacanal(a)riseup.net>
Cc: Brendan Higgins <brendan.higgins(a)linux.dev>
Cc: David Gow <davidgow(a)google.com>
Cc: linux-kselftest(a)vger.kernel.org
Cc: kunit-dev(a)googlegroups.com
Cc: dri-devel(a)lists.freedesktop.org
Cc: linux-kernel(a)vger.kernel.org
Cc: linux-media(a)vger.kernel.org
Cc: linaro-mm-sig(a)lists.linaro.org
Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
---
Changes in v2:
- Added some documentation for public functions
- Removed the fake device probe/remove workqueue
- Made sure the tests could be compiled as modules
- Moved the vc4 tests in the vc4 module
- Applied some of the preliminary patches
- Rebased on top of current drm-misc-next branch
- Fixed checkpatch issues
- Introduced BCM2835 (Pi0-3) tests for muxing
- Introduced tests to cover past bugs we had
- Link to v1: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v1-0-051a0bb60a16@cerno.…
---
Maxime Ripard (17):
drm/tests: helpers: Move the helper header to include/drm
drm/tests: helpers: Document drm_kunit_device_init()
drm/tests: helpers: Rename the device init helper
drm/tests: helpers: Remove the name parameter
drm/tests: helpers: Create the device in another function
drm/tests: helpers: Switch to a platform_device
drm/tests: helpers: Make sure the device is bound
drm/tests: helpers: Allow for a custom device struct to be allocated
drm/tests: helpers: Allow to pass a custom drm_driver
drm/tests: Add a test for DRM managed actions
drm/vc4: Move HVS state to main header
drm/vc4: crtc: Introduce a lower-level crtc init helper
drm/vc4: crtc: Make encoder lookup helper public
drm/vc4: hvs: Provide a function to initialize the HVS structure
drm/vc4: tests: Introduce a mocking infrastructure
drm/vc4: tests: Fail the current test if we access a register
drm/vc4: tests: Add unit test suite for the PV muxing
drivers/gpu/drm/tests/Makefile | 1 +
drivers/gpu/drm/tests/drm_client_modeset_test.c | 19 +-
drivers/gpu/drm/tests/drm_kunit_helpers.c | 106 ++-
drivers/gpu/drm/tests/drm_kunit_helpers.h | 11 -
drivers/gpu/drm/tests/drm_managed_test.c | 71 ++
drivers/gpu/drm/tests/drm_modes_test.c | 19 +-
drivers/gpu/drm/tests/drm_probe_helper_test.c | 20 +-
drivers/gpu/drm/vc4/Kconfig | 15 +
drivers/gpu/drm/vc4/Makefile | 7 +
drivers/gpu/drm/vc4/tests/.kunitconfig | 14 +
drivers/gpu/drm/vc4/tests/vc4_mock.c | 200 +++++
drivers/gpu/drm/vc4/tests/vc4_mock.h | 63 ++
drivers/gpu/drm/vc4/tests/vc4_mock_crtc.c | 41 +
drivers/gpu/drm/vc4/tests/vc4_mock_output.c | 138 +++
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 47 +
drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 1039 +++++++++++++++++++++++
drivers/gpu/drm/vc4/vc4_crtc.c | 102 ++-
drivers/gpu/drm/vc4/vc4_dpi.c | 13 +-
drivers/gpu/drm/vc4/vc4_drv.c | 4 +-
drivers/gpu/drm/vc4/vc4_drv.h | 91 +-
drivers/gpu/drm/vc4/vc4_dsi.c | 9 +-
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 4 +
drivers/gpu/drm/vc4/vc4_hvs.c | 81 +-
drivers/gpu/drm/vc4/vc4_kms.c | 25 +-
drivers/gpu/drm/vc4/vc4_txp.c | 15 +-
drivers/gpu/drm/vc4/vc4_vec.c | 13 +-
include/drm/drm_kunit_helpers.h | 91 ++
27 files changed, 2087 insertions(+), 172 deletions(-)
---
base-commit: 199557fab92548f8e9d5207e385097213abe0cab
change-id: 20221123-rpi-kunit-tests-87a388492a73
Best regards,
--
Maxime Ripard <maxime(a)cerno.tech>
Hi,
This series introduce Kunit tests to the vc4 KMS driver, but unlike what we
have been doing so far in KMS, it actually tests the atomic modesetting code.
In order to do so, I've had to improve a fair bit on the Kunit helpers already
found in the tree in order to register a full blown and somewhat functional KMS
driver.
It's of course relying on a mock so that we can test it anywhere. The mocking
approach created a number of issues, the main one being that we need to create
a decent mock in the first place, see patch 22. The basic idea is that I
created some structures to provide a decent approximation of the actual
hardware, and that would support both major architectures supported by vc4.
This is of course meant to evolve over time and support more tests, but I've
focused on testing the HVS FIFO assignment code which is fairly tricky (and the
tests have actually revealed one more bug with our current implementation). I
used to have a userspace implementation of those tests, where I would copy and
paste the kernel code and run the tests on a regular basis. It's was obviously
fairly suboptimal, so it seemed like the perfect testbed for that series.
Let me know what you think,
Maxime
To: David Airlie <airlied(a)gmail.com>
To: Daniel Vetter <daniel(a)ffwll.ch>
To: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
To: Maxime Ripard <mripard(a)kernel.org>
To: Thomas Zimmermann <tzimmermann(a)suse.de>
Cc: Dave Stevenson <dave.stevenson(a)raspberrypi.com>
Cc: Javier Martinez Canillas <javierm(a)redhat.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Maíra Canal <mairacanal(a)riseup.net>
Cc: Brendan Higgins <brendan.higgins(a)linux.dev>
Cc: David Gow <davidgow(a)google.com>
Cc: linux-kselftest(a)vger.kernel.org
Cc: kunit-dev(a)googlegroups.com
Cc: dri-devel(a)lists.freedesktop.org
Cc: linux-kernel(a)vger.kernel.org
Cc: linux-media(a)vger.kernel.org
Cc: linaro-mm-sig(a)lists.linaro.org
Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
---
Maxime Ripard (24):
drm/tests: helpers: Rename the device init helper
drm/tests: helpers: Remove the name parameter
drm/tests: helpers: Create the device in another function
drm/tests: helpers: Switch to a platform_device
drm/tests: helpers: Make sure the device is bound
drm/tests: kunit: Allow for a custom device struct to be allocated
drm/tests: helpers: Allow to pass a custom drm_driver
drm/tests: Add a test for DRM managed actions
drm/atomic: Constify the old/new state accessors
drm/vc4: kms: Sort the CRTCs by output before assigning them
drm/vc4: Constify container_of wrappers
drm/vc4: Move HVS state to main header
drm/vc4: kms: Constify the HVS old/new state helpers
drm/vc4: txp: Reorder the variable assignments
drm/vc4: Add TXP encoder type
drm/vc4: txp: Initialise the CRTC before the encoder and connector
drm/vc4: crtc: Pass the device and data in vc4_crtc_init
drm/vc4: crtc: Introduce a lower-level crtc init helper
drm/vc4: crtc: Make encoder lookup helper public
drm/vc4: crtc: Provide a CRTC name
drm/vc4: hvs: Provide a function to initialize the HVS structure
drm/vc4: tests: Introduce a mocking infrastructure
drm/vc4: tests: Fail the current test if we access a register
drm/vc4: tests: Add unit test suite for the PV muxing
drivers/gpu/drm/drm_atomic.c | 12 +-
drivers/gpu/drm/tests/Makefile | 1 +
drivers/gpu/drm/tests/drm_client_modeset_test.c | 16 +-
drivers/gpu/drm/tests/drm_kunit_helpers.c | 116 +++--
drivers/gpu/drm/tests/drm_kunit_helpers.h | 39 +-
drivers/gpu/drm/tests/drm_managed_test.c | 68 +++
drivers/gpu/drm/vc4/Kconfig | 15 +
drivers/gpu/drm/vc4/Makefile | 1 +
drivers/gpu/drm/vc4/tests/.kunitconfig | 14 +
drivers/gpu/drm/vc4/tests/Makefile | 8 +
drivers/gpu/drm/vc4/tests/vc4_mock.c | 174 +++++++
drivers/gpu/drm/vc4/tests/vc4_mock.h | 58 +++
drivers/gpu/drm/vc4/tests/vc4_mock_crtc.c | 39 ++
drivers/gpu/drm/vc4/tests/vc4_mock_output.c | 97 ++++
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 45 ++
drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 624 ++++++++++++++++++++++++
drivers/gpu/drm/vc4/vc4_crtc.c | 119 +++--
drivers/gpu/drm/vc4/vc4_dpi.c | 13 +-
drivers/gpu/drm/vc4/vc4_drv.c | 4 +-
drivers/gpu/drm/vc4/vc4_drv.h | 113 ++++-
drivers/gpu/drm/vc4/vc4_dsi.c | 9 +-
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 4 +
drivers/gpu/drm/vc4/vc4_hvs.c | 81 +--
drivers/gpu/drm/vc4/vc4_kms.c | 138 +++---
drivers/gpu/drm/vc4/vc4_txp.c | 66 ++-
drivers/gpu/drm/vc4/vc4_vec.c | 13 +-
include/drm/drm_atomic.h | 32 +-
27 files changed, 1678 insertions(+), 241 deletions(-)
---
base-commit: 35c3a2d02f0dc153a5f2f304ba33e1436b6a8d8f
change-id: 20221123-rpi-kunit-tests-87a388492a73
Best regards,
--
Maxime Ripard <maxime(a)cerno.tech>
I've been collecting these typo fixes for a while and it feels like
time to send them in.
Signed-off-by: T.J. Mercier <tjmercier(a)google.com>
---
drivers/dma-buf/dma-buf.c | 14 +++++++-------
include/linux/dma-buf.h | 6 +++---
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index dd0f83ee505b..614ccd208af4 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1141,7 +1141,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_unmap_attachment, DMA_BUF);
*
* @dmabuf: [in] buffer which is moving
*
- * Informs all attachmenst that they need to destroy and recreated all their
+ * Informs all attachments that they need to destroy and recreate all their
* mappings.
*/
void dma_buf_move_notify(struct dma_buf *dmabuf)
@@ -1159,11 +1159,11 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF);
/**
* DOC: cpu access
*
- * There are mutliple reasons for supporting CPU access to a dma buffer object:
+ * There are multiple reasons for supporting CPU access to a dma buffer object:
*
* - Fallback operations in the kernel, for example when a device is connected
* over USB and the kernel needs to shuffle the data around first before
- * sending it away. Cache coherency is handled by braketing any transactions
+ * sending it away. Cache coherency is handled by bracketing any transactions
* with calls to dma_buf_begin_cpu_access() and dma_buf_end_cpu_access()
* access.
*
@@ -1190,7 +1190,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_move_notify, DMA_BUF);
* replace ION buffers mmap support was needed.
*
* There is no special interfaces, userspace simply calls mmap on the dma-buf
- * fd. But like for CPU access there's a need to braket the actual access,
+ * fd. But like for CPU access there's a need to bracket the actual access,
* which is handled by the ioctl (DMA_BUF_IOCTL_SYNC). Note that
* DMA_BUF_IOCTL_SYNC can fail with -EAGAIN or -EINTR, in which case it must
* be restarted.
@@ -1264,10 +1264,10 @@ static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
* preparations. Coherency is only guaranteed in the specified range for the
* specified access direction.
* @dmabuf: [in] buffer to prepare cpu access for.
- * @direction: [in] length of range for cpu access.
+ * @direction: [in] direction of access.
*
* After the cpu access is complete the caller should call
- * dma_buf_end_cpu_access(). Only when cpu access is braketed by both calls is
+ * dma_buf_end_cpu_access(). Only when cpu access is bracketed by both calls is
* it guaranteed to be coherent with other DMA access.
*
* This function will also wait for any DMA transactions tracked through
@@ -1307,7 +1307,7 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_begin_cpu_access, DMA_BUF);
* actions. Coherency is only guaranteed in the specified range for the
* specified access direction.
* @dmabuf: [in] buffer to complete cpu access for.
- * @direction: [in] length of range for cpu access.
+ * @direction: [in] direction of access.
*
* This terminates CPU access started with dma_buf_begin_cpu_access().
*
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 71731796c8c3..1d61a4f6db35 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -330,7 +330,7 @@ struct dma_buf {
* @lock:
*
* Used internally to serialize list manipulation, attach/detach and
- * vmap/unmap. Note that in many cases this is superseeded by
+ * vmap/unmap. Note that in many cases this is superseded by
* dma_resv_lock() on @resv.
*/
struct mutex lock;
@@ -365,7 +365,7 @@ struct dma_buf {
*/
const char *name;
- /** @name_lock: Spinlock to protect name acces for read access. */
+ /** @name_lock: Spinlock to protect name access for read access. */
spinlock_t name_lock;
/**
@@ -402,7 +402,7 @@ struct dma_buf {
* anything the userspace API considers write access.
*
* - Drivers may just always add a write fence, since that only
- * causes unecessarily synchronization, but no correctness issues.
+ * causes unnecessary synchronization, but no correctness issues.
*
* - Some drivers only expose a synchronous userspace API with no
* pipelining across drivers. These do not set any fences for their
--
2.38.1.584.g0f3c55d4c2-goog