[PATCH v6 0/5] drm/amdgpu: Rework coredump memory allocation

[André Almeida]

Hi,

The patches of this set are a rework to alloc devcoredump dynamically and to
move it to a better source file.

Thanks,
André

Changelog:

v5: https://lore.kernel.org/lkml/20230817182050.205925-1-andrealm...@igalia.com/
- Added Shashank Sharma R-b tag

v4: 
https://lore.kernel.org/dri-devel/20230815195100.294458-1-andrealm...@igalia.com/
- New patch to encapsulate all reset info in a struct

v3: 
https://lore.kernel.org/dri-devel/20230810192330.198326-1-andrealm...@igalia.com/
- Changed from kmalloc to kzalloc
- Dropped "Create a module param to disable soft recovery" for now

v2: 
https://lore.kernel.org/dri-devel/20230713213242.680944-1-andrealm...@igalia.com/
- Drop the IB and ring patch
- Drop patch that limited information from kernel threads
- Add patch to move coredump to amdgpu_reset

v1: 
https://lore.kernel.org/dri-devel/20230711213501.526237-1-andrealm...@igalia.com/
 - Drop "Mark contexts guilty for causing soft recoveries" patch
 - Use GFP_NOWAIT for devcoredump allocatio

André Almeida (5):
  drm/amdgpu: Allocate coredump memory in a nonblocking way
  drm/amdgpu: Rework coredump to use memory dynamically
  drm/amdgpu: Encapsulate all device reset info
  drm/amdgpu: Move coredump code to amdgpu_reset file
  drm/amdgpu: Create version number for coredumps

 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 21 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 10 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 75 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c   | 77 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h   | 13 
 5 files changed, 114 insertions(+), 82 deletions(-)

-- 
2.42.0

[PATCH v6 2/5] drm/amdgpu: Rework coredump to use memory dynamically

[André Almeida]

Instead of storing coredump information inside amdgpu_device struct,
move if to a proper separated struct and allocate it dynamically. This
will make it easier to further expand the logged information.

Signed-off-by: André Almeida 
Reviewed-by: Shashank Sharma 
---
v6: no change
v5: no change
v4: change kmalloc to kzalloc
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 14 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 63 ++
 2 files changed, 49 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 9c6a332261ab..0d560b713948 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1088,11 +1088,6 @@ struct amdgpu_device {
uint32_t*reset_dump_reg_list;
uint32_t*reset_dump_reg_value;
int num_regs;
-#ifdef CONFIG_DEV_COREDUMP
-   struct amdgpu_task_info reset_task_info;
-   boolreset_vram_lost;
-   struct timespec64   reset_time;
-#endif
 
boolscpm_enabled;
uint32_tscpm_status;
@@ -1105,6 +1100,15 @@ struct amdgpu_device {
uint32_taid_mask;
 };
 
+#ifdef CONFIG_DEV_COREDUMP
+struct amdgpu_coredump_info {
+   struct amdgpu_device*adev;
+   struct amdgpu_task_info reset_task_info;
+   struct timespec64   reset_time;
+   boolreset_vram_lost;
+};
+#endif
+
 static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
 {
return container_of(ddev, struct amdgpu_device, ddev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index bf4781551f88..b5b879bcc5c9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4799,12 +4799,17 @@ static int amdgpu_reset_reg_dumps(struct amdgpu_device 
*adev)
return 0;
 }
 
-#ifdef CONFIG_DEV_COREDUMP
+#ifndef CONFIG_DEV_COREDUMP
+static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
+   struct amdgpu_reset_context *reset_context)
+{
+}
+#else
 static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t offset,
size_t count, void *data, size_t datalen)
 {
struct drm_printer p;
-   struct amdgpu_device *adev = data;
+   struct amdgpu_coredump_info *coredump = data;
struct drm_print_iterator iter;
int i;
 
@@ -4818,21 +4823,21 @@ static ssize_t amdgpu_devcoredump_read(char *buffer, 
loff_t offset,
drm_printf(, " AMDGPU Device Coredump \n");
drm_printf(, "kernel: " UTS_RELEASE "\n");
drm_printf(, "module: " KBUILD_MODNAME "\n");
-   drm_printf(, "time: %lld.%09ld\n", adev->reset_time.tv_sec, 
adev->reset_time.tv_nsec);
-   if (adev->reset_task_info.pid)
+   drm_printf(, "time: %lld.%09ld\n", coredump->reset_time.tv_sec, 
coredump->reset_time.tv_nsec);
+   if (coredump->reset_task_info.pid)
drm_printf(, "process_name: %s PID: %d\n",
-  adev->reset_task_info.process_name,
-  adev->reset_task_info.pid);
+  coredump->reset_task_info.process_name,
+  coredump->reset_task_info.pid);
 
-   if (adev->reset_vram_lost)
+   if (coredump->reset_vram_lost)
drm_printf(, "VRAM is lost due to GPU reset!\n");
-   if (adev->num_regs) {
+   if (coredump->adev->num_regs) {
drm_printf(, "AMDGPU register dumps:\nOffset: Value:\n");
 
-   for (i = 0; i < adev->num_regs; i++)
+   for (i = 0; i < coredump->adev->num_regs; i++)
drm_printf(, "0x%08x: 0x%08x\n",
-  adev->reset_dump_reg_list[i],
-  adev->reset_dump_reg_value[i]);
+  coredump->adev->reset_dump_reg_list[i],
+  coredump->adev->reset_dump_reg_value[i]);
}
 
return count - iter.remain;
@@ -4840,14 +4845,32 @@ static ssize_t amdgpu_devcoredump_read(char *buffer, 
loff_t offset,
 
 static void amdgpu_devcoredump_free(void *data)
 {
+   kfree(data);
 }
 
-static void amdgpu_reset_capture_coredumpm(struct amdgpu_device *adev)
+static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
+   struct amdgpu_reset_context *reset_context)
 {
+   struct amdgpu_coredump_info *coredump;
struct drm_device *dev = adev_to_drm(adev);
 
-   ktime_get_ts64(>reset_time);
-   dev_coredumpm(dev->dev, THIS_MODULE, adev, 0, GFP_NOWAIT,
+   coredump = kzalloc(sizeof(*coredump), GFP_NOWAIT);
+
+   if (!coredump) {
+   

[PATCH v6 1/5] drm/amdgpu: Allocate coredump memory in a nonblocking way

[André Almeida]

During a GPU reset, a normal memory reclaim could block to reclaim
memory. Giving that coredump is a best effort mechanism, it shouldn't
disturb the reset path. Change its memory allocation flag to a
nonblocking one.

Signed-off-by: André Almeida 
Reviewed-by: Christian König 
---
v5: no change
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index aa171db68639..bf4781551f88 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4847,7 +4847,7 @@ static void amdgpu_reset_capture_coredumpm(struct 
amdgpu_device *adev)
struct drm_device *dev = adev_to_drm(adev);
 
ktime_get_ts64(>reset_time);
-   dev_coredumpm(dev->dev, THIS_MODULE, adev, 0, GFP_KERNEL,
+   dev_coredumpm(dev->dev, THIS_MODULE, adev, 0, GFP_NOWAIT,
  amdgpu_devcoredump_read, amdgpu_devcoredump_free);
 }
 #endif
-- 
2.42.0

[PATCH v6 4/5] drm/amdgpu: Move coredump code to amdgpu_reset file

[André Almeida]

Giving that we use codedump just for device resets, move it's functions
and structs to a more semantic file, the amdgpu_reset.{c, h}.

Signed-off-by: André Almeida 
Reviewed-by: Shashank Sharma 
---
v6: no change
v5: no change
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  9 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 78 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c  | 76 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h  | 10 +++
 4 files changed, 86 insertions(+), 87 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 56d78ca6e917..b11187d153ef 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -781,15 +781,6 @@ struct amdgpu_mqd {
 #define AMDGPU_PRODUCT_NAME_LEN 64
 struct amdgpu_reset_domain;
 
-#ifdef CONFIG_DEV_COREDUMP
-struct amdgpu_coredump_info {
-   struct amdgpu_device*adev;
-   struct amdgpu_task_info reset_task_info;
-   struct timespec64   reset_time;
-   boolreset_vram_lost;
-};
-#endif
-
 struct amdgpu_reset_info {
/* reset dump register */
u32 *reset_dump_reg_list;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 96975591841d..883953f2ae53 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -32,8 +32,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 
@@ -4799,82 +4797,6 @@ static int amdgpu_reset_reg_dumps(struct amdgpu_device 
*adev)
return 0;
 }
 
-#ifndef CONFIG_DEV_COREDUMP
-static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
-   struct amdgpu_reset_context *reset_context)
-{
-}
-#else
-static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t offset,
-   size_t count, void *data, size_t datalen)
-{
-   struct drm_printer p;
-   struct amdgpu_coredump_info *coredump = data;
-   struct drm_print_iterator iter;
-   int i;
-
-   iter.data = buffer;
-   iter.offset = 0;
-   iter.start = offset;
-   iter.remain = count;
-
-   p = drm_coredump_printer();
-
-   drm_printf(, " AMDGPU Device Coredump \n");
-   drm_printf(, "kernel: " UTS_RELEASE "\n");
-   drm_printf(, "module: " KBUILD_MODNAME "\n");
-   drm_printf(, "time: %lld.%09ld\n", coredump->reset_time.tv_sec, 
coredump->reset_time.tv_nsec);
-   if (coredump->reset_task_info.pid)
-   drm_printf(, "process_name: %s PID: %d\n",
-  coredump->reset_task_info.process_name,
-  coredump->reset_task_info.pid);
-
-   if (coredump->reset_vram_lost)
-   drm_printf(, "VRAM is lost due to GPU reset!\n");
-   if (coredump->adev->reset_info.num_regs) {
-   drm_printf(, "AMDGPU register dumps:\nOffset: Value:\n");
-
-   for (i = 0; i < coredump->adev->reset_info.num_regs; i++)
-   drm_printf(, "0x%08x: 0x%08x\n",
-  
coredump->adev->reset_info.reset_dump_reg_list[i],
-  
coredump->adev->reset_info.reset_dump_reg_value[i]);
-   }
-
-   return count - iter.remain;
-}
-
-static void amdgpu_devcoredump_free(void *data)
-{
-   kfree(data);
-}
-
-static void amdgpu_coredump(struct amdgpu_device *adev, bool vram_lost,
-   struct amdgpu_reset_context *reset_context)
-{
-   struct amdgpu_coredump_info *coredump;
-   struct drm_device *dev = adev_to_drm(adev);
-
-   coredump = kzalloc(sizeof(*coredump), GFP_NOWAIT);
-
-   if (!coredump) {
-   DRM_ERROR("%s: failed to allocate memory for coredump\n", 
__func__);
-   return;
-   }
-
-   coredump->reset_vram_lost = vram_lost;
-
-   if (reset_context->job && reset_context->job->vm)
-   coredump->reset_task_info = reset_context->job->vm->task_info;
-
-   coredump->adev = adev;
-
-   ktime_get_ts64(>reset_time);
-
-   dev_coredumpm(dev->dev, THIS_MODULE, coredump, 0, GFP_NOWAIT,
- amdgpu_devcoredump_read, amdgpu_devcoredump_free);
-}
-#endif
-
 int amdgpu_do_asic_reset(struct list_head *device_list_handle,
 struct amdgpu_reset_context *reset_context)
 {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
index 5fed06ffcc6b..579b70a3cdab 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
@@ -21,6 +21,9 @@
  *
  */
 
+#include 
+#include 
+
 #include "amdgpu_reset.h"
 #include "aldebaran.h"
 #include "sienna_cichlid.h"
@@ -167,5 +170,78 @@ void amdgpu_device_unlock_reset_domain(struct 
amdgpu_reset_domain *reset_domain)
up_write(_domain->sem);
 }
 
+#ifndef CONFIG_DEV_COREDUMP
+void 

[PATCH v6 5/5] drm/amdgpu: Create version number for coredumps

[André Almeida]

Even if there's nothing currently parsing amdgpu's coredump files, if
we eventually have such tools they will be glad to find a version field
to properly read the file.

Create a version number to be displayed on top of coredump file, to be
incremented when the file format or content get changed.

Signed-off-by: André Almeida 
Reviewed-by: Shashank Sharma 
---
v6: no change
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
index 579b70a3cdab..e92c81ff27be 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c
@@ -192,6 +192,7 @@ static ssize_t amdgpu_devcoredump_read(char *buffer, loff_t 
offset,
p = drm_coredump_printer();
 
drm_printf(, " AMDGPU Device Coredump \n");
+   drm_printf(, "version: " AMDGPU_COREDUMP_VERSION "\n");
drm_printf(, "kernel: " UTS_RELEASE "\n");
drm_printf(, "module: " KBUILD_MODNAME "\n");
drm_printf(, "time: %lld.%09ld\n", coredump->reset_time.tv_sec, 
coredump->reset_time.tv_nsec);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h
index 01e8183ade4b..ec3a409ec509 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h
@@ -88,6 +88,9 @@ struct amdgpu_reset_domain {
 };
 
 #ifdef CONFIG_DEV_COREDUMP
+
+#define AMDGPU_COREDUMP_VERSION "1"
+
 struct amdgpu_coredump_info {
struct amdgpu_device*adev;
struct amdgpu_task_info reset_task_info;
-- 
2.42.0

[PATCH v6 3/5] drm/amdgpu: Encapsulate all device reset info

[André Almeida]

To better organize struct amdgpu_device, keep all reset information
related fields together in a separated struct.

Signed-off-by: André Almeida 
Reviewed-by: Shashank Sharma 
---
v6: no changes
v5: new patch, as required by Shashank Sharma
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 34 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 10 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 16 +-
 3 files changed, 34 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 0d560b713948..56d78ca6e917 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -781,6 +781,26 @@ struct amdgpu_mqd {
 #define AMDGPU_PRODUCT_NAME_LEN 64
 struct amdgpu_reset_domain;
 
+#ifdef CONFIG_DEV_COREDUMP
+struct amdgpu_coredump_info {
+   struct amdgpu_device*adev;
+   struct amdgpu_task_info reset_task_info;
+   struct timespec64   reset_time;
+   boolreset_vram_lost;
+};
+#endif
+
+struct amdgpu_reset_info {
+   /* reset dump register */
+   u32 *reset_dump_reg_list;
+   u32 *reset_dump_reg_value;
+   int num_regs;
+
+#ifdef CONFIG_DEV_COREDUMP
+   struct amdgpu_coredump_info *coredump_info;
+#endif
+};
+
 /*
  * Non-zero (true) if the GPU has VRAM. Zero (false) otherwise.
  */
@@ -1084,10 +1104,7 @@ struct amdgpu_device {
 
struct mutexbenchmark_mutex;
 
-   /* reset dump register */
-   uint32_t*reset_dump_reg_list;
-   uint32_t*reset_dump_reg_value;
-   int num_regs;
+   struct amdgpu_reset_inforeset_info;
 
boolscpm_enabled;
uint32_tscpm_status;
@@ -1100,15 +1117,6 @@ struct amdgpu_device {
uint32_taid_mask;
 };
 
-#ifdef CONFIG_DEV_COREDUMP
-struct amdgpu_coredump_info {
-   struct amdgpu_device*adev;
-   struct amdgpu_task_info reset_task_info;
-   struct timespec64   reset_time;
-   boolreset_vram_lost;
-};
-#endif
-
 static inline struct amdgpu_device *drm_to_adev(struct drm_device *ddev)
 {
return container_of(ddev, struct amdgpu_device, ddev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index a4faea4fa0b5..3136a0774dd9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -2016,8 +2016,8 @@ static ssize_t 
amdgpu_reset_dump_register_list_read(struct file *f,
if (ret)
return ret;
 
-   for (i = 0; i < adev->num_regs; i++) {
-   sprintf(reg_offset, "0x%x\n", adev->reset_dump_reg_list[i]);
+   for (i = 0; i < adev->reset_info.num_regs; i++) {
+   sprintf(reg_offset, "0x%x\n", 
adev->reset_info.reset_dump_reg_list[i]);
up_read(>reset_domain->sem);
if (copy_to_user(buf + len, reg_offset, strlen(reg_offset)))
return -EFAULT;
@@ -2074,9 +2074,9 @@ static ssize_t 
amdgpu_reset_dump_register_list_write(struct file *f,
if (ret)
goto error_free;
 
-   swap(adev->reset_dump_reg_list, tmp);
-   swap(adev->reset_dump_reg_value, new);
-   adev->num_regs = i;
+   swap(adev->reset_info.reset_dump_reg_list, tmp);
+   swap(adev->reset_info.reset_dump_reg_value, new);
+   adev->reset_info.num_regs = i;
up_write(>reset_domain->sem);
ret = size;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b5b879bcc5c9..96975591841d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -4790,10 +4790,10 @@ static int amdgpu_reset_reg_dumps(struct amdgpu_device 
*adev)
 
lockdep_assert_held(>reset_domain->sem);
 
-   for (i = 0; i < adev->num_regs; i++) {
-   adev->reset_dump_reg_value[i] = 
RREG32(adev->reset_dump_reg_list[i]);
-   trace_amdgpu_reset_reg_dumps(adev->reset_dump_reg_list[i],
-adev->reset_dump_reg_value[i]);
+   for (i = 0; i < adev->reset_info.num_regs; i++) {
+   adev->reset_info.reset_dump_reg_value[i] = 
RREG32(adev->reset_info.reset_dump_reg_list[i]);
+   
trace_amdgpu_reset_reg_dumps(adev->reset_info.reset_dump_reg_list[i],
+
adev->reset_info.reset_dump_reg_value[i]);
}
 
return 0;
@@ -4831,13 +4831,13 @@ static ssize_t amdgpu_devcoredump_read(char *buffer, 
loff_t offset,
 
if (coredump->reset_vram_lost)
drm_printf(, "VRAM is lost due to GPU reset!\n");
-   if (coredump->adev->num_regs) {
+   if 

[PATCH 9/9] dma_buf: heaps: mtk_sec_heap: Add a new CMA heap

[Yong Wu]

Create a new mtk_svp_cma heap from the CMA reserved buffer.

When the first allocating buffer, use cma_alloc to prepare whole the
CMA range, then send its range to TEE to protect and manage.
For the later allocating, we just adds the cma_used_size.

When SVP done, cma_release will release the buffer, then kernel may
reuse it.

Signed-off-by: Yong Wu 
---
 drivers/dma-buf/heaps/Kconfig   |   2 +-
 drivers/dma-buf/heaps/mtk_secure_heap.c | 121 +++-
 2 files changed, 119 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index 729c0cf3eb7c..e101f788ecbf 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -15,7 +15,7 @@ config DMABUF_HEAPS_CMA
 
 config DMABUF_HEAPS_MTK_SECURE
bool "DMA-BUF MediaTek Secure Heap"
-   depends on DMABUF_HEAPS && TEE
+   depends on DMABUF_HEAPS && TEE && CMA
help
  Choose this option to enable dma-buf MediaTek secure heap for Secure
  Video Path. This heap is backed by TEE client interfaces. If in
diff --git a/drivers/dma-buf/heaps/mtk_secure_heap.c 
b/drivers/dma-buf/heaps/mtk_secure_heap.c
index daf6cf2121a1..3f568fe6b569 100644
--- a/drivers/dma-buf/heaps/mtk_secure_heap.c
+++ b/drivers/dma-buf/heaps/mtk_secure_heap.c
@@ -4,11 +4,12 @@
  *
  * Copyright (C) 2023 MediaTek Inc.
  */
-
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -25,9 +26,11 @@
  * MediaTek secure (chunk) memory type
  *
  * @KREE_MEM_SEC_CM_TZ: static chunk memory carved out for trustzone.
+ * @KREE_MEM_SEC_CM_CMA: dynamic chunk memory carved out from CMA.
  */
 enum kree_mem_type {
KREE_MEM_SEC_CM_TZ = 1,
+   KREE_MEM_SEC_CM_CMA,
 };
 
 struct mtk_secure_heap_buffer {
@@ -42,6 +45,13 @@ struct mtk_secure_heap {
const enum kree_mem_type mem_type;
u32  mem_session;
struct tee_context  *tee_ctx;
+
+   struct cma  *cma;
+   struct page *cma_page;
+   unsigned long   cma_paddr;
+   unsigned long   cma_size;
+   unsigned long   cma_used_size;
+   struct mutexlock; /* lock for cma_used_size */
 };
 
 struct mtk_secure_heap_attachment {
@@ -90,6 +100,42 @@ static int mtk_kree_secure_session_init(struct 
mtk_secure_heap *sec_heap)
return ret;
 }
 
+static int mtk_sec_mem_cma_allocate(struct mtk_secure_heap *sec_heap, size_t 
size)
+{
+   /*
+* Allocate CMA only when allocating buffer for the first time, and just
+* increase cma_used_size at the other times.
+*/
+   mutex_lock(_heap->lock);
+   if (sec_heap->cma_used_size)
+   goto add_size;
+
+   mutex_unlock(_heap->lock);
+   sec_heap->cma_page = cma_alloc(sec_heap->cma, sec_heap->cma_size >> 
PAGE_SHIFT,
+  get_order(PAGE_SIZE), false);
+   if (!sec_heap->cma_page)
+   return -ENOMEM;
+
+   mutex_lock(_heap->lock);
+add_size:
+   sec_heap->cma_used_size += size;
+   mutex_unlock(_heap->lock);
+   return sec_heap->cma_used_size;
+}
+
+static void mtk_sec_mem_cma_free(struct mtk_secure_heap *sec_heap, size_t size)
+{
+   bool cma_is_empty;
+
+   mutex_lock(_heap->lock);
+   sec_heap->cma_used_size -= size;
+   cma_is_empty = !sec_heap->cma_used_size;
+   mutex_unlock(_heap->lock);
+
+   if (cma_is_empty)
+   cma_release(sec_heap->cma, sec_heap->cma_page, 
sec_heap->cma_size >> PAGE_SHIFT);
+}
+
 static int
 mtk_sec_mem_tee_service_call(struct tee_context *tee_ctx, u32 session,
 unsigned int command, struct tee_param *params)
@@ -114,23 +160,47 @@ static int mtk_sec_mem_allocate(struct mtk_secure_heap 
*sec_heap,
 {
struct tee_param params[MTK_TEE_PARAM_NUM] = {0};
u32 mem_session = sec_heap->mem_session;
+   bool cma_frst_alloc = false;
int ret;
 
+   if (sec_heap->cma) {
+   ret = mtk_sec_mem_cma_allocate(sec_heap, sec_buf->size);
+   if (ret < 0)
+   return ret;
+   /*
+* When CMA allocates for the first time, pass the CMA range to 
TEE
+* to protect it. It's the first allocating if the 
cma_used_size is equal
+* to this required buffer size.
+*/
+   cma_frst_alloc = (ret == sec_buf->size);
+   }
+
params[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
params[0].u.value.a = SZ_4K;/* alignment */
params[0].u.value.b = sec_heap->mem_type;   /* memory type */
params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
params[1].u.value.a = sec_buf->size;
params[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT;
+   if (sec_heap->cma && cma_frst_alloc) {
+   params[2].u.value.a = 

[PATCH 8/9] dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP

[Yong Wu]

This adds the binding for describing a CMA memory for MediaTek SVP(Secure
Video Path).

Signed-off-by: Yong Wu 
---
 .../mediatek,secure_cma_chunkmem.yaml | 42 +++
 1 file changed, 42 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml

diff --git 
a/Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml
 
b/Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml
new file mode 100644
index ..cc10e00d35c4
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: 
http://devicetree.org/schemas/reserved-memory/mediatek,secure_cma_chunkmem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek Secure Video Path Reserved Memory
+
+description:
+  This binding describes the reserved memory for secure video path.
+
+maintainers:
+  - Yong Wu 
+
+allOf:
+  - $ref: reserved-memory.yaml
+
+properties:
+  compatible:
+const: mediatek,secure_cma_chunkmem
+
+required:
+  - compatible
+  - reg
+  - reusable
+
+unevaluatedProperties: false
+
+examples:
+  - |
+
+reserved-memory {
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;
+
+reserved-memory@8000 {
+compatible = "mediatek,secure_cma_chunkmem";
+reusable;
+reg = <0x8000 0x1800>;
+};
+};
-- 
2.25.1

[PATCH 7/9] dma-buf: heaps: mtk_sec_heap: Add dma_ops

[Yong Wu]

Add the dma_ops for this secure heap.
a) For secure buffer, cache_ops/mmap are not allowed, thus return
EPERM for them.
b) The secure buffer can't be accessed in kernel, thus it doesn't
have va/dma_address for it. Use the dma_address property to save the
"secure handle".

Signed-off-by: Anan Sun 
Signed-off-by: Yong Wu 
---
 drivers/dma-buf/heaps/mtk_secure_heap.c | 116 
 1 file changed, 116 insertions(+)

diff --git a/drivers/dma-buf/heaps/mtk_secure_heap.c 
b/drivers/dma-buf/heaps/mtk_secure_heap.c
index 14c2a16a7164..daf6cf2121a1 100644
--- a/drivers/dma-buf/heaps/mtk_secure_heap.c
+++ b/drivers/dma-buf/heaps/mtk_secure_heap.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -43,6 +44,10 @@ struct mtk_secure_heap {
struct tee_context  *tee_ctx;
 };
 
+struct mtk_secure_heap_attachment {
+   struct sg_table *table;
+};
+
 static int mtk_optee_ctx_match(struct tee_ioctl_version_data *ver, const void 
*data)
 {
return ver->impl_id == TEE_IMPL_ID_OPTEE;
@@ -142,6 +147,116 @@ static void mtk_sec_mem_release(struct mtk_secure_heap 
*sec_heap,
 TZCMD_MEM_SECURECM_UNREF, params);
 }
 
+static int mtk_sec_heap_attach(struct dma_buf *dmabuf, struct 
dma_buf_attachment *attachment)
+{
+   struct mtk_secure_heap_buffer *sec_buf = dmabuf->priv;
+   struct mtk_secure_heap_attachment *a;
+   struct sg_table *table;
+   int ret = 0;
+
+   a = kzalloc(sizeof(*a), GFP_KERNEL);
+   if (!a)
+   return -ENOMEM;
+
+   table = kzalloc(sizeof(*table), GFP_KERNEL);
+   if (!table) {
+   ret = -ENOMEM;
+   goto err_free_attach;
+   }
+
+   ret = sg_alloc_table(table, 1, GFP_KERNEL);
+   if (ret)
+   goto err_free_sgt;
+   sg_set_page(table->sgl, 0, sec_buf->size, 0);
+
+   a->table = table;
+   attachment->priv = a;
+
+   return 0;
+
+err_free_sgt:
+   kfree(table);
+err_free_attach:
+   kfree(a);
+   return ret;
+}
+
+static void mtk_sec_heap_detach(struct dma_buf *dmabuf, struct 
dma_buf_attachment *attachment)
+{
+   struct mtk_secure_heap_attachment *a = attachment->priv;
+
+   sg_free_table(a->table);
+   kfree(a->table);
+   kfree(a);
+}
+
+static struct sg_table *
+mtk_sec_heap_map_dma_buf(struct dma_buf_attachment *attachment, enum 
dma_data_direction direction)
+{
+   struct mtk_secure_heap_attachment *a = attachment->priv;
+   struct dma_buf *dmabuf = attachment->dmabuf;
+   struct mtk_secure_heap_buffer *sec_buf = dmabuf->priv;
+   struct sg_table *table = a->table;
+
+   /*
+* Technically dma_address refers to the address used by HW, But for 
secure buffer
+* we don't know its dma_address in kernel, Instead, we only know its 
"secure handle".
+* Thus use this property to save the "secure handle", and the user 
will use it to
+* obtain the real address in secure world.
+*/
+   sg_dma_address(table->sgl) = sec_buf->sec_handle;
+   sg_dma_len(table->sgl) = sec_buf->size;
+
+   return table;
+}
+
+static void
+mtk_sec_heap_unmap_dma_buf(struct dma_buf_attachment *attachment, struct 
sg_table *table,
+  enum dma_data_direction direction)
+{
+   struct mtk_secure_heap_attachment *a = attachment->priv;
+
+   WARN_ON(a->table != table);
+   sg_dma_address(table->sgl) = 0;
+}
+
+static int
+mtk_sec_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, enum 
dma_data_direction direction)
+{
+   return -EPERM;
+}
+
+static int
+mtk_sec_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf, enum 
dma_data_direction direction)
+{
+   return -EPERM;
+}
+
+static int mtk_sec_heap_dma_buf_mmap(struct dma_buf *dmabuf, struct 
vm_area_struct *vma)
+{
+   return -EPERM;
+}
+
+static void mtk_sec_heap_free(struct dma_buf *dmabuf)
+{
+   struct mtk_secure_heap_buffer *sec_buf = dmabuf->priv;
+   struct mtk_secure_heap *sec_heap = dma_heap_get_drvdata(sec_buf->heap);
+
+   mtk_sec_mem_release(sec_heap, sec_buf);
+   kfree(sec_buf);
+}
+
+static const struct dma_buf_ops mtk_sec_heap_buf_ops = {
+   .attach = mtk_sec_heap_attach,
+   .detach = mtk_sec_heap_detach,
+   .map_dma_buf= mtk_sec_heap_map_dma_buf,
+   .unmap_dma_buf  = mtk_sec_heap_unmap_dma_buf,
+   .begin_cpu_access = mtk_sec_heap_dma_buf_begin_cpu_access,
+   .end_cpu_access = mtk_sec_heap_dma_buf_end_cpu_access,
+   .mmap   = mtk_sec_heap_dma_buf_mmap,
+   .release= mtk_sec_heap_free,
+};
+
 static struct dma_buf *
 mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
  unsigned long fd_flags, unsigned long heap_flags)
@@ -173,6 +288,7 @@ mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
if (ret)
goto err_free_buf;
exp_info.exp_name = 

[PATCH 6/9] dma-buf: heaps: mtk_sec_heap: Add tee service call for buffer allocating/freeing

[Yong Wu]

Add TEE service call for secure memory allocating/freeing.

Signed-off-by: Anan Sun 
Signed-off-by: Yong Wu 
---
 drivers/dma-buf/heaps/mtk_secure_heap.c | 69 -
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/heaps/mtk_secure_heap.c 
b/drivers/dma-buf/heaps/mtk_secure_heap.c
index e3da33a3d083..14c2a16a7164 100644
--- a/drivers/dma-buf/heaps/mtk_secure_heap.c
+++ b/drivers/dma-buf/heaps/mtk_secure_heap.c
@@ -17,6 +17,9 @@
 
 #define MTK_TEE_PARAM_NUM  4
 
+#define TZCMD_MEM_SECURECM_UNREF   7
+#define TZCMD_MEM_SECURECM_ZALLOC  15
+
 /*
  * MediaTek secure (chunk) memory type
  *
@@ -29,6 +32,8 @@ enum kree_mem_type {
 struct mtk_secure_heap_buffer {
struct dma_heap *heap;
size_t  size;
+
+   u32 sec_handle;
 };
 
 struct mtk_secure_heap {
@@ -80,6 +85,63 @@ static int mtk_kree_secure_session_init(struct 
mtk_secure_heap *sec_heap)
return ret;
 }
 
+static int
+mtk_sec_mem_tee_service_call(struct tee_context *tee_ctx, u32 session,
+unsigned int command, struct tee_param *params)
+{
+   struct tee_ioctl_invoke_arg arg = {0};
+   int ret;
+
+   arg.num_params = MTK_TEE_PARAM_NUM;
+   arg.session = session;
+   arg.func = command;
+
+   ret = tee_client_invoke_func(tee_ctx, , params);
+   if (ret < 0 || arg.ret) {
+   pr_err("%s: cmd %d ret %d:%x.\n", __func__, command, ret, 
arg.ret);
+   ret = -EOPNOTSUPP;
+   }
+   return ret;
+}
+
+static int mtk_sec_mem_allocate(struct mtk_secure_heap *sec_heap,
+   struct mtk_secure_heap_buffer *sec_buf)
+{
+   struct tee_param params[MTK_TEE_PARAM_NUM] = {0};
+   u32 mem_session = sec_heap->mem_session;
+   int ret;
+
+   params[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+   params[0].u.value.a = SZ_4K;/* alignment */
+   params[0].u.value.b = sec_heap->mem_type;   /* memory type */
+   params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+   params[1].u.value.a = sec_buf->size;
+   params[2].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INOUT;
+
+   /* Always request zeroed buffer */
+   ret = mtk_sec_mem_tee_service_call(sec_heap->tee_ctx, mem_session,
+  TZCMD_MEM_SECURECM_ZALLOC, params);
+   if (ret)
+   return -ENOMEM;
+
+   sec_buf->sec_handle = params[2].u.value.a;
+   return 0;
+}
+
+static void mtk_sec_mem_release(struct mtk_secure_heap *sec_heap,
+   struct mtk_secure_heap_buffer *sec_buf)
+{
+   struct tee_param params[MTK_TEE_PARAM_NUM] = {0};
+   u32 mem_session = sec_heap->mem_session;
+
+   params[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_INPUT;
+   params[0].u.value.a = sec_buf->sec_handle;
+   params[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT;
+
+   mtk_sec_mem_tee_service_call(sec_heap->tee_ctx, mem_session,
+TZCMD_MEM_SECURECM_UNREF, params);
+}
+
 static struct dma_buf *
 mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
  unsigned long fd_flags, unsigned long heap_flags)
@@ -107,6 +169,9 @@ mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
sec_buf->size = size;
sec_buf->heap = heap;
 
+   ret = mtk_sec_mem_allocate(sec_heap, sec_buf);
+   if (ret)
+   goto err_free_buf;
exp_info.exp_name = dma_heap_get_name(heap);
exp_info.size = sec_buf->size;
exp_info.flags = fd_flags;
@@ -115,11 +180,13 @@ mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
dmabuf = dma_buf_export(_info);
if (IS_ERR(dmabuf)) {
ret = PTR_ERR(dmabuf);
-   goto err_free_buf;
+   goto err_free_sec_mem;
}
 
return dmabuf;
 
+err_free_sec_mem:
+   mtk_sec_mem_release(sec_heap, sec_buf);
 err_free_buf:
kfree(sec_buf);
return ERR_PTR(ret);
-- 
2.25.1

[PATCH 5/9] dma-buf: heaps: mtk_sec_heap: Initialise tee session

[Yong Wu]

The TEE probe later than dma-buf heap, and PROBE_DEDER doesn't work
here since this is not a platform driver, therefore initialise the TEE
context/session while we allocate the first secure buffer.

Signed-off-by: Yong Wu 
---
 drivers/dma-buf/heaps/mtk_secure_heap.c | 61 +
 1 file changed, 61 insertions(+)

diff --git a/drivers/dma-buf/heaps/mtk_secure_heap.c 
b/drivers/dma-buf/heaps/mtk_secure_heap.c
index bbf1c8dce23e..e3da33a3d083 100644
--- a/drivers/dma-buf/heaps/mtk_secure_heap.c
+++ b/drivers/dma-buf/heaps/mtk_secure_heap.c
@@ -10,6 +10,12 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+#define TZ_TA_MEM_UUID "4477588a-8476-11e2-ad15-e41f1390d676"
+
+#define MTK_TEE_PARAM_NUM  4
 
 /*
  * MediaTek secure (chunk) memory type
@@ -28,17 +34,72 @@ struct mtk_secure_heap_buffer {
 struct mtk_secure_heap {
const char  *name;
const enum kree_mem_type mem_type;
+   u32  mem_session;
+   struct tee_context  *tee_ctx;
 };
 
+static int mtk_optee_ctx_match(struct tee_ioctl_version_data *ver, const void 
*data)
+{
+   return ver->impl_id == TEE_IMPL_ID_OPTEE;
+}
+
+static int mtk_kree_secure_session_init(struct mtk_secure_heap *sec_heap)
+{
+   struct tee_param t_param[MTK_TEE_PARAM_NUM] = {0};
+   struct tee_ioctl_open_session_arg arg = {0};
+   uuid_t ta_mem_uuid;
+   int ret;
+
+   sec_heap->tee_ctx = tee_client_open_context(NULL, mtk_optee_ctx_match,
+   NULL, NULL);
+   if (IS_ERR(sec_heap->tee_ctx)) {
+   pr_err("%s: open context failed, ret=%ld\n", sec_heap->name,
+  PTR_ERR(sec_heap->tee_ctx));
+   return -ENODEV;
+   }
+
+   arg.num_params = MTK_TEE_PARAM_NUM;
+   arg.clnt_login = TEE_IOCTL_LOGIN_PUBLIC;
+   ret = uuid_parse(TZ_TA_MEM_UUID, _mem_uuid);
+   if (ret)
+   goto close_context;
+   memcpy(, _mem_uuid.b, sizeof(ta_mem_uuid));
+
+   ret = tee_client_open_session(sec_heap->tee_ctx, , t_param);
+   if (ret < 0 || arg.ret) {
+   pr_err("%s: open session failed, ret=%d:%d\n",
+  sec_heap->name, ret, arg.ret);
+   ret = -EINVAL;
+   goto close_context;
+   }
+   sec_heap->mem_session = arg.session;
+   return 0;
+
+close_context:
+   tee_client_close_context(sec_heap->tee_ctx);
+   return ret;
+}
+
 static struct dma_buf *
 mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
  unsigned long fd_flags, unsigned long heap_flags)
 {
+   struct mtk_secure_heap *sec_heap = dma_heap_get_drvdata(heap);
struct mtk_secure_heap_buffer *sec_buf;
DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
struct dma_buf *dmabuf;
int ret;
 
+   /*
+* TEE probe may be late. Initialise the secure session in the first
+* allocating secure buffer.
+*/
+   if (!sec_heap->mem_session) {
+   ret = mtk_kree_secure_session_init(sec_heap);
+   if (ret)
+   return ERR_PTR(ret);
+   }
+
sec_buf = kzalloc(sizeof(*sec_buf), GFP_KERNEL);
if (!sec_buf)
return ERR_PTR(-ENOMEM);
-- 
2.25.1

[PATCH 4/9] dma-buf: heaps: Initialise MediaTek secure heap

[Yong Wu]

Initialise a mtk_svp heap. Currently just add a null heap, Prepare for
the later patches.

Signed-off-by: Yong Wu 
---
 drivers/dma-buf/heaps/Kconfig   |  8 ++
 drivers/dma-buf/heaps/Makefile  |  1 +
 drivers/dma-buf/heaps/mtk_secure_heap.c | 99 +
 3 files changed, 108 insertions(+)
 create mode 100644 drivers/dma-buf/heaps/mtk_secure_heap.c

diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
index a5eef06c4226..729c0cf3eb7c 100644
--- a/drivers/dma-buf/heaps/Kconfig
+++ b/drivers/dma-buf/heaps/Kconfig
@@ -12,3 +12,11 @@ config DMABUF_HEAPS_CMA
  Choose this option to enable dma-buf CMA heap. This heap is backed
  by the Contiguous Memory Allocator (CMA). If your system has these
  regions, you should say Y here.
+
+config DMABUF_HEAPS_MTK_SECURE
+   bool "DMA-BUF MediaTek Secure Heap"
+   depends on DMABUF_HEAPS && TEE
+   help
+ Choose this option to enable dma-buf MediaTek secure heap for Secure
+ Video Path. This heap is backed by TEE client interfaces. If in
+ doubt, say N.
diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
index 974467791032..df559dbe33fe 100644
--- a/drivers/dma-buf/heaps/Makefile
+++ b/drivers/dma-buf/heaps/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)  += system_heap.o
 obj-$(CONFIG_DMABUF_HEAPS_CMA) += cma_heap.o
+obj-$(CONFIG_DMABUF_HEAPS_MTK_SECURE)  += mtk_secure_heap.o
diff --git a/drivers/dma-buf/heaps/mtk_secure_heap.c 
b/drivers/dma-buf/heaps/mtk_secure_heap.c
new file mode 100644
index ..bbf1c8dce23e
--- /dev/null
+++ b/drivers/dma-buf/heaps/mtk_secure_heap.c
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DMABUF mtk_secure_heap exporter
+ *
+ * Copyright (C) 2023 MediaTek Inc.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * MediaTek secure (chunk) memory type
+ *
+ * @KREE_MEM_SEC_CM_TZ: static chunk memory carved out for trustzone.
+ */
+enum kree_mem_type {
+   KREE_MEM_SEC_CM_TZ = 1,
+};
+
+struct mtk_secure_heap_buffer {
+   struct dma_heap *heap;
+   size_t  size;
+};
+
+struct mtk_secure_heap {
+   const char  *name;
+   const enum kree_mem_type mem_type;
+};
+
+static struct dma_buf *
+mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
+ unsigned long fd_flags, unsigned long heap_flags)
+{
+   struct mtk_secure_heap_buffer *sec_buf;
+   DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
+   struct dma_buf *dmabuf;
+   int ret;
+
+   sec_buf = kzalloc(sizeof(*sec_buf), GFP_KERNEL);
+   if (!sec_buf)
+   return ERR_PTR(-ENOMEM);
+
+   sec_buf->size = size;
+   sec_buf->heap = heap;
+
+   exp_info.exp_name = dma_heap_get_name(heap);
+   exp_info.size = sec_buf->size;
+   exp_info.flags = fd_flags;
+   exp_info.priv = sec_buf;
+
+   dmabuf = dma_buf_export(_info);
+   if (IS_ERR(dmabuf)) {
+   ret = PTR_ERR(dmabuf);
+   goto err_free_buf;
+   }
+
+   return dmabuf;
+
+err_free_buf:
+   kfree(sec_buf);
+   return ERR_PTR(ret);
+}
+
+static const struct dma_heap_ops mtk_sec_heap_ops = {
+   .allocate   = mtk_sec_heap_allocate,
+};
+
+static struct mtk_secure_heap mtk_sec_heap[] = {
+   {
+   .name   = "mtk_svp",
+   .mem_type   = KREE_MEM_SEC_CM_TZ,
+   },
+};
+
+static int mtk_sec_heap_init(void)
+{
+   struct mtk_secure_heap *sec_heap = mtk_sec_heap;
+   struct dma_heap_export_info exp_info;
+   struct dma_heap *heap;
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(mtk_sec_heap); i++, sec_heap++) {
+   exp_info.name = sec_heap->name;
+   exp_info.ops = _sec_heap_ops;
+   exp_info.priv = (void *)sec_heap;
+
+   heap = dma_heap_add(_info);
+   if (IS_ERR(heap))
+   return PTR_ERR(heap);
+   }
+   return 0;
+}
+
+module_init(mtk_sec_heap_init);
+MODULE_DESCRIPTION("MediaTek Secure Heap Driver");
+MODULE_LICENSE("GPL");
-- 
2.25.1

[PATCH 3/9] dma-heap: Provide accessors so that in-kernel drivers can allocate dmabufs from specific heaps

[Yong Wu]

From: John Stultz 

This allows drivers who don't want to create their own
DMA-BUF exporter to be able to allocate DMA-BUFs directly
from existing DMA-BUF Heaps.

There is some concern that the premise of DMA-BUF heaps is
that userland knows better about what type of heap memory
is needed for a pipeline, so it would likely be best for
drivers to import and fill DMA-BUFs allocated by userland
instead of allocating one themselves, but this is still
up for debate.

Signed-off-by: John Stultz 
Signed-off-by: T.J. Mercier 
Signed-off-by: Yong Wu 
[Yong: Fix the checkpatch alignment warning]
---
 drivers/dma-buf/dma-heap.c | 60 --
 include/linux/dma-heap.h   | 25 
 2 files changed, 69 insertions(+), 16 deletions(-)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index dcc0e38c61fa..908bb30dc864 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -53,12 +53,15 @@ static dev_t dma_heap_devt;
 static struct class *dma_heap_class;
 static DEFINE_XARRAY_ALLOC(dma_heap_minors);
 
-static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
-unsigned int fd_flags,
-unsigned int heap_flags)
+struct dma_buf *dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
+ unsigned int fd_flags,
+ unsigned int heap_flags)
 {
-   struct dma_buf *dmabuf;
-   int fd;
+   if (fd_flags & ~DMA_HEAP_VALID_FD_FLAGS)
+   return ERR_PTR(-EINVAL);
+
+   if (heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
+   return ERR_PTR(-EINVAL);
 
/*
 * Allocations from all heaps have to begin
@@ -66,9 +69,20 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, 
size_t len,
 */
len = PAGE_ALIGN(len);
if (!len)
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
 
-   dmabuf = heap->ops->allocate(heap, len, fd_flags, heap_flags);
+   return heap->ops->allocate(heap, len, fd_flags, heap_flags);
+}
+EXPORT_SYMBOL_GPL(dma_heap_buffer_alloc);
+
+static int dma_heap_bufferfd_alloc(struct dma_heap *heap, size_t len,
+  unsigned int fd_flags,
+  unsigned int heap_flags)
+{
+   struct dma_buf *dmabuf;
+   int fd;
+
+   dmabuf = dma_heap_buffer_alloc(heap, len, fd_flags, heap_flags);
if (IS_ERR(dmabuf))
return PTR_ERR(dmabuf);
 
@@ -106,15 +120,9 @@ static long dma_heap_ioctl_allocate(struct file *file, 
void *data)
if (heap_allocation->fd)
return -EINVAL;
 
-   if (heap_allocation->fd_flags & ~DMA_HEAP_VALID_FD_FLAGS)
-   return -EINVAL;
-
-   if (heap_allocation->heap_flags & ~DMA_HEAP_VALID_HEAP_FLAGS)
-   return -EINVAL;
-
-   fd = dma_heap_buffer_alloc(heap, heap_allocation->len,
-  heap_allocation->fd_flags,
-  heap_allocation->heap_flags);
+   fd = dma_heap_bufferfd_alloc(heap, heap_allocation->len,
+heap_allocation->fd_flags,
+heap_allocation->heap_flags);
if (fd < 0)
return fd;
 
@@ -205,6 +213,7 @@ const char *dma_heap_get_name(struct dma_heap *heap)
 {
return heap->name;
 }
+EXPORT_SYMBOL_GPL(dma_heap_get_name);
 
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info)
 {
@@ -290,6 +299,24 @@ struct dma_heap *dma_heap_add(const struct 
dma_heap_export_info *exp_info)
kfree(heap);
return err_ret;
 }
+EXPORT_SYMBOL_GPL(dma_heap_add);
+
+struct dma_heap *dma_heap_find(const char *name)
+{
+   struct dma_heap *h;
+
+   mutex_lock(_list_lock);
+   list_for_each_entry(h, _list, list) {
+   if (!strcmp(h->name, name)) {
+   kref_get(>refcount);
+   mutex_unlock(_list_lock);
+   return h;
+   }
+   }
+   mutex_unlock(_list_lock);
+   return NULL;
+}
+EXPORT_SYMBOL_GPL(dma_heap_find);
 
 static void dma_heap_release(struct kref *ref)
 {
@@ -315,6 +342,7 @@ void dma_heap_put(struct dma_heap *h)
kref_put(>refcount, dma_heap_release);
mutex_unlock(_list_lock);
 }
+EXPORT_SYMBOL_GPL(dma_heap_put);
 
 static char *dma_heap_devnode(const struct device *dev, umode_t *mode)
 {
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index f3c678892c5c..59e70f6c7a60 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -64,10 +64,35 @@ const char *dma_heap_get_name(struct dma_heap *heap);
  */
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
 
+/**
+ * dma_heap_find - get the heap registered with the specified name
+ * @name: Name of the DMA-Heap to find
+ *
+ * Returns:
+ * The DMA-Heap 

[PATCH 2/9] dma-heap: Add proper kref handling on dma-buf heaps

[Yong Wu]

From: John Stultz 

Add proper refcounting on the dma_heap structure.
While existing heaps are built-in, we may eventually
have heaps loaded from modules, and we'll need to be
able to properly handle the references to the heaps

Also moves minor tracking into the heap structure so
we can properly free things.

Signed-off-by: John Stultz 
Signed-off-by: T.J. Mercier 
Signed-off-by: Yong Wu 
[Yong: Just add comment for "minor" and "refcount"]
---
 drivers/dma-buf/dma-heap.c | 38 ++
 include/linux/dma-heap.h   |  6 ++
 2 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 51030f6c9d6e..dcc0e38c61fa 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,6 +31,8 @@
  * @heap_devt: heap device node
  * @list:  list head connecting to list of heaps
  * @heap_cdev: heap char device
+ * @minor: heap device node minor number
+ * @refcount:  reference counter for this heap device
  *
  * Represents a heap of memory from which buffers can be made.
  */
@@ -40,6 +43,8 @@ struct dma_heap {
dev_t heap_devt;
struct list_head list;
struct cdev heap_cdev;
+   int minor;
+   struct kref refcount;
 };
 
 static LIST_HEAD(heap_list);
@@ -205,7 +210,6 @@ struct dma_heap *dma_heap_add(const struct 
dma_heap_export_info *exp_info)
 {
struct dma_heap *heap, *h, *err_ret;
struct device *dev_ret;
-   unsigned int minor;
int ret;
 
if (!exp_info->name || !strcmp(exp_info->name, "")) {
@@ -222,12 +226,13 @@ struct dma_heap *dma_heap_add(const struct 
dma_heap_export_info *exp_info)
if (!heap)
return ERR_PTR(-ENOMEM);
 
+   kref_init(>refcount);
heap->name = exp_info->name;
heap->ops = exp_info->ops;
heap->priv = exp_info->priv;
 
/* Find unused minor number */
-   ret = xa_alloc(_heap_minors, , heap,
+   ret = xa_alloc(_heap_minors, >minor, heap,
   XA_LIMIT(0, NUM_HEAP_MINORS - 1), GFP_KERNEL);
if (ret < 0) {
pr_err("dma_heap: Unable to get minor number for heap\n");
@@ -236,7 +241,7 @@ struct dma_heap *dma_heap_add(const struct 
dma_heap_export_info *exp_info)
}
 
/* Create device */
-   heap->heap_devt = MKDEV(MAJOR(dma_heap_devt), minor);
+   heap->heap_devt = MKDEV(MAJOR(dma_heap_devt), heap->minor);
 
cdev_init(>heap_cdev, _heap_fops);
ret = cdev_add(>heap_cdev, heap->heap_devt, 1);
@@ -280,12 +285,37 @@ struct dma_heap *dma_heap_add(const struct 
dma_heap_export_info *exp_info)
 err2:
cdev_del(>heap_cdev);
 err1:
-   xa_erase(_heap_minors, minor);
+   xa_erase(_heap_minors, heap->minor);
 err0:
kfree(heap);
return err_ret;
 }
 
+static void dma_heap_release(struct kref *ref)
+{
+   struct dma_heap *heap = container_of(ref, struct dma_heap, refcount);
+
+   /* Note, we already holding the heap_list_lock here */
+   list_del(>list);
+
+   device_destroy(dma_heap_class, heap->heap_devt);
+   cdev_del(>heap_cdev);
+   xa_erase(_heap_minors, heap->minor);
+
+   kfree(heap);
+}
+
+void dma_heap_put(struct dma_heap *h)
+{
+   /*
+* Take the heap_list_lock now to avoid racing with code
+* scanning the list and then taking a kref.
+*/
+   mutex_lock(_list_lock);
+   kref_put(>refcount, dma_heap_release);
+   mutex_unlock(_list_lock);
+}
+
 static char *dma_heap_devnode(const struct device *dev, umode_t *mode)
 {
return kasprintf(GFP_KERNEL, "dma_heap/%s", dev_name(dev));
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index c7c29b724ad6..f3c678892c5c 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -64,4 +64,10 @@ const char *dma_heap_get_name(struct dma_heap *heap);
  */
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
 
+/**
+ * dma_heap_put - drops a reference to a dmabuf heap, potentially freeing it
+ * @heap: the heap whose reference count to decrement
+ */
+void dma_heap_put(struct dma_heap *heap);
+
 #endif /* _DMA_HEAPS_H */
-- 
2.25.1

[PATCH 1/9] dma-buf: heaps: Deduplicate docs and adopt common format

[Yong Wu]

From: "T.J. Mercier" 

The docs for dma_heap_get_name were incorrect, and since they were
duplicated in the implementation file they were wrong there too.

The docs formatting was inconsistent so I tried to make it more
consistent across functions since I'm already in here doing cleanup.

Remove multiple unused includes.

Signed-off-by: T.J. Mercier 
Signed-off-by: Yong Wu 
[Yong: Just add a comment for "priv" to mute build warning]
---
 drivers/dma-buf/dma-heap.c | 29 +++--
 include/linux/dma-heap.h   | 11 +--
 2 files changed, 12 insertions(+), 28 deletions(-)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 84ae708fafe7..51030f6c9d6e 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -7,17 +7,15 @@
  */
 
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
-#include 
 #include 
-#include 
 #include 
-#include 
 #include 
-#include 
+#include 
+#include 
 #include 
 
 #define DEVNAME "dma_heap"
@@ -28,9 +26,10 @@
  * struct dma_heap - represents a dmabuf heap in the system
  * @name:  used for debugging/device-node name
  * @ops:   ops struct for this heap
- * @heap_devt  heap device node
- * @list   list head connecting to list of heaps
- * @heap_cdev  heap char device
+ * @priv:  private data for this heap
+ * @heap_devt: heap device node
+ * @list:  list head connecting to list of heaps
+ * @heap_cdev: heap char device
  *
  * Represents a heap of memory from which buffers can be made.
  */
@@ -192,25 +191,11 @@ static const struct file_operations dma_heap_fops = {
 #endif
 };
 
-/**
- * dma_heap_get_drvdata() - get per-subdriver data for the heap
- * @heap: DMA-Heap to retrieve private data for
- *
- * Returns:
- * The per-subdriver data for the heap.
- */
 void *dma_heap_get_drvdata(struct dma_heap *heap)
 {
return heap->priv;
 }
 
-/**
- * dma_heap_get_name() - get heap name
- * @heap: DMA-Heap to retrieve private data for
- *
- * Returns:
- * The char* for the heap name.
- */
 const char *dma_heap_get_name(struct dma_heap *heap)
 {
return heap->name;
diff --git a/include/linux/dma-heap.h b/include/linux/dma-heap.h
index 0c05561cad6e..c7c29b724ad6 100644
--- a/include/linux/dma-heap.h
+++ b/include/linux/dma-heap.h
@@ -9,14 +9,13 @@
 #ifndef _DMA_HEAPS_H
 #define _DMA_HEAPS_H
 
-#include 
 #include 
 
 struct dma_heap;
 
 /**
  * struct dma_heap_ops - ops to operate on a given heap
- * @allocate:  allocate dmabuf and return struct dma_buf ptr
+ * @allocate: allocate dmabuf and return struct dma_buf ptr
  *
  * allocate returns dmabuf on success, ERR_PTR(-errno) on error.
  */
@@ -42,7 +41,7 @@ struct dma_heap_export_info {
 };
 
 /**
- * dma_heap_get_drvdata() - get per-heap driver data
+ * dma_heap_get_drvdata - get per-heap driver data
  * @heap: DMA-Heap to retrieve private data for
  *
  * Returns:
@@ -51,8 +50,8 @@ struct dma_heap_export_info {
 void *dma_heap_get_drvdata(struct dma_heap *heap);
 
 /**
- * dma_heap_get_name() - get heap name
- * @heap: DMA-Heap to retrieve private data for
+ * dma_heap_get_name - get heap name
+ * @heap: DMA-Heap to retrieve the name of
  *
  * Returns:
  * The char* for the heap name.
@@ -61,7 +60,7 @@ const char *dma_heap_get_name(struct dma_heap *heap);
 
 /**
  * dma_heap_add - adds a heap to dmabuf heaps
- * @exp_info:  information needed to register this heap
+ * @exp_info: information needed to register this heap
  */
 struct dma_heap *dma_heap_add(const struct dma_heap_export_info *exp_info);
 
-- 
2.25.1

[PATCH 0/9] dma-buf: heaps: Add MediaTek secure heap

[Yong Wu]

This patchset consists of two parts, the first is from John and TJ.
It adds some heap interfaces, then our kernel users could allocate buffer
from special heap. The second part is adding MTK secure heap for SVP
(Secure Video Path). A total of two heaps are added, one is mtk_svp and
the other is mtk_svp_cma. The mtk_svp buffer is reserved for the secure
world after bootup and it is used for ES/working buffer, while the
mtk_svp_cma buffer is dynamically reserved for the secure world and will
be get ready when we start playing secure videos, this heap is used for the
frame buffer. Once the security video playing is complete, the CMA will be
released.

For easier viewing, I've split the new heap file into several patches.

The consumers of new heap and new interfaces are our codec and drm which
will send upstream soon, probably this week.

Base on v6.6-rc1.

John Stultz (2):
  dma-heap: Add proper kref handling on dma-buf heaps
  dma-heap: Provide accessors so that in-kernel drivers can allocate
dmabufs from specific heaps

T.J. Mercier (1):
  dma-buf: heaps: Deduplicate docs and adopt common format

Yong Wu (6):
  dma-buf: heaps: Initialise MediaTek secure heap
  dma-buf: heaps: mtk_sec_heap: Initialise tee session
  dma-buf: heaps: mtk_sec_heap: Add tee service call for buffer
allocating/freeing
  dma-buf: heaps: mtk_sec_heap: Add dma_ops
  dt-bindings: reserved-memory: MediaTek: Add reserved memory for SVP
  dma_buf: heaps: mtk_sec_heap: Add a new CMA heap

 .../mediatek,secure_cma_chunkmem.yaml |  42 ++
 drivers/dma-buf/dma-heap.c| 127 +++--
 drivers/dma-buf/heaps/Kconfig |   8 +
 drivers/dma-buf/heaps/Makefile|   1 +
 drivers/dma-buf/heaps/mtk_secure_heap.c   | 458 ++
 include/linux/dma-heap.h  |  42 +-
 6 files changed, 630 insertions(+), 48 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/reserved-memory/mediatek,secure_cma_chunkmem.yaml
 create mode 100644 drivers/dma-buf/heaps/mtk_secure_heap.c

-- 
2.18.0

Re: [PATCH v2 2/5] kernel: kexec: copy user-array safely

[Baoquan He]

On 09/08/23 at 09:59pm, Philipp Stanner wrote:
> Currently, there is no overflow-check with memdup_user().
> 
> Use the new function memdup_array_user() instead of memdup_user() for
> duplicating the user-space array safely.
> 
> Suggested-by: David Airlie 
> Signed-off-by: Philipp Stanner 
> ---
>  kernel/kexec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index 107f355eac10..8f35a5a42af8 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -247,7 +247,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned long, entry, 
> unsigned long, nr_segments,
>   ((flags & KEXEC_ARCH_MASK) != KEXEC_ARCH_DEFAULT))
>   return -EINVAL;
>  
> - ksegments = memdup_user(segments, nr_segments * sizeof(ksegments[0]));
> + ksegments = memdup_array_user(segments, nr_segments, 
> sizeof(ksegments[0]));

LGTM,

Acked-by: Baoquan He 

>   if (IS_ERR(ksegments))
>   return PTR_ERR(ksegments);
>  
> -- 
> 2.41.0
> 
> 
> ___
> kexec mailing list
> ke...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

[PATCH] drm/amd/display: fix replay_mode kernel-doc warning

[Randy Dunlap]

Fix the typo in the kernel-doc for @replay_mode to prevent
kernel-doc warnings:

drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:623: warning: Incorrect use 
of kernel-doc format:  * @replay mode: Replay supported
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:626: warning: Function 
parameter or member 'replay_mode' not described in 'amdgpu_hdmi_vsdb_info'

Fixes: ec8e59cb4e0c ("drm/amd/display: Get replay info from VSDB")
Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Cc: Bhawanpreet Lakha 
Cc: Harry Wentland 
Cc: Alex Deucher 
Cc: Leo Li 
Cc: Rodrigo Siqueira 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -620,7 +620,7 @@ struct amdgpu_hdmi_vsdb_info {
unsigned int max_refresh_rate_hz;
 
/**
-* @replay mode: Replay supported
+* @replay_mode: Replay supported
 */
bool replay_mode;
 };

Re: [PATCH] drm/simpledrm: Add support for multiple "power-domains"

[Christophe JAILLET]

ret == -EPROBE_DEFER) {
+   simpledrm_device_detach_genpd(sdev);
+   return PTR_ERR(sdev->pwr_dom_devs[i]);
+   }
+   drm_err(>dev,
+   "pm_domain_attach_by_id(%u) failed: %d\n", i, 
ret);
+   }
+


sdev->pwr_dom_devs[i] can be an ERR_PTR here.
Maybe a break or a continue missing after drm_err() above?

CJ


+   sdev->pwr_dom_links[i] = device_link_add(dev,
+sdev->pwr_dom_devs[i],
+DL_FLAG_STATELESS |
+DL_FLAG_PM_RUNTIME |
+DL_FLAG_RPM_ACTIVE);
+   if (!sdev->pwr_dom_links[i])
+   drm_err(>dev, "failed to link power-domain %u\n", 
i);
+   }
+
+   return devm_add_action_or_reset(dev, simpledrm_device_detach_genpd, 
sdev);
+}
+#else
+static int simpledrm_device_attach_genpd(struct simpledrm_device *sdev)
+{
+   return 0;
+}
+#endif
+
  /*
   * Modesetting
   */
@@ -651,6 +754,9 @@ static struct simpledrm_device 
*simpledrm_device_create(struct drm_driver *drv,
if (ret)
return ERR_PTR(ret);
ret = simpledrm_device_init_regulators(sdev);
+   if (ret)
+   return ERR_PTR(ret);
+   ret = simpledrm_device_attach_genpd(sdev);
if (ret)
return ERR_PTR(ret);
  


---
base-commit: 15d30b46573d75f5cb58cfacded8ebab9c76a2b0
change-id: 20230910-simpledrm-multiple-power-domains-f41efa6ad9bc

Best regards,

Re: [PATCH] drm: fix doc warnings related to drm connector

[Randy Dunlap]

On 9/9/23 23:37, Bragatheswaran Manickavel wrote:
>>On Sun, 10 Sept 2023 at 09:29, Randy Dunlap >> wrote:
>>On 9/9/23 20:54, Bagas Sanjaya wrote:
>>> On Sat, Sep 09, 2023 at 04:33:43PM +0530, Bragatheswaran Manickavel wrote:
 Addressing drm dp/hdmi connector related kernel documentation
 warning and add more information about these values.
>>>
>>> What are these?
>>>
>>
>>There are already patches for these issues.
>>
>>Please check latest linux-next and make patches to it instead of using 
>>mainline.
>>
>>Thanks.
> 
> Just had a look at the latest next-20230908. Changes of 
> include/drm/drm_connector.h are
> not present.

That's correct. The patch for that was sent on Sept. 6 and applied to a drm git 
tree
on Sept. 7.

It's here:  
https://lore.kernel.org/all/20230906-topic-drm_connector_doc-v2-1-1f2dcaa43...@gmail.com/



 Signed-off-by: Bragatheswaran Manickavel >>> >
 ---
  drivers/gpu/drm/drm_connector.c | 2 ++
  include/drm/drm_connector.h     | 2 ++
  2 files changed, 4 insertions(+)

 diff --git a/drivers/gpu/drm/drm_connector.c 
 b/drivers/gpu/drm/drm_connector.c
 index bf8371dc2a61..084c95785dda 100644
 --- a/drivers/gpu/drm/drm_connector.c
 +++ b/drivers/gpu/drm/drm_connector.c
 @@ -2203,6 +2203,7 @@ static int 
 drm_mode_create_colorspace_property(struct drm_connector *connector,
  /**
   * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace 
 property
   * @connector: connector to create the Colorspace property on.
 + * @supported_colorspaces: to get hdmi supported colorspaces.
   *
   * Called by a driver the first time it's needed, must be attached to 
 desired
   * HDMI connectors.
 @@ -2227,6 +2228,7 @@ 
 EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
  /**
   * drm_mode_create_dp_colorspace_property - create dp colorspace property
   * @connector: connector to create the Colorspace property on.
 + * @supported_colorspaces: to get dp supported colorspaces.
   *
   * Called by a driver the first time it's needed, must be attached to 
 desired
   * DP connectors.
 diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
 index d300fde6c1a4..556d66dd122c 100644
 --- a/include/drm/drm_connector.h
 +++ b/include/drm/drm_connector.h
 @@ -498,6 +498,8 @@ enum drm_privacy_screen_status {
   *   ITU-R BT.601 colorimetry format
   *   The DP spec does not say whether this is the 525 or the 625
   *   line version.
 + * @DRM_MODE_COLORIMETRY_COUNT:
 + *   Represents the count of colorspaces.
   */
  enum drm_colorspace {
      /* For Default case, driver will set the colorspace */
>>>
>>> Oh, you mean to add description for colorspace-related fields.
>>>
>>> Thanks.
>>>
>>>
>>
>>--
> ~Randy

-- 
~Randy

Re: [git pull] drm CI integration

[pr-tracker-bot]

The pull request you sent on Thu, 31 Aug 2023 11:00:20 +1000:

> git://anongit.freedesktop.org/drm/drm tags/topic/drm-ci-2023-08-31-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1548b060d6f32a00a2f7e2c11328205fb66fc4fa

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [PATCH] drm/simpledrm: Add support for multiple "power-domains"

[Janne Grunau]

On 2023-09-10 18:39:39 +0200, Janne Grunau via B4 Relay wrote:
> From: Janne Grunau 
> 
> Multiple power domains need to be handled explicitly in each driver. The
> driver core can not handle it automatically since it is not aware of
> power sequencing requirements the hardware might have. This is not a
> problem for simpledrm since everything is expected to be powered on by
> the bootloader. simpledrm has just ensure it remains powered on during
> its lifetime.
> This is required on Apple silicon M2 and M2 Pro/Max/Ultra desktop
> systems. The HDMI output initialized by the bootloader requires keeping
> the display controller and a DP phy power domain on.
> 
> Signed-off-by: Janne Grunau 
> ---
>  drivers/gpu/drm/tiny/simpledrm.c | 106 
> +++
>  1 file changed, 106 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tiny/simpledrm.c 
> b/drivers/gpu/drm/tiny/simpledrm.c
> index ff86ba1ae1b8..efedede57d42 100644
> --- a/drivers/gpu/drm/tiny/simpledrm.c
> +++ b/drivers/gpu/drm/tiny/simpledrm.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -227,6 +228,12 @@ struct simpledrm_device {
>   unsigned int regulator_count;
>   struct regulator **regulators;
>  #endif
> + /* power-domains */
> +#if defined CONFIG_OF && defined CONFIG_PM_GENERIC_DOMAINS
> + int pwr_dom_count;
> + struct device **pwr_dom_devs;
> + struct device_link **pwr_dom_links;
> +#endif
>  
>   /* simplefb settings */
>   struct drm_display_mode mode;
> @@ -468,6 +475,102 @@ static int simpledrm_device_init_regulators(struct 
> simpledrm_device *sdev)
>  }
>  #endif
>  
> +#if defined CONFIG_OF && defined CONFIG_PM_GENERIC_DOMAINS
> +/*
> + * Generic power domain handling code.
> + *
> + * Here we handle the power-domains properties of our "simple-framebuffer"
> + * dt node. This is only necessary if there is more than one power-domain.
> + * A single power-domains is handled automatically by the driver core. 
> Multiple
> + * power-domains have to be handled by drivers since the driver core can't 
> know
> + * the correct power sequencing. Power sequencing is not an issue for 
> simpledrm
> + * since the bootloader has put the power domains already in the correct 
> state.
> + * simpledrm has only to ensure they remain active for its lifetime.
> + *
> + * When the driver unloads, we detach from the power-domains.
> + *
> + * We only complain about errors here, no action is taken as the most likely
> + * error can only happen due to a mismatch between the bootloader which set
> + * up the "simple-framebuffer" dt node, and the PM domain providers in the
> + * device tree. Chances are that there are no adverse effects, and if there 
> are,
> + * a clean teardown of the fb probe will not help us much either. So just
> + * complain and carry on, and hope that the user actually gets a working fb 
> at
> + * the end of things.
> + */
> +static void simpledrm_device_detach_genpd(void *res)
> +{
> + int i;
> + struct simpledrm_device *sdev = /*(struct simpledrm_device *)*/res;

commented cast, removed locally for v2

> +
> +
> + drm_err(>dev, "% power-domains count:%d\n", __func__, 
> sdev->pwr_dom_count);

broken log statement as pointed out by kernel test robot, not ment to be 
included in this change. removed locally for v2

> + if (sdev->pwr_dom_count <= 1)
> + return;
> +
> + for (i = sdev->pwr_dom_count - 1; i >= 0; i--) {
> + if (!sdev->pwr_dom_links[i])
> + device_link_del(sdev->pwr_dom_links[i]);
> + if (!IS_ERR_OR_NULL(sdev->pwr_dom_devs[i]))
> + dev_pm_domain_detach(sdev->pwr_dom_devs[i], true);
> + }
> +}
> +
> +static int simpledrm_device_attach_genpd(struct simpledrm_device *sdev)
> +{
> + struct device *dev = sdev->dev.dev;
> + int i;
> +
> + sdev->pwr_dom_count = of_count_phandle_with_args(dev->of_node, 
> "power-domains",
> +  "#power-domain-cells");
> + /*
> +  * Single power-domain devices are handled by driver core nothing to do
> +  * here. The same for device nodes without "power-domains" property.
> +  */
> + if (sdev->pwr_dom_count <= 1)
> + return 0;
> +
> + sdev->pwr_dom_devs = devm_kcalloc(dev, sdev->pwr_dom_count,
> +sizeof(*sdev->pwr_dom_devs),
> +GFP_KERNEL);
> + if (!sdev->pwr_dom_devs)
> + return -ENOMEM;
> +
> + sdev->pwr_dom_links = devm_kcalloc(dev, sdev->pwr_dom_count,
> + sizeof(*sdev->pwr_dom_links),
> + GFP_KERNEL);
> + if (!sdev->pwr_dom_links)
> + return -ENOMEM;
> +
> + for (i = 0; i < sdev->pwr_dom_count; i++) {
> + sdev->pwr_dom_devs[i] = dev_pm_domain_attach_by_id(dev, 

Re: [git pull] drm CI integration

[Linus Torvalds]

On Wed, 30 Aug 2023 at 18:00, Dave Airlie  wrote:
>
> This is a PR to add drm-ci support files to the upstream tree.

So I finally had no other pull requests pending, and spent some time
looking at this, and I see nothing offensive.

I did wonder how this then expands to having more than one subsystem
using this (and mixing them possibly on the same CI system), but
that's more about my ignorance about how the gitlab CI works than
anything else, so that's certainly not a real concern.

The other side of that "I do wonder" coin is for when others want to
use the same tests but using some other CI infrastructure, whether
it's some AWS or google cloud thing, or github or whatever.

Anyway, considering that both of my idle curiosity reactions were
about "if this is successful", I think me having those questions only
means that I should pull this, rather than questioning the pull
itself.

If it works out so well that others want to actually do this and
integrate our other selftests in similar manners, I think that would
be lovely.

And if - as you say - this is a failure and the whole thing gets
deleted a year from now as "this didn't go anywhere", it doesn't look
like it should cause a ton of problems either.

Anyway, it's in my tree now, let's see where it goes.

   Linus

Re: [PATCH] drm/simpledrm: Add support for multiple "power-domains"

[kernel test robot]

Hi Janne,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 15d30b46573d75f5cb58cfacded8ebab9c76a2b0]

url:
https://github.com/intel-lab-lkp/linux/commits/Janne-Grunau-via-B4-Relay/drm-simpledrm-Add-support-for-multiple-power-domains/20230911-004026
base:   15d30b46573d75f5cb58cfacded8ebab9c76a2b0
patch link:
https://lore.kernel.org/r/20230910-simpledrm-multiple-power-domains-v1-1-f8718aefc685%40jannau.net
patch subject: [PATCH] drm/simpledrm: Add support for multiple "power-domains"
config: loongarch-allyesconfig 
(https://download.01.org/0day-ci/archive/20230911/202309110206.wdxp9yxl-...@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20230911/202309110206.wdxp9yxl-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202309110206.wdxp9yxl-...@intel.com/

All warnings (new ones prefixed by >>):

   In file included from include/linux/device.h:15,
from include/linux/acpi.h:14,
from include/linux/i2c.h:13,
from include/uapi/linux/fb.h:6,
from include/linux/fb.h:7,
from include/linux/platform_data/simplefb.h:12,
from drivers/gpu/drm/tiny/simpledrm.c:7:
   drivers/gpu/drm/tiny/simpledrm.c: In function 
'simpledrm_device_detach_genpd':
>> include/drm/drm_print.h:456:39: warning: ' ' flag used with '%p' gnu_printf 
>> format [-Wformat=]
 456 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
 |   ^~~~
   include/linux/dev_printk.h:110:30: note: in definition of macro 
'dev_printk_index_wrap'
 110 | _p_func(dev, fmt, ##__VA_ARGS__);
   \
 |  ^~~
   include/linux/dev_printk.h:144:56: note: in expansion of macro 'dev_fmt'
 144 | dev_printk_index_wrap(_dev_err, KERN_ERR, dev, dev_fmt(fmt), 
##__VA_ARGS__)
 |^~~
   include/drm/drm_print.h:456:9: note: in expansion of macro 'dev_err'
 456 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
 | ^~~~
   include/drm/drm_print.h:469:9: note: in expansion of macro '__drm_printk'
 469 | __drm_printk((drm), err,, "*ERROR* " fmt, ##__VA_ARGS__)
 | ^~~~
   drivers/gpu/drm/tiny/simpledrm.c:506:9: note: in expansion of macro 'drm_err'
 506 | drm_err(>dev, "% power-domains count:%d\n", __func__, 
sdev->pwr_dom_count);
 | ^~~


vim +456 include/drm/drm_print.h

e820f52577b14c6 Jim Cromie2022-09-11  416  
02c9656b2f0d699 Haneen Mohammed   2017-10-17  417  /**
b52817e9de06a3a Mauro Carvalho Chehab 2020-10-27  418   * DRM_DEV_DEBUG() - 
Debug output for generic drm code
02c9656b2f0d699 Haneen Mohammed   2017-10-17  419   *
306589856399e18 Douglas Anderson  2021-09-21  420   * NOTE: this is 
deprecated in favor of drm_dbg_core().
306589856399e18 Douglas Anderson  2021-09-21  421   *
091756bbb1a9613 Haneen Mohammed   2017-10-17  422   * @dev: device pointer
091756bbb1a9613 Haneen Mohammed   2017-10-17  423   * @fmt: printf() like 
format string.
02c9656b2f0d699 Haneen Mohammed   2017-10-17  424   */
db87086492581c8 Joe Perches   2018-03-16  425  #define 
DRM_DEV_DEBUG(dev, fmt, ...) \
db87086492581c8 Joe Perches   2018-03-16  426   drm_dev_dbg(dev, 
DRM_UT_CORE, fmt, ##__VA_ARGS__)
b52817e9de06a3a Mauro Carvalho Chehab 2020-10-27  427  /**
b52817e9de06a3a Mauro Carvalho Chehab 2020-10-27  428   * 
DRM_DEV_DEBUG_DRIVER() - Debug output for vendor specific part of the driver
b52817e9de06a3a Mauro Carvalho Chehab 2020-10-27  429   *
306589856399e18 Douglas Anderson  2021-09-21  430   * NOTE: this is 
deprecated in favor of drm_dbg() or dev_dbg().
306589856399e18 Douglas Anderson  2021-09-21  431   *
b52817e9de06a3a Mauro Carvalho Chehab 2020-10-27  432   * @dev: device pointer
b52817e9de06a3a Mauro Carvalho Chehab 2020-10-27  433   * @fmt: printf() like 
format string.
b52817e9de06a3a Mauro Carvalho Chehab 2020-10-27  434   */
db87086492581c8 Joe Perches   2018-03-16  435  #define 
DRM_DEV_DEBUG_DRIVER(dev, fmt, ...)  \
db87086492581c8 Joe Perches   2018-03-16  436   drm_dev_dbg(dev, 
DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
b52817e9de06a3a Mauro Carvalho Chehab 2020-10-27  437  /**
b52817e9de06a3a Mauro Carvalho Chehab 2020-10-27  438   * DRM_DEV_DEBUG_KMS() - 
Debug output for modesetting code
b52817e9de06a3a Maur

Re: [PATCH 00/11] add missing of_node_put

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by David S. Miller :

On Thu,  7 Sep 2023 11:55:10 +0200 you wrote:
> Add of_node_put on a break out of an of_node loop.
> 
> ---
> 
>  arch/powerpc/kexec/file_load_64.c|8 ++--
>  arch/powerpc/platforms/powermac/low_i2c.c|4 +++-
>  arch/powerpc/platforms/powermac/smp.c|4 +++-
>  drivers/bus/arm-cci.c|4 +++-
>  drivers/genpd/ti/ti_sci_pm_domains.c |8 ++--
>  drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c  |4 +++-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |4 +++-
>  drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c |1 +
>  drivers/mmc/host/atmel-mci.c |8 ++--
>  drivers/net/ethernet/broadcom/asp2/bcmasp.c  |1 +
>  drivers/soc/dove/pmu.c   |5 -
>  drivers/thermal/thermal_of.c |8 ++--
>  sound/soc/sh/rcar/core.c |1 +
>  13 files changed, 46 insertions(+), 14 deletions(-)

Here is the summary with links:
  - [02/11] net: bcmasp: add missing of_node_put
https://git.kernel.org/netdev/net/c/e73d1ab6cd7e

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

[PATCH] drm/simpledrm: Add support for multiple "power-domains"

[Janne Grunau via B4 Relay]

device_detach_genpd(sdev);
+   return PTR_ERR(sdev->pwr_dom_devs[i]);
+   }
+   drm_err(>dev,
+   "pm_domain_attach_by_id(%u) failed: %d\n", i, 
ret);
+   }
+
+   sdev->pwr_dom_links[i] = device_link_add(dev,
+sdev->pwr_dom_devs[i],
+DL_FLAG_STATELESS |
+DL_FLAG_PM_RUNTIME |
+DL_FLAG_RPM_ACTIVE);
+   if (!sdev->pwr_dom_links[i])
+   drm_err(>dev, "failed to link power-domain %u\n", 
i);
+   }
+
+   return devm_add_action_or_reset(dev, simpledrm_device_detach_genpd, 
sdev);
+}
+#else
+static int simpledrm_device_attach_genpd(struct simpledrm_device *sdev)
+{
+   return 0;
+}
+#endif
+
 /*
  * Modesetting
  */
@@ -651,6 +754,9 @@ static struct simpledrm_device 
*simpledrm_device_create(struct drm_driver *drv,
if (ret)
return ERR_PTR(ret);
ret = simpledrm_device_init_regulators(sdev);
+   if (ret)
+   return ERR_PTR(ret);
+   ret = simpledrm_device_attach_genpd(sdev);
if (ret)
return ERR_PTR(ret);
 

---
base-commit: 15d30b46573d75f5cb58cfacded8ebab9c76a2b0
change-id: 20230910-simpledrm-multiple-power-domains-f41efa6ad9bc

Best regards,
-- 
Janne Grunau 

[Bug 217896] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xwayland pid 2985 thread Xwayland:cs0 pid 3129

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217896

Artem S. Tashkinov (a...@gmx.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |ANSWERED

--- Comment #3 from Artem S. Tashkinov (a...@gmx.com) ---
Please repost your bug report here:

https://gitlab.freedesktop.org/drm/amd/-/issues

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 217896] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xwayland pid 2985 thread Xwayland:cs0 pid 3129

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217896

sander44 (ionut_n2...@yahoo.com) changed:

   What|Removed |Added

 Kernel Version||6.5.2

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 217896] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xwayland pid 2985 thread Xwayland:cs0 pid 3129

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217896

--- Comment #2 from sander44 (ionut_n2...@yahoo.com) ---
Created attachment 305079
  --> https://bugzilla.kernel.org/attachment.cgi?id=305079=edit
dmesg

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 217896] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xwayland pid 2985 thread Xwayland:cs0 pid 3129

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217896

--- Comment #1 from sander44 (ionut_n2...@yahoo.com) ---
Created attachment 305078
  --> https://bugzilla.kernel.org/attachment.cgi?id=305078=edit
journalctl

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 217896] New: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xwayland pid 2985 thread Xwayland:cs0 pid 3129

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217896

Bug ID: 217896
   Summary: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process
information: process Xwayland pid 2985 thread
Xwayland:cs0 pid 3129
   Product: Drivers
   Version: 2.5
  Hardware: AMD
OS: Linux
Status: NEW
  Severity: high
  Priority: P3
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: ionut_n2...@yahoo.com
Regression: No

Hi Kernel Team,

I have been using this kernel for a few days, 6.5.2.
This version brings quite a lot of improvements, but I notice a issue with the
AMD video GPU.

Error: 
dmesg -l err
[ 5788.382725] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_low timeout,
signaled seq=480904, emitted seq=480906
[ 5788.383216] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process yandex_browser pid 3520 thread yandex_bro:cs0 pid 3533
[ 5789.881712] amdgpu :04:00.0: [drm:amdgpu_ring_test_helper [amdgpu]]
*ERROR* ring gfx test failed (-110)
[ 5789.882217] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of
IP block  failed -110
[ 5789.882844] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* GPU Recovery Failed:
-110
[ 5800.316409] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_low timeout,
signaled seq=480906, emitted seq=480909
[ 5800.317011] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process Xwayland pid 2985 thread Xwayland:cs0 pid 3129
[ 5801.729521] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize
parser -125!

dmesg | grep RIP
[ 5800.392141] RIP: 0010:amdgpu_irq_put+0x49/0x70 [amdgpu]

lscpu
Architecture:x86_64
  CPU op-mode(s):32-bit, 64-bit
  Address sizes: 48 bits physical, 48 bits virtual
  Byte Order:Little Endian
CPU(s):  16
  On-line CPU(s) list:   0-15
Vendor ID:   AuthenticAMD
  BIOS Vendor ID:Advanced Micro Devices, Inc.
  Model name:AMD Ryzen 9 5900HS with Radeon Graphics
BIOS Model name: AMD Ryzen 9 5900HS with Radeon Graphics
Unknown CPU @ 3.3GHz
BIOS CPU family: 107
CPU family:  25
Model:   80
Thread(s) per core:  2
Core(s) per socket:  8
Socket(s):   1
Stepping:0
CPU(s) scaling MHz:  30%
CPU max MHz: 4680,
CPU min MHz: 400,
BogoMIPS:6596,80
Flags:   fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1
 gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc
cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1
sse
 4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm
cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
ski
 nit wdt tce topoext perfctr_core perfctr_nb bpext
perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall
fsg
 sbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a
rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc
cqm_oc
 cup_llc cqm_mbm_total cqm_mbm_local clzero irperf
xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale
vmcb_clea
 n flushbyasid decodeassists pausefilter pfthreshold
avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid
overfl
 ow_recov succor smca fsrm
Virtualization features: 
  Virtualization:AMD-V
Caches (sum of all): 
  L1d:   256 KiB (8 instances)
  L1i:   256 KiB (8 instances)
  L2:4 MiB (8 instances)
  L3:16 MiB (1 instance)
NUMA:
  NUMA node(s):  1
  NUMA node0 CPU(s): 0-15
Vulnerabilities: 
  Gather data sampling:  Not affected
  Itlb multihit: Not affected
  L1tf:  Not affected
  Mds:   Not affected
  Meltdown:  Not affected
  Mmio stale data:   Not affected
  Retbleed:  Not affected
  Spec rstack overflow:  Mitigation; safe RET, no microcode
  Spec store bypass: Mitigation; Speculative Store Bypass disabled via
prctl
  Spectre v1:Mitigation; usercopy/swapgs barriers and __user
pointer sanitization
  Spectre v2:Mitigation; Retpolines, IBPB conditional, IBRS_FW,
STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
  Srbds: Not affected
  Tsx async abort:   Not affected


lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root
Complex
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne IOMMU
00:01.0 Host 

Re: [syzbot] [mm?] kernel BUG in filemap_unaccount_folio

[Yin, Fengwei]

On 9/10/2023 3:02 PM, Kasireddy, Vivek wrote:
> Hi Fengwei,
> 
>>
>> Add udmabuf maintainers.
>>
>> On 9/7/2023 2:51 AM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:db906f0ca6bb Merge tag 'phy-for-6.6' of git://git.kernel.o..
>>> git tree:   upstream
>>> console+strace: https://syzkaller.appspot.com/x/log.txt?x=16cbb32fa8
>>> kernel config:
>> https://syzkaller.appspot.com/x/.config?x=3bd57a1ac08277b0
>>> dashboard link:
>> https://syzkaller.appspot.com/bug?extid=17a207d226b8a5fb0fd9
>>> compiler:   gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for
>> Debian) 2.40
>>> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11609f3868
>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14c1fc0068
>>>
>>> Downloadable assets:
>>> disk image: https://storage.googleapis.com/syzbot-
>> assets/46394f3ca3eb/disk-db906f0c.raw.xz
>>> vmlinux: https://storage.googleapis.com/syzbot-
>> assets/eeaa594bfd1f/vmlinux-db906f0c.xz
>>> kernel image: https://storage.googleapis.com/syzbot-
>> assets/5c8df8de79ec/bzImage-db906f0c.xz
>>>
>>> IMPORTANT: if you fix the issue, please add the following tag to the
>> commit:
>>> Reported-by: syzbot+17a207d226b8a5fb0...@syzkaller.appspotmail.com
>>
>> Operations from user space before kernel BUG hit:
>>
>> [pid  5043]
>> memfd_create("\x79\x10\x35\x25\xfa\x2c\x1f\x99\xa2\xc9\x8e\xcd\x5c\xfa
>> \xf6\x12\x95\x5e\xdf\x54\xe2\x3d\x0e\x7e\x46\xcd\x73\xa3\xff\x89\x3e\x
>> 84\xa9\x86\x86\xa2\x46\x90\x93\x98\x4e\x05\x65\x92\x4a\x77\xce\x63\xc
>> e\x9f\x32\xc8\x02\x66\x03\x07\x6d\x08\xb4\x48\x8f\x9e\xa5\x16\x8f\x61\
>> xff\xb2\x22\x8a\x15\x13\xa2\x17\x25\x21\x54\x8b\xa1\xb9\x2d\x13\xf9\x
>> 6f\x67\x95\x9d\x54\xef\xca\x68\x77\xf5\xff\x75\x7f\x75\xb8\x2a\xd3"...,
>> MFD_ALLOW_SEALING) = 3
>> [pid  5043] ftruncate(3, 65535) = 0
>> [pid  5043] fcntl(3, F_ADD_SEALS,
>> F_SEAL_SEAL|F_SEAL_SHRINK|F_SEAL_GROW) = 0
>> [pid  5043] openat(AT_FDCWD, "/dev/udmabuf", O_RDWR) = 4
>> [pid  5043] ioctl(4, UDMABUF_CREATE, 0x2000) = 5
>> [pid  5043] mmap(0x20667000, 16384,
>> PROT_WRITE|PROT_EXEC|PROT_SEM|PROT_GROWSDOWN,
>> MAP_SHARED|MAP_FIXED|MAP_POPULATE|MAP_STACK, 5, 0) = 0x20667000
>>
>> The crash happens when test app tried to close the memfd.
>>
>>
>> It's like test app created udmabuf above memfd. But didn't boost memfd
>> refcount.
>> And mmap with MAP_POPULATE make the underneath folios mapped.
>>
>> When memfd is closed without munmap 0x20667000, the memfd refcount
>> hit zero and
>> trigger evict() and hit
>>  VM_BUG_ON_FOLIO(folio_mapped(folio), folio);
>>
>>
>> Related test code:
>>
>>   res = syscall(__NR_memfd_create, /*name=*/0x2040ul, /*flags=*/2ul);
>>   if (res != -1)
>> r[0] = res;
>>   syscall(__NR_ftruncate, /*fd=*/r[0], /*len=*/0xul);
>>   syscall(__NR_fcntl, /*fd=*/r[0], /*cmd=*/0x409ul, /*seals=*/7ul);
>>   memcpy((void*)0x21c0, "/dev/udmabuf\000", 13);
>>   res = syscall(__NR_openat, /*fd=*/0xff9cul, 
>> /*file=*/0x21c0ul,
>> /*flags=*/2ul, 0);
>>   if (res != -1)
>> r[1] = res;
>>   *(uint32_t*)0x2000 = r[0];
>>   *(uint32_t*)0x2004 = 0;
>>   *(uint64_t*)0x2008 = 0;
>>   *(uint64_t*)0x2010 = 0x8000;
>>   res = syscall(__NR_ioctl, /*fd=*/r[1], /*cmd=*/0x40187542,
>> /*arg=*/0x2000ul);
>>   if (res != -1)
>> r[2] = res;
>>   syscall(__NR_mmap, /*addr=*/0x20667000ul, /*len=*/0x4000ul,
>>   /*prot=*/0x10eul, /*flags=*/0x28011ul, /*fd=*/r[2],
>>   /*offset=*/0ul);
>>   close_fds();
>>
>>
>> Should memfd refcount increased when create udmabuf above it? Thanks.
> I think the following patch should fix this crash:
> https://lists.freedesktop.org/archives/dri-devel/2023-August/418952.html
Yes. This patch avoid playing with struct page when mmap memory to user
space. And avoid make pages marked as mapped.


Regards
Yin, Fengwei

> 
> Thanks,
> Vivek
>>
>> Regards
>> Yin, Fengwei
>>
>>>
>>>  search_binary_handler fs/exec.c:1739 [inline]
>>>  exec_binprm fs/exec.c:1781 [inline]
>>>  bprm_execve fs/exec.c:1856 [inline]
>>>  bprm_execve+0x80a/0x1a50 fs/exec.c:1812
>>>  do_execveat_common.isra.0+0x5d3/0x740 fs/exec.c:1964
>>>  do_execve fs/exec.c:2038 [inline]
>>>  __do_sys_execve fs/exec.c:2114 [inline]
>>>  __se_sys_execve fs/exec.c:2109 [inline]
>>>  __x64_sys_execve+0x8c/0xb0 fs/exec.c:2109
>>>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>>>  do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
>>>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
>>> [ cut here ]
>>> kernel BUG at mm/filemap.c:158!
>>> invalid opcode:  [#1] PREEMPT SMP KASAN
>>> CPU: 0 PID: 5043 Comm: syz-executor729 Not tainted 6.5.0-syzkaller-11275-
>> gdb906f0ca6bb #0
>>> Hardware name: Google Google Compute Engine/Google Compute Engine,
>> BIOS Google 07/26/2023
>>> RIP: 0010:filemap_unaccount_folio+0x62e/0x870 mm/filemap.c:158
>>> Code: 0f 85 68 01 00 00 8b 6b 5c 31 ff 89 ee e8 

[Bug 217892] [amdgpu]: system freezes when trying to turn back on monitor

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=217892

Artem S. Tashkinov (a...@gmx.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |ANSWERED

--- Comment #3 from Artem S. Tashkinov (a...@gmx.com) ---
AMDGPU driver bug tracker is here:
https://gitlab.freedesktop.org/drm/amd/-/issues

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH v2] drm/ssd130x: Store the HW buffer in the driver-private CRTC state

[Javier Martinez Canillas]

The commit 45b58669e532 ("drm/ssd130x: Allocate buffer in the plane's
.atomic_check() callback") moved the allocation of the intermediate and
HW buffers from the encoder's .atomic_enable callback, to the plane's
.atomic_check callback.

This was suggested by Maxime Ripard, because drivers aren't allowed to
fail after the drm_atomic_helper_swap_state() function has been called.

And the encoder's .atomic_enable happens after the new atomic state has
been swapped, so allocations (that can fail) shouldn't be done there.

But the HW buffer isn't really tied to the plane's state. It has a fixed
size that only depends on the (also fixed) display resolution defined in
the Device Tree Blob.

That buffer can be considered part of the CRTC state, and for this reason
makes more sense to do its allocation in the CRTC .atomic_check callback.

The other allocated buffer (used to store a conversion from the emulated
XR24 format to the native R1 format) is part of the plane's state, since
it will be optional once the driver supports R1 and allows user-space to
set that pixel format.

So let's keep the allocation for it in the plane's .atomic_check callback,
this can't be moved to the CRTC's .atomic_check because changing a format
does not trigger a CRTC mode set.

Reported-by: Geert Uytterhoeven 
Closes: 
https://lore.kernel.org/dri-devel/CAMuHMdWv_QSatDgihr8=2SXHhvp=icnxumzczopwt9q_qio...@mail.gmail.com/
Signed-off-by: Javier Martinez Canillas 
---

Changes in v2:
- Drop RFC prefix.
- Fix typo in commit message (Thomas Zimmermann).
- Store the HW buffer in the driver's private CRTC state (Thomas Zimmermann).
- Just use kmalloc() kcalloc() when allocating buffers (Thomas Zimmermann).
- Keep the allocation of the intermediate buffer in the plane's .atomic_check

 drivers/gpu/drm/solomon/ssd130x.c | 143 ++
 1 file changed, 108 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/solomon/ssd130x.c 
b/drivers/gpu/drm/solomon/ssd130x.c
index 3b4dde09538a..c866dd40d163 100644
--- a/drivers/gpu/drm/solomon/ssd130x.c
+++ b/drivers/gpu/drm/solomon/ssd130x.c
@@ -141,14 +141,23 @@ const struct ssd130x_deviceinfo ssd130x_variants[] = {
 };
 EXPORT_SYMBOL_NS_GPL(ssd130x_variants, DRM_SSD130X);
 
+struct ssd130x_crtc_state {
+   struct drm_crtc_state base;
+   /* Buffer to store pixels in HW format and written to the panel */
+   u8 *data_array;
+};
+
 struct ssd130x_plane_state {
struct drm_shadow_plane_state base;
/* Intermediate buffer to convert pixels from XRGB to HW format */
u8 *buffer;
-   /* Buffer to store pixels in HW format and written to the panel */
-   u8 *data_array;
 };
 
+static inline struct ssd130x_crtc_state *to_ssd130x_crtc_state(struct 
drm_crtc_state *state)
+{
+   return container_of(state, struct ssd130x_crtc_state, base);
+}
+
 static inline struct ssd130x_plane_state *to_ssd130x_plane_state(struct 
drm_plane_state *state)
 {
return container_of(state, struct ssd130x_plane_state, base.base);
@@ -448,13 +457,11 @@ static int ssd130x_init(struct ssd130x_device *ssd130x)
 }
 
 static int ssd130x_update_rect(struct ssd130x_device *ssd130x,
-  struct ssd130x_plane_state *ssd130x_state,
-  struct drm_rect *rect)
+  struct drm_rect *rect, u8 *buf,
+  u8 *data_array)
 {
unsigned int x = rect->x1;
unsigned int y = rect->y1;
-   u8 *buf = ssd130x_state->buffer;
-   u8 *data_array = ssd130x_state->data_array;
unsigned int width = drm_rect_width(rect);
unsigned int height = drm_rect_height(rect);
unsigned int line_length = DIV_ROUND_UP(width, 8);
@@ -550,12 +557,10 @@ static int ssd130x_update_rect(struct ssd130x_device 
*ssd130x,
return ret;
 }
 
-static void ssd130x_clear_screen(struct ssd130x_device *ssd130x,
-struct ssd130x_plane_state *ssd130x_state)
+static void ssd130x_clear_screen(struct ssd130x_device *ssd130x, u8 
*data_array)
 {
unsigned int page_height = ssd130x->device_info->page_height;
unsigned int pages = DIV_ROUND_UP(ssd130x->height, page_height);
-   u8 *data_array = ssd130x_state->data_array;
unsigned int width = ssd130x->width;
int ret, i;
 
@@ -594,15 +599,13 @@ static void ssd130x_clear_screen(struct ssd130x_device 
*ssd130x,
}
 }
 
-static int ssd130x_fb_blit_rect(struct drm_plane_state *state,
+static int ssd130x_fb_blit_rect(struct drm_framebuffer *fb,
const struct iosys_map *vmap,
-   struct drm_rect *rect)
+   struct drm_rect *rect,
+   u8 *buf, u8 *data_array)
 {
-   struct drm_framebuffer *fb = state->fb;
struct ssd130x_device *ssd130x = drm_to_ssd130x(fb->dev);
unsigned int page_height = ssd130x->device_info->page_height;
- 

Re: [PATCH] drm: fix doc warnings related to drm connector

[Bragatheswaran Manickavel]

On Sun, 10 Sept 2023 at 09:29, Randy Dunlap  wrote:
>On 9/9/23 20:54, Bagas Sanjaya wrote:
>> On Sat, Sep 09, 2023 at 04:33:43PM +0530, Bragatheswaran Manickavel
wrote:
>>> Addressing drm dp/hdmi connector related kernel documentation
>>> warning and add more information about these values.
>>
>> What are these?
>>
>
>There are already patches for these issues.
>
>Please check latest linux-next and make patches to it instead of using
mainline.
>
>Thanks.

Just had a look at the latest next-20230908. Changes of
include/drm/drm_connector.h are
not present.

thanks,
>
>>>
>>> Signed-off-by: Bragatheswaran Manickavel 
>>> ---
>>>  drivers/gpu/drm/drm_connector.c | 2 ++
>>>  include/drm/drm_connector.h | 2 ++
>>>  2 files changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_connector.c
b/drivers/gpu/drm/drm_connector.c
>>> index bf8371dc2a61..084c95785dda 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -2203,6 +2203,7 @@ static int
drm_mode_create_colorspace_property(struct drm_connector *connector,
>>>  /**
>>>   * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace
property
>>>   * @connector: connector to create the Colorspace property on.
>>> + * @supported_colorspaces: to get hdmi supported colorspaces.
>>>   *
>>>   * Called by a driver the first time it's needed, must be attached to
desired
>>>   * HDMI connectors.
>>> @@ -2227,6 +2228,7 @@
EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
>>>  /**
>>>   * drm_mode_create_dp_colorspace_property - create dp colorspace
property
>>>   * @connector: connector to create the Colorspace property on.
>>> + * @supported_colorspaces: to get dp supported colorspaces.
>>>   *
>>>   * Called by a driver the first time it's needed, must be attached to
desired
>>>   * DP connectors.
>>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>>> index d300fde6c1a4..556d66dd122c 100644
>>> --- a/include/drm/drm_connector.h
>>> +++ b/include/drm/drm_connector.h
>>> @@ -498,6 +498,8 @@ enum drm_privacy_screen_status {
>>>   *   ITU-R BT.601 colorimetry format
>>>   *   The DP spec does not say whether this is the 525 or the 625
>>>   *   line version.
>>> + * @DRM_MODE_COLORIMETRY_COUNT:
>>> + *   Represents the count of colorspaces.
>>>   */
>>>  enum drm_colorspace {
>>>  /* For Default case, driver will set the colorspace */
>>
>> Oh, you mean to add description for colorspace-related fields.
>>
>> Thanks.

--

Re: [PATCH v2 1/5] string.h: add array-wrappers for (v)memdup_user()

[Andy Shevchenko]

On Fri, Sep 8, 2023 at 11:02 PM Philipp Stanner  wrote:
>
> Currently, user array duplications are sometimes done without an
> overflow check. Sometimes the checks are done manually; sometimes the
> array size is calculated with array_size() and sometimes by calculating
> n * size directly in code.
>
> Introduce wrappers for arrays for memdup_user() and vmemdup_user() to
> provide a standardized and safe way for duplicating user arrays.
>
> This is both for new code as well as replacing usage of (v)memdup_user()
> in existing code that uses, e.g., n * size to calculate array sizes.

No objections,
Reviewed-by: Andy Shevchenko 

-- 
With Best Regards,
Andy Shevchenko

RE: [syzbot] [mm?] kernel BUG in filemap_unaccount_folio

[Kasireddy, Vivek]

Hi Fengwei,

> 
> Add udmabuf maintainers.
> 
> On 9/7/2023 2:51 AM, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:db906f0ca6bb Merge tag 'phy-for-6.6' of git://git.kernel.o..
> > git tree:   upstream
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=16cbb32fa8
> > kernel config:
> https://syzkaller.appspot.com/x/.config?x=3bd57a1ac08277b0
> > dashboard link:
> https://syzkaller.appspot.com/bug?extid=17a207d226b8a5fb0fd9
> > compiler:   gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for
> Debian) 2.40
> > syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=11609f3868
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14c1fc0068
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-
> assets/46394f3ca3eb/disk-db906f0c.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-
> assets/eeaa594bfd1f/vmlinux-db906f0c.xz
> > kernel image: https://storage.googleapis.com/syzbot-
> assets/5c8df8de79ec/bzImage-db906f0c.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the
> commit:
> > Reported-by: syzbot+17a207d226b8a5fb0...@syzkaller.appspotmail.com
> 
> Operations from user space before kernel BUG hit:
> 
> [pid  5043]
> memfd_create("\x79\x10\x35\x25\xfa\x2c\x1f\x99\xa2\xc9\x8e\xcd\x5c\xfa
> \xf6\x12\x95\x5e\xdf\x54\xe2\x3d\x0e\x7e\x46\xcd\x73\xa3\xff\x89\x3e\x
> 84\xa9\x86\x86\xa2\x46\x90\x93\x98\x4e\x05\x65\x92\x4a\x77\xce\x63\xc
> e\x9f\x32\xc8\x02\x66\x03\x07\x6d\x08\xb4\x48\x8f\x9e\xa5\x16\x8f\x61\
> xff\xb2\x22\x8a\x15\x13\xa2\x17\x25\x21\x54\x8b\xa1\xb9\x2d\x13\xf9\x
> 6f\x67\x95\x9d\x54\xef\xca\x68\x77\xf5\xff\x75\x7f\x75\xb8\x2a\xd3"...,
> MFD_ALLOW_SEALING) = 3
> [pid  5043] ftruncate(3, 65535) = 0
> [pid  5043] fcntl(3, F_ADD_SEALS,
> F_SEAL_SEAL|F_SEAL_SHRINK|F_SEAL_GROW) = 0
> [pid  5043] openat(AT_FDCWD, "/dev/udmabuf", O_RDWR) = 4
> [pid  5043] ioctl(4, UDMABUF_CREATE, 0x2000) = 5
> [pid  5043] mmap(0x20667000, 16384,
> PROT_WRITE|PROT_EXEC|PROT_SEM|PROT_GROWSDOWN,
> MAP_SHARED|MAP_FIXED|MAP_POPULATE|MAP_STACK, 5, 0) = 0x20667000
> 
> The crash happens when test app tried to close the memfd.
> 
> 
> It's like test app created udmabuf above memfd. But didn't boost memfd
> refcount.
> And mmap with MAP_POPULATE make the underneath folios mapped.
> 
> When memfd is closed without munmap 0x20667000, the memfd refcount
> hit zero and
> trigger evict() and hit
>   VM_BUG_ON_FOLIO(folio_mapped(folio), folio);
> 
> 
> Related test code:
> 
>   res = syscall(__NR_memfd_create, /*name=*/0x2040ul, /*flags=*/2ul);
>   if (res != -1)
> r[0] = res;
>   syscall(__NR_ftruncate, /*fd=*/r[0], /*len=*/0xul);
>   syscall(__NR_fcntl, /*fd=*/r[0], /*cmd=*/0x409ul, /*seals=*/7ul);
>   memcpy((void*)0x21c0, "/dev/udmabuf\000", 13);
>   res = syscall(__NR_openat, /*fd=*/0xff9cul, 
> /*file=*/0x21c0ul,
> /*flags=*/2ul, 0);
>   if (res != -1)
> r[1] = res;
>   *(uint32_t*)0x2000 = r[0];
>   *(uint32_t*)0x2004 = 0;
>   *(uint64_t*)0x2008 = 0;
>   *(uint64_t*)0x2010 = 0x8000;
>   res = syscall(__NR_ioctl, /*fd=*/r[1], /*cmd=*/0x40187542,
> /*arg=*/0x2000ul);
>   if (res != -1)
> r[2] = res;
>   syscall(__NR_mmap, /*addr=*/0x20667000ul, /*len=*/0x4000ul,
>   /*prot=*/0x10eul, /*flags=*/0x28011ul, /*fd=*/r[2],
>   /*offset=*/0ul);
>   close_fds();
> 
> 
> Should memfd refcount increased when create udmabuf above it? Thanks.
I think the following patch should fix this crash:
https://lists.freedesktop.org/archives/dri-devel/2023-August/418952.html

Thanks,
Vivek
> 
> Regards
> Yin, Fengwei
> 
> >
> >  search_binary_handler fs/exec.c:1739 [inline]
> >  exec_binprm fs/exec.c:1781 [inline]
> >  bprm_execve fs/exec.c:1856 [inline]
> >  bprm_execve+0x80a/0x1a50 fs/exec.c:1812
> >  do_execveat_common.isra.0+0x5d3/0x740 fs/exec.c:1964
> >  do_execve fs/exec.c:2038 [inline]
> >  __do_sys_execve fs/exec.c:2114 [inline]
> >  __se_sys_execve fs/exec.c:2109 [inline]
> >  __x64_sys_execve+0x8c/0xb0 fs/exec.c:2109
> >  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> >  do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
> >  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > [ cut here ]
> > kernel BUG at mm/filemap.c:158!
> > invalid opcode:  [#1] PREEMPT SMP KASAN
> > CPU: 0 PID: 5043 Comm: syz-executor729 Not tainted 6.5.0-syzkaller-11275-
> gdb906f0ca6bb #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 07/26/2023
> > RIP: 0010:filemap_unaccount_folio+0x62e/0x870 mm/filemap.c:158
> > Code: 0f 85 68 01 00 00 8b 6b 5c 31 ff 89 ee e8 6a 3e d2 ff 85 ed 7e 16 e8 
> > f1
> 42 d2 ff 48 c7 c6 c0 3b 97 8a 48 89 df e8 a2 58 10 00 <0f> 0b e8 db 42 d2 ff 
> 48
> 8d 6b 58 be 04 00 00 00 48 89 ef e8 0a 0d
> > RSP: 0018:c900039ef828 EFLAGS: 00010093
> > RAX:  RBX: ea0001cfe400 RCX: 

Re: [PATCH 2/3] video: fbdev: ssd1307fb: Print the PWM's label instead of its number

[Javier Martinez Canillas]

Uwe Kleine-König  writes:

Hello Uwe,

> Hello,
>
> On Sat, Sep 09, 2023 at 04:38:28PM +0200, Javier Martinez Canillas wrote:
>> Javier Martinez Canillas  writes:
>> 
>> > Uwe Kleine-König  writes:
>> >
>> >> struct pwm_device::pwm is a write-only variable in the pwm core and used
>> >> nowhere apart from this and another dev_dbg. So it isn't useful to
>> >> identify the used PWM. Emit the PWM's label instead in the debug
>> >> message.
>> >>
>> >> Signed-off-by: Uwe Kleine-König 
>> >> ---
>> >
>> > Reviewed-by: Javier Martinez Canillas 
>> >
>> 
>> Pushed to drm-misc (drm-misc-next). Thanks!
>
> JFTR: This patch is already in linus/master. And Javier pushed
> "drm/ssd130x: Print the PWM's label instead of its number" to
> drm-misc-next which is great. So the "Pushed to ..." mail is just in
> reply to the wrong patch in this thread and in git everything is fine.
>

Ups, that's correct. Thanks a lot for pointing that out!

> Thanks
> Uwe
>


-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH] drm: fix doc warnings related to drm connector

[Bragatheswaran Manickavel]

>On Sun, 10 Sept 2023 at 09:29, Randy Dunlap  wrote:
>On 9/9/23 20:54, Bagas Sanjaya wrote:
>> On Sat, Sep 09, 2023 at 04:33:43PM +0530, Bragatheswaran Manickavel
wrote:
>>> Addressing drm dp/hdmi connector related kernel documentation
>>> warning and add more information about these values.
>>
>> What are these?
>>
>
>There are already patches for these issues.
>
>Please check latest linux-next and make patches to it instead of using
mainline.
>
>Thanks.

Just had a look at the latest next-20230908. Changes of
include/drm/drm_connector.h are
not present.

Thanks,
>
>>>
>>> Signed-off-by: Bragatheswaran Manickavel 
>>> ---
>>>  drivers/gpu/drm/drm_connector.c | 2 ++
>>>  include/drm/drm_connector.h | 2 ++
>>>  2 files changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_connector.c
b/drivers/gpu/drm/drm_connector.c
>>> index bf8371dc2a61..084c95785dda 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -2203,6 +2203,7 @@ static int
drm_mode_create_colorspace_property(struct drm_connector *connector,
>>>  /**
>>>   * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace
property
>>>   * @connector: connector to create the Colorspace property on.
>>> + * @supported_colorspaces: to get hdmi supported colorspaces.
>>>   *
>>>   * Called by a driver the first time it's needed, must be attached to
desired
>>>   * HDMI connectors.
>>> @@ -2227,6 +2228,7 @@
EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
>>>  /**
>>>   * drm_mode_create_dp_colorspace_property - create dp colorspace
property
>>>   * @connector: connector to create the Colorspace property on.
>>> + * @supported_colorspaces: to get dp supported colorspaces.
>>>   *
>>>   * Called by a driver the first time it's needed, must be attached to
desired
>>>   * DP connectors.
>>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>>> index d300fde6c1a4..556d66dd122c 100644
>>> --- a/include/drm/drm_connector.h
>>> +++ b/include/drm/drm_connector.h
>>> @@ -498,6 +498,8 @@ enum drm_privacy_screen_status {
>>>   *   ITU-R BT.601 colorimetry format
>>>   *   The DP spec does not say whether this is the 525 or the 625
>>>   *   line version.
>>> + * @DRM_MODE_COLORIMETRY_COUNT:
>>> + *   Represents the count of colorspaces.
>>>   */
>>>  enum drm_colorspace {
>>>  /* For Default case, driver will set the colorspace */
>>
>> Oh, you mean to add description for colorspace-related fields.
>>
>> Thanks.
>>
>>
>
--

Re: [PATCH] drm: fix doc warnings related to drm connector

[Bragatheswaran Manickavel]

>On Sun, 10 Sept 2023 at 09:29, Randy Dunlap  wrote:
>On 9/9/23 20:54, Bagas Sanjaya wrote:
>> On Sat, Sep 09, 2023 at 04:33:43PM +0530, Bragatheswaran Manickavel
wrote:
>>> Addressing drm dp/hdmi connector related kernel documentation
>>> warning and add more information about these values.
>>
>> What are these?
>>
>
>There are already patches for these issues.
>
>Please check latest linux-next and make patches to it instead of using
mainline.
>
>Thanks.

Just had a look at the latest next-20230908. Changes of
include/drm/drm_connector.h are
not present.

Thanks,
>
>
>
>>>
>>> Signed-off-by: Bragatheswaran Manickavel 
>>> ---
>>>  drivers/gpu/drm/drm_connector.c | 2 ++
>>>  include/drm/drm_connector.h | 2 ++
>>>  2 files changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_connector.c
b/drivers/gpu/drm/drm_connector.c
>>> index bf8371dc2a61..084c95785dda 100644
>>> --- a/drivers/gpu/drm/drm_connector.c
>>> +++ b/drivers/gpu/drm/drm_connector.c
>>> @@ -2203,6 +2203,7 @@ static int
drm_mode_create_colorspace_property(struct drm_connector *connector,
>>>  /**
>>>   * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace
property
>>>   * @connector: connector to create the Colorspace property on.
>>> + * @supported_colorspaces: to get hdmi supported colorspaces.
>>>   *
>>>   * Called by a driver the first time it's needed, must be attached to
desired
>>>   * HDMI connectors.
>>> @@ -2227,6 +2228,7 @@
EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
>>>  /**
>>>   * drm_mode_create_dp_colorspace_property - create dp colorspace
property
>>>   * @connector: connector to create the Colorspace property on.
>>> + * @supported_colorspaces: to get dp supported colorspaces.
>>>   *
>>>   * Called by a driver the first time it's needed, must be attached to
desired
>>>   * DP connectors.
>>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>>> index d300fde6c1a4..556d66dd122c 100644
>>> --- a/include/drm/drm_connector.h
>>> +++ b/include/drm/drm_connector.h
>>> @@ -498,6 +498,8 @@ enum drm_privacy_screen_status {
>>>   *   ITU-R BT.601 colorimetry format
>>>   *   The DP spec does not say whether this is the 525 or the 625
>>>   *   line version.
>>> + * @DRM_MODE_COLORIMETRY_COUNT:
>>> + *   Represents the count of colorspaces.
>>>   */
>>>  enum drm_colorspace {
>>>  /* For Default case, driver will set the colorspace */
>>
>> Oh, you mean to add description for colorspace-related fields.
>>
>> Thanks.
>>
>>
>
>--
~Randy