Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

18 participants
3200 discussions

[bug report] drm/amdkfd: Export DMABufs from KFD using GEM handles

by Dan Carpenter

Hello Felix Kuehling, The patch 1819200166ce: "drm/amdkfd: Export DMABufs from KFD using GEM handles" from Aug 24, 2023 (linux-next), leads to the following Smatch static checker warning: drivers/dma-buf/dma-buf.c:729 dma_buf_get() warn: fd used after fd_install() 'fd' drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 809 static int kfd_mem_export_dmabuf(struct kgd_mem *mem) 810 { 811 if (!mem->dmabuf) { 812 struct amdgpu_device *bo_adev; 813 struct dma_buf *dmabuf; 814 int r, fd; 815 816 bo_adev = amdgpu_ttm_adev(mem->bo->tbo.bdev); 817 r = drm_gem_prime_handle_to_fd(&bo_adev->ddev, bo_adev->kfd.client.file, 818 mem->gem_handle, 819 mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ? 820 DRM_RDWR : 0, &fd); ^^^ The drm_gem_prime_handle_to_fd() function does an fd_install() and returns the result as "fd". 821 if (r) 822 return r; 823 dmabuf = dma_buf_get(fd); ^^ Then we do another fget() inside dma_buf_get(). I'm not an expert, but this looks wrong. We can't assume that the dmabuf here is the same one from drm_gem_prime_handle_to_fd() because the user could change it after the fd_install(). I suspect drm_gem_prime_handle_to_fd() should pass the dmabuf back instead. We had several CVEs similar to this such as CVE-2022-1998. 824 close_fd(fd); 825 if (WARN_ON_ONCE(IS_ERR(dmabuf))) 826 return PTR_ERR(dmabuf); 827 mem->dmabuf = dmabuf; 828 } 829 830 return 0; 831 } regards, dan carpenter

1 year, 10 months

[PATCH v3 0/3] Add mediatek,gce-props.yaml for other bindings reference

by Jason-JH.Lin

From: Jason-jh Lin <jason-jh.lin(a)mediatek.corp-partner.google.com> The property "mediatek,gce-events" is used for GCE event ID corresponding to a hardware event signal sent by the hardware or a sofware driver. If the mailbox providers or consumers want to manipulate the value of the event ID, they need to know the specific event ID. Since mediatek,gce-events property is used for both mailbox producers and consumers, we add a mediatek,gce-props.yaml to place the common GCE properties like mediatek,gce-events. Change in v3: 1. Add more description and fix typo and grammar. 2. Fix $ref as full path. Change in v2: 1. Add mediatek,gce-props.yaml for other binding reference. Jason-JH.Lin (3): dt-bindings: mailbox: Add mediatek,gce-props.yaml dt-bindings: media: mediatek: mdp: Change mediatek,gce-events to reference dt-bindings: soc: mediatek: Change mediatek,gce-events to refernece .../bindings/mailbox/mediatek,gce-props.yaml | 52 +++++++++++++++++++ .../bindings/media/mediatek,mdp3-rdma.yaml | 11 ++-- .../bindings/media/mediatek,mdp3-rsz.yaml | 12 ++--- .../bindings/media/mediatek,mdp3-wrot.yaml | 12 ++--- .../bindings/soc/mediatek/mediatek,ccorr.yaml | 12 ++--- .../bindings/soc/mediatek/mediatek,mutex.yaml | 11 ++-- .../bindings/soc/mediatek/mediatek,wdma.yaml | 12 ++--- 7 files changed, 74 insertions(+), 48 deletions(-) create mode 100644 Documentation/devicetree/bindings/mailbox/mediatek,gce-props.yaml -- 2.18.0

1 year, 10 months

[PATCH 15/82] dma-buf: Refactor intentional wrap-around calculation

by Kees Cook

In an effort to separate intentional arithmetic wrap-around from unexpected wrap-around, we need to refactor places that depend on this kind of math. One of the most common code patterns of this is: VAR + value < VAR Notably, this is considered "undefined behavior" for signed and pointer types, which the kernel works around by using the -fno-strict-overflow option in the build[1] (which used to just be -fwrapv). Regardless, we want to get the kernel source to the position where we can meaningfully instrument arithmetic wrap-around conditions and catch them when they are unexpected, regardless of whether they are signed[2], unsigned[3], or pointer[4] types. Refactor open-coded unsigned wrap-around addition test to use check_add_overflow(), retaining the result for later usage (which removes the redundant open-coded addition). This paves the way to enabling the wrap-around sanitizers in the future. Link: https://git.kernel.org/linus/68df3755e383e6fecf2354a67b08f92f18536594 [1] Link: https://github.com/KSPP/linux/issues/26 [2] Link: https://github.com/KSPP/linux/issues/27 [3] Link: https://github.com/KSPP/linux/issues/344 [4] Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Christian König <christian.koenig(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Signed-off-by: Kees Cook <keescook(a)chromium.org> --- drivers/dma-buf/dma-buf.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 8fe5aa67b167..3743c63a9b59 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1458,6 +1458,8 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_end_cpu_access, DMA_BUF); int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, unsigned long pgoff) { + unsigned long sum; + if (WARN_ON(!dmabuf || !vma)) return -EINVAL; @@ -1466,12 +1468,11 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, return -EINVAL; /* check for offset overflow */ - if (pgoff + vma_pages(vma) < pgoff) + if (check_add_overflow(pgoff, vma_pages(vma), &sum)) return -EOVERFLOW; /* check for overflowing the buffer's size */ - if (pgoff + vma_pages(vma) > - dmabuf->size >> PAGE_SHIFT) + if (sum > dmabuf->size >> PAGE_SHIFT) return -EINVAL; /* readjust the vma */ -- 2.34.1

1 year, 10 months

Re: [PATCH v4 1/4] usb: gadget: Support already-mapped DMA SGs

by Paul Cercueil

Hi Frank, Le vendredi 19 janvier 2024 à 16:49 -0500, Frank Li a écrit : > On Wed, Jan 17, 2024 at 01:26:43PM +0100, Paul Cercueil wrote: > > Add a new 'sg_was_mapped' field to the struct usb_request. This > > field > > can be used to indicate that the scatterlist associated to the USB > > transfer has already been mapped into the DMA space, and it does > > not > > have to be done internally. > > > > Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> > > --- > > drivers/usb/gadget/udc/core.c | 7 ++++++- > > include/linux/usb/gadget.h | 2 ++ > > 2 files changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/usb/gadget/udc/core.c > > b/drivers/usb/gadget/udc/core.c > > index d59f94464b87..9d4150124fdb 100644 > > --- a/drivers/usb/gadget/udc/core.c > > +++ b/drivers/usb/gadget/udc/core.c > > @@ -903,6 +903,11 @@ int usb_gadget_map_request_by_dev(struct > > device *dev, > > if (req->length == 0) > > return 0; > > > > + if (req->sg_was_mapped) { > > + req->num_mapped_sgs = req->num_sgs; > > + return 0; > > + } > > + > > if (req->num_sgs) { > > int mapped; > > > > @@ -948,7 +953,7 @@ EXPORT_SYMBOL_GPL(usb_gadget_map_request); > > void usb_gadget_unmap_request_by_dev(struct device *dev, > > struct usb_request *req, int is_in) > > { > > - if (req->length == 0) > > + if (req->length == 0 || req->sg_was_mapped) > > return; > > > > if (req->num_mapped_sgs) { > > diff --git a/include/linux/usb/gadget.h > > b/include/linux/usb/gadget.h > > index a771ccc038ac..c529e4e06997 100644 > > --- a/include/linux/usb/gadget.h > > +++ b/include/linux/usb/gadget.h > > @@ -52,6 +52,7 @@ struct usb_ep; > > * @short_not_ok: When reading data, makes short packets be > > * treated as errors (queue stops advancing till cleanup). > > * @dma_mapped: Indicates if request has been mapped to DMA > > (internal) > > + * @sg_was_mapped: Set if the scatterlist has been mapped before > > the request > > * @complete: Function called when request completes, so this > > request and > > * its buffer may be re-used. The function will always be > > called with > > * interrupts disabled, and it must not sleep. > > @@ -111,6 +112,7 @@ struct usb_request { > > unsigned zero:1; > > unsigned short_not_ok:1; > > unsigned dma_mapped:1; > > + unsigned sg_was_mapped:1; > > why not use dma_mapped direclty? Because of the unmap case. We want to know whether we should unmap or not. > > Frank Cheers, -Paul > > > > > void (*complete)(struct usb_ep *ep, > > struct usb_request *req); > > -- > > 2.43.0 > >

1 year, 10 months

[PATCH v4 0/4] usb: gadget: functionfs: DMABUF import interface

by Paul Cercueil

Hi, This is the v4 of my patchset that adds a new DMABUF import interface to FunctionFS. It addresses the points that Daniel raised on the v3 - see changelog below. This interface is being used at Analog Devices, to transfer data from high-speed transceivers to USB in a zero-copy fashion, using also the DMABUF import interface to the IIO subsystem which is being upstreamed in parallel [1]. The two are used by the Libiio software [2]. On a ZCU102 board with a FMComms3 daughter board, using the combination of these two new interfaces yields a drastic improvement of the throughput, from about 127 MiB/s using IIO's buffer read/write interface + read/write to the FunctionFS endpoints, to about 274 MiB/s when passing around DMABUFs, for a lower CPU usage (0.85 load avg. before, vs. 0.65 after). Right now, *technically* there are no users of this interface, as Analog Devices wants to wait until both interfaces are accepted upstream to merge the DMABUF code in Libiio into the main branch, and Jonathan wants to wait and see if this patchset is accepted to greenlight the DMABUF interface in IIO as well. I think this isn't really a problem; once everybody is happy with its part of the cake, we can merge them all at once. This is obviously for 5.9, and based on next-20240117. Changelog: - [3/4]: - Protect the dmabufs list with a mutex - Use incremental sequence number for the dma_fences - Unref attachments and DMABUFs in workers - Remove dead code in ffs_dma_resv_lock() - Fix non-block actually blocking - Use dma_fence_begin/end_signalling() - Add comment about cache-management and dma_buf_unmap_attachment() - Make sure dma_buf_map_attachment() is called with the dma-resv locked Cheers, -Paul [1] https://lore.kernel.org/linux-iio/219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.… [2] https://github.com/analogdevicesinc/libiio/tree/pcercuei/dev-new-dmabuf-api Paul Cercueil (4): usb: gadget: Support already-mapped DMA SGs usb: gadget: functionfs: Factorize wait-for-endpoint code usb: gadget: functionfs: Add DMABUF import interface Documentation: usb: Document FunctionFS DMABUF API Documentation/usb/functionfs.rst | 36 ++ drivers/usb/gadget/function/f_fs.c | 500 ++++++++++++++++++++++++++-- drivers/usb/gadget/udc/core.c | 7 +- include/linux/usb/gadget.h | 2 + include/uapi/linux/usb/functionfs.h | 41 +++ 5 files changed, 565 insertions(+), 21 deletions(-) -- 2.43.0

1 year, 10 months

[PATCH v3 0/4] usb: gadget: functionfs: DMABUF import interface

by Paul Cercueil

Hi, This small patchset adds three new IOCTLs that can be used to attach, detach, or transfer from/to a DMABUF object. This interface is being used at Analog Devices, to transfer data from high-speed transceivers to USB in a zero-copy fashion, using also the DMABUF import interface to the IIO subsystem which is being upstreamed in parallel [1] (and has high chances to be accepted for 5.9, I think Jonathan can confirm). The two are used by the Libiio software [2]. On a ZCU102 board with a FMComms3 daughter board, using the combination of these two new interfaces yields a drastic improvement of the throughput, from about 127 MiB/s using IIO's buffer read/write interface + read/write to the FunctionFS endpoints, to about 274 MiB/s when passing around DMABUFs, for a lower CPU usage (0.85 load avg. before, vs. 0.65 after). Right now, *technically* there are no users of this interface, as Analog Devices wants to wait until both interfaces are accepted upstream to merge the DMABUF code in Libiio into the main branch, and Jonathan wants to wait and see if this patchset is accepted to greenlight the DMABUF interface in IIO as well. I think this isn't really a problem; once everybody is happy with its part of the cake, we can merge them all at once. This is obviously for 5.9, and based on next-20240108. Changelog: - [3/4]: - Inline to_ffs_dma_fence() which was called only once. - Simplify ffs_dma_resv_lock() - Add comment explaining why we unref twice in ffs_dmabuf_detach() - Document uapi struct usb_ffs_dmabuf_transfer_req and IOCTLs - [4/4]: New patch, as I figured out having documentation wouldn't hurt. Cheers, -Paul [1] https://lore.kernel.org/linux-iio/219abc43b4fdd4a13b307ed2efaa0e6869e68e3f.… [2] https://github.com/analogdevicesinc/libiio/tree/pcercuei/dev-new-dmabuf-api Paul Cercueil (4): usb: gadget: Support already-mapped DMA SGs usb: gadget: functionfs: Factorize wait-for-endpoint code usb: gadget: functionfs: Add DMABUF import interface Documentation: usb: Document FunctionFS DMABUF API Documentation/usb/functionfs.rst | 36 +++ drivers/usb/gadget/function/f_fs.c | 463 ++++++++++++++++++++++++++-- drivers/usb/gadget/udc/core.c | 7 +- include/linux/usb/gadget.h | 2 + include/uapi/linux/usb/functionfs.h | 41 +++ 5 files changed, 528 insertions(+), 21 deletions(-) -- 2.43.0

1 year, 10 months

Re: [PATCH v3 4/4] Documentation: usb: Document FunctionFS DMABUF API

by Paul Cercueil

Hi Vegard, Le mardi 09 janvier 2024 à 14:08 +0100, Vegard Nossum a écrit : > On 08/01/2024 13:00, Paul Cercueil wrote: > > Add documentation for the three ioctls used to attach or detach > > externally-created DMABUFs, and to request transfers from/to > > previously > > attached DMABUFs. > > > > Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> > > > > --- > > v3: New patch > > --- > > Documentation/usb/functionfs.rst | 36 > > ++++++++++++++++++++++++++++++++ > > 1 file changed, 36 insertions(+) > > Hi, > > I'd like to point out that this file (usb/functionfs.rst) is > currently > included by Documentation/subsystem-apis.rst, the top-level file for > the > "Kernel subsystem documentation" set of books, which describe > internal > APIs: "These books get into the details of how specific kernel > subsystems work from the point of view of a kernel developer". > > However, functionfs.rst (and especially your new additions) are > documenting a userspace API, so it really belongs somewhere in > Documentation/userspace-api/ -- that's where /proc, /sys, /dev and > ioctl > descriptions for userspace programmers belong. Agreed. Even the original content prior to my additions describe a userspace API. > > I'm not NAKing the patch -- I just want to draw attention to this > discrepancy. Maybe we can separate the kernel-implementation details > (stuff about __init sections and stuff) from the new ioctl() info? > > Looking at <https://docs.kernel.org/usb/> I see that there are many > other adjacent documents that are also not really documenting kernel > implementation details, rough categorization as follows: > > USB support > ----------- > > - Linux ACM driver v0.16 ==> admin/user info > - Authorizing (or not) your USB devices to connect to the system ==> > admin/user info > - ChipIdea Highspeed Dual Role Controller Driver => admin/user info > - DWC3 driver ==> driver TODOs (can be moved into source code?) > - EHCI driver ==> technical info + driver details > - How FunctionFS works > - Linux USB gadget configured through configfs ==> userspace API + > implementation > - Linux USB HID gadget driver ==> implementation + userspace API > - Multifunction Composite Gadget ==> technical + user info > - Linux USB Printer Gadget Driver ==> userspace API > - Linux Gadget Serial Driver v2.0 ==> user/admin + userspace API > - Linux UVC Gadget Driver ==> user/admin + userspace API > - Gadget Testing ==> user/admin + userspace API > - Infinity Usb Unlimited Readme ==> user/admin > - Mass Storage Gadget (MSG) ==> user/admin > - USB 7-Segment Numeric Display ==> user/admin > - mtouchusb driver ==> user/admin > - OHCI ==> technical info > - USB Raw Gadget ==> userspace API > - USB/IP protocol ==> technical info > - usbmon ==> user/admin + userspace API > - USB serial ==> user/admin + technical info > - USB references > - Linux CDC ACM inf > - Linux inf > - USB devfs drop permissions source > - Credits > > By "admin/user info", I mean things that a user would have to do or > run > (e.g. modprobe + flags) to make use of a driver; "technical info" is > more like device specifications (transfer speeds, modes of operation, > etc.); "userspace API" is stuff like configfs and ioctls; "driver > details" is really implementation details and internal > considerations. > > The last ones I don't even really know how to categorize. > > I'm guessing nobody is really enthralled by the idea of splitting > Documentation/usb/ up like this? > > Documentation/admin-guide/usb/ > Documentation/driver-api/usb/ (this one actually exists already) > Documentation/userspace-api/usb/ > > For the stuff that is _actually_ internal to a specific driver (so > not > useful for end users, not useful for admins, not generic USB info, > and > not useful for userspace programmers), I would honestly propose to > just > move it directly into the driver's source code, or, if the text is > obsolete, just get rid of it completely. > > The distinction between user/admin and userspace API is pretty clear > (one is for end users, the other is for userspace _programmers_), but > it > can sometimes be hard to determine whether something falls in one or > the > other category. > > In any case -- it looks like almost all of the usb/ directory does > not > document "how specific kernel subsystems work from the point of view > of > a kernel developer" so maybe we should just move the include to > userspace-api/ for now as an obvious improvement (if still not 100% > correct): > > diff --git a/Documentation/subsystem-apis.rst > b/Documentation/subsystem-apis.rst > index 2d353fb8ea26..fe972f57bf4c 100644 > --- a/Documentation/subsystem-apis.rst > +++ b/Documentation/subsystem-apis.rst > @@ -81,7 +81,6 @@ Storage interfaces > security/index > crypto/index > bpf/index > - usb/index > PCI/index > misc-devices/index > peci/index > diff --git a/Documentation/userspace-api/index.rst > b/Documentation/userspace-api/index.rst > index 82f9dbd228f5..e60cd9174ada 100644 > --- a/Documentation/userspace-api/index.rst > +++ b/Documentation/userspace-api/index.rst > @@ -41,6 +41,7 @@ Subsystem-specific documentation: > tee > isapnp > dcdbas > + ../usb/index > > Kernel ABIs: These documents describe the the ABI between the Linux > kernel and userspace, and the relative stability of these > interfaces. > > > Thoughts? Makes sense to me. There's definitely some cleanup to be done in the USB documentation. > Vegard Cheers, -Paul

1 year, 10 months

[PATCH] dma-buf/dma-resv: fix spelling

by Randy Dunlap

Fix spelling mistakes as reported by codespell. Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: Christian König <christian.koenig(a)amd.com> Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-resv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -- a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -405,7 +405,7 @@ static void dma_resv_iter_walk_unlocked( * * Beware that the iterator can be restarted. Code which accumulates statistics * or similar needs to check for this with dma_resv_iter_is_restarted(). For - * this reason prefer the locked dma_resv_iter_first() whenver possible. + * this reason prefer the locked dma_resv_iter_first() whenever possible. * * Returns the first fence from an unlocked dma_resv obj. */ @@ -428,7 +428,7 @@ EXPORT_SYMBOL(dma_resv_iter_first_unlock * * Beware that the iterator can be restarted. Code which accumulates statistics * or similar needs to check for this with dma_resv_iter_is_restarted(). For - * this reason prefer the locked dma_resv_iter_next() whenver possible. + * this reason prefer the locked dma_resv_iter_next() whenever possible. * * Returns the next fence from an unlocked dma_resv obj. */

1 year, 10 months

[PATCH] dma-buf/dma-fence: fix spelling

by Randy Dunlap

Fix spelling mistakes as reported by codespell. Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: Christian König <christian.koenig(a)amd.com> Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/dma-fence.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff -- a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -102,7 +102,7 @@ static atomic64_t dma_fence_context_coun * * * Drivers are allowed to call dma_fence_wait() from their &mmu_notifier * respectively &mmu_interval_notifier callbacks. This means any code required - * for fence completeion cannot allocate memory with GFP_NOFS or GFP_NOIO. + * for fence completion cannot allocate memory with GFP_NOFS or GFP_NOIO. * Only GFP_ATOMIC is permissible, which might fail. * * Note that only GPU drivers have a reasonable excuse for both requiring @@ -522,7 +522,7 @@ dma_fence_wait_timeout(struct dma_fence EXPORT_SYMBOL(dma_fence_wait_timeout); /** - * dma_fence_release - default relese function for fences + * dma_fence_release - default release function for fences * @kref: &dma_fence.recfount * * This is the default release functions for &dma_fence. Drivers shouldn't call @@ -974,8 +974,8 @@ void dma_fence_set_deadline(struct dma_f EXPORT_SYMBOL(dma_fence_set_deadline); /** - * dma_fence_describe - Dump fence describtion into seq_file - * @fence: the 6fence to describe + * dma_fence_describe - Dump fence description into seq_file + * @fence: the fence to describe * @seq: the seq_file to put the textual description into * * Dump a textual description of the fence and it's state into the seq_file.

1 year, 10 months

[PATCH v3 0/7] dma-buf: heaps: Add secure heap

by Yong Wu

This patchset is for secure video playback and enables other potential uses in the future. The 'secure dma-heap' will be used to allocate dma_buf objects that reference memory in the secure world that is inaccessible/ unmappable by the non-secure (i.e.kernel/userspace) world. That memory will be used by the secure world to store secure information (i.e. decrypted media content). The dma_bufs allocated from the kernel will be passed to V4L2 for video decoding (as input and output). They will also be used by the drm system for rendering of the content. This patchset adds two secure heaps and they will be used v4l2[1] and drm[2]. 1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path). The buffer is reserved for the secure world after bootup and it is used for vcodec's ES/working buffer; 2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is dynamically reserved for the secure world and will be got when we start playing secure videos, Once the security video playing is complete, the CMA will be released. This heap is used for the vcodec's frame buffer. [1] https://lore.kernel.org/linux-mediatek/20231206081538.17056-1-yunfei.dong@m… [2] https://lore.kernel.org/linux-mediatek/20231023044549.21412-1-jason-jh.lin@… Change note: v3: Base on v6.7-rc1. 1) Separate the secure heap into a common file(secure_heap.c) and a mtk special file (secure_heap_mtk.c), and put all tee related code into our special file. 2) About dt-binding, a) Add "mediatek," prefix since this is Mediatek TEE firmware definition. b) Mute dt-binding check waring. 3) Remove the normal CMA heap which is a draft for qcom. v2: https://lore.kernel.org/linux-mediatek/20231111111559.8218-1-yong.wu@mediat… 1) Move John's patches into the vcodec patchset since they use the new dma heap interface directly. https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.dong@m… 2) Reword the dt-binding description. 3) Rename the heap name from mtk_svp to secure_mtk_cm. This means the current vcodec/DRM upstream code doesn't match this. 4) Add a normal CMA heap. currently it should be a draft version. 5) Regarding the UUID, I still use hard code, but put it in a private data which allow the others could set their own UUID. What's more, UUID is necessary for the session with TEE. If we don't have it, we can't communicate with the TEE, including the get_uuid interface, which tries to make uuid more generic, not working. If there is other way to make UUID more general, please free to tell me. v1: https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong.wu@media… Base on v6.6-rc1. Yong Wu (7): dt-bindings: reserved-memory: Add mediatek,dynamic-secure-region dma-buf: heaps: Initialize a secure heap dma-buf: heaps: secure_heap: Add private heap ops dma-buf: heaps: secure_heap: Add dma_ops dma-buf: heaps: secure_heap: Add MediaTek secure heap and heap_init dma-buf: heaps: secure_heap_mtk: Add tee memory service call dma_buf: heaps: secure_heap_mtk: Add a new CMA heap .../mediatek,dynamic-secure-region.yaml | 43 +++ drivers/dma-buf/heaps/Kconfig | 13 + drivers/dma-buf/heaps/Makefile | 2 + drivers/dma-buf/heaps/secure_heap.c | 234 +++++++++++++ drivers/dma-buf/heaps/secure_heap.h | 43 +++ drivers/dma-buf/heaps/secure_heap_mtk.c | 321 ++++++++++++++++++ 6 files changed, 656 insertions(+) create mode 100644 Documentation/devicetree/bindings/reserved-memory/mediatek,dynamic-secure-region.yaml create mode 100644 drivers/dma-buf/heaps/secure_heap.c create mode 100644 drivers/dma-buf/heaps/secure_heap.h create mode 100644 drivers/dma-buf/heaps/secure_heap_mtk.c -- 2.18.0

1 year, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig