[PATCH 6.6 386/538] drm/vmwgfx: Prevent unmapping active read buffers

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit aba07b9a0587f50e5d3346eaa19019cf3f86c0ea upstream.

The kms paths keep a persistent map active to read and compare the cursor
buffer. These maps can race with each other in simple scenario where:
a) buffer "a" mapped for update
b) buffer "a" mapped for compare
c) do the compare
d) unmap "a" for compare
e) update the cursor
f) unmap "a" for update
At step "e" the buffer has been unmapped and the read contents is bogus.

Prevent unmapping of active read buffers by simply keeping a count of
how many paths have currently active maps and unmap only when the count
reaches 0.

Fixes: 485d98d472d5 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 4")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.19+
Signed-off-by: Zack Rusin 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240816183332.31961-2-zack.ru...@broadcom.com
Reviewed-by: Martin Krastev 
Reviewed-by: Maaz Mombasawala 
[Shivani: Modified to apply on v6.6.y]
Signed-off-by: Shivani Agarwal 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c |   13 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.h |3 +++
 2 files changed, 14 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -331,6 +331,8 @@ void *vmw_bo_map_and_cache(struct vmw_bo
void *virtual;
int ret;
 
+   atomic_inc(&vbo->map_count);
+
virtual = ttm_kmap_obj_virtual(&vbo->map, ¬_used);
if (virtual)
return virtual;
@@ -353,11 +355,17 @@ void *vmw_bo_map_and_cache(struct vmw_bo
  */
 void vmw_bo_unmap(struct vmw_bo *vbo)
 {
+   int map_count;
+
if (vbo->map.bo == NULL)
return;
 
-   ttm_bo_kunmap(&vbo->map);
-   vbo->map.bo = NULL;
+   map_count = atomic_dec_return(&vbo->map_count);
+
+   if (!map_count) {
+   ttm_bo_kunmap(&vbo->map);
+   vbo->map.bo = NULL;
+   }
 }
 
 
@@ -390,6 +398,7 @@ static int vmw_bo_init(struct vmw_privat
BUILD_BUG_ON(TTM_MAX_BO_PRIORITY <= 3);
vmw_bo->tbo.priority = 3;
vmw_bo->res_tree = RB_ROOT;
+   atomic_set(&vmw_bo->map_count, 0);
 
params->size = ALIGN(params->size, PAGE_SIZE);
drm_gem_private_object_init(vdev, &vmw_bo->tbo.base, params->size);
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
@@ -68,6 +68,8 @@ struct vmw_bo_params {
  * @map: Kmap object for semi-persistent mappings
  * @res_tree: RB tree of resources using this buffer object as a backing MOB
  * @res_prios: Eviction priority counts for attached resources
+ * @map_count: The number of currently active maps. Will differ from the
+ * cpu_writers because it includes kernel maps.
  * @cpu_writers: Number of synccpu write grabs. Protected by reservation when
  * increased. May be decreased without reservation.
  * @dx_query_ctx: DX context if this buffer object is used as a DX query MOB
@@ -86,6 +88,7 @@ struct vmw_bo {
struct rb_root res_tree;
u32 res_prios[TTM_MAX_BO_PRIORITY];
 
+   atomic_t map_count;
atomic_t cpu_writers;
/* Not ref-counted.  Protected by binding_mutex */
struct vmw_resource *dx_query_ctx;

[PATCH 6.10 042/149] drm/vmwgfx: Disable coherent dumb buffers without 3d

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit e9fd436bb8fb9b9d31fdf07bbcdba6d30290c5e4 upstream.

Coherent surfaces make only sense if the host renders to them using
accelerated apis. Without 3d the entire content of dumb buffers stays
in the guest making all of the extra work they're doing to synchronize
between guest and host useless.

Configurations without 3d also tend to run with very low graphics
memory limits. The pinned console fb, mob cursors and graphical login
manager tend to run out of 16MB graphics memory that those guests use.

Fix it by making sure the coherent dumb buffers are only used on
configs with 3d enabled.

Signed-off-by: Zack Rusin 
Fixes: d6667f0ddf46 ("drm/vmwgfx: Fix handling of dumb buffers")
Reported-by: Christian Heusel 
Closes: 
https://lore.kernel.org/all/0d0330f3-2ac0-4cd5-8075-7f1cbaf72...@heusel.eu
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.9+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240816183332.31961-4-zack.ru...@broadcom.com
Reviewed-by: Martin Krastev 
Reviewed-by: Maaz Mombasawala 
Tested-by: Benjamin Coddington 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -2283,9 +2283,11 @@ int vmw_dumb_create(struct drm_file *fil
/*
 * Without mob support we're just going to use raw memory buffer
 * because we wouldn't be able to support full surface coherency
-* without mobs
+* without mobs. There also no reason to support surface coherency
+* without 3d (i.e. gpu usage on the host) because then all the
+* contents is going to be rendered guest side.
 */
-   if (!dev_priv->has_mob) {
+   if (!dev_priv->has_mob || !vmw_supports_3d(dev_priv)) {
int cpp = DIV_ROUND_UP(args->bpp, 8);
 
switch (cpp) {

[PATCH 6.10 041/149] drm/vmwgfx: Fix prime with external buffers

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit 50f1199250912568606b3778dc56646c10cb7b04 upstream.

Make sure that for external buffers mapping goes through the dma_buf
interface instead of trying to access pages directly.

External buffers might not provide direct access to readable/writable
pages so to make sure the bo's created from external dma_bufs can be
read dma_buf interface has to be used.

Fixes crashes in IGT's kms_prime with vgem. Regular desktop usage won't
trigger this due to the fact that virtual machines will not have
multiple GPUs but it enables better test coverage in IGT.

Signed-off-by: Zack Rusin 
Fixes: b32233acceff ("drm/vmwgfx: Fix prime import/export")
Cc:  # v6.6+
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.9+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240816183332.31961-3-zack.ru...@broadcom.com
Reviewed-by: Martin Krastev 
Reviewed-by: Maaz Mombasawala 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_blit.c |  114 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |4 -
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |   12 +--
 3 files changed, 118 insertions(+), 12 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
@@ -27,6 +27,8 @@
  **/
 
 #include "vmwgfx_drv.h"
+
+#include "vmwgfx_bo.h"
 #include 
 
 /*
@@ -420,13 +422,105 @@ static int vmw_bo_cpu_blit_line(struct v
return 0;
 }
 
+static void *map_external(struct vmw_bo *bo, struct iosys_map *map)
+{
+   struct vmw_private *vmw =
+   container_of(bo->tbo.bdev, struct vmw_private, bdev);
+   void *ptr = NULL;
+   int ret;
+
+   if (bo->tbo.base.import_attach) {
+   ret = dma_buf_vmap(bo->tbo.base.dma_buf, map);
+   if (ret) {
+   drm_dbg_driver(&vmw->drm,
+  "Wasn't able to map external bo!\n");
+   goto out;
+   }
+   ptr = map->vaddr;
+   } else {
+   ptr = vmw_bo_map_and_cache(bo);
+   }
+
+out:
+   return ptr;
+}
+
+static void unmap_external(struct vmw_bo *bo, struct iosys_map *map)
+{
+   if (bo->tbo.base.import_attach)
+   dma_buf_vunmap(bo->tbo.base.dma_buf, map);
+   else
+   vmw_bo_unmap(bo);
+}
+
+static int vmw_external_bo_copy(struct vmw_bo *dst, u32 dst_offset,
+   u32 dst_stride, struct vmw_bo *src,
+   u32 src_offset, u32 src_stride,
+   u32 width_in_bytes, u32 height,
+   struct vmw_diff_cpy *diff)
+{
+   struct vmw_private *vmw =
+   container_of(dst->tbo.bdev, struct vmw_private, bdev);
+   size_t dst_size = dst->tbo.resource->size;
+   size_t src_size = src->tbo.resource->size;
+   struct iosys_map dst_map = {0};
+   struct iosys_map src_map = {0};
+   int ret, i;
+   int x_in_bytes;
+   u8 *vsrc;
+   u8 *vdst;
+
+   vsrc = map_external(src, &src_map);
+   if (!vsrc) {
+   drm_dbg_driver(&vmw->drm, "Wasn't able to map src\n");
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   vdst = map_external(dst, &dst_map);
+   if (!vdst) {
+   drm_dbg_driver(&vmw->drm, "Wasn't able to map dst\n");
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   vsrc += src_offset;
+   vdst += dst_offset;
+   if (src_stride == dst_stride) {
+   dst_size -= dst_offset;
+   src_size -= src_offset;
+   memcpy(vdst, vsrc,
+  min(dst_stride * height, min(dst_size, src_size)));
+   } else {
+   WARN_ON(dst_stride < width_in_bytes);
+   for (i = 0; i < height; ++i) {
+   memcpy(vdst, vsrc, width_in_bytes);
+   vsrc += src_stride;
+   vdst += dst_stride;
+   }
+   }
+
+   x_in_bytes = (dst_offset % dst_stride);
+   diff->rect.x1 =  x_in_bytes / diff->cpp;
+   diff->rect.y1 = ((dst_offset - x_in_bytes) / dst_stride);
+   diff->rect.x2 = diff->rect.x1 + width_in_bytes / diff->cpp;
+   diff->rect.y2 = diff->rect.y1 + height;
+
+   ret = 0;
+out:
+   unmap_external(src, &src_map);
+   unmap_external(dst, &dst_map);
+
+   return ret;
+}
+
 /**
  * vmw_bo_cpu_blit - in-kernel cpu blit.
  *
- * @dst: Destination buffer object.
+ * @vmw_dst: Destination buffer object.
  * @dst_offset: Destination offset o

[PATCH 6.10 040/149] drm/vmwgfx: Prevent unmapping active read buffers

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit aba07b9a0587f50e5d3346eaa19019cf3f86c0ea upstream.

The kms paths keep a persistent map active to read and compare the cursor
buffer. These maps can race with each other in simple scenario where:
a) buffer "a" mapped for update
b) buffer "a" mapped for compare
c) do the compare
d) unmap "a" for compare
e) update the cursor
f) unmap "a" for update
At step "e" the buffer has been unmapped and the read contents is bogus.

Prevent unmapping of active read buffers by simply keeping a count of
how many paths have currently active maps and unmap only when the count
reaches 0.

Fixes: 485d98d472d5 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 4")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.19+
Signed-off-by: Zack Rusin 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240816183332.31961-2-zack.ru...@broadcom.com
Reviewed-by: Martin Krastev 
Reviewed-by: Maaz Mombasawala 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c |   13 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.h |3 +++
 2 files changed, 14 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -360,6 +360,8 @@ void *vmw_bo_map_and_cache_size(struct v
void *virtual;
int ret;
 
+   atomic_inc(&vbo->map_count);
+
virtual = ttm_kmap_obj_virtual(&vbo->map, ¬_used);
if (virtual)
return virtual;
@@ -383,11 +385,17 @@ void *vmw_bo_map_and_cache_size(struct v
  */
 void vmw_bo_unmap(struct vmw_bo *vbo)
 {
+   int map_count;
+
if (vbo->map.bo == NULL)
return;
 
-   ttm_bo_kunmap(&vbo->map);
-   vbo->map.bo = NULL;
+   map_count = atomic_dec_return(&vbo->map_count);
+
+   if (!map_count) {
+   ttm_bo_kunmap(&vbo->map);
+   vbo->map.bo = NULL;
+   }
 }
 
 
@@ -421,6 +429,7 @@ static int vmw_bo_init(struct vmw_privat
vmw_bo->tbo.priority = 3;
vmw_bo->res_tree = RB_ROOT;
xa_init(&vmw_bo->detached_resources);
+   atomic_set(&vmw_bo->map_count, 0);
 
params->size = ALIGN(params->size, PAGE_SIZE);
drm_gem_private_object_init(vdev, &vmw_bo->tbo.base, params->size);
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
@@ -71,6 +71,8 @@ struct vmw_bo_params {
  * @map: Kmap object for semi-persistent mappings
  * @res_tree: RB tree of resources using this buffer object as a backing MOB
  * @res_prios: Eviction priority counts for attached resources
+ * @map_count: The number of currently active maps. Will differ from the
+ * cpu_writers because it includes kernel maps.
  * @cpu_writers: Number of synccpu write grabs. Protected by reservation when
  * increased. May be decreased without reservation.
  * @dx_query_ctx: DX context if this buffer object is used as a DX query MOB
@@ -90,6 +92,7 @@ struct vmw_bo {
u32 res_prios[TTM_MAX_BO_PRIORITY];
struct xarray detached_resources;
 
+   atomic_t map_count;
atomic_t cpu_writers;
/* Not ref-counted.  Protected by binding_mutex */
struct vmw_resource *dx_query_ctx;

[PATCH 6.6 26/93] drm/vmwgfx: Fix prime with external buffers

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit 50f1199250912568606b3778dc56646c10cb7b04 upstream.

Make sure that for external buffers mapping goes through the dma_buf
interface instead of trying to access pages directly.

External buffers might not provide direct access to readable/writable
pages so to make sure the bo's created from external dma_bufs can be
read dma_buf interface has to be used.

Fixes crashes in IGT's kms_prime with vgem. Regular desktop usage won't
trigger this due to the fact that virtual machines will not have
multiple GPUs but it enables better test coverage in IGT.

Signed-off-by: Zack Rusin 
Fixes: b32233acceff ("drm/vmwgfx: Fix prime import/export")
Cc:  # v6.6+
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.9+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240816183332.31961-3-zack.ru...@broadcom.com
Reviewed-by: Martin Krastev 
Reviewed-by: Maaz Mombasawala 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_blit.c |  114 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |4 -
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |   12 +--
 3 files changed, 118 insertions(+), 12 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
@@ -27,6 +27,8 @@
  **/
 
 #include "vmwgfx_drv.h"
+
+#include "vmwgfx_bo.h"
 #include 
 
 /*
@@ -420,13 +422,105 @@ static int vmw_bo_cpu_blit_line(struct v
return 0;
 }
 
+static void *map_external(struct vmw_bo *bo, struct iosys_map *map)
+{
+   struct vmw_private *vmw =
+   container_of(bo->tbo.bdev, struct vmw_private, bdev);
+   void *ptr = NULL;
+   int ret;
+
+   if (bo->tbo.base.import_attach) {
+   ret = dma_buf_vmap(bo->tbo.base.dma_buf, map);
+   if (ret) {
+   drm_dbg_driver(&vmw->drm,
+  "Wasn't able to map external bo!\n");
+   goto out;
+   }
+   ptr = map->vaddr;
+   } else {
+   ptr = vmw_bo_map_and_cache(bo);
+   }
+
+out:
+   return ptr;
+}
+
+static void unmap_external(struct vmw_bo *bo, struct iosys_map *map)
+{
+   if (bo->tbo.base.import_attach)
+   dma_buf_vunmap(bo->tbo.base.dma_buf, map);
+   else
+   vmw_bo_unmap(bo);
+}
+
+static int vmw_external_bo_copy(struct vmw_bo *dst, u32 dst_offset,
+   u32 dst_stride, struct vmw_bo *src,
+   u32 src_offset, u32 src_stride,
+   u32 width_in_bytes, u32 height,
+   struct vmw_diff_cpy *diff)
+{
+   struct vmw_private *vmw =
+   container_of(dst->tbo.bdev, struct vmw_private, bdev);
+   size_t dst_size = dst->tbo.resource->size;
+   size_t src_size = src->tbo.resource->size;
+   struct iosys_map dst_map = {0};
+   struct iosys_map src_map = {0};
+   int ret, i;
+   int x_in_bytes;
+   u8 *vsrc;
+   u8 *vdst;
+
+   vsrc = map_external(src, &src_map);
+   if (!vsrc) {
+   drm_dbg_driver(&vmw->drm, "Wasn't able to map src\n");
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   vdst = map_external(dst, &dst_map);
+   if (!vdst) {
+   drm_dbg_driver(&vmw->drm, "Wasn't able to map dst\n");
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   vsrc += src_offset;
+   vdst += dst_offset;
+   if (src_stride == dst_stride) {
+   dst_size -= dst_offset;
+   src_size -= src_offset;
+   memcpy(vdst, vsrc,
+  min(dst_stride * height, min(dst_size, src_size)));
+   } else {
+   WARN_ON(dst_stride < width_in_bytes);
+   for (i = 0; i < height; ++i) {
+   memcpy(vdst, vsrc, width_in_bytes);
+   vsrc += src_stride;
+   vdst += dst_stride;
+   }
+   }
+
+   x_in_bytes = (dst_offset % dst_stride);
+   diff->rect.x1 =  x_in_bytes / diff->cpp;
+   diff->rect.y1 = ((dst_offset - x_in_bytes) / dst_stride);
+   diff->rect.x2 = diff->rect.x1 + width_in_bytes / diff->cpp;
+   diff->rect.y2 = diff->rect.y1 + height;
+
+   ret = 0;
+out:
+   unmap_external(src, &src_map);
+   unmap_external(dst, &dst_map);
+
+   return ret;
+}
+
 /**
  * vmw_bo_cpu_blit - in-kernel cpu blit.
  *
- * @dst: Destination buffer object.
+ * @vmw_dst: Destination buffer object.
  * @dst_offset: Destination offset o

Re: [PATCH 00/12] Enable build system on macOS hosts

[Greg Kroah-Hartman]

On Sat, Aug 24, 2024 at 12:37:36AM +0200, Daniel Gomez wrote:
> On Wed, Aug 07, 2024 at 04:19:42PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Aug 07, 2024 at 01:56:38PM +, Daniel Gomez wrote:
> > > On Wed, Aug 07, 2024 at 01:01:08PM GMT, Greg Kroah-Hartman wrote:
> > > > On Wed, Aug 07, 2024 at 01:09:14AM +0200, Daniel Gomez via B4 Relay 
> > > > wrote:
> > > > > This patch set allows for building the Linux kernel for arm64 in 
> > > > > macOS with
> > > > > LLVM.
> > > > 
> > > > Is this a requirement somewhere that this must work?  It seems like an
> > > > odd request, what workflows require cross-operating-system builds like
> > > > this?
> > > 
> > > This isn't a requirement, but it would, for example, support workflows 
> > > for QEMU
> > > users and developers on macOS. They could build/compile the kernel 
> > > natively and
> > > use it to launch QEMU instances, simplifying their process.
> > 
> > But that's not a real workload of anyone?  How often does this ever come
> > up?  Who is going to maintain this cross-build functionality over time?
> 
> The delta is becoming very small thanks to the latest patches from Masahiro.
> Earlier this week (next-20240820) [1] I rebased the work with all the feedback
> and the patch series has been reduced to 7.
> 
> For the maintenance part, I suggest keeping a CI to build and boot the lastest
> linux-next tag available. I can set this up here [2] and take the 
> responsability
> for maintaining that. But I would be convenient to add documentation for it in
> the LLVM section and mark this as 'experimental'. If that's okay, I will 
> prepare
> a v2 with this.

Let's see what v2 looks like and go from there.

thanks,

greg k-h

[PATCH 5.10 327/352] drm/mgag200: Set DDC timeout in milliseconds

[Greg Kroah-Hartman]

5.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit ecde5db1598aecab54cc392282c15114f526f05f upstream.

Compute the i2c timeout in jiffies from a value in milliseconds. The
original values of 2 jiffies equals 2 milliseconds if HZ has been
configured to a value of 1000. This corresponds to 2.2 milliseconds
used by most other DRM drivers. Update mgag200 accordingly.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Fixes: 414c45310625 ("mgag200: initial g200se driver (v2)")
Cc: Dave Airlie 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v3.5+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -134,7 +134,7 @@ struct mga_i2c_chan *mgag200_i2c_create(
i2c->adapter.algo_data = &i2c->bit;
 
i2c->bit.udelay = 10;
-   i2c->bit.timeout = 2;
+   i2c->bit.timeout = usecs_to_jiffies(2200);
i2c->bit.data = i2c;
i2c->bit.setsda = mga_gpio_setsda;
i2c->bit.setscl = mga_gpio_setscl;

[PATCH 5.4 248/259] drm/mgag200: Set DDC timeout in milliseconds

[Greg Kroah-Hartman]

5.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit ecde5db1598aecab54cc392282c15114f526f05f upstream.

Compute the i2c timeout in jiffies from a value in milliseconds. The
original values of 2 jiffies equals 2 milliseconds if HZ has been
configured to a value of 1000. This corresponds to 2.2 milliseconds
used by most other DRM drivers. Update mgag200 accordingly.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Fixes: 414c45310625 ("mgag200: initial g200se driver (v2)")
Cc: Dave Airlie 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v3.5+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -135,7 +135,7 @@ struct mga_i2c_chan *mgag200_i2c_create(
i2c->adapter.algo_data = &i2c->bit;
 
i2c->bit.udelay = 10;
-   i2c->bit.timeout = 2;
+   i2c->bit.timeout = usecs_to_jiffies(2200);
i2c->bit.data = i2c;
i2c->bit.setsda = mga_gpio_setsda;
i2c->bit.setscl = mga_gpio_setscl;

[PATCH 5.15 450/484] drm/mgag200: Set DDC timeout in milliseconds

[Greg Kroah-Hartman]

5.15-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit ecde5db1598aecab54cc392282c15114f526f05f upstream.

Compute the i2c timeout in jiffies from a value in milliseconds. The
original values of 2 jiffies equals 2 milliseconds if HZ has been
configured to a value of 1000. This corresponds to 2.2 milliseconds
used by most other DRM drivers. Update mgag200 accordingly.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Fixes: 414c45310625 ("mgag200: initial g200se driver (v2)")
Cc: Dave Airlie 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v3.5+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -134,7 +134,7 @@ struct mga_i2c_chan *mgag200_i2c_create(
i2c->adapter.algo_data = &i2c->bit;
 
i2c->bit.udelay = 10;
-   i2c->bit.timeout = 2;
+   i2c->bit.timeout = usecs_to_jiffies(2200);
i2c->bit.data = i2c;
i2c->bit.setsda = mga_gpio_setsda;
i2c->bit.setscl = mga_gpio_setscl;

[PATCH 5.15 349/484] drm/vmwgfx: Fix a deadlock in dma buf fence polling

[Greg Kroah-Hartman]

5.15-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit e58337100721f3cc0c7424a18730e4f39844934f upstream.

Introduce a version of the fence ops that on release doesn't remove
the fence from the pending list, and thus doesn't require a lock to
fix poll->fence wait->fence unref deadlocks.

vmwgfx overwrites the wait callback to iterate over the list of all
fences and update their status, to do that it holds a lock to prevent
the list modifcations from other threads. The fence destroy callback
both deletes the fence and removes it from the list of pending
fences, for which it holds a lock.

dma buf polling cb unrefs a fence after it's been signaled: so the poll
calls the wait, which signals the fences, which are being destroyed.
The destruction tries to acquire the lock on the pending fences list
which it can never get because it's held by the wait from which it
was called.

Old bug, but not a lot of userspace apps were using dma-buf polling
interfaces. Fix those, in particular this fixes KDE stalls/deadlock.

Signed-off-by: Zack Rusin 
Fixes: 2298e804e96e ("drm/vmwgfx: rework to new fence interface, v2")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.2+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240722184313.181318-2-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |   17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -32,7 +32,6 @@
 #define VMW_FENCE_WRAP (1 << 31)
 
 struct vmw_fence_manager {
-   int num_fence_objects;
struct vmw_private *dev_priv;
spinlock_t lock;
struct list_head fence_list;
@@ -127,13 +126,13 @@ static void vmw_fence_obj_destroy(struct
 {
struct vmw_fence_obj *fence =
container_of(f, struct vmw_fence_obj, base);
-
struct vmw_fence_manager *fman = fman_from_fence(fence);
 
-   spin_lock(&fman->lock);
-   list_del_init(&fence->head);
-   --fman->num_fence_objects;
-   spin_unlock(&fman->lock);
+   if (!list_empty(&fence->head)) {
+   spin_lock(&fman->lock);
+   list_del_init(&fence->head);
+   spin_unlock(&fman->lock);
+   }
fence->destroy(fence);
 }
 
@@ -260,7 +259,6 @@ static const struct dma_fence_ops vmw_fe
.release = vmw_fence_obj_destroy,
 };
 
-
 /*
  * Execute signal actions on fences recently signaled.
  * This is done from a workqueue so we don't have to execute
@@ -363,7 +361,6 @@ static int vmw_fence_obj_init(struct vmw
goto out_unlock;
}
list_add_tail(&fence->head, &fman->fence_list);
-   ++fman->num_fence_objects;
 
 out_unlock:
spin_unlock(&fman->lock);
@@ -411,7 +408,7 @@ static bool vmw_fence_goal_new_locked(st
  u32 passed_seqno)
 {
u32 goal_seqno;
-   struct vmw_fence_obj *fence;
+   struct vmw_fence_obj *fence, *next_fence;
 
if (likely(!fman->seqno_valid))
return false;
@@ -421,7 +418,7 @@ static bool vmw_fence_goal_new_locked(st
return false;
 
fman->seqno_valid = false;
-   list_for_each_entry(fence, &fman->fence_list, head) {
+   list_for_each_entry_safe(fence, next_fence, &fman->fence_list, head) {
if (!list_empty(&fence->seq_passed_actions)) {
fman->seqno_valid = true;
vmw_fence_goal_write(fman->dev_priv,

[PATCH 4.19 187/196] drm/mgag200: Set DDC timeout in milliseconds

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit ecde5db1598aecab54cc392282c15114f526f05f upstream.

Compute the i2c timeout in jiffies from a value in milliseconds. The
original values of 2 jiffies equals 2 milliseconds if HZ has been
configured to a value of 1000. This corresponds to 2.2 milliseconds
used by most other DRM drivers. Update mgag200 accordingly.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Fixes: 414c45310625 ("mgag200: initial g200se driver (v2)")
Cc: Dave Airlie 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v3.5+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -133,7 +133,7 @@ struct mga_i2c_chan *mgag200_i2c_create(
i2c->adapter.algo_data = &i2c->bit;
 
i2c->bit.udelay = 10;
-   i2c->bit.timeout = 2;
+   i2c->bit.timeout = usecs_to_jiffies(2200);
i2c->bit.data = i2c;
i2c->bit.setsda = mga_gpio_setsda;
i2c->bit.setscl = mga_gpio_setscl;

[PATCH 6.10 246/263] drm/mgag200: Bind I2C lifetime to DRM device

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit eb1ae34e48a09b7a1179c579aed042b032e408f4 upstream.

Managed cleanup with devm_add_action_or_reset() will release the I2C
adapter when the underlying Linux device goes away. But the connector
still refers to it, so this cleanup leaves behind a stale pointer
in struct drm_connector.ddc.

Bind the lifetime of the I2C adapter to the connector's lifetime by
using DRM's managed release. When the DRM device goes away (after
the Linux device) DRM will first clean up the connector and then
clean up the I2C adapter.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Fixes: b279df242972 ("drm/mgag200: Switch I2C code to managed cleanup")
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.0+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-3-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 
+#include 
+
 #include "mgag200_drv.h"
 
 static int mga_i2c_read_gpio(struct mga_device *mdev)
@@ -86,7 +88,7 @@ static int mga_gpio_getscl(void *data)
return (mga_i2c_read_gpio(mdev) & i2c->clock) ? 1 : 0;
 }
 
-static void mgag200_i2c_release(void *res)
+static void mgag200_i2c_release(struct drm_device *dev, void *res)
 {
struct mga_i2c_chan *i2c = res;
 
@@ -125,5 +127,5 @@ int mgag200_i2c_init(struct mga_device *
if (ret)
return ret;
 
-   return devm_add_action_or_reset(dev->dev, mgag200_i2c_release, i2c);
+   return drmm_add_action_or_reset(dev, mgag200_i2c_release, i2c);
 }

[PATCH 6.10 245/263] drm/mgag200: Set DDC timeout in milliseconds

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit ecde5db1598aecab54cc392282c15114f526f05f upstream.

Compute the i2c timeout in jiffies from a value in milliseconds. The
original values of 2 jiffies equals 2 milliseconds if HZ has been
configured to a value of 1000. This corresponds to 2.2 milliseconds
used by most other DRM drivers. Update mgag200 accordingly.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Fixes: 414c45310625 ("mgag200: initial g200se driver (v2)")
Cc: Dave Airlie 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v3.5+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -114,7 +114,7 @@ int mgag200_i2c_init(struct mga_device *
i2c->adapter.algo_data = &i2c->bit;
 
i2c->bit.udelay = 10;
-   i2c->bit.timeout = 2;
+   i2c->bit.timeout = usecs_to_jiffies(2200);
i2c->bit.data = i2c;
i2c->bit.setsda = mga_gpio_setsda;
i2c->bit.setscl = mga_gpio_setscl;

[PATCH 6.6 164/189] drm/mgag200: Set DDC timeout in milliseconds

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit ecde5db1598aecab54cc392282c15114f526f05f upstream.

Compute the i2c timeout in jiffies from a value in milliseconds. The
original values of 2 jiffies equals 2 milliseconds if HZ has been
configured to a value of 1000. This corresponds to 2.2 milliseconds
used by most other DRM drivers. Update mgag200 accordingly.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Fixes: 414c45310625 ("mgag200: initial g200se driver (v2)")
Cc: Dave Airlie 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v3.5+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -115,7 +115,7 @@ int mgag200_i2c_init(struct mga_device *
i2c->adapter.algo_data = &i2c->bit;
 
i2c->bit.udelay = 10;
-   i2c->bit.timeout = 2;
+   i2c->bit.timeout = usecs_to_jiffies(2200);
i2c->bit.data = i2c;
i2c->bit.setsda = mga_gpio_setsda;
i2c->bit.setscl = mga_gpio_setscl;

[PATCH 6.6 165/189] drm/mgag200: Bind I2C lifetime to DRM device

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit eb1ae34e48a09b7a1179c579aed042b032e408f4 upstream.

Managed cleanup with devm_add_action_or_reset() will release the I2C
adapter when the underlying Linux device goes away. But the connector
still refers to it, so this cleanup leaves behind a stale pointer
in struct drm_connector.ddc.

Bind the lifetime of the I2C adapter to the connector's lifetime by
using DRM's managed release. When the DRM device goes away (after
the Linux device) DRM will first clean up the connector and then
clean up the I2C adapter.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Fixes: b279df242972 ("drm/mgag200: Switch I2C code to managed cleanup")
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.0+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-3-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 
+#include 
+
 #include "mgag200_drv.h"
 
 static int mga_i2c_read_gpio(struct mga_device *mdev)
@@ -86,7 +88,7 @@ static int mga_gpio_getscl(void *data)
return (mga_i2c_read_gpio(mdev) & i2c->clock) ? 1 : 0;
 }
 
-static void mgag200_i2c_release(void *res)
+static void mgag200_i2c_release(struct drm_device *dev, void *res)
 {
struct mga_i2c_chan *i2c = res;
 
@@ -126,5 +128,5 @@ int mgag200_i2c_init(struct mga_device *
if (ret)
return ret;
 
-   return devm_add_action_or_reset(dev->dev, mgag200_i2c_release, i2c);
+   return drmm_add_action_or_reset(dev, mgag200_i2c_release, i2c);
 }

[PATCH 6.1 128/150] drm/mgag200: Bind I2C lifetime to DRM device

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit eb1ae34e48a09b7a1179c579aed042b032e408f4 upstream.

Managed cleanup with devm_add_action_or_reset() will release the I2C
adapter when the underlying Linux device goes away. But the connector
still refers to it, so this cleanup leaves behind a stale pointer
in struct drm_connector.ddc.

Bind the lifetime of the I2C adapter to the connector's lifetime by
using DRM's managed release. When the DRM device goes away (after
the Linux device) DRM will first clean up the connector and then
clean up the I2C adapter.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Fixes: b279df242972 ("drm/mgag200: Switch I2C code to managed cleanup")
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.0+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-3-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 
+#include 
+
 #include "mgag200_drv.h"
 
 static int mga_i2c_read_gpio(struct mga_device *mdev)
@@ -86,7 +88,7 @@ static int mga_gpio_getscl(void *data)
return (mga_i2c_read_gpio(mdev) & i2c->clock) ? 1 : 0;
 }
 
-static void mgag200_i2c_release(void *res)
+static void mgag200_i2c_release(struct drm_device *dev, void *res)
 {
struct mga_i2c_chan *i2c = res;
 
@@ -126,5 +128,5 @@ int mgag200_i2c_init(struct mga_device *
if (ret)
return ret;
 
-   return devm_add_action_or_reset(dev->dev, mgag200_i2c_release, i2c);
+   return drmm_add_action_or_reset(dev, mgag200_i2c_release, i2c);
 }

[PATCH 6.1 127/150] drm/mgag200: Set DDC timeout in milliseconds

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit ecde5db1598aecab54cc392282c15114f526f05f upstream.

Compute the i2c timeout in jiffies from a value in milliseconds. The
original values of 2 jiffies equals 2 milliseconds if HZ has been
configured to a value of 1000. This corresponds to 2.2 milliseconds
used by most other DRM drivers. Update mgag200 accordingly.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Fixes: 414c45310625 ("mgag200: initial g200se driver (v2)")
Cc: Dave Airlie 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v3.5+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240513125620.6337-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/mgag200/mgag200_i2c.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/mgag200/mgag200_i2c.c
+++ b/drivers/gpu/drm/mgag200/mgag200_i2c.c
@@ -115,7 +115,7 @@ int mgag200_i2c_init(struct mga_device *
i2c->adapter.algo_data = &i2c->bit;
 
i2c->bit.udelay = 10;
-   i2c->bit.timeout = 2;
+   i2c->bit.timeout = usecs_to_jiffies(2200);
i2c->bit.data = i2c;
i2c->bit.setsda = mga_gpio_setsda;
i2c->bit.setscl = mga_gpio_setscl;

[PATCH 6.1 76/86] drm/vmwgfx: Fix a deadlock in dma buf fence polling

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit e58337100721f3cc0c7424a18730e4f39844934f upstream.

Introduce a version of the fence ops that on release doesn't remove
the fence from the pending list, and thus doesn't require a lock to
fix poll->fence wait->fence unref deadlocks.

vmwgfx overwrites the wait callback to iterate over the list of all
fences and update their status, to do that it holds a lock to prevent
the list modifcations from other threads. The fence destroy callback
both deletes the fence and removes it from the list of pending
fences, for which it holds a lock.

dma buf polling cb unrefs a fence after it's been signaled: so the poll
calls the wait, which signals the fences, which are being destroyed.
The destruction tries to acquire the lock on the pending fences list
which it can never get because it's held by the wait from which it
was called.

Old bug, but not a lot of userspace apps were using dma-buf polling
interfaces. Fix those, in particular this fixes KDE stalls/deadlock.

Signed-off-by: Zack Rusin 
Fixes: 2298e804e96e ("drm/vmwgfx: rework to new fence interface, v2")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.2+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240722184313.181318-2-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |   17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -32,7 +32,6 @@
 #define VMW_FENCE_WRAP (1 << 31)
 
 struct vmw_fence_manager {
-   int num_fence_objects;
struct vmw_private *dev_priv;
spinlock_t lock;
struct list_head fence_list;
@@ -124,13 +123,13 @@ static void vmw_fence_obj_destroy(struct
 {
struct vmw_fence_obj *fence =
container_of(f, struct vmw_fence_obj, base);
-
struct vmw_fence_manager *fman = fman_from_fence(fence);
 
-   spin_lock(&fman->lock);
-   list_del_init(&fence->head);
-   --fman->num_fence_objects;
-   spin_unlock(&fman->lock);
+   if (!list_empty(&fence->head)) {
+   spin_lock(&fman->lock);
+   list_del_init(&fence->head);
+   spin_unlock(&fman->lock);
+   }
fence->destroy(fence);
 }
 
@@ -257,7 +256,6 @@ static const struct dma_fence_ops vmw_fe
.release = vmw_fence_obj_destroy,
 };
 
-
 /*
  * Execute signal actions on fences recently signaled.
  * This is done from a workqueue so we don't have to execute
@@ -355,7 +353,6 @@ static int vmw_fence_obj_init(struct vmw
goto out_unlock;
}
list_add_tail(&fence->head, &fman->fence_list);
-   ++fman->num_fence_objects;
 
 out_unlock:
spin_unlock(&fman->lock);
@@ -403,7 +400,7 @@ static bool vmw_fence_goal_new_locked(st
  u32 passed_seqno)
 {
u32 goal_seqno;
-   struct vmw_fence_obj *fence;
+   struct vmw_fence_obj *fence, *next_fence;
 
if (likely(!fman->seqno_valid))
return false;
@@ -413,7 +410,7 @@ static bool vmw_fence_goal_new_locked(st
return false;
 
fman->seqno_valid = false;
-   list_for_each_entry(fence, &fman->fence_list, head) {
+   list_for_each_entry_safe(fence, next_fence, &fman->fence_list, head) {
if (!list_empty(&fence->seq_passed_actions)) {
fman->seqno_valid = true;
vmw_fence_goal_write(fman->dev_priv,

[PATCH 6.1 32/86] drm/udl: Remove DRM_CONNECTOR_POLL_HPD

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

[ Upstream commit 5aed213c7c6c4f5dcb1a3ef146f493f18fe703dc ]

DisplayLink devices do not generate hotplug events. Remove the poll
flag DRM_CONNECTOR_POLL_HPD, as it may not be specified together with
DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT.

Signed-off-by: Thomas Zimmermann 
Fixes: afdfc4c6f55f ("drm/udl: Fixed problem with UDL adpater reconnection")
Reviewed-by: Jani Nikula 
Cc: Robert Tarasov 
Cc: Alex Deucher 
Cc: Dave Airlie 
Cc: Sean Paul 
Cc: Thomas Zimmermann 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.15+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240510154841.11370-2-tzimmerm...@suse.de
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/udl/udl_modeset.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
b/drivers/gpu/drm/udl/udl_modeset.c
index 93e7554e83fa3..8f4c4a857b6e8 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -514,8 +514,7 @@ struct drm_connector *udl_connector_init(struct drm_device 
*dev)
 
drm_connector_helper_add(connector, &udl_connector_helper_funcs);
 
-   connector->polled = DRM_CONNECTOR_POLL_HPD |
-   DRM_CONNECTOR_POLL_CONNECT |
+   connector->polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
 
return connector;
-- 
2.43.0

[PATCH 6.6 106/121] drm/vmwgfx: Fix a deadlock in dma buf fence polling

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit e58337100721f3cc0c7424a18730e4f39844934f upstream.

Introduce a version of the fence ops that on release doesn't remove
the fence from the pending list, and thus doesn't require a lock to
fix poll->fence wait->fence unref deadlocks.

vmwgfx overwrites the wait callback to iterate over the list of all
fences and update their status, to do that it holds a lock to prevent
the list modifcations from other threads. The fence destroy callback
both deletes the fence and removes it from the list of pending
fences, for which it holds a lock.

dma buf polling cb unrefs a fence after it's been signaled: so the poll
calls the wait, which signals the fences, which are being destroyed.
The destruction tries to acquire the lock on the pending fences list
which it can never get because it's held by the wait from which it
was called.

Old bug, but not a lot of userspace apps were using dma-buf polling
interfaces. Fix those, in particular this fixes KDE stalls/deadlock.

Signed-off-by: Zack Rusin 
Fixes: 2298e804e96e ("drm/vmwgfx: rework to new fence interface, v2")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.2+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240722184313.181318-2-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |   17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -32,7 +32,6 @@
 #define VMW_FENCE_WRAP (1 << 31)
 
 struct vmw_fence_manager {
-   int num_fence_objects;
struct vmw_private *dev_priv;
spinlock_t lock;
struct list_head fence_list;
@@ -124,13 +123,13 @@ static void vmw_fence_obj_destroy(struct
 {
struct vmw_fence_obj *fence =
container_of(f, struct vmw_fence_obj, base);
-
struct vmw_fence_manager *fman = fman_from_fence(fence);
 
-   spin_lock(&fman->lock);
-   list_del_init(&fence->head);
-   --fman->num_fence_objects;
-   spin_unlock(&fman->lock);
+   if (!list_empty(&fence->head)) {
+   spin_lock(&fman->lock);
+   list_del_init(&fence->head);
+   spin_unlock(&fman->lock);
+   }
fence->destroy(fence);
 }
 
@@ -257,7 +256,6 @@ static const struct dma_fence_ops vmw_fe
.release = vmw_fence_obj_destroy,
 };
 
-
 /*
  * Execute signal actions on fences recently signaled.
  * This is done from a workqueue so we don't have to execute
@@ -355,7 +353,6 @@ static int vmw_fence_obj_init(struct vmw
goto out_unlock;
}
list_add_tail(&fence->head, &fman->fence_list);
-   ++fman->num_fence_objects;
 
 out_unlock:
spin_unlock(&fman->lock);
@@ -403,7 +400,7 @@ static bool vmw_fence_goal_new_locked(st
  u32 passed_seqno)
 {
u32 goal_seqno;
-   struct vmw_fence_obj *fence;
+   struct vmw_fence_obj *fence, *next_fence;
 
if (likely(!fman->seqno_valid))
return false;
@@ -413,7 +410,7 @@ static bool vmw_fence_goal_new_locked(st
return false;
 
fman->seqno_valid = false;
-   list_for_each_entry(fence, &fman->fence_list, head) {
+   list_for_each_entry_safe(fence, next_fence, &fman->fence_list, head) {
if (!list_empty(&fence->seq_passed_actions)) {
fman->seqno_valid = true;
vmw_fence_goal_write(fman->dev_priv,

[PATCH 6.10 094/123] drm/ast: Fix black screen after resume

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Jammy Huang 

commit 12c35c5582acb0fd8f7713ffa75f450766022ff1 upstream.

Suspend will disable pcie device. Thus, resume should do full hw
initialization again.
Add some APIs to ast_drm_thaw() before ast_post_gpu() to fix the issue.

v2:
- fix function-call arguments

Fixes: 5b71707dd13c ("drm/ast: Enable and unlock device access early during 
init")
Reported-by: Cary Garrett 
Closes: 
https://lore.kernel.org/dri-devel/8ce1e1cc351153a890b65e62fed93b54ccd43f6a.ca...@gmail.com/
Cc: Thomas Zimmermann 
Cc: Jocelyn Falempe 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.6+
Signed-off-by: Jammy Huang 
Reviewed-by: Thomas Zimmermann 
Signed-off-by: Thomas Zimmermann 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240718030352.654155-1-jammy_hu...@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/ast/ast_drv.c |5 +
 1 file changed, 5 insertions(+)

--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -391,6 +391,11 @@ static int ast_drm_freeze(struct drm_dev
 
 static int ast_drm_thaw(struct drm_device *dev)
 {
+   struct ast_device *ast = to_ast_device(dev);
+
+   ast_enable_vga(ast->ioregs);
+   ast_open_key(ast->ioregs);
+   ast_enable_mmio(dev->dev, ast->ioregs);
ast_post_gpu(dev);
 
return drm_mode_config_helper_resume(dev);

[PATCH 6.10 093/123] drm/ast: astdp: Wake up during connector status detection

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit 0ce91928ec62d189b5c51816e325f02587b53118 upstream.

Power up the ASTDP connector for connection status detection if the
connector is not active. Keep it powered if a display is attached.

This fixes a bug where the connector does not come back after
disconnecting the display. The encoder's atomic_disable turns off
power on the physical connector. Further HPD reads will fail,
thus preventing the driver from detecting re-connected displays.

For connectors that are actively used, only test the HPD flag without
touching power.

Fixes: f81bb0ac7872 ("drm/ast: report connection status on Display Port.")
Cc: Jocelyn Falempe 
Cc: Thomas Zimmermann 
Cc: Dave Airlie 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.6+
Signed-off-by: Thomas Zimmermann 
Reviewed-by: Jocelyn Falempe 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240717143319.104012-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/ast/ast_dp.c   |7 +++
 drivers/gpu/drm/ast/ast_drv.h  |1 +
 drivers/gpu/drm/ast/ast_mode.c |   29 +++--
 3 files changed, 35 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -158,7 +158,14 @@ void ast_dp_launch(struct drm_device *de
   ASTDP_HOST_EDID_READ_DONE);
 }
 
+bool ast_dp_power_is_on(struct ast_device *ast)
+{
+   u8 vgacre3;
+
+   vgacre3 = ast_get_index_reg(ast, AST_IO_VGACRI, 0xe3);
 
+   return !(vgacre3 & AST_DP_PHY_SLEEP);
+}
 
 void ast_dp_power_on_off(struct drm_device *dev, bool on)
 {
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -472,6 +472,7 @@ void ast_init_3rdtx(struct drm_device *d
 bool ast_astdp_is_connected(struct ast_device *ast);
 int ast_astdp_read_edid(struct drm_device *dev, u8 *ediddata);
 void ast_dp_launch(struct drm_device *dev);
+bool ast_dp_power_is_on(struct ast_device *ast);
 void ast_dp_power_on_off(struct drm_device *dev, bool no);
 void ast_dp_set_on_off(struct drm_device *dev, bool no);
 void ast_dp_set_mode(struct drm_crtc *crtc, struct ast_vbios_mode_info 
*vbios_mode);
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -28,6 +28,7 @@
  * Authors: Dave Airlie 
  */
 
+#include 
 #include 
 #include 
 
@@ -1641,11 +1642,35 @@ static int ast_astdp_connector_helper_de
 struct drm_modeset_acquire_ctx 
*ctx,
 bool force)
 {
+   struct drm_device *dev = connector->dev;
struct ast_device *ast = to_ast_device(connector->dev);
+   enum drm_connector_status status = connector_status_disconnected;
+   struct drm_connector_state *connector_state = connector->state;
+   bool is_active = false;
+
+   mutex_lock(&ast->modeset_lock);
+
+   if (connector_state && connector_state->crtc) {
+   struct drm_crtc_state *crtc_state = 
connector_state->crtc->state;
+
+   if (crtc_state && crtc_state->active)
+   is_active = true;
+   }
+
+   if (!is_active && !ast_dp_power_is_on(ast)) {
+   ast_dp_power_on_off(dev, true);
+   msleep(50);
+   }
 
if (ast_astdp_is_connected(ast))
-   return connector_status_connected;
-   return connector_status_disconnected;
+   status = connector_status_connected;
+
+   if (!is_active && status == connector_status_disconnected)
+   ast_dp_power_on_off(dev, false);
+
+   mutex_unlock(&ast->modeset_lock);
+
+   return status;
 }
 
 static const struct drm_connector_helper_funcs 
ast_astdp_connector_helper_funcs = {

[PATCH 6.10 092/123] drm/vmwgfx: Fix handling of dumb buffers

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit d6667f0ddf46c671d379cd5fe66ce0a54d2a743a upstream.

Dumb buffers can be used in kms but also through prime with gallium's
resource_from_handle. In the second case the dumb buffers can be
rendered by the GPU where with the regular DRM kms interfaces they
are mapped and written to by the CPU. Because the same buffer can
be written to by the GPU and CPU vmwgfx needs to use vmw_surface (object
which properly tracks dirty state of the guest and gpu memory)
instead of vmw_bo (which is just guest side memory).

Furthermore the dumb buffer handles are expected to be gem objects by
a lot of userspace.

Make vmwgfx accept gem handles in prime and kms but internally switch
to vmw_surface's to properly track the dirty state of the objects between
the GPU and CPU.

Fixes new kwin and kde on wayland.

Signed-off-by: Zack Rusin 
Fixes: b32233acceff ("drm/vmwgfx: Fix prime import/export")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.9+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240722184313.181318-4-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmw_surface_cache.h |   10 
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c |  127 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.h |   15 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|   40 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|  502 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h|   17 
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c|   14 
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |   32 +
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |   27 +
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c   |   33 +
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c   |  145 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c|  280 +++-
 12 files changed, 740 insertions(+), 502 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmw_surface_cache.h
+++ b/drivers/gpu/drm/vmwgfx/vmw_surface_cache.h
@@ -1,6 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
 /**
- * Copyright 2021 VMware, Inc.
- * SPDX-License-Identifier: GPL-2.0 OR MIT
+ *
+ * Copyright (c) 2021-2024 Broadcom. All Rights Reserved. The term
+ * “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.
  *
  * Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
@@ -31,6 +33,10 @@
 
 #include 
 
+#define SVGA3D_FLAGS_UPPER_32(svga3d_flags) ((svga3d_flags) >> 32)
+#define SVGA3D_FLAGS_LOWER_32(svga3d_flags) \
+   ((svga3d_flags) & ((uint64_t)U32_MAX))
+
 static inline u32 clamped_umul32(u32 a, u32 b)
 {
uint64_t tmp = (uint64_t) a*b;
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -1,8 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0 OR MIT
 /**
  *
- * Copyright © 2011-2023 VMware, Inc., Palo Alto, CA., USA
- * All Rights Reserved.
+ * Copyright (c) 2011-2024 Broadcom. All Rights Reserved. The term
+ * “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the
@@ -28,15 +28,39 @@
 
 #include "vmwgfx_bo.h"
 #include "vmwgfx_drv.h"
-
+#include "vmwgfx_resource_priv.h"
 
 #include 
 
 static void vmw_bo_release(struct vmw_bo *vbo)
 {
+   struct vmw_resource *res;
+
WARN_ON(vbo->tbo.base.funcs &&
kref_read(&vbo->tbo.base.refcount) != 0);
vmw_bo_unmap(vbo);
+
+   xa_destroy(&vbo->detached_resources);
+   WARN_ON(vbo->is_dumb && !vbo->dumb_surface);
+   if (vbo->is_dumb && vbo->dumb_surface) {
+   res = &vbo->dumb_surface->res;
+   WARN_ON(vbo != res->guest_memory_bo);
+   WARN_ON(!res->guest_memory_bo);
+   if (res->guest_memory_bo) {
+   /* Reserve and switch the backing mob. */
+   mutex_lock(&res->dev_priv->cmdbuf_mutex);
+   (void)vmw_resource_reserve(res, false, true);
+   vmw_resource_mob_detach(res);
+   if (res->coherent)
+   vmw_bo_dirty_release(res->guest_memory_bo);
+   res->guest_memory_bo = NULL;
+   res->guest_memory_offset = 0;
+   vmw_resource_unreserve(res, false, false, false, NULL,
+  0);
+   mutex_unlock(&res->dev_priv->cm

[PATCH 6.10 091/123] drm/vmwgfx: Fix a deadlock in dma buf fence polling

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit e58337100721f3cc0c7424a18730e4f39844934f upstream.

Introduce a version of the fence ops that on release doesn't remove
the fence from the pending list, and thus doesn't require a lock to
fix poll->fence wait->fence unref deadlocks.

vmwgfx overwrites the wait callback to iterate over the list of all
fences and update their status, to do that it holds a lock to prevent
the list modifcations from other threads. The fence destroy callback
both deletes the fence and removes it from the list of pending
fences, for which it holds a lock.

dma buf polling cb unrefs a fence after it's been signaled: so the poll
calls the wait, which signals the fences, which are being destroyed.
The destruction tries to acquire the lock on the pending fences list
which it can never get because it's held by the wait from which it
was called.

Old bug, but not a lot of userspace apps were using dma-buf polling
interfaces. Fix those, in particular this fixes KDE stalls/deadlock.

Signed-off-by: Zack Rusin 
Fixes: 2298e804e96e ("drm/vmwgfx: rework to new fence interface, v2")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.2+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240722184313.181318-2-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |   17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -32,7 +32,6 @@
 #define VMW_FENCE_WRAP (1 << 31)
 
 struct vmw_fence_manager {
-   int num_fence_objects;
struct vmw_private *dev_priv;
spinlock_t lock;
struct list_head fence_list;
@@ -124,13 +123,13 @@ static void vmw_fence_obj_destroy(struct
 {
struct vmw_fence_obj *fence =
container_of(f, struct vmw_fence_obj, base);
-
struct vmw_fence_manager *fman = fman_from_fence(fence);
 
-   spin_lock(&fman->lock);
-   list_del_init(&fence->head);
-   --fman->num_fence_objects;
-   spin_unlock(&fman->lock);
+   if (!list_empty(&fence->head)) {
+   spin_lock(&fman->lock);
+   list_del_init(&fence->head);
+   spin_unlock(&fman->lock);
+   }
fence->destroy(fence);
 }
 
@@ -257,7 +256,6 @@ static const struct dma_fence_ops vmw_fe
.release = vmw_fence_obj_destroy,
 };
 
-
 /*
  * Execute signal actions on fences recently signaled.
  * This is done from a workqueue so we don't have to execute
@@ -355,7 +353,6 @@ static int vmw_fence_obj_init(struct vmw
goto out_unlock;
}
list_add_tail(&fence->head, &fman->fence_list);
-   ++fman->num_fence_objects;
 
 out_unlock:
spin_unlock(&fman->lock);
@@ -403,7 +400,7 @@ static bool vmw_fence_goal_new_locked(st
  u32 passed_seqno)
 {
u32 goal_seqno;
-   struct vmw_fence_obj *fence;
+   struct vmw_fence_obj *fence, *next_fence;
 
if (likely(!fman->seqno_valid))
return false;
@@ -413,7 +410,7 @@ static bool vmw_fence_goal_new_locked(st
return false;
 
fman->seqno_valid = false;
-   list_for_each_entry(fence, &fman->fence_list, head) {
+   list_for_each_entry_safe(fence, next_fence, &fman->fence_list, head) {
if (!list_empty(&fence->seq_passed_actions)) {
fman->seqno_valid = true;
vmw_fence_goal_write(fman->dev_priv,

[PATCH 6.10 022/123] drm/vmwgfx: Make sure the screen surface is ref counted

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 09f34a00272d2311f6e5d64ed8ad824ef78f7487 ]

Fix races issues in virtual crc generation by making sure the surface
the code uses for crc computation is properly ref counted.

Crc generation was trying to be too clever by allowing the surfaces
to go in and out of scope, with the hope of always having some kind
of screen present. That's not always the code, in particular during
atomic disable, so to make sure the surface, when present, is not
being actively destroyed at the same time, hold a reference to it.

Signed-off-by: Zack Rusin 
Fixes: 7b0062036c3b ("drm/vmwgfx: Implement virtual crc generation")
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240722184313.181318-3-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c | 40 +++-
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c
index 7e93a45948f79..ac002048d8e5e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_vkms.c
@@ -76,7 +76,7 @@ vmw_surface_sync(struct vmw_private *vmw,
return ret;
 }
 
-static int
+static void
 compute_crc(struct drm_crtc *crtc,
struct vmw_surface *surf,
u32 *crc)
@@ -102,8 +102,6 @@ compute_crc(struct drm_crtc *crtc,
}
 
vmw_bo_unmap(bo);
-
-   return 0;
 }
 
 static void
@@ -117,7 +115,6 @@ crc_generate_worker(struct work_struct *work)
u64 frame_start, frame_end;
u32 crc32 = 0;
struct vmw_surface *surf = 0;
-   int ret;
 
spin_lock_irq(&du->vkms.crc_state_lock);
crc_pending = du->vkms.crc_pending;
@@ -131,22 +128,24 @@ crc_generate_worker(struct work_struct *work)
return;
 
spin_lock_irq(&du->vkms.crc_state_lock);
-   surf = du->vkms.surface;
+   surf = vmw_surface_reference(du->vkms.surface);
spin_unlock_irq(&du->vkms.crc_state_lock);
 
-   if (vmw_surface_sync(vmw, surf)) {
-   drm_warn(crtc->dev, "CRC worker wasn't able to sync the crc 
surface!\n");
-   return;
-   }
+   if (surf) {
+   if (vmw_surface_sync(vmw, surf)) {
+   drm_warn(
+   crtc->dev,
+   "CRC worker wasn't able to sync the crc 
surface!\n");
+   return;
+   }
 
-   ret = compute_crc(crtc, surf, &crc32);
-   if (ret)
-   return;
+   compute_crc(crtc, surf, &crc32);
+   vmw_surface_unreference(&surf);
+   }
 
spin_lock_irq(&du->vkms.crc_state_lock);
frame_start = du->vkms.frame_start;
frame_end = du->vkms.frame_end;
-   crc_pending = du->vkms.crc_pending;
du->vkms.frame_start = 0;
du->vkms.frame_end = 0;
du->vkms.crc_pending = false;
@@ -165,7 +164,7 @@ vmw_vkms_vblank_simulate(struct hrtimer *timer)
struct vmw_display_unit *du = container_of(timer, struct 
vmw_display_unit, vkms.timer);
struct drm_crtc *crtc = &du->crtc;
struct vmw_private *vmw = vmw_priv(crtc->dev);
-   struct vmw_surface *surf = NULL;
+   bool has_surface = false;
u64 ret_overrun;
bool locked, ret;
 
@@ -180,10 +179,10 @@ vmw_vkms_vblank_simulate(struct hrtimer *timer)
WARN_ON(!ret);
if (!locked)
return HRTIMER_RESTART;
-   surf = du->vkms.surface;
+   has_surface = du->vkms.surface != NULL;
vmw_vkms_unlock(crtc);
 
-   if (du->vkms.crc_enabled && surf) {
+   if (du->vkms.crc_enabled && has_surface) {
u64 frame = drm_crtc_accurate_vblank_count(crtc);
 
spin_lock(&du->vkms.crc_state_lock);
@@ -337,6 +336,8 @@ vmw_vkms_crtc_cleanup(struct drm_crtc *crtc)
 {
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
 
+   if (du->vkms.surface)
+   vmw_surface_unreference(&du->vkms.surface);
WARN_ON(work_pending(&du->vkms.crc_generator_work));
hrtimer_cancel(&du->vkms.timer);
 }
@@ -498,9 +499,12 @@ vmw_vkms_set_crc_surface(struct drm_crtc *crtc,
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
struct vmw_private *vmw = vmw_priv(crtc->dev);
 
-   if (vmw->vkms_enabled) {
+   if (vmw->vkms_enabled && du->vkms.surface != surf) {
WARN_ON(atomic_read(&du->vkms.atomic_lock) != 
VMW_VKMS_LOCK_MODESET);
-   du->vkms.surface = surf;
+   if (du->vkms.surface)
+   vmw_surface_unreference(&du->vkms.surface);
+   if (surf)
+   du->vkms.surface = vmw_surface_re

Re: [PATCH 00/12] Enable build system on macOS hosts

[Greg Kroah-Hartman]

On Wed, Aug 07, 2024 at 01:56:38PM +, Daniel Gomez wrote:
> On Wed, Aug 07, 2024 at 01:01:08PM GMT, Greg Kroah-Hartman wrote:
> > On Wed, Aug 07, 2024 at 01:09:14AM +0200, Daniel Gomez via B4 Relay wrote:
> > > This patch set allows for building the Linux kernel for arm64 in macOS 
> > > with
> > > LLVM.
> > 
> > Is this a requirement somewhere that this must work?  It seems like an
> > odd request, what workflows require cross-operating-system builds like
> > this?
> 
> This isn't a requirement, but it would, for example, support workflows for 
> QEMU
> users and developers on macOS. They could build/compile the kernel natively 
> and
> use it to launch QEMU instances, simplifying their process.

But that's not a real workload of anyone?  How often does this ever come
up?  Who is going to maintain this cross-build functionality over time?

thanks,

greg k-h

Re: [PATCH 08/12] include: add elf.h support

[Greg Kroah-Hartman]

On Wed, Aug 07, 2024 at 02:13:57PM +, Daniel Gomez wrote:
> > Also, as this is not internal for the kernel, but rather for userspace
> > builds, shouldn't the include/ path be different?
> 
> Can you suggest an alternative path or provide documentation that could help
> identify the correct location? Perhaps usr/include?

That is better than the generic include path as you are attempting to
mix userspace and kernel headers in the same directory :(

Re: [PATCH 08/12] include: add elf.h support

[Greg Kroah-Hartman]

On Wed, Aug 07, 2024 at 01:09:22AM +0200, Daniel Gomez via B4 Relay wrote:
> From: Daniel Gomez 
> 
> Add a copy of elf/elf.h header from the GNU C Library (glibc), version
> glibc-2.40 into include/elf. Update Makefiles where elf.h header is used
> to ensure the compiler can find all necessary headers, for macOS host
> where these headers are not provided by the system.
> 
> Signed-off-by: Daniel Gomez 
> ---
>  arch/arm64/kernel/pi/Makefile |1 +
>  arch/arm64/kernel/vdso32/Makefile |1 +
>  arch/arm64/kvm/hyp/nvhe/Makefile  |2 +-
>  include/elf/elf.h | 4491 
> +
>  scripts/Makefile  |3 +-
>  scripts/mod/Makefile  |6 +
>  6 files changed, 4502 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/kernel/pi/Makefile b/arch/arm64/kernel/pi/Makefile
> index 4d11a8c29181..eb782aaa6585 100644
> --- a/arch/arm64/kernel/pi/Makefile
> +++ b/arch/arm64/kernel/pi/Makefile
> @@ -20,6 +20,7 @@ KBUILD_CFLAGS   := $(filter-out $(CC_FLAGS_SCS), 
> $(KBUILD_CFLAGS))
>  KBUILD_CFLAGS:= $(filter-out $(CC_FLAGS_LTO), $(KBUILD_CFLAGS))
>  
>  hostprogs:= relacheck
> +HOSTCFLAGS_relacheck.o = -I$(srctree)/include/elf
>  
>  quiet_cmd_piobjcopy = $(quiet_cmd_objcopy)
>cmd_piobjcopy = $(cmd_objcopy) && $(obj)/relacheck $(@) $(<)
> diff --git a/arch/arm64/kernel/vdso32/Makefile 
> b/arch/arm64/kernel/vdso32/Makefile
> index 25a2cb6317f3..e1ac384e6332 100644
> --- a/arch/arm64/kernel/vdso32/Makefile
> +++ b/arch/arm64/kernel/vdso32/Makefile
> @@ -107,6 +107,7 @@ VDSO_LDFLAGS += 
> --orphan-handling=$(CONFIG_LD_ORPHAN_WARN_LEVEL)
>  # $(hostprogs) with $(obj)
>  munge := ../../../arm/vdso/vdsomunge
>  hostprogs := $(munge)
> +HOSTCFLAGS_$(munge).o = -I$(objtree)/include/elf
>  
>  c-obj-vdso := note.o
>  c-obj-vdso-gettimeofday := vgettimeofday.o
> diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile 
> b/arch/arm64/kvm/hyp/nvhe/Makefile
> index 782b34b004be..40541c0812bf 100644
> --- a/arch/arm64/kvm/hyp/nvhe/Makefile
> +++ b/arch/arm64/kvm/hyp/nvhe/Makefile
> @@ -15,7 +15,7 @@ ccflags-y += -fno-stack-protector   \
>$(DISABLE_STACKLEAK_PLUGIN)
>  
>  hostprogs := gen-hyprel
> -HOST_EXTRACFLAGS += -I$(objtree)/include
> +HOST_EXTRACFLAGS += -I$(objtree)/include -I$(srctree)/include/elf
>  
>  lib-objs := clear_page.o copy_page.o memcpy.o memset.o
>  lib-objs := $(addprefix ../../../lib/, $(lib-objs))
> diff --git a/include/elf/elf.h b/include/elf/elf.h
> new file mode 100644
> index ..33aea7f743b8
> --- /dev/null
> +++ b/include/elf/elf.h
> @@ -0,0 +1,4491 @@
> +/* This file defines standard ELF types, structures, and macros.
> +   Copyright (C) 1995-2024 Free Software Foundation, Inc.
> +   This file is part of the GNU C Library.
> +
> +   The GNU C Library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   The GNU C Library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with the GNU C Library; if not, see
> +   .  */

I understand your want/need for this, but new files need a SPDX license
header instead of this type of license boilerplate.  Didn't glibc
already convert to SPDX?

Also, as this is not internal for the kernel, but rather for userspace
builds, shouldn't the include/ path be different?

thanks,

greg k-h

Re: [PATCH 00/12] Enable build system on macOS hosts

[Greg Kroah-Hartman]

On Wed, Aug 07, 2024 at 01:09:14AM +0200, Daniel Gomez via B4 Relay wrote:
> This patch set allows for building the Linux kernel for arm64 in macOS with
> LLVM.

Is this a requirement somewhere that this must work?  It seems like an
odd request, what workflows require cross-operating-system builds like
this?

thanks,

greg k-h

Re: [PATCH v2 0/2] Fix mmap memory boundary calculation

[Greg Kroah-Hartman]

On Mon, Aug 05, 2024 at 11:05:22PM +0100, Andi Shyti wrote:
> Hi Greg,
> 
> > Andi Shyti (2):
> >   drm/i915/gem: Adjust vma offset for framebuffer mmap offset
> >   drm/i915/gem: Fix Virtual Memory mapping boundaries calculation
> 
> I have forgotten to Cc the stable mailing list here. These two
> patches need to be merged together even if only the second patch
> has the "Fixes:" tag.
> 
> Is there anything I should still do here?
> 
> I could have used the "Requires:" tag, but the commit id would
> change in between merges and rebases.



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

[PATCH 6.10 700/809] drm/udl: Remove DRM_CONNECTOR_POLL_HPD

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit 5aed213c7c6c4f5dcb1a3ef146f493f18fe703dc upstream.

DisplayLink devices do not generate hotplug events. Remove the poll
flag DRM_CONNECTOR_POLL_HPD, as it may not be specified together with
DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT.

Signed-off-by: Thomas Zimmermann 
Fixes: afdfc4c6f55f ("drm/udl: Fixed problem with UDL adpater reconnection")
Reviewed-by: Jani Nikula 
Cc: Robert Tarasov 
Cc: Alex Deucher 
Cc: Dave Airlie 
Cc: Sean Paul 
Cc: Thomas Zimmermann 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.15+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240510154841.11370-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/udl/udl_modeset.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -527,8 +527,7 @@ struct drm_connector *udl_connector_init
 
drm_connector_helper_add(connector, &udl_connector_helper_funcs);
 
-   connector->polled = DRM_CONNECTOR_POLL_HPD |
-   DRM_CONNECTOR_POLL_CONNECT |
+   connector->polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
 
return connector;

[PATCH 6.10 557/809] drm/xe: Use write-back caching mode for system memory on DGFX

[Greg Kroah-Hartman]

6.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Hellström 

commit 5207c393d3e7dda9aff813d6b3e2264370d241be upstream.

The caching mode for buffer objects with VRAM as a possible
placement was forced to write-combined, regardless of placement.

However, write-combined system memory is expensive to allocate and
even though it is pooled, the pool is expensive to shrink, since
it involves global CPU TLB flushes.

Moreover write-combined system memory from TTM is only reliably
available on x86 and DGFX doesn't have an x86 restriction.

So regardless of the cpu caching mode selected for a bo,
internally use write-back caching mode for system memory on DGFX.

Coherency is maintained, but user-space clients may perceive a
difference in cpu access speeds.

v2:
- Update RB- and Ack tags.
- Rephrase wording in xe_drm.h (Matt Roper)
v3:
- Really rephrase wording.

Signed-off-by: Thomas Hellström 
Fixes: 622f709ca629 ("drm/xe/uapi: Add support for CPU caching mode")
Cc: Pallavi Mishra 
Cc: Matthew Auld 
Cc: dri-devel@lists.freedesktop.org
Cc: Joonas Lahtinen 
Cc: Effie Yu 
Cc: Matthew Brost 
Cc: Maarten Lankhorst 
Cc: Jose Souza 
Cc: Michal Mrozek 
Cc:  # v6.8+
Acked-by: Matthew Auld 
Acked-by: José Roberto de Souza 
Reviewed-by: Rodrigo Vivi 
Fixes: 622f709ca629 ("drm/xe/uapi: Add support for CPU caching mode")
Acked-by: Michal Mrozek 
Acked-by: Effie Yu  #On chat
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240705132828.27714-1-thomas.hellst...@linux.intel.com
(cherry picked from commit 01e0cfc994be484ddcb9e121e353e51d8bb837c0)
Signed-off-by: Lucas De Marchi 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/xe/xe_bo.c   |   47 +++
 drivers/gpu/drm/xe/xe_bo_types.h |3 +-
 include/uapi/drm/xe_drm.h|8 +-
 3 files changed, 37 insertions(+), 21 deletions(-)

--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -317,7 +317,7 @@ static struct ttm_tt *xe_ttm_tt_create(s
struct xe_device *xe = xe_bo_device(bo);
struct xe_ttm_tt *tt;
unsigned long extra_pages;
-   enum ttm_caching caching;
+   enum ttm_caching caching = ttm_cached;
int err;
 
tt = kzalloc(sizeof(*tt), GFP_KERNEL);
@@ -331,26 +331,35 @@ static struct ttm_tt *xe_ttm_tt_create(s
extra_pages = DIV_ROUND_UP(xe_device_ccs_bytes(xe, bo->size),
   PAGE_SIZE);
 
-   switch (bo->cpu_caching) {
-   case DRM_XE_GEM_CPU_CACHING_WC:
-   caching = ttm_write_combined;
-   break;
-   default:
-   caching = ttm_cached;
-   break;
-   }
-
-   WARN_ON((bo->flags & XE_BO_FLAG_USER) && !bo->cpu_caching);
-
/*
-* Display scanout is always non-coherent with the CPU cache.
-*
-* For Xe_LPG and beyond, PPGTT PTE lookups are also non-coherent and
-* require a CPU:WC mapping.
+* DGFX system memory is always WB / ttm_cached, since
+* other caching modes are only supported on x86. DGFX
+* GPU system memory accesses are always coherent with the
+* CPU.
 */
-   if ((!bo->cpu_caching && bo->flags & XE_BO_FLAG_SCANOUT) ||
-   (xe->info.graphics_verx100 >= 1270 && bo->flags & 
XE_BO_FLAG_PAGETABLE))
-   caching = ttm_write_combined;
+   if (!IS_DGFX(xe)) {
+   switch (bo->cpu_caching) {
+   case DRM_XE_GEM_CPU_CACHING_WC:
+   caching = ttm_write_combined;
+   break;
+   default:
+   caching = ttm_cached;
+   break;
+   }
+
+   WARN_ON((bo->flags & XE_BO_FLAG_USER) && !bo->cpu_caching);
+
+   /*
+* Display scanout is always non-coherent with the CPU cache.
+*
+* For Xe_LPG and beyond, PPGTT PTE lookups are also
+* non-coherent and require a CPU:WC mapping.
+*/
+   if ((!bo->cpu_caching && bo->flags & XE_BO_FLAG_SCANOUT) ||
+   (xe->info.graphics_verx100 >= 1270 &&
+bo->flags & XE_BO_FLAG_PAGETABLE))
+   caching = ttm_write_combined;
+   }
 
err = ttm_tt_init(&tt->ttm, &bo->ttm, page_flags, caching, extra_pages);
if (err) {
--- a/drivers/gpu/drm/xe/xe_bo_types.h
+++ b/drivers/gpu/drm/xe/xe_bo_types.h
@@ -66,7 +66,8 @@ struct xe_bo {
 
/**
 * @cpu_caching: CPU caching mode. Currently only used for userspace
-* objects.
+* objects. Exceptions are system memory on DGFX, which is always
+* WB.
 */
u16 cpu_caching;
 
--- a/i

[PATCH 6.6 476/568] drm/udl: Remove DRM_CONNECTOR_POLL_HPD

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit 5aed213c7c6c4f5dcb1a3ef146f493f18fe703dc upstream.

DisplayLink devices do not generate hotplug events. Remove the poll
flag DRM_CONNECTOR_POLL_HPD, as it may not be specified together with
DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT.

Signed-off-by: Thomas Zimmermann 
Fixes: afdfc4c6f55f ("drm/udl: Fixed problem with UDL adpater reconnection")
Reviewed-by: Jani Nikula 
Cc: Robert Tarasov 
Cc: Alex Deucher 
Cc: Dave Airlie 
Cc: Sean Paul 
Cc: Thomas Zimmermann 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.15+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240510154841.11370-2-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/udl/udl_modeset.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -512,8 +512,7 @@ struct drm_connector *udl_connector_init
 
drm_connector_helper_add(connector, &udl_connector_helper_funcs);
 
-   connector->polled = DRM_CONNECTOR_POLL_HPD |
-   DRM_CONNECTOR_POLL_CONNECT |
+   connector->polled = DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT;
 
return connector;

Re: [PATCH] agp: uninorth: add missing MODULE_DESCRIPTION() macro

[Greg Kroah-Hartman]

On Thu, Jul 11, 2024 at 01:27:23PM -0600, Jeffrey Hugo wrote:
> On 7/11/2024 12:19 PM, Jeff Johnson wrote:
> > On 6/28/24 20:14, Jeff Johnson wrote:
> > > On 6/15/2024 2:01 PM, Jeff Johnson wrote:
> > > > With ARCH=powerpc, make allmodconfig && make W=1 C=1 reports:
> > > > WARNING: modpost: missing MODULE_DESCRIPTION() in
> > > > drivers/char/agp/uninorth-agp.o
> > > > 
> > > > Add the missing invocation of the MODULE_DESCRIPTION() macro.
> > > > 
> > > > Signed-off-by: Jeff Johnson 
> > > > ---
> > > >   drivers/char/agp/uninorth-agp.c | 1 +
> > > >   1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/drivers/char/agp/uninorth-agp.c
> > > > b/drivers/char/agp/uninorth-agp.c
> > > > index 84411b13c49f..b8d7115b8c9e 100644
> > > > --- a/drivers/char/agp/uninorth-agp.c
> > > > +++ b/drivers/char/agp/uninorth-agp.c
> > > > @@ -726,4 +726,5 @@ MODULE_PARM_DESC(aperture,
> > > >    "\t\tDefault: " DEFAULT_APERTURE_STRING "M");
> > > >   MODULE_AUTHOR("Ben Herrenschmidt & Paul Mackerras");
> > > > +MODULE_DESCRIPTION("Apple UniNorth & U3 AGP support");
> > > >   MODULE_LICENSE("GPL");
> > > > 
> > > > ---
> > > > base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
> > > > change-id: 20240615-md-powerpc-drivers-char-agp-db644db58c24
> > > 
> > > Following up to see if anything else is needed from me. Hoping to
> > > see this in
> > > linux-next so I can remove it from my tracking spreadsheet :)
> > 
> > I still don't see this in linux-next.
> > Adding Greg KH since he's picked up many of these fixes.
> > Hope to have all of these warnings fixed tree-wide in 6.11.
> 
> Reviewed-by: Jeffrey Hugo 
> 
> Dave, this seems like a trivial fix that is stuck, but normally routed
> through DRM.  I hope I'm not over stepping, but I think I'll drop this in
> drm-misc-next on the 19th if there isn't any other activity.

I can take it now, otherwise you will miss the 6.11-rc1 merge window.

thanks,

greg k-h

[PATCH 6.9 150/197] drm/ttm: Always take the bo delayed cleanup path for imported bos

[Greg Kroah-Hartman]

ter_hwframe+0x76/0x7e
[22982.117176] RIP: 0033:0x7f943d267169
[22982.117192] Code: Unable to access opcode bytes at 0x7f943d26713f.
[22982.117193] RSP: 002b:7f9430bffc80 EFLAGS: 0246 ORIG_RAX: 
00ca
[22982.117195] RAX: fe00 RBX:  RCX: 7f943d267169
[22982.117196] RDX:  RSI: 0189 RDI: 5622f89579d0
[22982.117197] RBP: 7f9430bffcb0 R08:  R09: 
[22982.117198] R10:  R11: 0246 R12: 
[22982.117199] R13:  R14:  R15: 5622f89579d0
[22982.117202]  

Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Cc: Christian König 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: intel...@lists.freedesktop.org
Cc:  # v6.8+
Signed-off-by: Thomas Hellström 
Reviewed-by: Matthew Brost 
Reviewed-by: Daniel Vetter 
Reviewed-by: Christian König 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240628153848.4989-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 6396dece0db1..2427be8bc97f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -346,6 +346,7 @@ static void ttm_bo_release(struct kref *kref)
if (!dma_resv_test_signaled(bo->base.resv,
DMA_RESV_USAGE_BOOKKEEP) ||
(want_init_on_free() && (bo->ttm != NULL)) ||
+   bo->type == ttm_bo_type_sg ||
!dma_resv_trylock(bo->base.resv)) {
/* The BO is not idle, resurrect it for delayed destroy 
*/
ttm_bo_flush_all_fences(bo);
-- 
2.45.2

[PATCH] driver core: have match() callback in struct bus_type take a const *

[Greg Kroah-Hartman]

In the match() callback, the struct device_driver * should not be
changed, so change the function callback to be a const *.  This is one
step of many towards making the driver core safe to have struct
device_driver in read-only memory.

Because the match() callback is in all busses, all busses are modified
to handle this properly.  This does entail switching some container_of()
calls to container_of_const() to properly handle the constant *.

For some busses, like PCI and USB and HV, the const * is cast away in
the match callback as those busses do want to modify those structures at
this point in time (they have a local lock in the driver structure.)
That will have to be changed in the future if they wish to have their
struct device * in read-only-memory.

Cc: "Rafael J. Wysocki" 
Signed-off-by: Greg Kroah-Hartman 
---
 - cc: list suppressed as it just touches too many different subsystems
   at once, sorry.  I tried to hit all of the mailing lists as a bcc:
   hopefully they don't reject it...

 arch/arm/common/locomo.c  |  4 ++--
 arch/arm/include/asm/hardware/locomo.h|  2 +-
 arch/parisc/include/asm/parisc-device.h   |  2 +-
 arch/parisc/kernel/drivers.c  |  4 ++--
 arch/powerpc/include/asm/ps3.h|  6 +-
 arch/powerpc/include/asm/vio.h|  6 +-
 arch/powerpc/platforms/ps3/system-bus.c   |  4 ++--
 arch/powerpc/platforms/pseries/ibmebus.c  |  2 +-
 arch/powerpc/platforms/pseries/vio.c  |  6 +++---
 arch/s390/include/asm/ccwdev.h|  2 +-
 arch/sparc/include/asm/vio.h  |  6 +-
 arch/sparc/kernel/vio.c   |  4 ++--
 drivers/acpi/bus.c|  4 ++--
 drivers/amba/bus.c|  6 +++---
 drivers/base/auxiliary.c  |  2 +-
 drivers/base/base.h   |  3 +--
 drivers/base/cpu.c|  2 +-
 drivers/base/isa.c|  2 +-
 drivers/base/platform.c   |  2 +-
 drivers/bcma/main.c   |  6 +++---
 drivers/bus/fsl-mc/fsl-mc-bus.c   |  4 ++--
 drivers/bus/mhi/ep/main.c |  4 ++--
 drivers/bus/mhi/host/init.c   |  4 ++--
 drivers/bus/mips_cdmm.c   |  6 +++---
 drivers/bus/moxtet.c  |  4 ++--
 drivers/bus/sunxi-rsb.c   |  2 +-
 drivers/cdx/cdx.c |  4 ++--
 drivers/cxl/core/port.c   |  2 +-
 drivers/cxl/cxl.h |  5 +
 drivers/dax/bus.c | 17 +++--
 drivers/dma/idxd/bus.c|  6 +++---
 drivers/eisa/eisa-bus.c   |  4 ++--
 drivers/firewire/core-device.c|  6 +++---
 drivers/firmware/arm_ffa/bus.c|  2 +-
 drivers/firmware/arm_scmi/bus.c   |  6 +++---
 drivers/firmware/google/coreboot_table.c  |  6 +++---
 drivers/fpga/dfl.c|  4 ++--
 drivers/fsi/fsi-core.c|  4 ++--
 drivers/gpio/gpiolib.c|  2 +-
 drivers/gpu/drm/display/drm_dp_aux_bus.c  |  2 +-
 drivers/gpu/drm/drm_mipi_dsi.c|  2 +-
 drivers/gpu/host1x/bus.c  |  2 +-
 drivers/greybus/core.c|  4 ++--
 drivers/hid/hid-core.c|  2 +-
 drivers/hid/intel-ish-hid/ishtp/bus.c |  2 +-
 drivers/hsi/hsi_core.c|  2 +-
 drivers/hv/vmbus_drv.c|  8 
 drivers/hwtracing/intel_th/core.c |  4 ++--
 drivers/hwtracing/intel_th/intel_th.h |  2 +-
 drivers/i2c/i2c-core-base.c   |  4 ++--
 drivers/i3c/master.c  |  4 ++--
 drivers/input/gameport/gameport.c |  4 ++--
 drivers/input/rmi4/rmi_bus.c  |  6 +++---
 drivers/input/rmi4/rmi_bus.h  |  2 +-
 drivers/input/rmi4/rmi_driver.c   |  2 +-
 drivers/input/rmi4/rmi_driver.h   |  2 +-
 drivers/input/serio/serio.c   |  4 ++--
 drivers/ipack/ipack.c |  6 +++---
 drivers/macintosh/macio_asic.c|  2 +-
 drivers/mcb/mcb-core.c|  4 ++--
 drivers/media/pci/bt8xx/bttv-gpio.c   |  4 ++--
 drivers/media/pci/bt8xx/bttv.h|  2 +-
 drivers/memstick/core/memstick.c  |  7 +++
 drivers/mfd/mcp-core.c|  2 +-
 drivers/misc/mei/bus.c|  4 ++--
 drivers/misc/tifm_core.c  |  6 +++---
 drivers/mmc/core/sdio_bus.c   | 10 +-
 drivers/most/core.c   |  2 +-
 drivers/net/phy/mdio_bus.c|  4 ++--
 drivers/net/phy/mdio_device.c  

Re: [PATCH] staging: fbtft: Remove unnecessary parentheses

[Greg Kroah-Hartman]

On Mon, Jun 17, 2024 at 07:57:47PM +0530, Shiva Kiran K wrote:
> Remove unnecessary parentheses in `if` statements.
> Reported by checkpatch.pl
> 
> Signed-off-by: Shiva Kiran K 
> ---
>  drivers/staging/fbtft/fb_ili9320.c | 2 +-
>  drivers/staging/fbtft/fb_ra8875.c  | 2 +-
>  drivers/staging/fbtft/fbtft-bus.c  | 2 +-
>  drivers/staging/fbtft/fbtft-core.c | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/fbtft/fb_ili9320.c 
> b/drivers/staging/fbtft/fb_ili9320.c
> index 0be7c2d51..409b54cc5 100644
> --- a/drivers/staging/fbtft/fb_ili9320.c
> +++ b/drivers/staging/fbtft/fb_ili9320.c
> @@ -37,7 +37,7 @@ static int init_display(struct fbtft_par *par)
>   devcode = read_devicecode(par);
>   fbtft_par_dbg(DEBUG_INIT_DISPLAY, par, "Device code: 0x%04X\n",
> devcode);
> - if ((devcode != 0x) && (devcode != 0x9320))
> + if (devcode != 0x && devcode != 0x9320)
>   dev_warn(par->info->device,
>"Unrecognized Device code: 0x%04X (expected 0x9320)\n",
>   devcode);
> diff --git a/drivers/staging/fbtft/fb_ra8875.c 
> b/drivers/staging/fbtft/fb_ra8875.c
> index 398bdbf53..ce305a0be 100644
> --- a/drivers/staging/fbtft/fb_ra8875.c
> +++ b/drivers/staging/fbtft/fb_ra8875.c
> @@ -50,7 +50,7 @@ static int init_display(struct fbtft_par *par)
>  
>   par->fbtftops.reset(par);
>  
> - if ((par->info->var.xres == 320) && (par->info->var.yres == 240)) {
> + if (par->info->var.xres == 320 && par->info->var.yres == 240) {
>   /* PLL clock frequency */
>   write_reg(par, 0x88, 0x0A);
>   write_reg(par, 0x89, 0x02);
> diff --git a/drivers/staging/fbtft/fbtft-bus.c 
> b/drivers/staging/fbtft/fbtft-bus.c
> index 3d422bc11..ab903c938 100644
> --- a/drivers/staging/fbtft/fbtft-bus.c
> +++ b/drivers/staging/fbtft/fbtft-bus.c
> @@ -85,7 +85,7 @@ void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, 
> ...)
>   if (len <= 0)
>   return;
>  
> - if (par->spi && (par->spi->bits_per_word == 8)) {
> + if (par->spi && par->spi->bits_per_word == 8) {
>   /* we're emulating 9-bit, pad start of buffer with no-ops
>* (assuming here that zero is a no-op)
>*/
> diff --git a/drivers/staging/fbtft/fbtft-core.c 
> b/drivers/staging/fbtft/fbtft-core.c
> index c8d52c63d..64babfe3a 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -666,7 +666,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct 
> fbtft_display *display,
>   txbuflen = 0;
>  
>  #ifdef __LITTLE_ENDIAN
> - if ((!txbuflen) && (bpp > 8))
> + if (!txbuflen && bpp > 8)
>   txbuflen = PAGE_SIZE; /* need buffer for byteswapping */
>  #endif
>  
> -- 
> 2.45.2
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You sent a patch that has been sent multiple times in the past few
  days, and is identical to ones that has been recently rejected.
  Please always look at the mailing list traffic to determine if you are
  duplicating other people's work.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

[PATCH 6.9 257/281] drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)

[Greg Kroah-Hartman]

6.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Wachowski, Karol 

commit 39bc27bd688066a63e56f7f64ad34fae03fbe3b8 upstream.

Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap
allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag
causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:
BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags));

Return -EINVAL early if COW mapping is detected.

This bug affects all drm drivers using default shmem helpers.
It can be reproduced by this simple example:
void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);
ptr[0] = 0;

Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects")
Cc: Noralf Trønnes 
Cc: Eric Anholt 
Cc: Rob Herring 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.2+
Signed-off-by: Wachowski, Karol 
Signed-off-by: Jacek Lawrynowicz 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240520100514.925681-1-jacek.lawrynow...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -610,6 +610,9 @@ int drm_gem_shmem_mmap(struct drm_gem_sh
return ret;
}
 
+   if (is_cow_mapping(vma->vm_flags))
+   return -EINVAL;
+
dma_resv_lock(shmem->base.resv, NULL);
ret = drm_gem_shmem_get_pages(shmem);
dma_resv_unlock(shmem->base.resv);

[PATCH 6.6 216/267] drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Wachowski, Karol 

commit 39bc27bd688066a63e56f7f64ad34fae03fbe3b8 upstream.

Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap
allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag
causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:
BUG_ON((vma->vm_flags & VM_PFNMAP) && is_cow_mapping(vma->vm_flags));

Return -EINVAL early if COW mapping is detected.

This bug affects all drm drivers using default shmem helpers.
It can be reproduced by this simple example:
void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);
ptr[0] = 0;

Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects")
Cc: Noralf Trønnes 
Cc: Eric Anholt 
Cc: Rob Herring 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.2+
Signed-off-by: Wachowski, Karol 
Signed-off-by: Jacek Lawrynowicz 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240520100514.925681-1-jacek.lawrynow...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/drm_gem_shmem_helper.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -610,6 +610,9 @@ int drm_gem_shmem_mmap(struct drm_gem_sh
return ret;
}
 
+   if (is_cow_mapping(vma->vm_flags))
+   return -EINVAL;
+
dma_resv_lock(shmem->base.resv, NULL);
ret = drm_gem_shmem_get_pages(shmem);
dma_resv_unlock(shmem->base.resv);

Re: [PATCH] staging: fbtft: Remove unnecessary parentheses

[Greg Kroah-Hartman]

On Mon, Jun 17, 2024 at 07:57:47PM +0530, Shiva Kiran K wrote:
> Remove unnecessary parentheses in `if` statements.
> Reported by checkpatch.pl

As per the many times this came up in the past (see the mailing list
archives), checkpatch is wrong here.

sorry,

greg k-h

[PATCH 5.15 139/402] fbdev: sh7760fb: allow modular build

[Greg Kroah-Hartman]

5.15-stable review patch.  If anyone has any objections, please let me know.

--

From: Randy Dunlap 

[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]

There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.

Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven 
Signed-off-by: Randy Dunlap 
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: John Paul Adrian Glaubitz 
Cc: Sam Ravnborg 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: John Paul Adrian Glaubitz 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 662524574cc33..26dfc4e5b10ce 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2016,8 +2016,8 @@ config FB_COBALT
depends on FB && MIPS_COBALT
 
 config FB_SH7760
-   bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
-   depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+   tristate "SH7760/SH7763/SH7720/SH7721 LCDC support"
+   depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
-- 
2.43.0

[PATCH 5.10 102/317] fbdev: sh7760fb: allow modular build

[Greg Kroah-Hartman]

5.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Randy Dunlap 

[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]

There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.

Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven 
Signed-off-by: Randy Dunlap 
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: John Paul Adrian Glaubitz 
Cc: Sam Ravnborg 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: John Paul Adrian Glaubitz 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index dd59584630979..9ad3e51578691 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2013,8 +2013,8 @@ config FB_COBALT
depends on FB && MIPS_COBALT
 
 config FB_SH7760
-   bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
-   depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+   tristate "SH7760/SH7763/SH7720/SH7721 LCDC support"
+   depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
-- 
2.43.0

[PATCH 5.4 077/202] fbdev: sh7760fb: allow modular build

[Greg Kroah-Hartman]

5.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Randy Dunlap 

[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]

There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.

Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven 
Signed-off-by: Randy Dunlap 
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: John Paul Adrian Glaubitz 
Cc: Sam Ravnborg 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: John Paul Adrian Glaubitz 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 0396df868bc79..8a3014455327b 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2031,8 +2031,8 @@ config FB_COBALT
depends on FB && MIPS_COBALT
 
 config FB_SH7760
-   bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
-   depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+   tristate "SH7760/SH7763/SH7720/SH7721 LCDC support"
+   depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
-- 
2.43.0

[PATCH 4.19 073/213] fbdev: sh7760fb: allow modular build

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Randy Dunlap 

[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]

There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.

Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven 
Signed-off-by: Randy Dunlap 
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: John Paul Adrian Glaubitz 
Cc: Sam Ravnborg 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: John Paul Adrian Glaubitz 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8e224ee27ade9..12846837f5de0 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2084,8 +2084,8 @@ config FB_COBALT
depends on FB && MIPS_COBALT
 
 config FB_SH7760
-   bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
-   depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+   tristate "SH7760/SH7763/SH7720/SH7721 LCDC support"
+   depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
-- 
2.43.0

[PATCH 6.6 314/744] fbdev: sh7760fb: allow modular build

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Randy Dunlap 

[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]

There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.

Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven 
Signed-off-by: Randy Dunlap 
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: John Paul Adrian Glaubitz 
Cc: Sam Ravnborg 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: John Paul Adrian Glaubitz 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index c29754b65c0ec..325298573e120 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1761,8 +1761,8 @@ config FB_COBALT
depends on FB && MIPS_COBALT
 
 config FB_SH7760
-   bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
-   depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+   tristate "SH7760/SH7763/SH7720/SH7721 LCDC support"
+   depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
select FB_IOMEM_HELPERS
help
-- 
2.43.0

[PATCH 6.1 219/473] fbdev: sh7760fb: allow modular build

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Randy Dunlap 

[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]

There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.

Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven 
Signed-off-by: Randy Dunlap 
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: John Paul Adrian Glaubitz 
Cc: Sam Ravnborg 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: John Paul Adrian Glaubitz 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index ff95f19224901..37089d5a7ccc5 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2014,8 +2014,8 @@ config FB_COBALT
depends on FB && MIPS_COBALT
 
 config FB_SH7760
-   bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
-   depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+   tristate "SH7760/SH7763/SH7720/SH7721 LCDC support"
+   depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
-- 
2.43.0

Re: [PATCH] kernel/resource: optimize find_next_iomem_res

[Greg Kroah-Hartman]

On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote:
> We can skip children resources when the parent resource does not cover
> the range.
> 
> This should help vmf_insert_* users on x86, such as several DRM drivers.
> On my AMD Ryzen 5 7520C, when streaming data from cpu memory into amdgpu
> bo, the throughput goes from 5.1GB/s to 6.6GB/s.  perf report says
> 
>   34.69%--__do_fault
>   34.60%--amdgpu_gem_fault
>   34.00%--ttm_bo_vm_fault_reserved
>   32.95%--vmf_insert_pfn_prot
>   25.89%--track_pfn_insert
>   24.35%--lookup_memtype
>   21.77%--pat_pagerange_is_ram
>   20.80%--walk_system_ram_range
>   17.42%--find_next_iomem_res
> 
> before this change, and
> 
>   26.67%--__do_fault
>   26.57%--amdgpu_gem_fault
>   25.83%--ttm_bo_vm_fault_reserved
>   24.40%--vmf_insert_pfn_prot
>   14.30%--track_pfn_insert
>   12.20%--lookup_memtype
>   9.34%--pat_pagerange_is_ram
>   8.22%--walk_system_ram_range
>   5.09%--find_next_iomem_res
> 
> after.

That's great, but why is walk_system_ram_range() being called so often?

Shouldn't that be a "set up the device" only type of thing?  Why hammer
on "lookup_memtype" when you know the memtype, you just did the same
thing for the previous frame.

This feels like it could be optimized to just "don't call these things"
which would make it go faster, right?

What am I missing here, why does this always have to be calculated all
the time?  Resource mapping changes are rare, if at all, over the
lifetime of a system uptime.  Constantly calculating something that
never changes feels odd to me.

thanks,

greg k-h

[PATCH 6.8 399/493] fbdev: sh7760fb: allow modular build

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Randy Dunlap 

[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]

There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.

Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven 
Signed-off-by: Randy Dunlap 
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: John Paul Adrian Glaubitz 
Cc: Sam Ravnborg 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: John Paul Adrian Glaubitz 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index ba4ab33f6094b..411bf2b2c4d03 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1680,8 +1680,8 @@ config FB_COBALT
select FB_IOMEM_HELPERS
 
 config FB_SH7760
-   bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
-   depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+   tristate "SH7760/SH7763/SH7720/SH7721 LCDC support"
+   depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
select FB_IOMEM_HELPERS
help
-- 
2.43.0

[PATCH 6.9 325/427] fbdev: sh7760fb: allow modular build

[Greg Kroah-Hartman]

6.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Randy Dunlap 

[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]

There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.

Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven 
Signed-off-by: Randy Dunlap 
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: John Paul Adrian Glaubitz 
Cc: Sam Ravnborg 
Cc: Helge Deller 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: John Paul Adrian Glaubitz 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 197b6d5268e94..3f46663aa563d 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1648,8 +1648,8 @@ config FB_COBALT
select FB_IOMEM_HELPERS
 
 config FB_SH7760
-   bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
-   depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
+   tristate "SH7760/SH7763/SH7720/SH7721 LCDC support"
+   depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
|| CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
select FB_IOMEM_HELPERS
help
-- 
2.43.0

[PATCH 5.15 162/168] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

5.15-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1068,7 +1068,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, &event->base, 
&event->event.base);

[PATCH 5.10 108/111] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

5.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1066,7 +1066,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, &event->base, 
&event->event.base);

[PATCH 5.4 78/84] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

5.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1066,7 +1066,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, &event->base, 
&event->event.base);

[PATCH 4.19 61/63] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -1064,7 +1064,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, &event->base, 
&event->event.base);

[PATCH 6.1 221/236] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -991,7 +991,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, &event->base, 
&event->event.base);

[PATCH 6.6 271/301] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -991,7 +991,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, &event->base, 
&event->event.base);

[PATCH 6.6 269/301] drm/ttm: Print the memory decryption status just once

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit 27906e5d78248b19bcdfdae72049338c828897bb upstream.

Stop printing the TT memory decryption status info each time tt is created
and instead print it just once.

Reduces the spam in the system logs when running guests with SEV enabled.

Signed-off-by: Zack Rusin 
Fixes: 71ce046327cf ("drm/ttm: Make sure the mapped tt pages are decrypted when 
needed")
Reviewed-by: Christian König 
Cc: Thomas Hellström 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v5.14+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240408155605.1398631-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index 578a7c37f00b..d776e3f87064 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -92,7 +92,7 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool 
zero_alloc)
 */
if (bdev->pool.use_dma_alloc && 
cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
page_flags |= TTM_TT_FLAG_DECRYPTED;
-   drm_info(ddev, "TT memory decryption enabled.");
+   drm_info_once(ddev, "TT memory decryption enabled.");
}
 
bo->ttm = bdev->funcs->ttm_tt_create(bo, page_flags);
-- 
2.45.0

[PATCH 6.8 298/336] drm/vmwgfx: Fix invalid reads in fence signaled events

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c upstream.

Correctly set the length of the drm_event to the size of the structure
that's actually used.

The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.

Signed-off-by: Zack Rusin 
Fixes: 8b7de6aa8468 ("vmwgfx: Rework fence event action")
Reported-by: zdi-disclosu...@trendmicro.com # ZDI-CAN-23566
Cc: David Airlie 
CC: Daniel Vetter 
Cc: Zack Rusin 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v3.4+
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240425192748.1761522-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -991,7 +991,7 @@ static int vmw_event_fence_action_create
}
 
event->event.base.type = DRM_VMW_EVENT_FENCE_SIGNALED;
-   event->event.base.length = sizeof(*event);
+   event->event.base.length = sizeof(event->event);
event->event.user_data = user_data;
 
ret = drm_event_reserve_init(dev, file_priv, &event->base, 
&event->event.base);

[PATCH 6.8 296/336] drm/ttm: Print the memory decryption status just once

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit 27906e5d78248b19bcdfdae72049338c828897bb upstream.

Stop printing the TT memory decryption status info each time tt is created
and instead print it just once.

Reduces the spam in the system logs when running guests with SEV enabled.

Signed-off-by: Zack Rusin 
Fixes: 71ce046327cf ("drm/ttm: Make sure the mapped tt pages are decrypted when 
needed")
Reviewed-by: Christian König 
Cc: Thomas Hellström 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v5.14+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240408155605.1398631-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/ttm/ttm_tt.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -92,7 +92,7 @@ int ttm_tt_create(struct ttm_buffer_obje
 */
if (bdev->pool.use_dma_alloc && 
cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
page_flags |= TTM_TT_FLAG_DECRYPTED;
-   drm_info(ddev, "TT memory decryption enabled.");
+   drm_info_once(ddev, "TT memory decryption enabled.");
}
 
bo->ttm = bdev->funcs->ttm_tt_create(bo, page_flags);

Re: [PATCH] drm/bridge: aux-hpd-bridge: correct devm_drm_dp_hpd_bridge_add() stub

[Greg Kroah-Hartman]

On Sat, May 11, 2024 at 11:54:30AM +0300, Dmitry Baryshkov wrote:
> If CONFIG_DRM_AUX_HPD_BRIDGE is not enabled, the aux-bridge.h header
> provides a stub for the bridge's functions. Correct the arguments list
> of one of those stubs to match the argument list of the non-stubbed
> function.
> 
> Fixes: e5ca263508f7 ("drm/bridge: aux-hpd: separate allocation and 
> registration")
> Reported-by: kernel test robot 
> Closes: 
> https://lore.kernel.org/oe-kbuild-all/202405110428.tmcfb1ut-...@intel.com/
> Cc: Johan Hovold 
> Signed-off-by: Dmitry Baryshkov 
> ---
>  include/drm/bridge/aux-bridge.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

You beat me to it, thanks!  I'll take this through the usb-next tree as
we have a commit there that requires this to build properly on 0-day
testing.

greg k-h

Re: [PATCH v2 5/5] misc: add ge-addon-connector driver

[Greg Kroah-Hartman]

On Fri, May 10, 2024 at 12:54:17PM +0200, Luca Ceresoli wrote:
> > > +static int sunh_conn_handle_event(struct sunh_conn *conn, bool plugged)
> > > +{
> > > + int err;
> > > +
> > > + if (plugged == conn->plugged)
> > > + return 0;
> > > +
> > > + dev_info(conn->dev, "%s\n", plugged ? "connected" : "disconnected");  
> > 
> > Please remove debugging code from stuff you want to see merged.
> > 
> > Same for all dev_info() calls here, when drivers work properly, they are
> > quiet.
> 
> While agree for other dev_info() calls, this one seems quite similar in
> principle to the link up/down messages that get logged by the MII code
> at [0]:
> 
>   [347229.872315] asix 1-1.3.2:1.0 enx000cf616fecb: link up, 100Mbps,
>   full-duplex, lpa 0xC5E1 [347229.920449] asix 1-1.3.2:1.0 enx000cf616fecb: 
> link down
> 
> In my case it is logging that a removable part of the hardware has been
> added or removed, which appears useful. Do you think it make sense in
> this scenario?

Nope, sorry, again, when drivers are working properly, they should be
quiet otherwise they just fill up the log with unneeded messages.

thanks,

greg k-h

Re: [PATCH v2 5/5] misc: add ge-addon-connector driver

[Greg Kroah-Hartman]

On Fri, May 10, 2024 at 09:10:41AM +0200, Luca Ceresoli wrote:
> Add a driver to support the runtime hot-pluggable add-on connector on the
> GE SUNH device. This connector allows connecting and disconnecting an
> add-on to/from the main device to augment its features. Connection and
> disconnection can happen at runtime at any moment without notice.
> 
> Different add-on models can be connected, and each has an EEPROM with a
> model identifier at a fixed address.
> 
> The add-on hardware is added and removed using device tree overlay loading
> and unloading.
> 
> Co-developed-by: Herve Codina 
> Signed-off-by: Herve Codina 
> Signed-off-by: Luca Ceresoli 
> 
> ---
> 
> This commit is new in v2.
> ---
>  MAINTAINERS  |   1 +
>  drivers/misc/Kconfig |  15 ++
>  drivers/misc/Makefile|   1 +
>  drivers/misc/ge-sunh-connector.c | 464 
> +++
>  4 files changed, 481 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 672c26372c92..0bdb4fc496b8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9905,6 +9905,7 @@ F:  drivers/iio/pressure/mprls0025pa*
>  HOTPLUG CONNECTOR FOR GE SUNH ADDONS
>  M:   Luca Ceresoli 
>  S:   Maintained
> +F:   drivers/misc/ge-sunh-connector.c
>  F:   Documentation/devicetree/bindings/connector/ge,sunh-addon-connector.yaml
>  
>  HP BIOSCFG DRIVER
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 4fb291f0bf7c..99ef2eccbbaa 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -574,6 +574,21 @@ config NSM
> To compile this driver as a module, choose M here.
> The module will be called nsm.
>  
> +config GE_SUNH_CONNECTOR
> + tristate "GE SUNH hotplug add-on connector"
> + depends on OF
> + select OF_OVERLAY
> + select FW_LOADER
> + select NVMEM
> + select DRM_HOTPLUG_BRIDGE

Can these be depends instead of select?  'select' causes dependencies
that are hard, if not almost impossible, to detect at times why
something is being enabled.

> + help
> +   Driver for the runtime hot-pluggable add-on connector on the GE SUNH
> +   device. This connector allows connecting and disconnecting an add-on
> +   to/from the main device to augment its features. Connection and
> +   disconnection can be done at runtime at any moment without
> +   notice. Different add-on models can be connected, and each has an 
> EEPROM
> +   with a model identifier at a fixed address.

Module name?


> +static void sunh_conn_reset(struct sunh_conn *conn, bool keep_reset)
> +{
> + dev_dbg(conn->dev, "reset\n");

ftrace is your friend.

> +static int sunh_conn_handle_event(struct sunh_conn *conn, bool plugged)
> +{
> + int err;
> +
> + if (plugged == conn->plugged)
> + return 0;
> +
> + dev_info(conn->dev, "%s\n", plugged ? "connected" : "disconnected");

Please remove debugging code from stuff you want to see merged.

Same for all dev_info() calls here, when drivers work properly, they are
quiet.

thanks,

greg k-h

[PATCH 5.15 47/80] drm/vmwgfx: Fix crtcs atomic check conditional

[Greg Kroah-Hartman]

5.15-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit a60ccade88f926e871a57176e86a34bbf0db0098 ]

The conditional was supposed to prevent enabling of a crtc state
without a set primary plane. Accidently it also prevented disabling
crtc state with a set primary plane. Neither is correct.

Fix the conditional and just driver-warn when a crtc state has been
enabled without a primary plane which will help debug broken userspace.

Fixes IGT's kms_atomic_interruptible and kms_atomic_transition tests.

Signed-off-by: Zack Rusin 
Fixes: 06ec41909e31 ("drm/vmwgfx: Add and connect CRTC helper functions")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.12+
Reviewed-by: Ian Forbes 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240412025511.78553-5-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 01d5a01af2594..e2a52b5de1733 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -537,6 +537,7 @@ int vmw_du_cursor_plane_atomic_check(struct drm_plane 
*plane,
 int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
 struct drm_atomic_state *state)
 {
+   struct vmw_private *vmw = vmw_priv(crtc->dev);
struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state,
 crtc);
struct vmw_display_unit *du = vmw_crtc_to_du(new_state->crtc);
@@ -544,9 +545,13 @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
bool has_primary = new_state->plane_mask &
   drm_plane_mask(crtc->primary);
 
-   /* We always want to have an active plane with an active CRTC */
-   if (has_primary != new_state->enable)
-   return -EINVAL;
+   /*
+* This is fine in general, but broken userspace might expect
+* some actual rendering so give a clue as why it's blank.
+*/
+   if (new_state->enable && !has_primary)
+   drm_dbg_driver(&vmw->drm,
+  "CRTC without a primary plane will be blank.\n");
 
 
if (new_state->connector_mask != connector_mask &&
-- 
2.43.0

[PATCH 5.15 65/71] drm/vmwgfx: Sort primary plane formats by order of preference

[Greg Kroah-Hartman]

5.15-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit d4c972bff3129a9dd4c22a3999fd8eba1a81531a upstream.

The table of primary plane formats wasn't sorted at all, leading to
applications picking our least desirable formats by defaults.

Sort the primary plane formats according to our order of preference.

Nice side-effect of this change is that it makes IGT's kms_atomic
plane-invalid-params pass because the test picks the first format
which for vmwgfx was DRM_FORMAT_XRGB1555 and uses fb's with odd sizes
which make Pixman, which IGT depends on assert due to the fact that our
16bpp formats aren't 32 bit aligned like Pixman requires all formats
to be.

Signed-off-by: Zack Rusin 
Fixes: 36cc79bc9077 ("drm/vmwgfx: Add universal plane support")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.12+
Acked-by: Pekka Paalanen 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240412025511.78553-6-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -246,10 +246,10 @@ struct vmw_framebuffer_bo {
 
 
 static const uint32_t __maybe_unused vmw_primary_plane_formats[] = {
-   DRM_FORMAT_XRGB1555,
-   DRM_FORMAT_RGB565,
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB1555,
 };
 
 static const uint32_t __maybe_unused vmw_cursor_plane_formats[] = {

[PATCH 6.1 129/141] drm/vmwgfx: Fix crtcs atomic check conditional

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a60ccade88f926e871a57176e86a34bbf0db0098 upstream.

The conditional was supposed to prevent enabling of a crtc state
without a set primary plane. Accidently it also prevented disabling
crtc state with a set primary plane. Neither is correct.

Fix the conditional and just driver-warn when a crtc state has been
enabled without a primary plane which will help debug broken userspace.

Fixes IGT's kms_atomic_interruptible and kms_atomic_transition tests.

Signed-off-by: Zack Rusin 
Fixes: 06ec41909e31 ("drm/vmwgfx: Add and connect CRTC helper functions")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.12+
Reviewed-by: Ian Forbes 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240412025511.78553-5-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -793,6 +793,7 @@ int vmw_du_cursor_plane_atomic_check(str
 int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
 struct drm_atomic_state *state)
 {
+   struct vmw_private *vmw = vmw_priv(crtc->dev);
struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state,
 crtc);
struct vmw_display_unit *du = vmw_crtc_to_du(new_state->crtc);
@@ -800,9 +801,13 @@ int vmw_du_crtc_atomic_check(struct drm_
bool has_primary = new_state->plane_mask &
   drm_plane_mask(crtc->primary);
 
-   /* We always want to have an active plane with an active CRTC */
-   if (has_primary != new_state->enable)
-   return -EINVAL;
+   /*
+* This is fine in general, but broken userspace might expect
+* some actual rendering so give a clue as why it's blank.
+*/
+   if (new_state->enable && !has_primary)
+   drm_dbg_driver(&vmw->drm,
+  "CRTC without a primary plane will be blank.\n");
 
 
if (new_state->connector_mask != connector_mask &&

[PATCH 6.1 128/141] drm/vmwgfx: Sort primary plane formats by order of preference

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit d4c972bff3129a9dd4c22a3999fd8eba1a81531a upstream.

The table of primary plane formats wasn't sorted at all, leading to
applications picking our least desirable formats by defaults.

Sort the primary plane formats according to our order of preference.

Nice side-effect of this change is that it makes IGT's kms_atomic
plane-invalid-params pass because the test picks the first format
which for vmwgfx was DRM_FORMAT_XRGB1555 and uses fb's with odd sizes
which make Pixman, which IGT depends on assert due to the fact that our
16bpp formats aren't 32 bit aligned like Pixman requires all formats
to be.

Signed-off-by: Zack Rusin 
Fixes: 36cc79bc9077 ("drm/vmwgfx: Add universal plane support")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.12+
Acked-by: Pekka Paalanen 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240412025511.78553-6-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -246,10 +246,10 @@ struct vmw_framebuffer_bo {
 
 
 static const uint32_t __maybe_unused vmw_primary_plane_formats[] = {
-   DRM_FORMAT_XRGB1555,
-   DRM_FORMAT_RGB565,
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB1555,
 };
 
 static const uint32_t __maybe_unused vmw_cursor_plane_formats[] = {

[PATCH 6.1 001/141] drm/vmwgfx: Enable DMA mappings with SEV

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 4c08f01934ab67d1d283d5cbaa52b923abcfe4cd ]

Enable DMA mappings in vmwgfx after TTM has been fixed in commit
3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")

This enables full guest-backed memory support and in particular allows
usage of screen targets as the presentation mechanism.

Signed-off-by: Zack Rusin 
Reported-by: Ye Li 
Tested-by: Ye Li 
Fixes: 3b0d6458c705 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is 
active")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.6+
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240408022802.358641-1-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 9d7a1b710f48f..53f63ad656a41 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -663,11 +663,12 @@ static int vmw_dma_select_mode(struct vmw_private 
*dev_priv)
[vmw_dma_map_populate] = "Caching DMA mappings.",
[vmw_dma_map_bind] = "Giving up DMA mappings early."};
 
-   /* TTM currently doesn't fully support SEV encryption. */
-   if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
-   return -EINVAL;
-
-   if (vmw_force_coherent)
+   /*
+* When running with SEV we always want dma mappings, because
+* otherwise ttm tt pool pages will bounce through swiotlb running
+* out of available space.
+*/
+   if (vmw_force_coherent || cc_platform_has(CC_ATTR_MEM_ENCRYPT))
dev_priv->map_mode = vmw_dma_alloc_coherent;
else if (vmw_restrict_iommu)
dev_priv->map_mode = vmw_dma_map_bind;
-- 
2.43.0

[PATCH 6.6 146/158] drm/vmwgfx: Fix crtcs atomic check conditional

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a60ccade88f926e871a57176e86a34bbf0db0098 upstream.

The conditional was supposed to prevent enabling of a crtc state
without a set primary plane. Accidently it also prevented disabling
crtc state with a set primary plane. Neither is correct.

Fix the conditional and just driver-warn when a crtc state has been
enabled without a primary plane which will help debug broken userspace.

Fixes IGT's kms_atomic_interruptible and kms_atomic_transition tests.

Signed-off-by: Zack Rusin 
Fixes: 06ec41909e31 ("drm/vmwgfx: Add and connect CRTC helper functions")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.12+
Reviewed-by: Ian Forbes 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240412025511.78553-5-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -926,6 +926,7 @@ int vmw_du_cursor_plane_atomic_check(str
 int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
 struct drm_atomic_state *state)
 {
+   struct vmw_private *vmw = vmw_priv(crtc->dev);
struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state,
 crtc);
struct vmw_display_unit *du = vmw_crtc_to_du(new_state->crtc);
@@ -933,9 +934,13 @@ int vmw_du_crtc_atomic_check(struct drm_
bool has_primary = new_state->plane_mask &
   drm_plane_mask(crtc->primary);
 
-   /* We always want to have an active plane with an active CRTC */
-   if (has_primary != new_state->enable)
-   return -EINVAL;
+   /*
+* This is fine in general, but broken userspace might expect
+* some actual rendering so give a clue as why it's blank.
+*/
+   if (new_state->enable && !has_primary)
+   drm_dbg_driver(&vmw->drm,
+  "CRTC without a primary plane will be blank.\n");
 
 
if (new_state->connector_mask != connector_mask &&

[PATCH 6.6 145/158] drm/vmwgfx: Sort primary plane formats by order of preference

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit d4c972bff3129a9dd4c22a3999fd8eba1a81531a upstream.

The table of primary plane formats wasn't sorted at all, leading to
applications picking our least desirable formats by defaults.

Sort the primary plane formats according to our order of preference.

Nice side-effect of this change is that it makes IGT's kms_atomic
plane-invalid-params pass because the test picks the first format
which for vmwgfx was DRM_FORMAT_XRGB1555 and uses fb's with odd sizes
which make Pixman, which IGT depends on assert due to the fact that our
16bpp formats aren't 32 bit aligned like Pixman requires all formats
to be.

Signed-off-by: Zack Rusin 
Fixes: 36cc79bc9077 ("drm/vmwgfx: Add universal plane support")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.12+
Acked-by: Pekka Paalanen 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240412025511.78553-6-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -243,10 +243,10 @@ struct vmw_framebuffer_bo {
 
 
 static const uint32_t __maybe_unused vmw_primary_plane_formats[] = {
-   DRM_FORMAT_XRGB1555,
-   DRM_FORMAT_RGB565,
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB1555,
 };
 
 static const uint32_t __maybe_unused vmw_cursor_plane_formats[] = {

[PATCH 6.8 147/158] drm/vmwgfx: Fix crtcs atomic check conditional

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit a60ccade88f926e871a57176e86a34bbf0db0098 upstream.

The conditional was supposed to prevent enabling of a crtc state
without a set primary plane. Accidently it also prevented disabling
crtc state with a set primary plane. Neither is correct.

Fix the conditional and just driver-warn when a crtc state has been
enabled without a primary plane which will help debug broken userspace.

Fixes IGT's kms_atomic_interruptible and kms_atomic_transition tests.

Signed-off-by: Zack Rusin 
Fixes: 06ec41909e31 ("drm/vmwgfx: Add and connect CRTC helper functions")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.12+
Reviewed-by: Ian Forbes 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240412025511.78553-5-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -932,6 +932,7 @@ int vmw_du_cursor_plane_atomic_check(str
 int vmw_du_crtc_atomic_check(struct drm_crtc *crtc,
 struct drm_atomic_state *state)
 {
+   struct vmw_private *vmw = vmw_priv(crtc->dev);
struct drm_crtc_state *new_state = drm_atomic_get_new_crtc_state(state,
 crtc);
struct vmw_display_unit *du = vmw_crtc_to_du(new_state->crtc);
@@ -939,9 +940,13 @@ int vmw_du_crtc_atomic_check(struct drm_
bool has_primary = new_state->plane_mask &
   drm_plane_mask(crtc->primary);
 
-   /* We always want to have an active plane with an active CRTC */
-   if (has_primary != new_state->enable)
-   return -EINVAL;
+   /*
+* This is fine in general, but broken userspace might expect
+* some actual rendering so give a clue as why it's blank.
+*/
+   if (new_state->enable && !has_primary)
+   drm_dbg_driver(&vmw->drm,
+  "CRTC without a primary plane will be blank.\n");
 
 
if (new_state->connector_mask != connector_mask &&

[PATCH 6.8 146/158] drm/vmwgfx: Sort primary plane formats by order of preference

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit d4c972bff3129a9dd4c22a3999fd8eba1a81531a upstream.

The table of primary plane formats wasn't sorted at all, leading to
applications picking our least desirable formats by defaults.

Sort the primary plane formats according to our order of preference.

Nice side-effect of this change is that it makes IGT's kms_atomic
plane-invalid-params pass because the test picks the first format
which for vmwgfx was DRM_FORMAT_XRGB1555 and uses fb's with odd sizes
which make Pixman, which IGT depends on assert due to the fact that our
16bpp formats aren't 32 bit aligned like Pixman requires all formats
to be.

Signed-off-by: Zack Rusin 
Fixes: 36cc79bc9077 ("drm/vmwgfx: Add universal plane support")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.12+
Acked-by: Pekka Paalanen 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240412025511.78553-6-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -243,10 +243,10 @@ struct vmw_framebuffer_bo {
 
 
 static const uint32_t __maybe_unused vmw_primary_plane_formats[] = {
-   DRM_FORMAT_XRGB1555,
-   DRM_FORMAT_RGB565,
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
+   DRM_FORMAT_RGB565,
+   DRM_FORMAT_XRGB1555,
 };
 
 static const uint32_t __maybe_unused vmw_cursor_plane_formats[] = {

Re: [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas

[Greg Kroah-Hartman]

On Fri, Apr 19, 2024 at 06:57:47PM +0200, Christian Gmeiner wrote:
> Am Di., 9. Apr. 2024 um 14:14 Uhr schrieb Greg Kroah-Hartman
> :
> >
> > On Tue, Apr 09, 2024 at 02:06:05PM +0200, Pascal FONTAIN wrote:
> > > From: Andrew Davis 
> > >
> > > This new export type exposes to userspace the SRAM area as a DMA-BUF
> > > Heap,
> > > this allows for allocations of DMA-BUFs that can be consumed by various
> > > DMA-BUF supporting devices.
> > >
> > > Signed-off-by: Andrew Davis 
> > > Tested-by: Pascal Fontain 
> >
> > When sending on a patch from someone else, you too must sign off on it
> > as per our documenation.  Please read it and understand what you are
> > agreeing to when you do that for a new version please.
> >
> > > ---
> > >  drivers/misc/Kconfig |   7 +
> > >  drivers/misc/Makefile|   1 +
> > >  drivers/misc/sram-dma-heap.c | 246 +++
> > >  drivers/misc/sram.c  |   6 +
> > >  drivers/misc/sram.h  |  16 +++
> > >  5 files changed, 276 insertions(+)
> > >  create mode 100644 drivers/misc/sram-dma-heap.c
> > >
> > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > index 9e4ad4d61f06..e6674e913168 100644
> > > --- a/drivers/misc/Kconfig
> > > +++ b/drivers/misc/Kconfig
> > > @@ -448,6 +448,13 @@ config SRAM
> > >  config SRAM_EXEC
> > >   bool
> > >
> > > +config SRAM_DMA_HEAP
> > > + bool "Export on-chip SRAM pools using DMA-Heaps"
> > > + depends on DMABUF_HEAPS && SRAM
> > > + help
> > > +   This driver allows the export of on-chip SRAM marked as both pool
> > > +   and exportable to userspace using the DMA-Heaps interface.
> >
> > What will use this in userspace?
> >
> 
> I could imagine a way it might be used.

This implies it is not needed because no one actually has actually used
it for anything, so why make this change?

> Imagine a SoC like TI's AM64x series, where some cores (A53) run Linux
> and others (R5F) are managed by remoteproc to
> execute a RTOS. When it comes to efficiently exchanging large data
> sets, the conventional method involves using rpmsg,
> which has limitations due to message size and could potentially slow
> down data transfer. However, an alternative
> approach could be to allocate a sizable chunk of SRAM memory in
> userspace. By utilizing memcpy() to copy data into
> this memory, followed by a single rpmsg signal to notify the RTOS that
> the data is ready, we can leverage the faster access
> speed of SRAM compared to DDR from the remoteproc.

Why is virtio not used instead?

thanks,

greg k-h

Re: [PATCH] component: Support masters with no subcomponents

[Greg Kroah-Hartman]

On Wed, Apr 17, 2024 at 11:12:09AM +0200, Herman van Hazendonk wrote:
> This happens in the MSM DRM driver when it is used
> without any subcomponents, which is a special corner
> case.
> 
> If the MDP4 is used with nothing but the LVDS display,
> we get this problem that no components are found since
> the LVDS is part of the MDP4 itself.
> 
> We cannot use a NULL match, so create a dummy match
> with no components for this case so the driver will
> still probe nicely without adding a secondary
> complicated probe() path to the MSM DRM driver.
> 
> Signed-off-by: Linus Walleij 
> Signed-off-by: Herman van Hazendonk 
> ---
> This happens in the MSM DRM driver when it is used
> without any subcomponents, which is a special corner
> case.
> 
> If the MDP4 is used with nothing but the LVDS display,
> we get this problem that no components are found since
> the LVDS is part of the MDP4 itself.
> 
> We cannot use a NULL match, so create a dummy match
> with no components for this case so the driver will
> still probe nicely without adding a secondary
> complicated probe() path to the MSM DRM driver.

Why is the text duplicated here twice?

Also, why are you adding complexity to the core for something that has
not been an issue for any other device?  Shouldn't the driver need to
handle this instead if it wishes to use the component code?  Will this
change affect any other in-tree user?

thanks,

greg k-h

Re: [PATCH] staging: fbtft Removed redundant parentheses

[Greg Kroah-Hartman]

b33 100644
> --- a/drivers/staging/fbtft/fb_tinylcd.c
> +++ b/drivers/staging/fbtft/fb_tinylcd.c
> @@ -38,7 +38,7 @@ static int init_display(struct fbtft_par *par)
>   write_reg(par, 0xE5, 0x00);
>   write_reg(par, 0xF0, 0x36, 0xA5, 0x53);
>   write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
> -0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
> +   0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
>   write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
>   write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
>   udelay(250);
> diff --git a/drivers/staging/fbtft/fbtft-bus.c
> b/drivers/staging/fbtft/fbtft-bus.c
> index 3d422bc11641..02d7dbd38678 100644
> --- a/drivers/staging/fbtft/fbtft-bus.c
> +++ b/drivers/staging/fbtft/fbtft-bus.c
> @@ -62,9 +62,9 @@
> out:\
>  }
> \
>  EXPORT_SYMBOL(func);
>  
> -define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
> +define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8,)
>  define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16,
> cpu_to_be16)
> -define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
> +define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16,)
>  
>  void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
>  {
> @@ -85,7 +85,7 @@ void fbtft_write_reg8_bus9(struct fbtft_par *par, int
> len, ...)
>   if (len <= 0)
>   return;
>  
> - if (par->spi && (par->spi->bits_per_word == 8)) {
> + if (par->spi && par->spi->bits_per_word == 8) {
>   /* we're emulating 9-bit, pad start of buffer with no-
> ops
>* (assuming here that zero is a no-op)
>*/
> diff --git a/drivers/staging/fbtft/fbtft-core.c
> b/drivers/staging/fbtft/fbtft-core.c
> index 38845f23023f..98ffca49df81 100644
> --- a/drivers/staging/fbtft/fbtft-core.c
> +++ b/drivers/staging/fbtft/fbtft-core.c
> @@ -216,8 +216,6 @@ static void fbtft_reset(struct fbtft_par *par)
>   if (!par->gpio.reset)
>   return;
>  
> - fbtft_par_dbg(DEBUG_RESET, par, "%s()\n", __func__);
> -
>   gpiod_set_value_cansleep(par->gpio.reset, 1);
>   usleep_range(20, 40);
>   gpiod_set_value_cansleep(par->gpio.reset, 0);
> @@ -667,7 +665,7 @@ struct fb_info *fbtft_framebuffer_alloc(struct
> fbtft_display *display,
>   txbuflen = 0;
>  
>  #ifdef __LITTLE_ENDIAN
> - if ((!txbuflen) && (bpp > 8))
> + if (!txbuflen && bpp > 8)
>   txbuflen = PAGE_SIZE; /* need buffer for byteswapping
> */
>  #endif
>  
> @@ -1053,8 +1051,6 @@ static int fbtft_verify_gpios(struct fbtft_par
> *par)
>   struct fbtft_platform_data *pdata = par->pdata;
>   int i;
>  
> - fbtft_par_dbg(DEBUG_VERIFY_GPIOS, par, "%s()\n", __func__);
> -
>   if (pdata->display.buswidth != 9 &&  par->startbyte == 0 &&
>   !par->gpio.dc) {
>   dev_err(par->info->device,
> @@ -1159,7 +1155,6 @@ int fbtft_probe_common(struct fbtft_display
> *display,
>   dev = &pdev->dev;
>  
>   if (unlikely(display->debug & DEBUG_DRIVER_INIT_FUNCTIONS))
> - dev_info(dev, "%s()\n", __func__);
>  
>   pdata = dev->platform_data;
>   if (!pdata) {
> -- 
> 2.34.1
> 
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- Your patch contains warnings and/or errors noticed by the
  scripts/checkpatch.pl tool.

- Your patch is malformed (tabs converted to spaces, linewrapped, etc.)
  and can not be applied.  Please read the file,
  Documentation/process/email-clients.rst in order to fix this.

- Your patch was attached, please place it inline so that it can be
  applied directly from the email message itself.

- Your patch did many different things all at once, making it difficult
  to review.  All Linux kernel patches need to only do one thing at a
  time.  If you need to do multiple things (such as clean up all coding
  style issues in a file/driver), do it in a sequence of patches, each
  one doing only one thing.  This wi

[PATCH 6.1 48/69] drm/ast: Fix soft lockup

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Jammy Huang 

commit bc004f5038220b1891ef4107134ccae44be55109 upstream.

There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx, checked in
this API is a scratch register actually controlled by a MCU, named
DPMCU, in BMC.

These scratch registers are protected by scu-lock. If suc-lock is not
off, DPMCU can not update these registers and then host will have soft
lockup due to never updated status.

DPMCU is used to control DP and relative registers to handshake with
host's VGA driver. Even the most time-consuming task, DP's link
training, is less than 100ms. 200ms should be enough.

Signed-off-by: Jammy Huang 
Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory 
Display-Port")
Reviewed-by: Jocelyn Falempe 
Reviewed-by: Thomas Zimmermann 
Signed-off-by: Thomas Zimmermann 
Cc: KuoHsiang Chou 
Cc: Thomas Zimmermann 
Cc: Dave Airlie 
Cc: Jocelyn Falempe 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.19+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240403090246.1495487-1-jammy_hu...@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/ast/ast_dp.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -190,6 +190,7 @@ void ast_dp_set_on_off(struct drm_device
 {
struct ast_private *ast = to_ast_private(dev);
u8 video_on_off = on;
+   u32 i = 0;
 
// Video On/Off
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE3, (u8) 
~AST_DP_VIDEO_ENABLE, on);
@@ -202,6 +203,8 @@ void ast_dp_set_on_off(struct drm_device
ASTDP_MIRROR_VIDEO_ENABLE) != 
video_on_off) {
// wait 1 ms
mdelay(1);
+   if (++i > 200)
+   break;
}
}
 }

[PATCH 6.6 091/122] drm/ast: Fix soft lockup

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Jammy Huang 

commit bc004f5038220b1891ef4107134ccae44be55109 upstream.

There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx, checked in
this API is a scratch register actually controlled by a MCU, named
DPMCU, in BMC.

These scratch registers are protected by scu-lock. If suc-lock is not
off, DPMCU can not update these registers and then host will have soft
lockup due to never updated status.

DPMCU is used to control DP and relative registers to handshake with
host's VGA driver. Even the most time-consuming task, DP's link
training, is less than 100ms. 200ms should be enough.

Signed-off-by: Jammy Huang 
Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory 
Display-Port")
Reviewed-by: Jocelyn Falempe 
Reviewed-by: Thomas Zimmermann 
Signed-off-by: Thomas Zimmermann 
Cc: KuoHsiang Chou 
Cc: Thomas Zimmermann 
Cc: Dave Airlie 
Cc: Jocelyn Falempe 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.19+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240403090246.1495487-1-jammy_hu...@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/ast/ast_dp.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -180,6 +180,7 @@ void ast_dp_set_on_off(struct drm_device
 {
struct ast_device *ast = to_ast_device(dev);
u8 video_on_off = on;
+   u32 i = 0;
 
// Video On/Off
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xE3, (u8) 
~AST_DP_VIDEO_ENABLE, on);
@@ -192,6 +193,8 @@ void ast_dp_set_on_off(struct drm_device
ASTDP_MIRROR_VIDEO_ENABLE) != 
video_on_off) {
// wait 1 ms
mdelay(1);
+   if (++i > 200)
+   break;
}
}
 }

[PATCH 6.6 088/122] drm/vmwgfx: Enable DMA mappings with SEV

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit 4c08f01934ab67d1d283d5cbaa52b923abcfe4cd upstream.

Enable DMA mappings in vmwgfx after TTM has been fixed in commit
3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")

This enables full guest-backed memory support and in particular allows
usage of screen targets as the presentation mechanism.

Signed-off-by: Zack Rusin 
Reported-by: Ye Li 
Tested-by: Ye Li 
Fixes: 3b0d6458c705 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is 
active")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.6+
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240408022802.358641-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -666,11 +666,12 @@ static int vmw_dma_select_mode(struct vm
[vmw_dma_map_populate] = "Caching DMA mappings.",
[vmw_dma_map_bind] = "Giving up DMA mappings early."};
 
-   /* TTM currently doesn't fully support SEV encryption. */
-   if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
-   return -EINVAL;
-
-   if (vmw_force_coherent)
+   /*
+* When running with SEV we always want dma mappings, because
+* otherwise ttm tt pool pages will bounce through swiotlb running
+* out of available space.
+*/
+   if (vmw_force_coherent || cc_platform_has(CC_ATTR_MEM_ENCRYPT))
dev_priv->map_mode = vmw_dma_alloc_coherent;
else if (vmw_restrict_iommu)
dev_priv->map_mode = vmw_dma_map_bind;

[PATCH 6.8 126/172] drm/ast: Fix soft lockup

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Jammy Huang 

commit bc004f5038220b1891ef4107134ccae44be55109 upstream.

There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx, checked in
this API is a scratch register actually controlled by a MCU, named
DPMCU, in BMC.

These scratch registers are protected by scu-lock. If suc-lock is not
off, DPMCU can not update these registers and then host will have soft
lockup due to never updated status.

DPMCU is used to control DP and relative registers to handshake with
host's VGA driver. Even the most time-consuming task, DP's link
training, is less than 100ms. 200ms should be enough.

Signed-off-by: Jammy Huang 
Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory 
Display-Port")
Reviewed-by: Jocelyn Falempe 
Reviewed-by: Thomas Zimmermann 
Signed-off-by: Thomas Zimmermann 
Cc: KuoHsiang Chou 
Cc: Thomas Zimmermann 
Cc: Dave Airlie 
Cc: Jocelyn Falempe 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.19+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240403090246.1495487-1-jammy_hu...@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/ast/ast_dp.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -180,6 +180,7 @@ void ast_dp_set_on_off(struct drm_device
 {
struct ast_device *ast = to_ast_device(dev);
u8 video_on_off = on;
+   u32 i = 0;
 
// Video On/Off
ast_set_index_reg_mask(ast, AST_IO_VGACRI, 0xE3, (u8) 
~AST_DP_VIDEO_ENABLE, on);
@@ -192,6 +193,8 @@ void ast_dp_set_on_off(struct drm_device
ASTDP_MIRROR_VIDEO_ENABLE) != 
video_on_off) {
// wait 1 ms
mdelay(1);
+   if (++i > 200)
+   break;
}
}
 }

[PATCH 6.8 123/172] drm/vmwgfx: Enable DMA mappings with SEV

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

commit 4c08f01934ab67d1d283d5cbaa52b923abcfe4cd upstream.

Enable DMA mappings in vmwgfx after TTM has been fixed in commit
3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem")

This enables full guest-backed memory support and in particular allows
usage of screen targets as the presentation mechanism.

Signed-off-by: Zack Rusin 
Reported-by: Ye Li 
Tested-by: Ye Li 
Fixes: 3b0d6458c705 ("drm/vmwgfx: Refuse DMA operation when SEV encryption is 
active")
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.6+
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240408022802.358641-1-zack.ru...@broadcom.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -666,11 +666,12 @@ static int vmw_dma_select_mode(struct vm
[vmw_dma_map_populate] = "Caching DMA mappings.",
[vmw_dma_map_bind] = "Giving up DMA mappings early."};
 
-   /* TTM currently doesn't fully support SEV encryption. */
-   if (cc_platform_has(CC_ATTR_MEM_ENCRYPT))
-   return -EINVAL;
-
-   if (vmw_force_coherent)
+   /*
+* When running with SEV we always want dma mappings, because
+* otherwise ttm tt pool pages will bounce through swiotlb running
+* out of available space.
+*/
+   if (vmw_force_coherent || cc_platform_has(CC_ATTR_MEM_ENCRYPT))
dev_priv->map_mode = vmw_dma_alloc_coherent;
else if (vmw_restrict_iommu)
dev_priv->map_mode = vmw_dma_map_bind;

Re: [PATCH 4.19 000/175] 4.19.312-rc1 review

[Greg Kroah-Hartman]

On Thu, Apr 11, 2024 at 07:50:57PM +0530, Naresh Kamboju wrote:
> On Thu, 11 Apr 2024 at 15:30, Greg Kroah-Hartman
>  wrote:
> >
> > This is the start of the stable review cycle for the 4.19.312 release.
> > There are 175 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat, 13 Apr 2024 09:53:55 +.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.312-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.19.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> 
> The arm imx_v6_v7_defconfig build failed with gcc-12 and clang on Linux
> stable-rc linux-4.19.y.
> 
> Regressions:
>  - arm
> * gcc-12-imx_v6_v7_defconfig - failed
> 
> Reported-by: Linux Kernel Functional Testing 
> 
> Build log:
> 
> drivers/gpu/drm/imx/parallel-display.c: In function
> 'imx_pd_bridge_atomic_check':
> drivers/gpu/drm/imx/parallel-display.c:222:23: error: implicit
> declaration of function 'drm_bridge_get_next_bridge'
> [-Werror=implicit-function-declaration]
>   222 | next_bridge = drm_bridge_get_next_bridge(bridge);
>   |   ^~
> 
> 
> Links:
>  - 
> https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.311-176-gf0cf5f6110a7/testrun/23411280/suite/build/test/gcc-12-imx_v6_v7_defconfig/details/
>  - 
> https://storage.tuxsuite.com/public/linaro/lkft/builds/2ex1v6eevudbi33g4ozA7hJ4fvs/

Offending commit now dropped, thanks!

greg k-h

[PATCH 5.10 017/294] drm/vmwgfx: Fix possible null pointer derefence with invalid contexts

[Greg Kroah-Hartman]

5.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 517621b7060096e48e42f545fa6646fc00252eac ]

vmw_context_cotable can return either an error or a null pointer and its
usage sometimes went unchecked. Subsequent code would then try to access
either a null pointer or an error value.

The invalid dereferences were only possible with malformed userspace
apps which never properly initialized the rendering contexts.

Check the results of vmw_context_cotable to fix the invalid derefs.

Thanks:
ziming zhang(@ezrak1e) from Ant Group Light-Year Security Lab
who was the first person to discover it.
Niels De Graef who reported it and helped to track down the poc.

Fixes: 9c079b8ce8bf ("drm/vmwgfx: Adapt execbuf to the new validation api")
Cc:  # v4.20+
Reported-by: Niels De Graef  
Signed-off-by: Zack Rusin 
Cc: Martin Krastev 
Cc: Maaz Mombasawala 
Cc: Ian Forbes 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240110200305.94086-1-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 831291b5d1a03..616f6cb622783 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -467,7 +467,7 @@ static int vmw_resource_context_res_add(struct vmw_private 
*dev_priv,
vmw_res_type(ctx) == vmw_res_dx_context) {
for (i = 0; i < cotable_max; ++i) {
res = vmw_context_cotable(ctx, i);
-   if (IS_ERR(res))
+   if (IS_ERR_OR_NULL(res))
continue;
 
ret = vmw_execbuf_res_noctx_val_add(sw_context, res,
@@ -1272,6 +1272,8 @@ static int vmw_cmd_dx_define_query(struct vmw_private 
*dev_priv,
return -EINVAL;
 
cotable_res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXQUERY);
+   if (IS_ERR_OR_NULL(cotable_res))
+   return cotable_res ? PTR_ERR(cotable_res) : -EINVAL;
ret = vmw_cotable_notify(cotable_res, cmd->body.queryId);
 
return ret;
@@ -2450,6 +2452,8 @@ static int vmw_cmd_dx_view_define(struct vmw_private 
*dev_priv,
return ret;
 
res = vmw_context_cotable(ctx_node->ctx, vmw_view_cotables[view_type]);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->defined_id);
if (unlikely(ret != 0))
return ret;
@@ -2535,8 +2539,8 @@ static int vmw_cmd_dx_so_define(struct vmw_private 
*dev_priv,
 
so_type = vmw_so_cmd_to_type(header->id);
res = vmw_context_cotable(ctx_node->ctx, vmw_so_cotables[so_type]);
-   if (IS_ERR(res))
-   return PTR_ERR(res);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
cmd = container_of(header, typeof(*cmd), header);
ret = vmw_cotable_notify(res, cmd->defined_id);
 
@@ -2655,6 +2659,8 @@ static int vmw_cmd_dx_define_shader(struct vmw_private 
*dev_priv,
return -EINVAL;
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXSHADER);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.shaderId);
if (ret)
return ret;
@@ -2976,6 +2982,8 @@ static int vmw_cmd_dx_define_streamoutput(struct 
vmw_private *dev_priv,
}
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_STREAMOUTPUT);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.soid);
if (ret)
return ret;
-- 
2.43.0

[PATCH 5.10 015/294] drm/vmwgfx/vmwgfx_cmdbuf_res: Remove unused variable ret

[Greg Kroah-Hartman]

5.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Lee Jones 

[ Upstream commit 43ebfe61c3928573a5ef8d80c2f5300aa5c904c0 ]

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c: In function 
‘vmw_cmdbuf_res_revert’:
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:162:6: warning: variable ‘ret’ set 
but not used [-Wunused-but-set-variable]

Cc: VMware Graphics 
Cc: Roland Scheidegger 
Cc: Zack Rusin 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
Signed-off-by: Zack Rusin 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-40-lee.jo...@linaro.org
Stable-dep-of: 517621b70600 ("drm/vmwgfx: Fix possible null pointer derefence 
with invalid contexts")
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
index 44d858ce4ce7f..47b92d0c898a7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
@@ -160,7 +160,6 @@ void vmw_cmdbuf_res_commit(struct list_head *list)
 void vmw_cmdbuf_res_revert(struct list_head *list)
 {
struct vmw_cmdbuf_res *entry, *next;
-   int ret;
 
list_for_each_entry_safe(entry, next, list, head) {
switch (entry->state) {
@@ -168,8 +167,7 @@ void vmw_cmdbuf_res_revert(struct list_head *list)
vmw_cmdbuf_res_free(entry->man, entry);
break;
case VMW_CMDBUF_RES_DEL:
-   ret = drm_ht_insert_item(&entry->man->resources,
-&entry->hash);
+   drm_ht_insert_item(&entry->man->resources, 
&entry->hash);
list_del(&entry->head);
list_add_tail(&entry->head, &entry->man->list);
entry->state = VMW_CMDBUF_RES_COMMITTED;
-- 
2.43.0

[PATCH 4.19 109/175] drm/imx: parallel-display: Remove bus flags check in imx_pd_bridge_atomic_check()

[Greg Kroah-Hartman]

4.19-stable review patch.  If anyone has any objections, please let me know.

--

From: Christoph Niedermaier 

commit 6061806a863e8b65b109eb06a280041cc7525442 upstream.

If display timings were read from the devicetree using
of_get_display_timing() and pixelclk-active is defined
there, the flag DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE is
automatically generated. Through the function
drm_bus_flags_from_videomode() e.g. called in the
panel-simple driver this flag got into the bus flags,
but then in imx_pd_bridge_atomic_check() the bus flag
check failed and will not initialize the display. The
original commit fe141cedc433 does not explain why this
check was introduced. So remove the bus flags check,
because it stops the initialization of the display with
valid bus flags.

Fixes: fe141cedc433 ("drm/imx: pd: Use bus format/flags provided by the bridge 
when available")
Signed-off-by: Christoph Niedermaier 
Cc: Marek Vasut 
Cc: Boris Brezillon 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Pengutronix Kernel Team 
Cc: Fabio Estevam 
Cc: NXP Linux Team 
Cc: linux-arm-ker...@lists.infradead.org
To: dri-devel@lists.freedesktop.org
Tested-by: Max Krummenacher 
Acked-by: Boris Brezillon 
Signed-off-by: Marek Vasut 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20220201113643.4638-1-cniederma...@dh-electronics.com
Signed-off-by: Maarten Lankhorst 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/imx/parallel-display.c |8 
 1 file changed, 8 deletions(-)

--- a/drivers/gpu/drm/imx/parallel-display.c
+++ b/drivers/gpu/drm/imx/parallel-display.c
@@ -235,14 +235,6 @@ static int imx_pd_bridge_atomic_check(st
if (!imx_pd_format_supported(bus_fmt))
return -EINVAL;
 
-   if (bus_flags &
-   ~(DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_DE_HIGH |
- DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE |
- DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)) {
-   dev_warn(imxpd->dev, "invalid bus_flags (%x)\n", bus_flags);
-   return -EINVAL;
-   }
-
bridge_state->output_bus_cfg.flags = bus_flags;
bridge_state->input_bus_cfg.flags = bus_flags;
imx_crtc_state->bus_flags = bus_flags;

Re: [PATCH v3 2/2] misc: sram: Add DMA-BUF Heap exporting of SRAM areas

[Greg Kroah-Hartman]

On Tue, Apr 09, 2024 at 02:06:05PM +0200, Pascal FONTAIN wrote:
> From: Andrew Davis 
> 
> This new export type exposes to userspace the SRAM area as a DMA-BUF
> Heap,
> this allows for allocations of DMA-BUFs that can be consumed by various
> DMA-BUF supporting devices.
> 
> Signed-off-by: Andrew Davis 
> Tested-by: Pascal Fontain 

When sending on a patch from someone else, you too must sign off on it
as per our documenation.  Please read it and understand what you are
agreeing to when you do that for a new version please.

> ---
>  drivers/misc/Kconfig |   7 +
>  drivers/misc/Makefile|   1 +
>  drivers/misc/sram-dma-heap.c | 246 +++
>  drivers/misc/sram.c  |   6 +
>  drivers/misc/sram.h  |  16 +++
>  5 files changed, 276 insertions(+)
>  create mode 100644 drivers/misc/sram-dma-heap.c
> 
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 9e4ad4d61f06..e6674e913168 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -448,6 +448,13 @@ config SRAM
>  config SRAM_EXEC
>   bool
>  
> +config SRAM_DMA_HEAP
> + bool "Export on-chip SRAM pools using DMA-Heaps"
> + depends on DMABUF_HEAPS && SRAM
> + help
> +   This driver allows the export of on-chip SRAM marked as both pool
> +   and exportable to userspace using the DMA-Heaps interface.

What will use this in userspace?

thanks,

greg k-h

[PATCH 5.15 016/690] drm/vmwgfx: Fix possible null pointer derefence with invalid contexts

[Greg Kroah-Hartman]

5.15-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 517621b7060096e48e42f545fa6646fc00252eac ]

vmw_context_cotable can return either an error or a null pointer and its
usage sometimes went unchecked. Subsequent code would then try to access
either a null pointer or an error value.

The invalid dereferences were only possible with malformed userspace
apps which never properly initialized the rendering contexts.

Check the results of vmw_context_cotable to fix the invalid derefs.

Thanks:
ziming zhang(@ezrak1e) from Ant Group Light-Year Security Lab
who was the first person to discover it.
Niels De Graef who reported it and helped to track down the poc.

Fixes: 9c079b8ce8bf ("drm/vmwgfx: Adapt execbuf to the new validation api")
Cc:  # v4.20+
Reported-by: Niels De Graef  
Signed-off-by: Zack Rusin 
Cc: Martin Krastev 
Cc: Maaz Mombasawala 
Cc: Ian Forbes 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240110200305.94086-1-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index b91f8d17404d6..21134c7f18382 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -472,7 +472,7 @@ static int vmw_resource_context_res_add(struct vmw_private 
*dev_priv,
vmw_res_type(ctx) == vmw_res_dx_context) {
for (i = 0; i < cotable_max; ++i) {
res = vmw_context_cotable(ctx, i);
-   if (IS_ERR(res))
+   if (IS_ERR_OR_NULL(res))
continue;
 
ret = vmw_execbuf_res_noctx_val_add(sw_context, res,
@@ -1277,6 +1277,8 @@ static int vmw_cmd_dx_define_query(struct vmw_private 
*dev_priv,
return -EINVAL;
 
cotable_res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXQUERY);
+   if (IS_ERR_OR_NULL(cotable_res))
+   return cotable_res ? PTR_ERR(cotable_res) : -EINVAL;
ret = vmw_cotable_notify(cotable_res, cmd->body.queryId);
 
return ret;
@@ -2455,6 +2457,8 @@ static int vmw_cmd_dx_view_define(struct vmw_private 
*dev_priv,
return ret;
 
res = vmw_context_cotable(ctx_node->ctx, vmw_view_cotables[view_type]);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->defined_id);
if (unlikely(ret != 0))
return ret;
@@ -2540,8 +2544,8 @@ static int vmw_cmd_dx_so_define(struct vmw_private 
*dev_priv,
 
so_type = vmw_so_cmd_to_type(header->id);
res = vmw_context_cotable(ctx_node->ctx, vmw_so_cotables[so_type]);
-   if (IS_ERR(res))
-   return PTR_ERR(res);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
cmd = container_of(header, typeof(*cmd), header);
ret = vmw_cotable_notify(res, cmd->defined_id);
 
@@ -2660,6 +2664,8 @@ static int vmw_cmd_dx_define_shader(struct vmw_private 
*dev_priv,
return -EINVAL;
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXSHADER);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.shaderId);
if (ret)
return ret;
@@ -2981,6 +2987,8 @@ static int vmw_cmd_dx_define_streamoutput(struct 
vmw_private *dev_priv,
}
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_STREAMOUTPUT);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.soid);
if (ret)
return ret;
-- 
2.43.0

[PATCH 6.1 017/272] drm/vmwgfx: Fix possible null pointer derefence with invalid contexts

[Greg Kroah-Hartman]

6.1-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 517621b7060096e48e42f545fa6646fc00252eac ]

vmw_context_cotable can return either an error or a null pointer and its
usage sometimes went unchecked. Subsequent code would then try to access
either a null pointer or an error value.

The invalid dereferences were only possible with malformed userspace
apps which never properly initialized the rendering contexts.

Check the results of vmw_context_cotable to fix the invalid derefs.

Thanks:
ziming zhang(@ezrak1e) from Ant Group Light-Year Security Lab
who was the first person to discover it.
Niels De Graef who reported it and helped to track down the poc.

Fixes: 9c079b8ce8bf ("drm/vmwgfx: Adapt execbuf to the new validation api")
Cc:  # v4.20+
Reported-by: Niels De Graef  
Signed-off-by: Zack Rusin 
Cc: Martin Krastev 
Cc: Maaz Mombasawala 
Cc: Ian Forbes 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240110200305.94086-1-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index bc7f02e4ecebb..2f7ac91149fc0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -447,7 +447,7 @@ static int vmw_resource_context_res_add(struct vmw_private 
*dev_priv,
vmw_res_type(ctx) == vmw_res_dx_context) {
for (i = 0; i < cotable_max; ++i) {
res = vmw_context_cotable(ctx, i);
-   if (IS_ERR(res))
+   if (IS_ERR_OR_NULL(res))
continue;
 
ret = vmw_execbuf_res_val_add(sw_context, res,
@@ -1259,6 +1259,8 @@ static int vmw_cmd_dx_define_query(struct vmw_private 
*dev_priv,
return -EINVAL;
 
cotable_res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXQUERY);
+   if (IS_ERR_OR_NULL(cotable_res))
+   return cotable_res ? PTR_ERR(cotable_res) : -EINVAL;
ret = vmw_cotable_notify(cotable_res, cmd->body.queryId);
 
return ret;
@@ -2477,6 +2479,8 @@ static int vmw_cmd_dx_view_define(struct vmw_private 
*dev_priv,
return ret;
 
res = vmw_context_cotable(ctx_node->ctx, vmw_view_cotables[view_type]);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->defined_id);
if (unlikely(ret != 0))
return ret;
@@ -2562,8 +2566,8 @@ static int vmw_cmd_dx_so_define(struct vmw_private 
*dev_priv,
 
so_type = vmw_so_cmd_to_type(header->id);
res = vmw_context_cotable(ctx_node->ctx, vmw_so_cotables[so_type]);
-   if (IS_ERR(res))
-   return PTR_ERR(res);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
cmd = container_of(header, typeof(*cmd), header);
ret = vmw_cotable_notify(res, cmd->defined_id);
 
@@ -2682,6 +2686,8 @@ static int vmw_cmd_dx_define_shader(struct vmw_private 
*dev_priv,
return -EINVAL;
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXSHADER);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.shaderId);
if (ret)
return ret;
@@ -3003,6 +3009,8 @@ static int vmw_cmd_dx_define_streamoutput(struct 
vmw_private *dev_priv,
}
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_STREAMOUTPUT);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.soid);
if (ret)
return ret;
-- 
2.43.0

[PATCH 6.6 189/396] drm/ttm: Make sure the mapped tt pages are decrypted when needed

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 71ce046327cfd3aef3f93d1c44e091395eb03f8f ]

Some drivers require the mapped tt pages to be decrypted. In an ideal
world this would have been handled by the dma layer, but the TTM page
fault handling would have to be rewritten to able to do that.

A side-effect of the TTM page fault handling is using a dma allocation
per order (via ttm_pool_alloc_page) which makes it impossible to just
trivially use dma_mmap_attrs. As a result ttm has to be very careful
about trying to make its pgprot for the mapped tt pages match what
the dma layer thinks it is. At the ttm layer it's possible to
deduce the requirement to have tt pages decrypted by checking
whether coherent dma allocations have been requested and the system
is running with confidential computing technologies.

This approach isn't ideal but keeping TTM matching DMAs expectations
for the page properties is in general fragile, unfortunately proper
fix would require a rewrite of TTM's page fault handling.

Fixes vmwgfx with SEV enabled.

v2: Explicitly include cc_platform.h
v3: Use CC_ATTR_GUEST_MEM_ENCRYPT instead of CC_ATTR_MEM_ENCRYPT to
limit the scope to guests and log when memory decryption is enabled.

Signed-off-by: Zack Rusin 
Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based 
iomem")
Reviewed-by: Thomas Hellström 
Acked-by: Christian König 
Cc: Huang Rui 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v5.14+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230926040359.3040017-1-z...@kde.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 13 +++--
 drivers/gpu/drm/ttm/ttm_tt.c  | 13 +
 include/drm/ttm/ttm_tt.h  |  9 -
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index fd9fd3d15101c..0b3f4267130c4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -294,7 +294,13 @@ pgprot_t ttm_io_prot(struct ttm_buffer_object *bo, struct 
ttm_resource *res,
enum ttm_caching caching;
 
man = ttm_manager_type(bo->bdev, res->mem_type);
-   caching = man->use_tt ? bo->ttm->caching : res->bus.caching;
+   if (man->use_tt) {
+   caching = bo->ttm->caching;
+   if (bo->ttm->page_flags & TTM_TT_FLAG_DECRYPTED)
+   tmp = pgprot_decrypted(tmp);
+   } else  {
+   caching = res->bus.caching;
+   }
 
return ttm_prot_from_caching(caching, tmp);
 }
@@ -337,6 +343,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
.no_wait_gpu = false
};
struct ttm_tt *ttm = bo->ttm;
+   struct ttm_resource_manager *man =
+   ttm_manager_type(bo->bdev, bo->resource->mem_type);
pgprot_t prot;
int ret;
 
@@ -346,7 +354,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
if (ret)
return ret;
 
-   if (num_pages == 1 && ttm->caching == ttm_cached) {
+   if (num_pages == 1 && ttm->caching == ttm_cached &&
+   !(man->use_tt && (ttm->page_flags & TTM_TT_FLAG_DECRYPTED))) {
/*
 * We're mapping a single page, and the desired
 * page protection is consistent with the bo.
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index e0a77671edd6c..43eaffa7faae3 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -31,11 +31,14 @@
 
 #define pr_fmt(fmt) "[TTM] " fmt
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -60,6 +63,7 @@ static atomic_long_t ttm_dma32_pages_allocated;
 int ttm_tt_create(struct ttm_buffer_object *bo, bool zero_alloc)
 {
struct ttm_device *bdev = bo->bdev;
+   struct drm_device *ddev = bo->base.dev;
uint32_t page_flags = 0;
 
dma_resv_assert_held(bo->base.resv);
@@ -81,6 +85,15 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool 
zero_alloc)
pr_err("Illegal buffer object type\n");
return -EINVAL;
}
+   /*
+* When using dma_alloc_coherent with memory encryption the
+* mapped TT pages need to be decrypted or otherwise the drivers
+* will end up sending encrypted mem to the gpu.
+*/
+   if (bdev->pool.use_dma_alloc && 
cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
+   page_flags |= TTM_TT_FLAG_DECRYPTED;
+   drm_info(ddev, "TT memory decryption enabled.");
+   }
 
bo->ttm = bdev->funcs->ttm_tt_create(bo, page_flags);
if (unlikely(bo->ttm == NULL))
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index a4eff85b1f449..2b9d856ff388d 100644
--- a/include/drm/ttm/ttm_t

[PATCH 6.6 003/396] drm/vmwgfx: Unmap the surface before resetting it on a plane state

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 27571c64f1855881753e6f33c3186573afbab7ba ]

Switch to a new plane state requires unreferencing of all held surfaces.
In the work required for mob cursors the mapped surfaces started being
cached but the variable indicating whether the surface is currently
mapped was not being reset. This leads to crashes as the duplicated
state, incorrectly, indicates the that surface is mapped even when
no surface is present. That's because after unreferencing the surface
it's perfectly possible for the plane to be backed by a bo instead of a
surface.

Reset the surface mapped flag when unreferencing the plane state surface
to fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland:

Oops:  [#1] PREEMPT SMP PTI
CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference 
Platform, BIOS 6.00 11/12/2020
RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 
c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>
RSP: 0018:b6b98216fa80 EFLAGS: 00010246
RAX:  RBX: 969d84cdcb00 RCX: 0027
RDX:  RSI: 0001 RDI: 969e75f21600
RBP: 969d4143dc50 R08:  R09: b6b98216f920
R10: 0003 R11: 969e7feb3b10 R12: 
R13:  R14: 027b R15: 969d49c9fc00
FS:  7f1e8f1b4180() GS:969e75f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0028 CR3: 000104006004 CR4: 003706f0
Call Trace:
 
 ? __die+0x23/0x70
 ? page_fault_oops+0x171/0x4e0
 ? exc_page_fault+0x7f/0x180
 ? asm_exc_page_fault+0x26/0x30
 ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
 drm_atomic_helper_cleanup_planes+0x9b/0xc0
 commit_tail+0xd1/0x130
 drm_atomic_helper_commit+0x11a/0x140
 drm_atomic_commit+0x97/0xd0
 ? __pfx___drm_printfn_info+0x10/0x10
 drm_atomic_helper_update_plane+0xf5/0x160
 drm_mode_cursor_universal+0x10e/0x270
 drm_mode_cursor_common+0x102/0x230
 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10
 drm_ioctl_kernel+0xb2/0x110
 drm_ioctl+0x26d/0x4b0
 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10
 ? __pfx_drm_ioctl+0x10/0x10
 vmw_generic_ioctl+0xa4/0x110 [vmwgfx]
 __x64_sys_ioctl+0x94/0xd0
 do_syscall_64+0x61/0xe0
 ? __x64_sys_ioctl+0xaf/0xd0
 ? syscall_exit_to_user_mode+0x2b/0x40
 ? do_syscall_64+0x70/0xe0
 ? __x64_sys_ioctl+0xaf/0xd0
 ? syscall_exit_to_user_mode+0x2b/0x40
 ? do_syscall_64+0x70/0xe0
 ? exc_page_fault+0x7f/0x180
 entry_SYSCALL_64_after_hwframe+0x6e/0x76
RIP: 0033:0x7f1e93f279ed
Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 
89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f>
RSP: 002b:7ffca0faf600 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 55db876ed2c0 RCX: 7f1e93f279ed
RDX: 7ffca0faf6c0 RSI: c02464bb RDI: 0015
RBP: 7ffca0faf650 R08: 55db87184010 R09: 0007
R10: 55db886471a0 R11: 0246 R12: 7ffca0faf6c0
R13: c02464bb R14: 0015 R15: 7ffca0faf790
 
Modules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns 
nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib 
nft_reject_ine>
CR2: 0028
---[ end trace  ]---
RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 
c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>
RSP: 0018:b6b98216fa80 EFLAGS: 00010246
RAX:  RBX: 969d84cdcb00 RCX: 0027
RDX:  RSI: 0001 RDI: 969e75f21600
RBP: 969d4143dc50 R08:  R09: b6b98216f920
R10: 0003 R11: 969e7feb3b10 R12: 
R13:  R14: 027b R15: 969d49c9fc00
FS:  7f1e8f1b4180() GS:969e75f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0028 CR3: 000104006004 CR4: 003706f0

Signed-off-by: Zack Rusin 
Fixes: 485d98d472d5 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 4")
Reported-by: Stefan Hoffmeister 
Closes: https://gitlab.freedesktop.org/drm/misc/-/issues/34
Cc: Martin Krastev 
Cc: Maaz Mombasawala 
Cc: Ian Forbes 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.19+
Acked-by: Javier Martinez Canillas 
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20231224052540.605040-1-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwg

[PATCH 6.6 013/396] drm/vmwgfx: Fix possible null pointer derefence with invalid contexts

[Greg Kroah-Hartman]

6.6-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 517621b7060096e48e42f545fa6646fc00252eac ]

vmw_context_cotable can return either an error or a null pointer and its
usage sometimes went unchecked. Subsequent code would then try to access
either a null pointer or an error value.

The invalid dereferences were only possible with malformed userspace
apps which never properly initialized the rendering contexts.

Check the results of vmw_context_cotable to fix the invalid derefs.

Thanks:
ziming zhang(@ezrak1e) from Ant Group Light-Year Security Lab
who was the first person to discover it.
Niels De Graef who reported it and helped to track down the poc.

Fixes: 9c079b8ce8bf ("drm/vmwgfx: Adapt execbuf to the new validation api")
Cc:  # v4.20+
Reported-by: Niels De Graef  
Signed-off-by: Zack Rusin 
Cc: Martin Krastev 
Cc: Maaz Mombasawala 
Cc: Ian Forbes 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240110200305.94086-1-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 36987ef3fc300..5fef0b31c1179 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -447,7 +447,7 @@ static int vmw_resource_context_res_add(struct vmw_private 
*dev_priv,
vmw_res_type(ctx) == vmw_res_dx_context) {
for (i = 0; i < cotable_max; ++i) {
res = vmw_context_cotable(ctx, i);
-   if (IS_ERR(res))
+   if (IS_ERR_OR_NULL(res))
continue;
 
ret = vmw_execbuf_res_val_add(sw_context, res,
@@ -1266,6 +1266,8 @@ static int vmw_cmd_dx_define_query(struct vmw_private 
*dev_priv,
return -EINVAL;
 
cotable_res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXQUERY);
+   if (IS_ERR_OR_NULL(cotable_res))
+   return cotable_res ? PTR_ERR(cotable_res) : -EINVAL;
ret = vmw_cotable_notify(cotable_res, cmd->body.queryId);
 
return ret;
@@ -2484,6 +2486,8 @@ static int vmw_cmd_dx_view_define(struct vmw_private 
*dev_priv,
return ret;
 
res = vmw_context_cotable(ctx_node->ctx, vmw_view_cotables[view_type]);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->defined_id);
if (unlikely(ret != 0))
return ret;
@@ -2569,8 +2573,8 @@ static int vmw_cmd_dx_so_define(struct vmw_private 
*dev_priv,
 
so_type = vmw_so_cmd_to_type(header->id);
res = vmw_context_cotable(ctx_node->ctx, vmw_so_cotables[so_type]);
-   if (IS_ERR(res))
-   return PTR_ERR(res);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
cmd = container_of(header, typeof(*cmd), header);
ret = vmw_cotable_notify(res, cmd->defined_id);
 
@@ -2689,6 +2693,8 @@ static int vmw_cmd_dx_define_shader(struct vmw_private 
*dev_priv,
return -EINVAL;
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXSHADER);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.shaderId);
if (ret)
return ret;
@@ -3010,6 +3016,8 @@ static int vmw_cmd_dx_define_streamoutput(struct 
vmw_private *dev_priv,
}
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_STREAMOUTPUT);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.soid);
if (ret)
return ret;
-- 
2.43.0

[PATCH 6.7 225/432] drm/ttm: Make sure the mapped tt pages are decrypted when needed

[Greg Kroah-Hartman]

6.7-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 71ce046327cfd3aef3f93d1c44e091395eb03f8f ]

Some drivers require the mapped tt pages to be decrypted. In an ideal
world this would have been handled by the dma layer, but the TTM page
fault handling would have to be rewritten to able to do that.

A side-effect of the TTM page fault handling is using a dma allocation
per order (via ttm_pool_alloc_page) which makes it impossible to just
trivially use dma_mmap_attrs. As a result ttm has to be very careful
about trying to make its pgprot for the mapped tt pages match what
the dma layer thinks it is. At the ttm layer it's possible to
deduce the requirement to have tt pages decrypted by checking
whether coherent dma allocations have been requested and the system
is running with confidential computing technologies.

This approach isn't ideal but keeping TTM matching DMAs expectations
for the page properties is in general fragile, unfortunately proper
fix would require a rewrite of TTM's page fault handling.

Fixes vmwgfx with SEV enabled.

v2: Explicitly include cc_platform.h
v3: Use CC_ATTR_GUEST_MEM_ENCRYPT instead of CC_ATTR_MEM_ENCRYPT to
limit the scope to guests and log when memory decryption is enabled.

Signed-off-by: Zack Rusin 
Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based 
iomem")
Reviewed-by: Thomas Hellström 
Acked-by: Christian König 
Cc: Huang Rui 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v5.14+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230926040359.3040017-1-z...@kde.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 13 +++--
 drivers/gpu/drm/ttm/ttm_tt.c  | 13 +
 include/drm/ttm/ttm_tt.h  |  9 -
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index fd9fd3d15101c..0b3f4267130c4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -294,7 +294,13 @@ pgprot_t ttm_io_prot(struct ttm_buffer_object *bo, struct 
ttm_resource *res,
enum ttm_caching caching;
 
man = ttm_manager_type(bo->bdev, res->mem_type);
-   caching = man->use_tt ? bo->ttm->caching : res->bus.caching;
+   if (man->use_tt) {
+   caching = bo->ttm->caching;
+   if (bo->ttm->page_flags & TTM_TT_FLAG_DECRYPTED)
+   tmp = pgprot_decrypted(tmp);
+   } else  {
+   caching = res->bus.caching;
+   }
 
return ttm_prot_from_caching(caching, tmp);
 }
@@ -337,6 +343,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
.no_wait_gpu = false
};
struct ttm_tt *ttm = bo->ttm;
+   struct ttm_resource_manager *man =
+   ttm_manager_type(bo->bdev, bo->resource->mem_type);
pgprot_t prot;
int ret;
 
@@ -346,7 +354,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
if (ret)
return ret;
 
-   if (num_pages == 1 && ttm->caching == ttm_cached) {
+   if (num_pages == 1 && ttm->caching == ttm_cached &&
+   !(man->use_tt && (ttm->page_flags & TTM_TT_FLAG_DECRYPTED))) {
/*
 * We're mapping a single page, and the desired
 * page protection is consistent with the bo.
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index e0a77671edd6c..43eaffa7faae3 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -31,11 +31,14 @@
 
 #define pr_fmt(fmt) "[TTM] " fmt
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -60,6 +63,7 @@ static atomic_long_t ttm_dma32_pages_allocated;
 int ttm_tt_create(struct ttm_buffer_object *bo, bool zero_alloc)
 {
struct ttm_device *bdev = bo->bdev;
+   struct drm_device *ddev = bo->base.dev;
uint32_t page_flags = 0;
 
dma_resv_assert_held(bo->base.resv);
@@ -81,6 +85,15 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool 
zero_alloc)
pr_err("Illegal buffer object type\n");
return -EINVAL;
}
+   /*
+* When using dma_alloc_coherent with memory encryption the
+* mapped TT pages need to be decrypted or otherwise the drivers
+* will end up sending encrypted mem to the gpu.
+*/
+   if (bdev->pool.use_dma_alloc && 
cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
+   page_flags |= TTM_TT_FLAG_DECRYPTED;
+   drm_info(ddev, "TT memory decryption enabled.");
+   }
 
bo->ttm = bdev->funcs->ttm_tt_create(bo, page_flags);
if (unlikely(bo->ttm == NULL))
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index a4eff85b1f449..2b9d856ff388d 100644
--- a/include/drm/ttm/ttm_t

[PATCH 6.7 013/432] drm/vmwgfx: Fix possible null pointer derefence with invalid contexts

[Greg Kroah-Hartman]

6.7-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 517621b7060096e48e42f545fa6646fc00252eac ]

vmw_context_cotable can return either an error or a null pointer and its
usage sometimes went unchecked. Subsequent code would then try to access
either a null pointer or an error value.

The invalid dereferences were only possible with malformed userspace
apps which never properly initialized the rendering contexts.

Check the results of vmw_context_cotable to fix the invalid derefs.

Thanks:
ziming zhang(@ezrak1e) from Ant Group Light-Year Security Lab
who was the first person to discover it.
Niels De Graef who reported it and helped to track down the poc.

Fixes: 9c079b8ce8bf ("drm/vmwgfx: Adapt execbuf to the new validation api")
Cc:  # v4.20+
Reported-by: Niels De Graef  
Signed-off-by: Zack Rusin 
Cc: Martin Krastev 
Cc: Maaz Mombasawala 
Cc: Ian Forbes 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240110200305.94086-1-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 36987ef3fc300..5fef0b31c1179 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -447,7 +447,7 @@ static int vmw_resource_context_res_add(struct vmw_private 
*dev_priv,
vmw_res_type(ctx) == vmw_res_dx_context) {
for (i = 0; i < cotable_max; ++i) {
res = vmw_context_cotable(ctx, i);
-   if (IS_ERR(res))
+   if (IS_ERR_OR_NULL(res))
continue;
 
ret = vmw_execbuf_res_val_add(sw_context, res,
@@ -1266,6 +1266,8 @@ static int vmw_cmd_dx_define_query(struct vmw_private 
*dev_priv,
return -EINVAL;
 
cotable_res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXQUERY);
+   if (IS_ERR_OR_NULL(cotable_res))
+   return cotable_res ? PTR_ERR(cotable_res) : -EINVAL;
ret = vmw_cotable_notify(cotable_res, cmd->body.queryId);
 
return ret;
@@ -2484,6 +2486,8 @@ static int vmw_cmd_dx_view_define(struct vmw_private 
*dev_priv,
return ret;
 
res = vmw_context_cotable(ctx_node->ctx, vmw_view_cotables[view_type]);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->defined_id);
if (unlikely(ret != 0))
return ret;
@@ -2569,8 +2573,8 @@ static int vmw_cmd_dx_so_define(struct vmw_private 
*dev_priv,
 
so_type = vmw_so_cmd_to_type(header->id);
res = vmw_context_cotable(ctx_node->ctx, vmw_so_cotables[so_type]);
-   if (IS_ERR(res))
-   return PTR_ERR(res);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
cmd = container_of(header, typeof(*cmd), header);
ret = vmw_cotable_notify(res, cmd->defined_id);
 
@@ -2689,6 +2693,8 @@ static int vmw_cmd_dx_define_shader(struct vmw_private 
*dev_priv,
return -EINVAL;
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXSHADER);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.shaderId);
if (ret)
return ret;
@@ -3010,6 +3016,8 @@ static int vmw_cmd_dx_define_streamoutput(struct 
vmw_private *dev_priv,
}
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_STREAMOUTPUT);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.soid);
if (ret)
return ret;
-- 
2.43.0

[PATCH 6.7 003/432] drm/vmwgfx: Unmap the surface before resetting it on a plane state

[Greg Kroah-Hartman]

6.7-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 27571c64f1855881753e6f33c3186573afbab7ba ]

Switch to a new plane state requires unreferencing of all held surfaces.
In the work required for mob cursors the mapped surfaces started being
cached but the variable indicating whether the surface is currently
mapped was not being reset. This leads to crashes as the duplicated
state, incorrectly, indicates the that surface is mapped even when
no surface is present. That's because after unreferencing the surface
it's perfectly possible for the plane to be backed by a bo instead of a
surface.

Reset the surface mapped flag when unreferencing the plane state surface
to fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland:

Oops:  [#1] PREEMPT SMP PTI
CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference 
Platform, BIOS 6.00 11/12/2020
RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 
c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>
RSP: 0018:b6b98216fa80 EFLAGS: 00010246
RAX:  RBX: 969d84cdcb00 RCX: 0027
RDX:  RSI: 0001 RDI: 969e75f21600
RBP: 969d4143dc50 R08:  R09: b6b98216f920
R10: 0003 R11: 969e7feb3b10 R12: 
R13:  R14: 027b R15: 969d49c9fc00
FS:  7f1e8f1b4180() GS:969e75f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0028 CR3: 000104006004 CR4: 003706f0
Call Trace:
 
 ? __die+0x23/0x70
 ? page_fault_oops+0x171/0x4e0
 ? exc_page_fault+0x7f/0x180
 ? asm_exc_page_fault+0x26/0x30
 ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
 drm_atomic_helper_cleanup_planes+0x9b/0xc0
 commit_tail+0xd1/0x130
 drm_atomic_helper_commit+0x11a/0x140
 drm_atomic_commit+0x97/0xd0
 ? __pfx___drm_printfn_info+0x10/0x10
 drm_atomic_helper_update_plane+0xf5/0x160
 drm_mode_cursor_universal+0x10e/0x270
 drm_mode_cursor_common+0x102/0x230
 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10
 drm_ioctl_kernel+0xb2/0x110
 drm_ioctl+0x26d/0x4b0
 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10
 ? __pfx_drm_ioctl+0x10/0x10
 vmw_generic_ioctl+0xa4/0x110 [vmwgfx]
 __x64_sys_ioctl+0x94/0xd0
 do_syscall_64+0x61/0xe0
 ? __x64_sys_ioctl+0xaf/0xd0
 ? syscall_exit_to_user_mode+0x2b/0x40
 ? do_syscall_64+0x70/0xe0
 ? __x64_sys_ioctl+0xaf/0xd0
 ? syscall_exit_to_user_mode+0x2b/0x40
 ? do_syscall_64+0x70/0xe0
 ? exc_page_fault+0x7f/0x180
 entry_SYSCALL_64_after_hwframe+0x6e/0x76
RIP: 0033:0x7f1e93f279ed
Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 
89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f>
RSP: 002b:7ffca0faf600 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 55db876ed2c0 RCX: 7f1e93f279ed
RDX: 7ffca0faf6c0 RSI: c02464bb RDI: 0015
RBP: 7ffca0faf650 R08: 55db87184010 R09: 0007
R10: 55db886471a0 R11: 0246 R12: 7ffca0faf6c0
R13: c02464bb R14: 0015 R15: 7ffca0faf790
 
Modules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns 
nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib 
nft_reject_ine>
CR2: 0028
---[ end trace  ]---
RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 
c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>
RSP: 0018:b6b98216fa80 EFLAGS: 00010246
RAX:  RBX: 969d84cdcb00 RCX: 0027
RDX:  RSI: 0001 RDI: 969e75f21600
RBP: 969d4143dc50 R08:  R09: b6b98216f920
R10: 0003 R11: 969e7feb3b10 R12: 
R13:  R14: 027b R15: 969d49c9fc00
FS:  7f1e8f1b4180() GS:969e75f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0028 CR3: 000104006004 CR4: 003706f0

Signed-off-by: Zack Rusin 
Fixes: 485d98d472d5 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 4")
Reported-by: Stefan Hoffmeister 
Closes: https://gitlab.freedesktop.org/drm/misc/-/issues/34
Cc: Martin Krastev 
Cc: Maaz Mombasawala 
Cc: Ian Forbes 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.19+
Acked-by: Javier Martinez Canillas 
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20231224052540.605040-1-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwg

[PATCH 6.8 306/399] fbdev: Select I/O-memory framebuffer ops for SBus

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Thomas Zimmermann 

commit a8eb93b42d7e068306ca07f51055cbcde893fea3 upstream.

Framebuffer I/O on the Sparc Sbus requires read/write helpers for
I/O memory. Select FB_IOMEM_FOPS accordingly.

Reported-by: Nick Bowler 
Closes: 
https://lore.kernel.org/lkml/5bc21364-41da-a339-676e-5bb0f4fae...@draconx.ca/
Signed-off-by: Thomas Zimmermann 
Fixes: 8813e86f6d82 ("fbdev: Remove default file-I/O implementations")
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: Sam Ravnborg 
Cc: Arnd Bergmann 
Cc: Geert Uytterhoeven 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.8+
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Sam Ravnborg 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240322083005.24269-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/video/fbdev/Kconfig |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -501,6 +501,7 @@ config FB_SBUS_HELPERS
select FB_CFB_COPYAREA
select FB_CFB_FILLRECT
select FB_CFB_IMAGEBLIT
+   select FB_IOMEM_FOPS
 
 config FB_BW2
bool "BWtwo support"
@@ -521,6 +522,7 @@ config FB_CG6
depends on (FB = y) && (SPARC && FB_SBUS)
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+   select FB_IOMEM_FOPS
help
  This is the frame buffer device driver for the CGsix (GX, TurboGX)
  frame buffer.
@@ -530,6 +532,7 @@ config FB_FFB
depends on FB_SBUS && SPARC64
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+   select FB_IOMEM_FOPS
help
  This is the frame buffer device driver for the Creator, Creator3D,
  and Elite3D graphics boards.

[PATCH 6.8 225/399] drm/ttm: Make sure the mapped tt pages are decrypted when needed

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 71ce046327cfd3aef3f93d1c44e091395eb03f8f ]

Some drivers require the mapped tt pages to be decrypted. In an ideal
world this would have been handled by the dma layer, but the TTM page
fault handling would have to be rewritten to able to do that.

A side-effect of the TTM page fault handling is using a dma allocation
per order (via ttm_pool_alloc_page) which makes it impossible to just
trivially use dma_mmap_attrs. As a result ttm has to be very careful
about trying to make its pgprot for the mapped tt pages match what
the dma layer thinks it is. At the ttm layer it's possible to
deduce the requirement to have tt pages decrypted by checking
whether coherent dma allocations have been requested and the system
is running with confidential computing technologies.

This approach isn't ideal but keeping TTM matching DMAs expectations
for the page properties is in general fragile, unfortunately proper
fix would require a rewrite of TTM's page fault handling.

Fixes vmwgfx with SEV enabled.

v2: Explicitly include cc_platform.h
v3: Use CC_ATTR_GUEST_MEM_ENCRYPT instead of CC_ATTR_MEM_ENCRYPT to
limit the scope to guests and log when memory decryption is enabled.

Signed-off-by: Zack Rusin 
Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based 
iomem")
Reviewed-by: Thomas Hellström 
Acked-by: Christian König 
Cc: Huang Rui 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc:  # v5.14+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230926040359.3040017-1-z...@kde.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 13 +++--
 drivers/gpu/drm/ttm/ttm_tt.c  | 13 +
 include/drm/ttm/ttm_tt.h  |  9 -
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index fd9fd3d15101c..0b3f4267130c4 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -294,7 +294,13 @@ pgprot_t ttm_io_prot(struct ttm_buffer_object *bo, struct 
ttm_resource *res,
enum ttm_caching caching;
 
man = ttm_manager_type(bo->bdev, res->mem_type);
-   caching = man->use_tt ? bo->ttm->caching : res->bus.caching;
+   if (man->use_tt) {
+   caching = bo->ttm->caching;
+   if (bo->ttm->page_flags & TTM_TT_FLAG_DECRYPTED)
+   tmp = pgprot_decrypted(tmp);
+   } else  {
+   caching = res->bus.caching;
+   }
 
return ttm_prot_from_caching(caching, tmp);
 }
@@ -337,6 +343,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
.no_wait_gpu = false
};
struct ttm_tt *ttm = bo->ttm;
+   struct ttm_resource_manager *man =
+   ttm_manager_type(bo->bdev, bo->resource->mem_type);
pgprot_t prot;
int ret;
 
@@ -346,7 +354,8 @@ static int ttm_bo_kmap_ttm(struct ttm_buffer_object *bo,
if (ret)
return ret;
 
-   if (num_pages == 1 && ttm->caching == ttm_cached) {
+   if (num_pages == 1 && ttm->caching == ttm_cached &&
+   !(man->use_tt && (ttm->page_flags & TTM_TT_FLAG_DECRYPTED))) {
/*
 * We're mapping a single page, and the desired
 * page protection is consistent with the bo.
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index e0a77671edd6c..43eaffa7faae3 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -31,11 +31,14 @@
 
 #define pr_fmt(fmt) "[TTM] " fmt
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -60,6 +63,7 @@ static atomic_long_t ttm_dma32_pages_allocated;
 int ttm_tt_create(struct ttm_buffer_object *bo, bool zero_alloc)
 {
struct ttm_device *bdev = bo->bdev;
+   struct drm_device *ddev = bo->base.dev;
uint32_t page_flags = 0;
 
dma_resv_assert_held(bo->base.resv);
@@ -81,6 +85,15 @@ int ttm_tt_create(struct ttm_buffer_object *bo, bool 
zero_alloc)
pr_err("Illegal buffer object type\n");
return -EINVAL;
}
+   /*
+* When using dma_alloc_coherent with memory encryption the
+* mapped TT pages need to be decrypted or otherwise the drivers
+* will end up sending encrypted mem to the gpu.
+*/
+   if (bdev->pool.use_dma_alloc && 
cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) {
+   page_flags |= TTM_TT_FLAG_DECRYPTED;
+   drm_info(ddev, "TT memory decryption enabled.");
+   }
 
bo->ttm = bdev->funcs->ttm_tt_create(bo, page_flags);
if (unlikely(bo->ttm == NULL))
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index a4eff85b1f449..2b9d856ff388d 100644
--- a/include/drm/ttm/ttm_t

[PATCH 6.8 011/399] drm/vmwgfx: Fix possible null pointer derefence with invalid contexts

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 517621b7060096e48e42f545fa6646fc00252eac ]

vmw_context_cotable can return either an error or a null pointer and its
usage sometimes went unchecked. Subsequent code would then try to access
either a null pointer or an error value.

The invalid dereferences were only possible with malformed userspace
apps which never properly initialized the rendering contexts.

Check the results of vmw_context_cotable to fix the invalid derefs.

Thanks:
ziming zhang(@ezrak1e) from Ant Group Light-Year Security Lab
who was the first person to discover it.
Niels De Graef who reported it and helped to track down the poc.

Fixes: 9c079b8ce8bf ("drm/vmwgfx: Adapt execbuf to the new validation api")
Cc:  # v4.20+
Reported-by: Niels De Graef  
Signed-off-by: Zack Rusin 
Cc: Martin Krastev 
Cc: Maaz Mombasawala 
Cc: Ian Forbes 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20240110200305.94086-1-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 36987ef3fc300..5fef0b31c1179 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -447,7 +447,7 @@ static int vmw_resource_context_res_add(struct vmw_private 
*dev_priv,
vmw_res_type(ctx) == vmw_res_dx_context) {
for (i = 0; i < cotable_max; ++i) {
res = vmw_context_cotable(ctx, i);
-   if (IS_ERR(res))
+   if (IS_ERR_OR_NULL(res))
continue;
 
ret = vmw_execbuf_res_val_add(sw_context, res,
@@ -1266,6 +1266,8 @@ static int vmw_cmd_dx_define_query(struct vmw_private 
*dev_priv,
return -EINVAL;
 
cotable_res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXQUERY);
+   if (IS_ERR_OR_NULL(cotable_res))
+   return cotable_res ? PTR_ERR(cotable_res) : -EINVAL;
ret = vmw_cotable_notify(cotable_res, cmd->body.queryId);
 
return ret;
@@ -2484,6 +2486,8 @@ static int vmw_cmd_dx_view_define(struct vmw_private 
*dev_priv,
return ret;
 
res = vmw_context_cotable(ctx_node->ctx, vmw_view_cotables[view_type]);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->defined_id);
if (unlikely(ret != 0))
return ret;
@@ -2569,8 +2573,8 @@ static int vmw_cmd_dx_so_define(struct vmw_private 
*dev_priv,
 
so_type = vmw_so_cmd_to_type(header->id);
res = vmw_context_cotable(ctx_node->ctx, vmw_so_cotables[so_type]);
-   if (IS_ERR(res))
-   return PTR_ERR(res);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
cmd = container_of(header, typeof(*cmd), header);
ret = vmw_cotable_notify(res, cmd->defined_id);
 
@@ -2689,6 +2693,8 @@ static int vmw_cmd_dx_define_shader(struct vmw_private 
*dev_priv,
return -EINVAL;
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_DXSHADER);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.shaderId);
if (ret)
return ret;
@@ -3010,6 +3016,8 @@ static int vmw_cmd_dx_define_streamoutput(struct 
vmw_private *dev_priv,
}
 
res = vmw_context_cotable(ctx_node->ctx, SVGA_COTABLE_STREAMOUTPUT);
+   if (IS_ERR_OR_NULL(res))
+   return res ? PTR_ERR(res) : -EINVAL;
ret = vmw_cotable_notify(res, cmd->body.soid);
if (ret)
return ret;
-- 
2.43.0

[PATCH 6.8 001/399] drm/vmwgfx: Unmap the surface before resetting it on a plane state

[Greg Kroah-Hartman]

6.8-stable review patch.  If anyone has any objections, please let me know.

--

From: Zack Rusin 

[ Upstream commit 27571c64f1855881753e6f33c3186573afbab7ba ]

Switch to a new plane state requires unreferencing of all held surfaces.
In the work required for mob cursors the mapped surfaces started being
cached but the variable indicating whether the surface is currently
mapped was not being reset. This leads to crashes as the duplicated
state, incorrectly, indicates the that surface is mapped even when
no surface is present. That's because after unreferencing the surface
it's perfectly possible for the plane to be backed by a bo instead of a
surface.

Reset the surface mapped flag when unreferencing the plane state surface
to fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland:

Oops:  [#1] PREEMPT SMP PTI
CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference 
Platform, BIOS 6.00 11/12/2020
RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 
c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>
RSP: 0018:b6b98216fa80 EFLAGS: 00010246
RAX:  RBX: 969d84cdcb00 RCX: 0027
RDX:  RSI: 0001 RDI: 969e75f21600
RBP: 969d4143dc50 R08:  R09: b6b98216f920
R10: 0003 R11: 969e7feb3b10 R12: 
R13:  R14: 027b R15: 969d49c9fc00
FS:  7f1e8f1b4180() GS:969e75f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0028 CR3: 000104006004 CR4: 003706f0
Call Trace:
 
 ? __die+0x23/0x70
 ? page_fault_oops+0x171/0x4e0
 ? exc_page_fault+0x7f/0x180
 ? asm_exc_page_fault+0x26/0x30
 ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
 drm_atomic_helper_cleanup_planes+0x9b/0xc0
 commit_tail+0xd1/0x130
 drm_atomic_helper_commit+0x11a/0x140
 drm_atomic_commit+0x97/0xd0
 ? __pfx___drm_printfn_info+0x10/0x10
 drm_atomic_helper_update_plane+0xf5/0x160
 drm_mode_cursor_universal+0x10e/0x270
 drm_mode_cursor_common+0x102/0x230
 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10
 drm_ioctl_kernel+0xb2/0x110
 drm_ioctl+0x26d/0x4b0
 ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10
 ? __pfx_drm_ioctl+0x10/0x10
 vmw_generic_ioctl+0xa4/0x110 [vmwgfx]
 __x64_sys_ioctl+0x94/0xd0
 do_syscall_64+0x61/0xe0
 ? __x64_sys_ioctl+0xaf/0xd0
 ? syscall_exit_to_user_mode+0x2b/0x40
 ? do_syscall_64+0x70/0xe0
 ? __x64_sys_ioctl+0xaf/0xd0
 ? syscall_exit_to_user_mode+0x2b/0x40
 ? do_syscall_64+0x70/0xe0
 ? exc_page_fault+0x7f/0x180
 entry_SYSCALL_64_after_hwframe+0x6e/0x76
RIP: 0033:0x7f1e93f279ed
Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 
89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f>
RSP: 002b:7ffca0faf600 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 55db876ed2c0 RCX: 7f1e93f279ed
RDX: 7ffca0faf6c0 RSI: c02464bb RDI: 0015
RBP: 7ffca0faf650 R08: 55db87184010 R09: 0007
R10: 55db886471a0 R11: 0246 R12: 7ffca0faf6c0
R13: c02464bb R14: 0015 R15: 7ffca0faf790
 
Modules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns 
nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib 
nft_reject_ine>
CR2: 0028
---[ end trace  ]---
RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 
c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>
RSP: 0018:b6b98216fa80 EFLAGS: 00010246
RAX:  RBX: 969d84cdcb00 RCX: 0027
RDX:  RSI: 0001 RDI: 969e75f21600
RBP: 969d4143dc50 R08:  R09: b6b98216f920
R10: 0003 R11: 969e7feb3b10 R12: 
R13:  R14: 027b R15: 969d49c9fc00
FS:  7f1e8f1b4180() GS:969e75f0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0028 CR3: 000104006004 CR4: 003706f0

Signed-off-by: Zack Rusin 
Fixes: 485d98d472d5 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 4")
Reported-by: Stefan Hoffmeister 
Closes: https://gitlab.freedesktop.org/drm/misc/-/issues/34
Cc: Martin Krastev 
Cc: Maaz Mombasawala 
Cc: Ian Forbes 
Cc: Broadcom internal kernel review list 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v5.19+
Acked-by: Javier Martinez Canillas 
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20231224052540.605040-1-zack.ru...@broadcom.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwg

Re: [PATCH 0/2] video: backlight: constify struct class usage

[Greg Kroah-Hartman]

On Thu, Mar 28, 2024 at 09:46:01AM -0300, Ricardo B. Marliere wrote:
> On 28 Mar 13:01, Greg Kroah-Hartman wrote:
> > On Thu, Mar 28, 2024 at 11:41:31AM +, Lee Jones wrote:
> > > On Tue, 05 Mar 2024, Ricardo B. Marliere wrote:
> > > 
> > > > This is a simple and straight forward cleanup series that aims to make 
> > > > the
> > > > class structures in backlight constant. This has been possible since 
> > > > 2023
> > > > [1].
> > > > 
> > > > [1]: 
> > > > https://lore.kernel.org/all/2023040248-customary-release-4aec@gregkh/
> > > > 
> > > > Signed-off-by: Ricardo B. Marliere 
> > > > ---
> > > > Ricardo B. Marliere (2):
> > > >   video: backlight: make backlight_class constant
> > > >   video: backlight: lcd: make lcd_class constant
> > > > 
> > > >  drivers/video/backlight/backlight.c | 29 -
> > > >  drivers/video/backlight/lcd.c   | 23 +--
> > > >  2 files changed, 29 insertions(+), 23 deletions(-)
> > > 
> > > No longer apply.
> > > 
> > > Please rebase on top of v6.9-rc1 or for-backlight-next.
> > 
> > As I already had this in my local tree, I've sent out a v2 at:
> > https://lore.kernel.org/lkml/2024032805-putdown-mushy-a0f9@gregkh/
> 
> Thank you Greg. I will see what is left to be made const for -next.

Many of your patches were not picked up for -rc1, I'll be taking a bunch
of them into my tree "soon" as that usually means the subsystem isn't as
active.

thanks,

greg k-h

Re: [PATCH 0/2] video: backlight: constify struct class usage

[Greg Kroah-Hartman]

On Thu, Mar 28, 2024 at 11:41:31AM +, Lee Jones wrote:
> On Tue, 05 Mar 2024, Ricardo B. Marliere wrote:
> 
> > This is a simple and straight forward cleanup series that aims to make the
> > class structures in backlight constant. This has been possible since 2023
> > [1].
> > 
> > [1]: https://lore.kernel.org/all/2023040248-customary-release-4aec@gregkh/
> > 
> > Signed-off-by: Ricardo B. Marliere 
> > ---
> > Ricardo B. Marliere (2):
> >   video: backlight: make backlight_class constant
> >   video: backlight: lcd: make lcd_class constant
> > 
> >  drivers/video/backlight/backlight.c | 29 -
> >  drivers/video/backlight/lcd.c   | 23 +--
> >  2 files changed, 29 insertions(+), 23 deletions(-)
> 
> No longer apply.
> 
> Please rebase on top of v6.9-rc1 or for-backlight-next.

As I already had this in my local tree, I've sent out a v2 at:
https://lore.kernel.org/lkml/2024032805-putdown-mushy-a0f9@gregkh/

thanks,

greg k-h

[PATCH v2 1/2] video: backlight: make backlight_class constant

[Greg Kroah-Hartman]

From: "Ricardo B. Marliere" 

Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the backlight_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.

Cc: Greg Kroah-Hartman 
Suggested-by: Greg Kroah-Hartman 
Signed-off-by: "Ricardo B. Marliere" 
Signed-off-by: Greg Kroah-Hartman 
---
v2: rebased on 6.9-rc1

 drivers/video/backlight/backlight.c | 29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/video/backlight/backlight.c 
b/drivers/video/backlight/backlight.c
index 86e1cdc8e369..d2feaebfd84a 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -317,8 +317,6 @@ static ssize_t scale_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(scale);
 
-static struct class *backlight_class;
-
 #ifdef CONFIG_PM_SLEEP
 static int backlight_suspend(struct device *dev)
 {
@@ -369,6 +367,12 @@ static struct attribute *bl_device_attrs[] = {
 };
 ATTRIBUTE_GROUPS(bl_device);
 
+static const struct class backlight_class = {
+   .name = "backlight",
+   .dev_groups = bl_device_groups,
+   .pm = &backlight_class_dev_pm_ops,
+};
+
 /**
  * backlight_force_update - tell the backlight subsystem that hardware state
  *   has changed
@@ -418,7 +422,7 @@ struct backlight_device *backlight_device_register(const 
char *name,
mutex_init(&new_bd->update_lock);
mutex_init(&new_bd->ops_lock);
 
-   new_bd->dev.class = backlight_class;
+   new_bd->dev.class = &backlight_class;
new_bd->dev.parent = parent;
new_bd->dev.release = bl_device_release;
dev_set_name(&new_bd->dev, "%s", name);
@@ -510,7 +514,7 @@ struct backlight_device *backlight_device_get_by_name(const 
char *name)
 {
struct device *dev;
 
-   dev = class_find_device_by_name(backlight_class, name);
+   dev = class_find_device_by_name(&backlight_class, name);
 
return dev ? to_backlight_device(dev) : NULL;
 }
@@ -678,7 +682,7 @@ struct backlight_device *of_find_backlight_by_node(struct 
device_node *node)
 {
struct device *dev;
 
-   dev = class_find_device(backlight_class, NULL, node, of_parent_match);
+   dev = class_find_device(&backlight_class, NULL, node, of_parent_match);
 
return dev ? to_backlight_device(dev) : NULL;
 }
@@ -746,20 +750,19 @@ EXPORT_SYMBOL(devm_of_find_backlight);
 
 static void __exit backlight_class_exit(void)
 {
-   class_destroy(backlight_class);
+   class_unregister(&backlight_class);
 }
 
 static int __init backlight_class_init(void)
 {
-   backlight_class = class_create("backlight");
-   if (IS_ERR(backlight_class)) {
-   pr_warn("Unable to create backlight class; errno = %ld\n",
-   PTR_ERR(backlight_class));
-   return PTR_ERR(backlight_class);
+   int ret;
+
+   ret = class_register(&backlight_class);
+   if (ret) {
+   pr_warn("Unable to create backlight class; errno = %d\n", ret);
+   return ret;
}
 
-   backlight_class->dev_groups = bl_device_groups;
-   backlight_class->pm = &backlight_class_dev_pm_ops;
INIT_LIST_HEAD(&backlight_dev_list);
mutex_init(&backlight_dev_list_mutex);
BLOCKING_INIT_NOTIFIER_HEAD(&backlight_notifier);
-- 
2.44.0

[PATCH v2 2/2] video: backlight: lcd: make lcd_class constant

[Greg Kroah-Hartman]

From: "Ricardo B. Marliere" 

Since commit 43a7206b0963 ("driver core: class: make class_register() take
a const *"), the driver core allows for struct class to be in read-only
memory, so move the lcd_class structure to be declared at build time
placing it into read-only memory, instead of having to be dynamically
allocated at boot time.

Cc: Greg Kroah-Hartman 
Suggested-by: Greg Kroah-Hartman 
Signed-off-by: "Ricardo B. Marliere" 
Signed-off-by: Greg Kroah-Hartman 
---
v2: rebased on 6.9-rc1

 drivers/video/backlight/lcd.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/video/backlight/lcd.c b/drivers/video/backlight/lcd.c
index 77c5cb2a44e2..ba4771cbd781 100644
--- a/drivers/video/backlight/lcd.c
+++ b/drivers/video/backlight/lcd.c
@@ -159,8 +159,6 @@ static ssize_t max_contrast_show(struct device *dev,
 }
 static DEVICE_ATTR_RO(max_contrast);
 
-static struct class *lcd_class;
-
 static void lcd_device_release(struct device *dev)
 {
struct lcd_device *ld = to_lcd_device(dev);
@@ -175,6 +173,11 @@ static struct attribute *lcd_device_attrs[] = {
 };
 ATTRIBUTE_GROUPS(lcd_device);
 
+static const struct class lcd_class = {
+   .name = "lcd",
+   .dev_groups = lcd_device_groups,
+};
+
 /**
  * lcd_device_register - register a new object of lcd_device class.
  * @name: the name of the new object(must be the same as the name of the
@@ -202,7 +205,7 @@ struct lcd_device *lcd_device_register(const char *name, 
struct device *parent,
mutex_init(&new_ld->ops_lock);
mutex_init(&new_ld->update_lock);
 
-   new_ld->dev.class = lcd_class;
+   new_ld->dev.class = &lcd_class;
new_ld->dev.parent = parent;
new_ld->dev.release = lcd_device_release;
dev_set_name(&new_ld->dev, "%s", name);
@@ -318,19 +321,19 @@ EXPORT_SYMBOL(devm_lcd_device_unregister);
 
 static void __exit lcd_class_exit(void)
 {
-   class_destroy(lcd_class);
+   class_unregister(&lcd_class);
 }
 
 static int __init lcd_class_init(void)
 {
-   lcd_class = class_create("lcd");
-   if (IS_ERR(lcd_class)) {
-   pr_warn("Unable to create backlight class; errno = %ld\n",
-   PTR_ERR(lcd_class));
-   return PTR_ERR(lcd_class);
+   int ret;
+
+   ret = class_register(&lcd_class);
+   if (ret) {
+   pr_warn("Unable to create backlight class; errno = %d\n", ret);
+   return ret;
}
 
-   lcd_class->dev_groups = lcd_device_groups;
return 0;
 }
 
-- 
2.44.0

Re: [PATCH v7 2/9] usb: misc: onboard_hub: use device supply names

[Greg Kroah-Hartman]

On Tue, Mar 05, 2024 at 06:55:02AM +0100, Javier Carrasco wrote:
> The current implementation uses generic names for the power supplies,
> which conflicts with proper name definitions in the device bindings.
> 
> Add a per-device property to include real supply names and keep generic
> names for existing devices to keep backward compatibility.
> 
> Acked-by: Matthias Kaehlcke 
> Signed-off-by: Javier Carrasco 
> ---
>  drivers/usb/misc/onboard_usb_hub.c | 49 
> --
>  drivers/usb/misc/onboard_usb_hub.h | 12 ++
>  2 files changed, 38 insertions(+), 23 deletions(-)

Due to other patches to this file, this commit does not apply to my
tree.  Can you rebase and resend after -rc1 is out?

thanks,

greg k-h