[PATCH 5.15 162/168] drm/vmwgfx: Fix invalid reads in fence signaled events
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, >base,
>event.base);
[PATCH 5.10 108/111] drm/vmwgfx: Fix invalid reads in fence signaled events
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, >base,
>event.base);
[PATCH 5.4 78/84] drm/vmwgfx: Fix invalid reads in fence signaled events
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, >base,
>event.base);
[PATCH 4.19 61/63] drm/vmwgfx: Fix invalid reads in fence signaled events
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, >base,
>event.base);
[PATCH 6.1 221/236] drm/vmwgfx: Fix invalid reads in fence signaled events
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, >base,
>event.base);
[PATCH 6.6 271/301] drm/vmwgfx: Fix invalid reads in fence signaled events
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, >base,
>event.base);
[PATCH 6.6 269/301] drm/ttm: Print the memory decryption status just once
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
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, >base,
>event.base);
[PATCH 6.8 296/336] drm/ttm: Print the memory decryption status just once
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
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
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
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
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(>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
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
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(>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
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
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
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(>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
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
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(>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
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
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
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
b_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 = >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 will make it easier to review the
patches to ensure that the
[PATCH 6.1 48/69] drm/ast: Fix soft lockup
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
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
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
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
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
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
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
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(>man->resources,
->hash);
+ drm_ht_insert_item(>man->resources,
>hash);
list_del(>head);
list_add_tail(>head, >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()
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
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
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
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
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
---
[PATCH 6.6 003/396] drm/vmwgfx: Unmap the surface before resetting it on a plane state
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
---
[PATCH 6.6 013/396] drm/vmwgfx: Fix possible null pointer derefence with invalid contexts
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
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
---
[PATCH 6.7 013/432] drm/vmwgfx: Fix possible null pointer derefence with invalid contexts
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
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
---
[PATCH 6.8 306/399] fbdev: Select I/O-memory framebuffer ops for SBus
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
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
---
[PATCH 6.8 011/399] drm/vmwgfx: Fix possible null pointer derefence with invalid contexts
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
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
---
Re: [PATCH 0/2] video: backlight: constify struct class usage
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
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
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 = _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(_bd->update_lock);
mutex_init(_bd->ops_lock);
- new_bd->dev.class = backlight_class;
+ new_bd->dev.class = _class;
new_bd->dev.parent = parent;
new_bd->dev.release = bl_device_release;
dev_set_name(_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(_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(_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(_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(_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 = _class_dev_pm_ops;
INIT_LIST_HEAD(_dev_list);
mutex_init(_dev_list_mutex);
BLOCKING_INIT_NOTIFIER_HEAD(_notifier);
--
2.44.0
[PATCH v2 2/2] video: backlight: lcd: make lcd_class constant
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(_ld->ops_lock);
mutex_init(_ld->update_lock);
- new_ld->dev.class = lcd_class;
+ new_ld->dev.class = _class;
new_ld->dev.parent = parent;
new_ld->dev.release = lcd_device_release;
dev_set_name(_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(_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(_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
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
[PATCH 5.15 44/84] fbcon: always restore the old font data in fbcon_do_set_font()
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby (SUSE)
[ Upstream commit 00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f ]
Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when
vc_resize() failed) started restoring old font data upon failure (of
vc_resize()). But it performs so only for user fonts. It means that the
"system"/internal fonts are not restored at all. So in result, the very
first call to fbcon_do_set_font() performs no restore at all upon
failing vc_resize().
This can be reproduced by Syzkaller to crash the system on the next
invocation of font_get(). It's rather hard to hit the allocation failure
in vc_resize() on the first font_set(), but not impossible. Esp. if
fault injection is used to aid the execution/failure. It was
demonstrated by Sirius:
BUG: unable to handle page fault for address: fff8
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0
Oops: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
04/01/2014
RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286
Call Trace:
con_font_get drivers/tty/vt/vt.c:4558 [inline]
con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673
vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]
vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752
tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803
vfs_ioctl fs/ioctl.c:51 [inline]
...
So restore the font data in any case, not only for user fonts. Note the
later 'if' is now protected by 'old_userfont' and not 'old_data' as the
latter is always set now. (And it is supposed to be non-NULL. Otherwise
we would see the bug above again.)
Signed-off-by: Jiri Slaby (SUSE)
Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize()
failed")
Reported-and-tested-by: Ubisectech Sirius
Cc: Ubisectech Sirius
Cc: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20240208114411.14604-1-jirisl...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbcon.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index b6712655ec1f0..b163b54b868e6 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2409,11 +2409,9 @@ static int fbcon_do_set_font(struct vc_data *vc, int w,
int h, int charcount,
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = _display[vc->vc_num];
int resize, ret, old_userfont, old_width, old_height, old_charcount;
- char *old_data = NULL;
+ u8 *old_data = vc->vc_font.data;
resize = (w != vc->vc_font.width) || (h != vc->vc_font.height);
- if (p->userfont)
- old_data = vc->vc_font.data;
vc->vc_font.data = (void *)(p->fontdata = data);
old_userfont = p->userfont;
if ((p->userfont = userfont))
@@ -2447,13 +2445,13 @@ static int fbcon_do_set_font(struct vc_data *vc, int w,
int h, int charcount,
update_screen(vc);
}
- if (old_data && (--REFCOUNT(old_data) == 0))
+ if (old_userfont && (--REFCOUNT(old_data) == 0))
kfree(old_data - FONT_EXTRA_WORDS * sizeof(int));
return 0;
err_out:
p->fontdata = old_data;
- vc->vc_font.data = (void *)old_data;
+ vc->vc_font.data = old_data;
if (userfont) {
p->userfont = old_userfont;
--
2.43.0
[PATCH 6.1 068/215] fbcon: always restore the old font data in fbcon_do_set_font()
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby (SUSE)
[ Upstream commit 00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f ]
Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when
vc_resize() failed) started restoring old font data upon failure (of
vc_resize()). But it performs so only for user fonts. It means that the
"system"/internal fonts are not restored at all. So in result, the very
first call to fbcon_do_set_font() performs no restore at all upon
failing vc_resize().
This can be reproduced by Syzkaller to crash the system on the next
invocation of font_get(). It's rather hard to hit the allocation failure
in vc_resize() on the first font_set(), but not impossible. Esp. if
fault injection is used to aid the execution/failure. It was
demonstrated by Sirius:
BUG: unable to handle page fault for address: fff8
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0
Oops: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
04/01/2014
RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286
Call Trace:
con_font_get drivers/tty/vt/vt.c:4558 [inline]
con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673
vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]
vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752
tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803
vfs_ioctl fs/ioctl.c:51 [inline]
...
So restore the font data in any case, not only for user fonts. Note the
later 'if' is now protected by 'old_userfont' and not 'old_data' as the
latter is always set now. (And it is supposed to be non-NULL. Otherwise
we would see the bug above again.)
Signed-off-by: Jiri Slaby (SUSE)
Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize()
failed")
Reported-and-tested-by: Ubisectech Sirius
Cc: Ubisectech Sirius
Cc: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20240208114411.14604-1-jirisl...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbcon.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index fa205be94a4b8..14498a0d13e0b 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2397,11 +2397,9 @@ static int fbcon_do_set_font(struct vc_data *vc, int w,
int h, int charcount,
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = _display[vc->vc_num];
int resize, ret, old_userfont, old_width, old_height, old_charcount;
- char *old_data = NULL;
+ u8 *old_data = vc->vc_font.data;
resize = (w != vc->vc_font.width) || (h != vc->vc_font.height);
- if (p->userfont)
- old_data = vc->vc_font.data;
vc->vc_font.data = (void *)(p->fontdata = data);
old_userfont = p->userfont;
if ((p->userfont = userfont))
@@ -2435,13 +2433,13 @@ static int fbcon_do_set_font(struct vc_data *vc, int w,
int h, int charcount,
update_screen(vc);
}
- if (old_data && (--REFCOUNT(old_data) == 0))
+ if (old_userfont && (--REFCOUNT(old_data) == 0))
kfree(old_data - FONT_EXTRA_WORDS * sizeof(int));
return 0;
err_out:
p->fontdata = old_data;
- vc->vc_font.data = (void *)old_data;
+ vc->vc_font.data = old_data;
if (userfont) {
p->userfont = old_userfont;
--
2.43.0
[PATCH 6.6 059/143] fbcon: always restore the old font data in fbcon_do_set_font()
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby (SUSE)
[ Upstream commit 00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f ]
Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when
vc_resize() failed) started restoring old font data upon failure (of
vc_resize()). But it performs so only for user fonts. It means that the
"system"/internal fonts are not restored at all. So in result, the very
first call to fbcon_do_set_font() performs no restore at all upon
failing vc_resize().
This can be reproduced by Syzkaller to crash the system on the next
invocation of font_get(). It's rather hard to hit the allocation failure
in vc_resize() on the first font_set(), but not impossible. Esp. if
fault injection is used to aid the execution/failure. It was
demonstrated by Sirius:
BUG: unable to handle page fault for address: fff8
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0
Oops: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
04/01/2014
RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286
Call Trace:
con_font_get drivers/tty/vt/vt.c:4558 [inline]
con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673
vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]
vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752
tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803
vfs_ioctl fs/ioctl.c:51 [inline]
...
So restore the font data in any case, not only for user fonts. Note the
later 'if' is now protected by 'old_userfont' and not 'old_data' as the
latter is always set now. (And it is supposed to be non-NULL. Otherwise
we would see the bug above again.)
Signed-off-by: Jiri Slaby (SUSE)
Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize()
failed")
Reported-and-tested-by: Ubisectech Sirius
Cc: Ubisectech Sirius
Cc: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20240208114411.14604-1-jirisl...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbcon.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index f157a5a1dffcf..24035b4f2cd70 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2398,11 +2398,9 @@ static int fbcon_do_set_font(struct vc_data *vc, int w,
int h, int charcount,
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = _display[vc->vc_num];
int resize, ret, old_userfont, old_width, old_height, old_charcount;
- char *old_data = NULL;
+ u8 *old_data = vc->vc_font.data;
resize = (w != vc->vc_font.width) || (h != vc->vc_font.height);
- if (p->userfont)
- old_data = vc->vc_font.data;
vc->vc_font.data = (void *)(p->fontdata = data);
old_userfont = p->userfont;
if ((p->userfont = userfont))
@@ -2436,13 +2434,13 @@ static int fbcon_do_set_font(struct vc_data *vc, int w,
int h, int charcount,
update_screen(vc);
}
- if (old_data && (--REFCOUNT(old_data) == 0))
+ if (old_userfont && (--REFCOUNT(old_data) == 0))
kfree(old_data - FONT_EXTRA_WORDS * sizeof(int));
return 0;
err_out:
p->fontdata = old_data;
- vc->vc_font.data = (void *)old_data;
+ vc->vc_font.data = old_data;
if (userfont) {
p->userfont = old_userfont;
--
2.43.0
[PATCH 6.7 062/162] fbcon: always restore the old font data in fbcon_do_set_font()
6.7-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Slaby (SUSE)
[ Upstream commit 00d6a284fcf3fad1b7e1b5bc3cd87cbfb60ce03f ]
Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when
vc_resize() failed) started restoring old font data upon failure (of
vc_resize()). But it performs so only for user fonts. It means that the
"system"/internal fonts are not restored at all. So in result, the very
first call to fbcon_do_set_font() performs no restore at all upon
failing vc_resize().
This can be reproduced by Syzkaller to crash the system on the next
invocation of font_get(). It's rather hard to hit the allocation failure
in vc_resize() on the first font_set(), but not impossible. Esp. if
fault injection is used to aid the execution/failure. It was
demonstrated by Sirius:
BUG: unable to handle page fault for address: fff8
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0
Oops: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
04/01/2014
RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286
Call Trace:
con_font_get drivers/tty/vt/vt.c:4558 [inline]
con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673
vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]
vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752
tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803
vfs_ioctl fs/ioctl.c:51 [inline]
...
So restore the font data in any case, not only for user fonts. Note the
later 'if' is now protected by 'old_userfont' and not 'old_data' as the
latter is always set now. (And it is supposed to be non-NULL. Otherwise
we would see the bug above again.)
Signed-off-by: Jiri Slaby (SUSE)
Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize()
failed")
Reported-and-tested-by: Ubisectech Sirius
Cc: Ubisectech Sirius
Cc: Daniel Vetter
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20240208114411.14604-1-jirisl...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/video/fbdev/core/fbcon.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 63af6ab034b5f..e6c45d585482f 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2400,11 +2400,9 @@ static int fbcon_do_set_font(struct vc_data *vc, int w,
int h, int charcount,
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = _display[vc->vc_num];
int resize, ret, old_userfont, old_width, old_height, old_charcount;
- char *old_data = NULL;
+ u8 *old_data = vc->vc_font.data;
resize = (w != vc->vc_font.width) || (h != vc->vc_font.height);
- if (p->userfont)
- old_data = vc->vc_font.data;
vc->vc_font.data = (void *)(p->fontdata = data);
old_userfont = p->userfont;
if ((p->userfont = userfont))
@@ -2438,13 +2436,13 @@ static int fbcon_do_set_font(struct vc_data *vc, int w,
int h, int charcount,
update_screen(vc);
}
- if (old_data && (--REFCOUNT(old_data) == 0))
+ if (old_userfont && (--REFCOUNT(old_data) == 0))
kfree(old_data - FONT_EXTRA_WORDS * sizeof(int));
return 0;
err_out:
p->fontdata = old_data;
- vc->vc_font.data = (void *)old_data;
+ vc->vc_font.data = old_data;
if (userfont) {
p->userfont = old_userfont;
--
2.43.0
[PATCH 6.1 085/195] drm/ttm: Fix an invalid freeing on already freed page in error path
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellström
commit 40510a941d27d405a82dc3320823d875f94625df upstream.
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages already
freed in the first step.
Fix.
Signed-off-by: Thomas Hellström
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.4+
Reviewed-by: Matthew Auld
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_pool.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -383,7 +383,7 @@ static void ttm_pool_free_range(struct t
enum ttm_caching caching,
pgoff_t start_page, pgoff_t end_page)
{
- struct page **pages = tt->pages;
+ struct page **pages = >pages[start_page];
unsigned int order;
pgoff_t i, nr;
[PATCH 5.15 078/245] drm/ttm: Fix an invalid freeing on already freed page in error path
5.15-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellström
commit 40510a941d27d405a82dc3320823d875f94625df upstream.
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages already
freed in the first step.
Fix.
Signed-off-by: Thomas Hellström
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.4+
Reviewed-by: Matthew Auld
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_pool.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -384,7 +384,7 @@ static void ttm_pool_free_range(struct t
enum ttm_caching caching,
pgoff_t start_page, pgoff_t end_page)
{
- struct page **pages = tt->pages;
+ struct page **pages = >pages[start_page];
unsigned int order;
pgoff_t i, nr;
[PATCH 6.6 140/299] drm/ttm: Fix an invalid freeing on already freed page in error path
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellström
commit 40510a941d27d405a82dc3320823d875f94625df upstream.
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages already
freed in the first step.
Fix.
Signed-off-by: Thomas Hellström
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.4+
Reviewed-by: Matthew Auld
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_pool.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -384,7 +384,7 @@ static void ttm_pool_free_range(struct t
enum ttm_caching caching,
pgoff_t start_page, pgoff_t end_page)
{
- struct page **pages = tt->pages;
+ struct page **pages = >pages[start_page];
unsigned int order;
pgoff_t i, nr;
[PATCH 6.7 148/334] drm/ttm: Fix an invalid freeing on already freed page in error path
6.7-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Hellström
commit 40510a941d27d405a82dc3320823d875f94625df upstream.
If caching mode change fails due to, for example, OOM we
free the allocated pages in a two-step process. First the pages
for which the caching change has already succeeded. Secondly
the pages for which a caching change did not succeed.
However the second step was incorrectly freeing the pages already
freed in the first step.
Fix.
Signed-off-by: Thomas Hellström
Fixes: 379989e7cbdc ("drm/ttm/pool: Fix ttm_pool_alloc error path")
Cc: Christian König
Cc: Dave Airlie
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.4+
Reviewed-by: Matthew Auld
Reviewed-by: Christian König
Link:
https://patchwork.freedesktop.org/patch/msgid/20240221073324.3303-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/ttm/ttm_pool.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -387,7 +387,7 @@ static void ttm_pool_free_range(struct t
enum ttm_caching caching,
pgoff_t start_page, pgoff_t end_page)
{
- struct page **pages = tt->pages;
+ struct page **pages = >pages[start_page];
unsigned int order;
pgoff_t i, nr;
Re: [PATCH] gpu: host1x: bus: make host1x_bus_type const
On Tue, Feb 13, 2024 at 11:44:40AM -0300, Ricardo B. Marliere wrote:
> Since commit d492cc2573a0 ("driver core: device.h: make struct
> bus_type a const *"), the driver core can properly handle constant
> struct bus_type, move the host1x_bus_type variable to be a constant
> structure as well, placing it into read-only memory which can not be
> modified at runtime.
>
> Cc: Greg Kroah-Hartman
> Suggested-by: Greg Kroah-Hartman
> Signed-off-by: Ricardo B. Marliere
Reviewed-by: Greg Kroah-Hartman
Re: [PATCH 0/2] drivers: drm: struct bus_type cleanup
On Sat, Feb 03, 2024 at 03:25:02PM -0300, Ricardo B. Marliere wrote: > This series is part of an effort to cleanup the users of the driver > core, as can be seen in many recent patches authored by Greg across the > tree (e.g. [1]). Specifically, this series is part of the task of > splitting one of his TODOs [2]. > > --- > [1]: > https://lore.kernel.org/lkml/?q=f%3Agregkh%40linuxfoundation.org+s%3A%22make%22+and+s%3A%22const%22 > [2]: > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=bus_cleanup=26105f537f0c60eacfeb430abd2e05d7ddcdd8aa > > To: Maarten Lankhorst > To: Maxime Ripard > To: Thomas Zimmermann > To: David Airlie > To: Daniel Vetter > Cc: Greg Kroah-Hartman > Cc: > Cc: > Signed-off-by: Ricardo B. Marliere > > --- > Ricardo B. Marliere (2): > drm: display: make dp_aux_bus_type const > drm: mipi-dsi: make mipi_dsi_bus_type const > Reviewed-by: Greg Kroah-Hartman
Re: [PATCH 3/3] drm/amdgpu: wire up the can_remove() callback
On Fri, Feb 02, 2024 at 05:25:56PM -0500, Hamza Mahfooz wrote:
> Removing an amdgpu device that still has user space references allocated
> to it causes undefined behaviour. So, implement amdgpu_pci_can_remove()
> and disallow devices that still have files allocated to them from being
> unbound.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Hamza Mahfooz
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index cc69005f5b46..cfa64f3c5be5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2323,6 +2323,22 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> return ret;
> }
>
> +static bool amdgpu_pci_can_remove(struct pci_dev *pdev)
> +{
> + struct drm_device *dev = pci_get_drvdata(pdev);
> +
> + mutex_lock(>filelist_mutex);
> +
> + if (!list_empty(>filelist)) {
> + mutex_unlock(>filelist_mutex);
> + return false;
> + }
> +
> + mutex_unlock(>filelist_mutex);
> +
> + return true;
Also, to be pedantic, this will not work as right after you returned
"true" here, userspace could open a file, causing the same issue you are
trying to prevent to have happen, happen.
So even if we wanted to do this, which again, we do not, this isn't even
a solution for it because it will still cause you problems.
greg k-h
Re: [PATCH 3/3] drm/amdgpu: wire up the can_remove() callback
On Fri, Feb 02, 2024 at 05:25:56PM -0500, Hamza Mahfooz wrote: > Removing an amdgpu device that still has user space references allocated > to it causes undefined behaviour. Then fix that please. There should not be anything special about your hardware that all of the tens of thousands of other devices can't handle today. What happens when I yank your device out of a system with a pci hotplug bus? You can't prevent that either, so this should not be any different at all. sorry, but please, just fix your driver. greg k-h
Re: [PATCH 2/3] PCI: introduce can_remove()
On Fri, Feb 02, 2024 at 05:25:55PM -0500, Hamza Mahfooz wrote: > Wire up the can_remove() callback, such that pci drivers can implement > their own version of it. > > Cc: sta...@vger.kernel.org > Signed-off-by: Hamza Mahfooz > --- Again, sorry, nope, not allowed.
Re: [PATCH 1/3] driver core: bus: introduce can_remove()
On Fri, Feb 02, 2024 at 05:25:54PM -0500, Hamza Mahfooz wrote: > Currently, drivers have no mechanism to block requests to unbind > devices. And that is by design. > However, this can cause resource leaks and leave the device in > an inconsistent state, such that rebinding the device may cause a hang > or otherwise prevent the device from being rebound. That is a driver bug, please fix your driver. > So, introduce the can_remove() callback to allow drivers to indicate > if it isn't appropriate to remove a device at the given time. Nope, sorry, the driver needs to be fixed. What broken driver are you needing this for? Also realize, only root can unbind drivers (and it can also unload modules), so if the root user really wants to do this, it can, and should be possible to. sorry, greg k-h
Re: [PATCH 40/46] dma-buf: move dma-buf symbols into the DMA_BUF module namespace.
On Fri, Feb 02, 2024 at 02:01:47PM +0530, Kolanupaka Naveena wrote: > +#ifdef BPM_MODULE_IMPORT_NS_SUPPORT > +#include > +#endif No #ifdef in .c files please, this should not be an issue, just include the .h file. > #include > > #include "gem/i915_gem_dmabuf.h" > @@ -23,6 +26,10 @@ > #include "i915_trace.h" > #include "intel_iaf.h" > > +#ifdef BPM_MODULE_IMPORT_NS_SUPPORT > +MODULE_IMPORT_NS(DMA_BUF); > +#endif Why is a #ifdef needed here? If this isn't built as a module, it's not an issue, please just make it simpler. But really, why is this a #define at all in the first place? thanks, greg k-h
[PATCH 6.6 259/331] drm: Disable the cursor plane on atomic contexts with virtualized drivers
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit 4e3b70da64a53784683cfcbac2deda5d6e540407 upstream.
Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g. the cursor plane
should react to the mouse movement the way a mouse cursor would be
expected to and the client is required to set hotspot properties on it
in order for the mouse events to be routed correctly.
This breaks the contract as specified by the "universal planes". Fix it
by disabling the cursor planes on virtualized drivers while adding
a foundation on top of which it's possible to special case mouse cursor
planes for clients that want it.
Disabling the cursor planes makes some kms compositors which were broken,
e.g. Weston, fallback to software cursor which works fine or at least
better than currently while having no effect on others, e.g. gnome-shell
or kwin, which put virtualized drivers on a deny-list when running in
atomic context to make them fallback to legacy kms and avoid this issue.
Signed-off-by: Zack Rusin
Fixes: 681e7ec73044 ("drm: Allow userspace to ask for universal plane list
(v2)")
Cc: # v5.4+
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Hans de Goede
Cc: Gurchetan Singh
Cc: Chia-I Wu
Cc: dri-devel@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
Acked-by: Pekka Paalanen
Reviewed-by: Javier Martinez Canillas
Acked-by: Simon Ser
Signed-off-by: Javier Martinez Canillas
Link:
https://patchwork.freedesktop.org/patch/msgid/20231023074613.41327-2-aest...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_plane.c | 13 +
drivers/gpu/drm/qxl/qxl_drv.c|2 +-
drivers/gpu/drm/vboxvideo/vbox_drv.c |2 +-
drivers/gpu/drm/virtio/virtgpu_drv.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 +-
include/drm/drm_drv.h|9 +
include/drm/drm_file.h | 12
7 files changed, 38 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -678,6 +678,19 @@ int drm_mode_getplane_res(struct drm_dev
!file_priv->universal_planes)
continue;
+ /*
+* If we're running on a virtualized driver then,
+* unless userspace advertizes support for the
+* virtualized cursor plane, disable cursor planes
+* because they'll be broken due to missing cursor
+* hotspot info.
+*/
+ if (plane->type == DRM_PLANE_TYPE_CURSOR &&
+ drm_core_check_feature(dev, DRIVER_CURSOR_HOTSPOT) &&
+ file_priv->atomic &&
+ !file_priv->supports_virtualized_cursor_plane)
+ continue;
+
if (drm_lease_held(file_priv, plane->base.id)) {
if (count < plane_resp->count_planes &&
put_user(plane->base.id, plane_ptr + count))
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -283,7 +283,7 @@ static const struct drm_ioctl_desc qxl_i
};
static struct drm_driver qxl_driver = {
- .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+ .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
DRIVER_CURSOR_HOTSPOT,
.dumb_create = qxl_mode_dumb_create,
.dumb_map_offset = drm_gem_ttm_dumb_map_offset,
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -182,7 +182,7 @@ DEFINE_DRM_GEM_FOPS(vbox_fops);
static const struct drm_driver driver = {
.driver_features =
- DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
+ DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC | DRIVER_CURSOR_HOTSPOT,
.fops = _fops,
.name = DRIVER_NAME,
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -177,7 +177,7 @@ static const struct drm_driver driver =
* out via drm_device::driver_features:
*/
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_RENDER |
DRIVER_ATOMIC |
- DRIVER_SYNCOBJ | DRIVER_SYNCOBJ_TIMELINE,
+ DRIVER_SYNCOBJ | DRIVER_SYNCOBJ_TIMELINE |
DRIVER_CURSOR_HOTSPOT,
.open = virtio_gpu_driver_open,
.postclose = virtio_gpu_driver_postclose,
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1611,7 +1611,7 @@ static const struct file_operations vmwg
static const struct drm_driver driver = {
.driver_features =
- DRIVER_MODESET | DRIVER
[PATCH 6.6 257/331] drm: Fix TODO list mentioning non-KMS drivers
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 9cf5ca1f485cae406968947a92bf304603999fa1 upstream.
Non-KMS drivers have been removed from DRM. Update the TODO list
accordingly.
Signed-off-by: Thomas Zimmermann
Fixes: a276afc19eec ("drm: Remove some obsolete drm pciids(tdfx, mga, i810,
savage, r128, sis, via)")
Cc: Cai Huoqing
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Thomas Zimmermann
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jonathan Corbet
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.3+
Cc: linux-...@vger.kernel.org
Reviewed-by: David Airlie
Reviewed-by: Daniel Vetter
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20231122122449.11588-3-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
Documentation/gpu/todo.rst | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 503d57c75215..41a264bf84ce 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -337,8 +337,8 @@ connector register/unregister fixes
Level: Intermediate
-Remove load/unload callbacks from all non-DRIVER_LEGACY drivers
+Remove load/unload callbacks
+
The load/unload callbacks in struct _driver are very much midlayers, plus
for historical reasons they get the ordering wrong (and we can't fix that)
@@ -347,8 +347,7 @@ between setting up the _driver structure and calling
drm_dev_register().
- Rework drivers to no longer use the load/unload callbacks, directly coding
the
load/unload sequence into the driver's probe function.
-- Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload
- callbacks for all modern drivers.
+- Once all drivers are converted, remove the load/unload callbacks.
Contact: Daniel Vetter
--
2.43.0
[PATCH 6.7 253/346] drm: Disable the cursor plane on atomic contexts with virtualized drivers
6.7-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit 4e3b70da64a53784683cfcbac2deda5d6e540407 upstream.
Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g. the cursor plane
should react to the mouse movement the way a mouse cursor would be
expected to and the client is required to set hotspot properties on it
in order for the mouse events to be routed correctly.
This breaks the contract as specified by the "universal planes". Fix it
by disabling the cursor planes on virtualized drivers while adding
a foundation on top of which it's possible to special case mouse cursor
planes for clients that want it.
Disabling the cursor planes makes some kms compositors which were broken,
e.g. Weston, fallback to software cursor which works fine or at least
better than currently while having no effect on others, e.g. gnome-shell
or kwin, which put virtualized drivers on a deny-list when running in
atomic context to make them fallback to legacy kms and avoid this issue.
Signed-off-by: Zack Rusin
Fixes: 681e7ec73044 ("drm: Allow userspace to ask for universal plane list
(v2)")
Cc: # v5.4+
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Hans de Goede
Cc: Gurchetan Singh
Cc: Chia-I Wu
Cc: dri-devel@lists.freedesktop.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
Acked-by: Pekka Paalanen
Reviewed-by: Javier Martinez Canillas
Acked-by: Simon Ser
Signed-off-by: Javier Martinez Canillas
Link:
https://patchwork.freedesktop.org/patch/msgid/20231023074613.41327-2-aest...@redhat.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_plane.c | 13 +
drivers/gpu/drm/qxl/qxl_drv.c|2 +-
drivers/gpu/drm/vboxvideo/vbox_drv.c |2 +-
drivers/gpu/drm/virtio/virtgpu_drv.c |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 +-
include/drm/drm_drv.h|9 +
include/drm/drm_file.h | 12
7 files changed, 38 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -678,6 +678,19 @@ int drm_mode_getplane_res(struct drm_dev
!file_priv->universal_planes)
continue;
+ /*
+* If we're running on a virtualized driver then,
+* unless userspace advertizes support for the
+* virtualized cursor plane, disable cursor planes
+* because they'll be broken due to missing cursor
+* hotspot info.
+*/
+ if (plane->type == DRM_PLANE_TYPE_CURSOR &&
+ drm_core_check_feature(dev, DRIVER_CURSOR_HOTSPOT) &&
+ file_priv->atomic &&
+ !file_priv->supports_virtualized_cursor_plane)
+ continue;
+
if (drm_lease_held(file_priv, plane->base.id)) {
if (count < plane_resp->count_planes &&
put_user(plane->base.id, plane_ptr + count))
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -285,7 +285,7 @@ static const struct drm_ioctl_desc qxl_i
};
static struct drm_driver qxl_driver = {
- .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+ .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
DRIVER_CURSOR_HOTSPOT,
.dumb_create = qxl_mode_dumb_create,
.dumb_map_offset = drm_gem_ttm_dumb_map_offset,
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -182,7 +182,7 @@ DEFINE_DRM_GEM_FOPS(vbox_fops);
static const struct drm_driver driver = {
.driver_features =
- DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
+ DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC | DRIVER_CURSOR_HOTSPOT,
.fops = _fops,
.name = DRIVER_NAME,
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -177,7 +177,7 @@ static const struct drm_driver driver =
* out via drm_device::driver_features:
*/
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_RENDER |
DRIVER_ATOMIC |
- DRIVER_SYNCOBJ | DRIVER_SYNCOBJ_TIMELINE,
+ DRIVER_SYNCOBJ | DRIVER_SYNCOBJ_TIMELINE |
DRIVER_CURSOR_HOTSPOT,
.open = virtio_gpu_driver_open,
.postclose = virtio_gpu_driver_postclose,
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1611,7 +1611,7 @@ static const struct file_operations vmwg
static const struct drm_driver driver = {
.driver_features =
- DRIVER_MODESET | DRIVER
[PATCH 6.7 251/346] drm: Fix TODO list mentioning non-KMS drivers
6.7-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 9cf5ca1f485cae406968947a92bf304603999fa1 upstream.
Non-KMS drivers have been removed from DRM. Update the TODO list
accordingly.
Signed-off-by: Thomas Zimmermann
Fixes: a276afc19eec ("drm: Remove some obsolete drm pciids(tdfx, mga, i810,
savage, r128, sis, via)")
Cc: Cai Huoqing
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Thomas Zimmermann
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jonathan Corbet
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.3+
Cc: linux-...@vger.kernel.org
Reviewed-by: David Airlie
Reviewed-by: Daniel Vetter
Acked-by: Alex Deucher
Link:
https://patchwork.freedesktop.org/patch/msgid/20231122122449.11588-3-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman
---
Documentation/gpu/todo.rst |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -337,8 +337,8 @@ connector register/unregister fixes
Level: Intermediate
-Remove load/unload callbacks from all non-DRIVER_LEGACY drivers
+Remove load/unload callbacks
+
The load/unload callbacks in struct _driver are very much midlayers, plus
for historical reasons they get the ordering wrong (and we can't fix that)
@@ -347,8 +347,7 @@ between setting up the _driver struc
- Rework drivers to no longer use the load/unload callbacks, directly coding
the
load/unload sequence into the driver's probe function.
-- Once all non-DRIVER_LEGACY drivers are converted, disallow the load/unload
- callbacks for all modern drivers.
+- Once all drivers are converted, remove the load/unload callbacks.
Contact: Daniel Vetter
Re: [PATCH v2 25/33] staging: fbtft: Follow renaming of SPI "master" to "controller"
On Mon, Jan 22, 2024 at 07:07:20PM +0100, Uwe Kleine-König wrote:
> In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
> some functions and struct members were renamed. To not break all drivers
> compatibility macros were provided.
>
> To be able to remove these compatibility macros push the renaming into
> this driver.
>
> Signed-off-by: Uwe Kleine-König
> ---
Acked-by: Greg Kroah-Hartman
Re: [PATCH v2 00/33] spi: get rid of some legacy macros
On Wed, Jan 24, 2024 at 05:22:00PM +, Mark Brown wrote: > On Wed, Jan 24, 2024 at 09:13:49AM -0800, Greg Kroah-Hartman wrote: > > On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote: > > > > Note that Jonathan Cameron has already applied patch 3 to his tree, it > > > didn't appear in a public tree though yet. I still included it here to > > > make the kernel build bots happy. > > > Are we supposed to take the individual changes in our different > > subsystem trees, or do you want them all to go through the spi tree? > > Given that the final patch removes the legacy interfaces I'm expecting > to take them via SPI. Great, thanks, I'll go ack the subsystem patches that are relevent for me. greg k-h
Re: [PATCH v2 00/33] spi: get rid of some legacy macros
On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote: > Hello, > > this is v2 of this patch set. > > Changes since (implicit) v1, sent with Message-Id: > cover.1705348269.git.u.kleine-koe...@pengutronix.de: > > - Rebase to v6.8-rc1 > - Fix a build failure on sh > - Added the tags received in (implicit) v1. > > The slave-mt27xx driver needs some more work. The patch presented here > is enough however to get rid of the defines handled in patch 32. > Cleaning that up is out-of-scope for this series, so I'll delay that > until later. > > Note that Jonathan Cameron has already applied patch 3 to his tree, it > didn't appear in a public tree though yet. I still included it here to > make the kernel build bots happy. Are we supposed to take the individual changes in our different subsystem trees, or do you want them all to go through the spi tree? Either is fine with me, just need to know. thanks, greg k-h
Re: [PATCH 5.10 1/1] drm/qxl: fix UAF on handle creation
On Tue, Jan 09, 2024 at 02:08:25PM +0300, Fedor Pchelkin wrote: > From: Wander Lairson Costa > > commit c611589b4259ed63b9b77be6872b1ce07ec0ac16 upstream. Now queued up, thanks. greg k-h
Re: [PATCH] vt: remove superfluous CONFIG_HW_CONSOLE
On Mon, Jan 08, 2024 at 02:41:02PM +0100, Lukas Bulwahn wrote: > The config HW_CONSOLE is always identical to the config VT and is not > visible in the kernel's build menuconfig. So, CONFIG_HW_CONSOLE is > redundant. > > Replace all references to CONFIG_HW_CONSOLE with CONFIG_VT and remove > CONFIG_HW_CONSOLE. > > Signed-off-by: Lukas Bulwahn > --- > I think this patch is best picked up by Greg rather than splitting it > in smaller pieces for m68k, amiga keyboard, fbdev etc. > > Greg, if that is fine, could you pick this for the next merge window? Yes, the "next" one, it's too late for 6.8-rc1, sorry. I'll look at it after -rc1 is out. thanks, greg k-h
Re: [PATCH 24/27] sparc32: Drop config SPARC_LEON
On Tue, Dec 19, 2023 at 11:03:29PM +0100, Sam Ravnborg via B4 Relay wrote: > From: Sam Ravnborg > > The only support sparc32 CPU is LEON, so there is no need for a > config option to select it. > > Signed-off-by: Sam Ravnborg > Cc: "David S. Miller" > Cc: Arnd Bergmann > Cc: Andreas Larsson For the USB stuff: Acked-by: Greg Kroah-Hartman
Re: [PATCH RESEND 0/6] drm: simplify support for transparent DRM bridges
On Sun, Dec 03, 2023 at 02:43:27PM +0300, Dmitry Baryshkov wrote: > Greg, could you please ack the last patch to be merged through the > drm-misc tree? You have acked patch 3, but since that time I've added > patches 4-6. That is up to the typec maintainer to ack, not me! thanks, greg k-h
[PATCH] driver core: make device_is_dependent() static
The function device_is_dependent() is only called by the driver core
internally and should not, at this time, be called by anyone else
outside of it, so mark it as static so as not to give driver authors the
wrong idea.
Cc: "Rafael J. Wysocki"
Cc: Saravana Kannan
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/core.c| 2 +-
include/linux/device.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index dafdb9970901..6dcc26eec096 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -298,7 +298,7 @@ static inline bool device_link_flag_is_sync_state_only(u32
flags)
* Check if @target depends on @dev or any device dependent on it (its child or
* its consumer etc). Return 1 if that is the case or 0 otherwise.
*/
-int device_is_dependent(struct device *dev, void *target)
+static int device_is_dependent(struct device *dev, void *target)
{
struct device_link *link;
int ret;
diff --git a/include/linux/device.h b/include/linux/device.h
index c11d60cabaab..6a4ee40af3df 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1071,7 +1071,6 @@ int device_rename(struct device *dev, const char
*new_name);
int device_move(struct device *dev, struct device *new_parent,
enum dpm_order dpm_order);
int device_change_owner(struct device *dev, kuid_t kuid, kgid_t kgid);
-int device_is_dependent(struct device *dev, void *target);
static inline bool device_supports_offline(struct device *dev)
{
--
2.43.0
Re: [PATCH 0/3] Revert panel fixes and original buggy patch
On Tue, Nov 28, 2023 at 01:52:44AM +0200, Laurent Pinchart wrote: > On Tue, Nov 28, 2023 at 12:36:15AM +0100, Linus Walleij wrote: > > On Tue, Nov 28, 2023 at 12:25 AM Laurent Pinchart wrote: > > > On Tue, Nov 28, 2023 at 12:10:18AM +0100, Linus Walleij wrote: > > > > This series reverts the attempts to fix the bug that went > > > > into v6.7-rc1 in commit 199cf07ebd2b > > > > "drm/bridge: panel: Add a device link between drm device and panel > > > > device" > > > > and then it reverts that patch as well. > > > > > > > > Signed-off-by: Linus Walleij > > > > --- > > > > Linus Walleij (3): > > > > Revert "driver core: Export device_is_dependent() to modules" > > > > Revert "drm/bridge: panel: Check device dependency before > > > > managing device link" > > > > Revert "drm/bridge: panel: Add a device link between drm device > > > > and panel device" > > > > > > To preserve bisectability, you should revert in the opposite order. > > > > You mean apply patch 2, then 1, then 3 so the kernel builds after each > > revert? > > > > Yeah that's a good idea, I don't know if I should apply these though, better > > someone else do it since I screwed up too much. > > > > Another option is to just squash the reverts into one, that bisects too :/ > > I thought the commits have been applied to drm-misc in a bisectable > order in the first place, but that doesn't seem to be the case :-( > Reverting "driver core: Export device_is_dependent() to modules" last > seems to be the best option in this case. I wouldn't squash them. Agreed, don't squash, just revert in the opposite order they were applied in originally, that way the tree can always build. thanks, greg k-h
Re: [PATCH v2 26/32] staging/sm750fb: Initialize fb_ops with fbdev macros
On Mon, Nov 27, 2023 at 02:15:55PM +0100, Thomas Zimmermann wrote: > Initialize all instances of struct fb_ops with fbdev initializer > macros for framebuffers in I/O address space. Set the read/write, > draw and mmap callbacks to the correct implementation and avoid > implicit defaults. Also select the necessary helpers in Kconfig. > > Fbdev drivers sometimes rely on the callbacks being NULL for a > default I/O-memory-based implementation to be invoked; hence > requiring the I/O helpers to be built in any case. Setting all > callbacks in all drivers explicitly will allow to make the I/O > helpers optional. This benefits systems that do not use these > functions. > > Signed-off-by: Thomas Zimmermann > Cc: Sudip Mukherjee > Cc: Teddy Wang > Cc: Greg Kroah-Hartman > Cc: linux-stag...@lists.linux.dev > Reviewed-by: Javier Martinez Canillas Acked-by: Greg Kroah-Hartman
Re: [PATCH v2 25/32] staging/sm750fb: Declare fb_ops as constant
On Mon, Nov 27, 2023 at 02:15:54PM +0100, Thomas Zimmermann wrote: > Split up lynxfb_ops and declare each as constant. The fb_ops > instance used to be modified while initializing the driver. It is > now constant and the driver picks the correct instance, depending > on the settings for acceleration and cursor support. > > Signed-off-by: Thomas Zimmermann > Cc: Sudip Mukherjee > Cc: Teddy Wang > Cc: Greg Kroah-Hartman > Cc: linux-stag...@lists.linux.dev > Acked-by: Javier Martinez Canillas > --- > drivers/staging/sm750fb/sm750.c | 59 +++-- > 1 file changed, 49 insertions(+), 10 deletions(-) Acked-by: Greg Kroah-Hartman
[PATCH 6.1 324/372] drm/mediatek/dp: fix memory leak on ->get_edid callback audio detection
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
commit dab12fa8d2bd3868cf2de485ed15a3feef28a13d upstream.
The sads returned by drm_edid_to_sad() needs to be freed.
Fixes: e71a8ebbe086 ("drm/mediatek: dp: Audio support for MT8195")
Cc: Guillaume Ranquet
Cc: Bo-Chen Chen
Cc: AngeloGioacchino Del Regno
Cc: Dmitry Osipenko
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: # v6.1+
Signed-off-by: Jani Nikula
Reviewed-by: Chen-Yu Tsai
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20230914155317.2511876-1-jani.nik...@intel.com/
Signed-off-by: Chun-Kuang Hu
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/mediatek/mtk_dp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -1983,7 +1983,6 @@ static struct edid *mtk_dp_get_edid(stru
bool enabled = mtk_dp->enabled;
struct edid *new_edid = NULL;
struct mtk_dp_audio_cfg *audio_caps = _dp->info.audio_cur_cfg;
- struct cea_sad *sads;
if (!enabled) {
drm_bridge_chain_pre_enable(bridge);
@@ -2010,7 +2009,11 @@ static struct edid *mtk_dp_get_edid(stru
}
if (new_edid) {
+ struct cea_sad *sads;
+
audio_caps->sad_count = drm_edid_to_sad(new_edid, );
+ kfree(sads);
+
audio_caps->detect_monitor = drm_detect_monitor_audio(new_edid);
}
[PATCH 6.1 325/372] drm/mediatek/dp: fix memory leak on ->get_edid callback error path
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
commit fcaf9761fd5884a64eaac48536f8c27ecfd2e6bc upstream.
Setting new_edid to NULL leaks the buffer.
Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
Cc: Markus Schneider-Pargmann
Cc: Guillaume Ranquet
Cc: Bo-Chen Chen
Cc: CK Hu
Cc: AngeloGioacchino Del Regno
Cc: Dmitry Osipenko
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: # v6.1+
Signed-off-by: Jani Nikula
Reviewed-by: Guillaume Ranquet
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20230914131058.2472260-1-jani.nik...@intel.com/
Signed-off-by: Chun-Kuang Hu
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/mediatek/mtk_dp.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2005,6 +2005,7 @@ static struct edid *mtk_dp_get_edid(stru
*/
if (mtk_dp_parse_capabilities(mtk_dp)) {
drm_err(mtk_dp->drm_dev, "Can't parse capabilities\n");
+ kfree(new_edid);
new_edid = NULL;
}
[PATCH 6.5 428/491] drm/mediatek/dp: fix memory leak on ->get_edid callback error path
6.5-stable review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
commit fcaf9761fd5884a64eaac48536f8c27ecfd2e6bc upstream.
Setting new_edid to NULL leaks the buffer.
Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
Cc: Markus Schneider-Pargmann
Cc: Guillaume Ranquet
Cc: Bo-Chen Chen
Cc: CK Hu
Cc: AngeloGioacchino Del Regno
Cc: Dmitry Osipenko
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: # v6.1+
Signed-off-by: Jani Nikula
Reviewed-by: Guillaume Ranquet
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20230914131058.2472260-1-jani.nik...@intel.com/
Signed-off-by: Chun-Kuang Hu
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/mediatek/mtk_dp.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2005,6 +2005,7 @@ static struct edid *mtk_dp_get_edid(stru
*/
if (mtk_dp_parse_capabilities(mtk_dp)) {
drm_err(mtk_dp->drm_dev, "Can't parse capabilities\n");
+ kfree(new_edid);
new_edid = NULL;
}
[PATCH 6.5 427/491] drm/mediatek/dp: fix memory leak on ->get_edid callback audio detection
6.5-stable review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
commit dab12fa8d2bd3868cf2de485ed15a3feef28a13d upstream.
The sads returned by drm_edid_to_sad() needs to be freed.
Fixes: e71a8ebbe086 ("drm/mediatek: dp: Audio support for MT8195")
Cc: Guillaume Ranquet
Cc: Bo-Chen Chen
Cc: AngeloGioacchino Del Regno
Cc: Dmitry Osipenko
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: # v6.1+
Signed-off-by: Jani Nikula
Reviewed-by: Chen-Yu Tsai
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20230914155317.2511876-1-jani.nik...@intel.com/
Signed-off-by: Chun-Kuang Hu
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/mediatek/mtk_dp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -1983,7 +1983,6 @@ static struct edid *mtk_dp_get_edid(stru
bool enabled = mtk_dp->enabled;
struct edid *new_edid = NULL;
struct mtk_dp_audio_cfg *audio_caps = _dp->info.audio_cur_cfg;
- struct cea_sad *sads;
if (!enabled) {
drm_atomic_bridge_chain_pre_enable(bridge,
connector->state->state);
@@ -2010,7 +2009,11 @@ static struct edid *mtk_dp_get_edid(stru
}
if (new_edid) {
+ struct cea_sad *sads;
+
audio_caps->sad_count = drm_edid_to_sad(new_edid, );
+ kfree(sads);
+
audio_caps->detect_monitor = drm_detect_monitor_audio(new_edid);
}
[PATCH 6.6 461/530] drm/mediatek/dp: fix memory leak on ->get_edid callback error path
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
commit fcaf9761fd5884a64eaac48536f8c27ecfd2e6bc upstream.
Setting new_edid to NULL leaks the buffer.
Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
Cc: Markus Schneider-Pargmann
Cc: Guillaume Ranquet
Cc: Bo-Chen Chen
Cc: CK Hu
Cc: AngeloGioacchino Del Regno
Cc: Dmitry Osipenko
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: # v6.1+
Signed-off-by: Jani Nikula
Reviewed-by: Guillaume Ranquet
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20230914131058.2472260-1-jani.nik...@intel.com/
Signed-off-by: Chun-Kuang Hu
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/mediatek/mtk_dp.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2048,6 +2048,7 @@ static struct edid *mtk_dp_get_edid(stru
*/
if (mtk_dp_parse_capabilities(mtk_dp)) {
drm_err(mtk_dp->drm_dev, "Can't parse capabilities\n");
+ kfree(new_edid);
new_edid = NULL;
}
[PATCH 6.6 460/530] drm/mediatek/dp: fix memory leak on ->get_edid callback audio detection
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
commit dab12fa8d2bd3868cf2de485ed15a3feef28a13d upstream.
The sads returned by drm_edid_to_sad() needs to be freed.
Fixes: e71a8ebbe086 ("drm/mediatek: dp: Audio support for MT8195")
Cc: Guillaume Ranquet
Cc: Bo-Chen Chen
Cc: AngeloGioacchino Del Regno
Cc: Dmitry Osipenko
Cc: Chun-Kuang Hu
Cc: Philipp Zabel
Cc: Matthias Brugger
Cc: dri-devel@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: # v6.1+
Signed-off-by: Jani Nikula
Reviewed-by: Chen-Yu Tsai
Link:
https://patchwork.kernel.org/project/dri-devel/patch/20230914155317.2511876-1-jani.nik...@intel.com/
Signed-off-by: Chun-Kuang Hu
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/mediatek/mtk_dp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2034,7 +2034,6 @@ static struct edid *mtk_dp_get_edid(stru
bool enabled = mtk_dp->enabled;
struct edid *new_edid = NULL;
struct mtk_dp_audio_cfg *audio_caps = _dp->info.audio_cur_cfg;
- struct cea_sad *sads;
if (!enabled) {
drm_atomic_bridge_chain_pre_enable(bridge,
connector->state->state);
@@ -2053,7 +2052,11 @@ static struct edid *mtk_dp_get_edid(stru
}
if (new_edid) {
+ struct cea_sad *sads;
+
audio_caps->sad_count = drm_edid_to_sad(new_edid, );
+ kfree(sads);
+
audio_caps->detect_monitor = drm_detect_monitor_audio(new_edid);
}
Re: [PATCH 20/22] usb: fsl-mph-dr-of: mark fsl_usb2_mpc5121_init() static
On Wed, Nov 08, 2023 at 01:58:41PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This function is only called locally and should always have been static:
>
> drivers/usb/host/fsl-mph-dr-of.c:291:5: error: no previous prototype for
> 'fsl_usb2_mpc5121_init' [-Werror=missing-prototypes]
>
> Fixes: 230f7ede6c2f ("USB: add USB EHCI support for MPC5121 SoC")
> Signed-off-by: Arnd Bergmann
Acked-by: Greg Kroah-Hartman
[PATCH 6.6 215/603] drm: bridge: for GENERIC_PHY_MIPI_DPHY also select GENERIC_PHY
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 96413b355a49fd684430a230479bd231d977894f ]
Three DRM bridge drivers select GENERIC_PHY_MIPI_DPHY when GENERIC_PHY
might not be set. This causes Kconfig warnings and a build error.
WARNING: unmet direct dependencies detected for GENERIC_PHY_MIPI_DPHY
Depends on [n]: GENERIC_PHY [=n]
Selected by [y]:
- DRM_NWL_MIPI_DSI [=y] && DRM_BRIDGE [=y] && DRM [=y] && COMMON_CLK [=y] &&
OF [=y] && HAS_IOMEM [=y]
- DRM_SAMSUNG_DSIM [=y] && DRM [=y] && DRM_BRIDGE [=y] && COMMON_CLK [=y] &&
OF [=y] && HAS_IOMEM [=y]
(drm/bridge/cadence/Kconfig was found by inspection.)
aarch64-linux-ld: drivers/gpu/drm/bridge/samsung-dsim.o: in function
`samsung_dsim_set_phy_ctrl':
drivers/gpu/drm/bridge/samsung-dsim.c:731: undefined reference to
`phy_mipi_dphy_get_default_config_for_hsclk'
Prevent these warnings and build error by also selecting GENERIC_PHY
whenever selecting GENERIC_PHY_MIPI_DPHY.
Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
Fixes: 44cfc6233447 ("drm/bridge: Add NWL MIPI DSI host controller support")
Fixes: 171b3b1e0f8b ("drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY")
Signed-off-by: Randy Dunlap
Reported-by: Aleksandr Nogikh
Link: lore.kernel.org/r/20230803144227.2187749-1-nog...@google.com
Cc: Adam Ford
Cc: Maxime Ripard
Cc: Guido Günther
Cc: Robert Chiras
Cc: Sam Ravnborg
Cc: Neil Armstrong
Cc: Andrzej Hajda
Cc: Robert Foss
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Adam Ford
Tested-by: Aleksandr Nogikh
Reviewed-by: Guido Günther
Signed-off-by: Robert Foss
Link:
https://patchwork.freedesktop.org/patch/msgid/20230804030140.21395-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/Kconfig | 2 ++
drivers/gpu/drm/bridge/cadence/Kconfig | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 44a660a4bdbfc..ba82a1142adf7 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -181,6 +181,7 @@ config DRM_NWL_MIPI_DSI
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
select MFD_SYSCON
select MULTIPLEXER
@@ -227,6 +228,7 @@ config DRM_SAMSUNG_DSIM
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
help
The Samsung MIPI DSIM bridge controller driver.
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index ec35215a20034..cced81633ddcd 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -4,6 +4,7 @@ config DRM_CDNS_DSI
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
depends on OF
help
--
2.42.0
[PATCH 6.5 203/550] drm: bridge: for GENERIC_PHY_MIPI_DPHY also select GENERIC_PHY
6.5-stable review patch. If anyone has any objections, please let me know.
--
From: Randy Dunlap
[ Upstream commit 96413b355a49fd684430a230479bd231d977894f ]
Three DRM bridge drivers select GENERIC_PHY_MIPI_DPHY when GENERIC_PHY
might not be set. This causes Kconfig warnings and a build error.
WARNING: unmet direct dependencies detected for GENERIC_PHY_MIPI_DPHY
Depends on [n]: GENERIC_PHY [=n]
Selected by [y]:
- DRM_NWL_MIPI_DSI [=y] && DRM_BRIDGE [=y] && DRM [=y] && COMMON_CLK [=y] &&
OF [=y] && HAS_IOMEM [=y]
- DRM_SAMSUNG_DSIM [=y] && DRM [=y] && DRM_BRIDGE [=y] && COMMON_CLK [=y] &&
OF [=y] && HAS_IOMEM [=y]
(drm/bridge/cadence/Kconfig was found by inspection.)
aarch64-linux-ld: drivers/gpu/drm/bridge/samsung-dsim.o: in function
`samsung_dsim_set_phy_ctrl':
drivers/gpu/drm/bridge/samsung-dsim.c:731: undefined reference to
`phy_mipi_dphy_get_default_config_for_hsclk'
Prevent these warnings and build error by also selecting GENERIC_PHY
whenever selecting GENERIC_PHY_MIPI_DPHY.
Fixes: fced5a364dee ("drm/bridge: cdns: Convert to phy framework")
Fixes: 44cfc6233447 ("drm/bridge: Add NWL MIPI DSI host controller support")
Fixes: 171b3b1e0f8b ("drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY")
Signed-off-by: Randy Dunlap
Reported-by: Aleksandr Nogikh
Link: lore.kernel.org/r/20230803144227.2187749-1-nog...@google.com
Cc: Adam Ford
Cc: Maxime Ripard
Cc: Guido Günther
Cc: Robert Chiras
Cc: Sam Ravnborg
Cc: Neil Armstrong
Cc: Andrzej Hajda
Cc: Robert Foss
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Adam Ford
Tested-by: Aleksandr Nogikh
Reviewed-by: Guido Günther
Signed-off-by: Robert Foss
Link:
https://patchwork.freedesktop.org/patch/msgid/20230804030140.21395-1-rdun...@infradead.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/bridge/Kconfig | 2 ++
drivers/gpu/drm/bridge/cadence/Kconfig | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 82c68b0424443..42d05a247511a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -181,6 +181,7 @@ config DRM_NWL_MIPI_DSI
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
select MFD_SYSCON
select MULTIPLEXER
@@ -227,6 +228,7 @@ config DRM_SAMSUNG_DSIM
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
help
The Samsung MIPI DSIM bridge controller driver.
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index ec35215a20034..cced81633ddcd 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -4,6 +4,7 @@ config DRM_CDNS_DSI
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL_BRIDGE
+ select GENERIC_PHY
select GENERIC_PHY_MIPI_DPHY
depends on OF
help
--
2.42.0
Re: [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
On Tue, Nov 07, 2023 at 01:18:14PM +0100, Maxime Ripard wrote: > On Tue, Nov 07, 2023 at 12:22:21PM +0100, Greg Kroah-Hartman wrote: > > On Tue, Nov 07, 2023 at 11:57:49AM +0100, Maxime Ripard wrote: > > > +GKH > > > > Why? I don't see a question for me here, sorry. > > I guess the question is: we have a bus with various power states > (powered off, low power, high speed) Great, have fun! And is this per-device or per-bus-instance? > low power is typically used to send commands to a device, high speed to > transmit pixels, but still allows to send commands. > > Depending on the devices, there's different requirements about the state > devices expect the bus to be in to send commands. Some will need to send > all the commands in the low power state, some don't care, etc. See > the mail I was replying too for more details. > > We've tried so far to model that in KMS itself, so the framework the > drivers would register too, but we're kind of reaching the limits of > what we can do there. It also feels to me that "the driver can't access > its device" is more of a problem for the bus to solve rather than the > framework. This is up to the specific bus to resolve, there's nothing special needed in the driver core for it, right? > Do you agree? Are you aware of any other bus in Linux with similar > requirements we could look at? Or any suggestion on how to solve it? There might be others, yes, look at how the dynamic power management works for different devices on most busses, that might help you out here. good luck! greg k-h
Re: [RFC PATCH 03/10] drm/mipi-dsi: add API for manual control over the DSI link power state
On Tue, Nov 07, 2023 at 11:57:49AM +0100, Maxime Ripard wrote: > +GKH Why? I don't see a question for me here, sorry. greg k-h
[PATCH 5.10 66/95] fbdev: atyfb: only use ioremap_uc() on i386 and ia64
5.10-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann Signed-off-by: Baoquan He Reviewed-by: Luis Chamberlain Cc: Helge Deller Cc: Thomas Zimmermann Cc: Christophe Leroy Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin --- drivers/video/fbdev/aty/atyfb_base.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index c8feff0ee8da9..eb32ff0910d3e 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3440,11 +3440,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0
[PATCH 5.15 082/128] fbdev: atyfb: only use ioremap_uc() on i386 and ia64
5.15-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann Signed-off-by: Baoquan He Reviewed-by: Luis Chamberlain Cc: Helge Deller Cc: Thomas Zimmermann Cc: Christophe Leroy Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin --- drivers/video/fbdev/aty/atyfb_base.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index 1aef3d6ebd880..246bf67b32ea0 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3447,11 +3447,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0
[PATCH 5.4 55/74] fbdev: atyfb: only use ioremap_uc() on i386 and ia64
5.4-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann Signed-off-by: Baoquan He Reviewed-by: Luis Chamberlain Cc: Helge Deller Cc: Thomas Zimmermann Cc: Christophe Leroy Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin --- drivers/video/fbdev/aty/atyfb_base.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index 6dda5d885a03b..bb9ecf12e7630 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3410,11 +3410,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0
[PATCH 6.5 18/88] fbdev: atyfb: only use ioremap_uc() on i386 and ia64
6.5-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann Signed-off-by: Baoquan He Reviewed-by: Luis Chamberlain Cc: Helge Deller Cc: Thomas Zimmermann Cc: Christophe Leroy Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin --- drivers/video/fbdev/aty/atyfb_base.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index cba2b113b28b0..a73114c1c6918 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3440,11 +3440,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0
[PATCH 6.1 10/62] fbdev: atyfb: only use ioremap_uc() on i386 and ia64
6.1-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann Signed-off-by: Baoquan He Reviewed-by: Luis Chamberlain Cc: Helge Deller Cc: Thomas Zimmermann Cc: Christophe Leroy Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin --- drivers/video/fbdev/aty/atyfb_base.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index b3463d1371520..faaa64fa5dfe9 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3447,11 +3447,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0
[PATCH 4.19 47/61] fbdev: atyfb: only use ioremap_uc() on i386 and ia64
4.19-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann Signed-off-by: Baoquan He Reviewed-by: Luis Chamberlain Cc: Helge Deller Cc: Thomas Zimmermann Cc: Christophe Leroy Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin --- drivers/video/fbdev/aty/atyfb_base.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index 05111e90f1681..5ef008e9c61c3 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3435,11 +3435,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0
[PATCH 4.14 33/48] fbdev: atyfb: only use ioremap_uc() on i386 and ia64
4.14-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann [ Upstream commit c1a8d1d0edb71dec15c9649cb56866c71c1ecd9e ] ioremap_uc() is only meaningful on old x86-32 systems with the PAT extension, and on ia64 with its slightly unconventional ioremap() behavior, everywhere else this is the same as ioremap() anyway. Change the only driver that still references ioremap_uc() to only do so on x86-32/ia64 in order to allow removing that interface at some point in the future for the other architectures. On some architectures, ioremap_uc() just returns NULL, changing the driver to call ioremap() means that they now have a chance of working correctly. Signed-off-by: Arnd Bergmann Signed-off-by: Baoquan He Reviewed-by: Luis Chamberlain Cc: Helge Deller Cc: Thomas Zimmermann Cc: Christophe Leroy Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Helge Deller Signed-off-by: Sasha Levin --- drivers/video/fbdev/aty/atyfb_base.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/aty/atyfb_base.c b/drivers/video/fbdev/aty/atyfb_base.c index d4b938276d238..71e95533613cd 100644 --- a/drivers/video/fbdev/aty/atyfb_base.c +++ b/drivers/video/fbdev/aty/atyfb_base.c @@ -3435,11 +3435,15 @@ static int atyfb_setup_generic(struct pci_dev *pdev, struct fb_info *info, } info->fix.mmio_start = raddr; +#if defined(__i386__) || defined(__ia64__) /* * By using strong UC we force the MTRR to never have an * effect on the MMIO region on both non-PAT and PAT systems. */ par->ati_regbase = ioremap_uc(info->fix.mmio_start, 0x1000); +#else + par->ati_regbase = ioremap(info->fix.mmio_start, 0x1000); +#endif if (par->ati_regbase == NULL) return -ENOMEM; -- 2.42.0
[PATCH 6.5 123/191] drm/tiny: correctly print `struct resource *` on error
6.5-stable review patch. If anyone has any objections, please let me know.
--
From: Joey Gouly
commit c1165df2be2fffe3adeeaa68f4ee4325108c5e4e upstream.
The `res` variable is already a `struct resource *`, don't take the address of
it.
Fixes incorrect output:
simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not
acquire memory range [??? 0x4be88a387d00-0xfefffde0a240 flags 0x0]: -16
To be correct:
simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not
acquire memory range [mem 0x9e20dc000-0x9e307bfff flags 0x200]: -16
Signed-off-by: Joey Gouly
Fixes: 9a10c7e6519b ("drm/simpledrm: Add support for system memory
framebuffers")
Cc: Thomas Zimmermann
Cc: Thierry Reding
Cc: Javier Martinez Canillas
Cc: dri-devel@lists.freedesktop.org
Cc: # v6.3+
Reviewed-by: Thomas Zimmermann
Signed-off-by: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20231010174652.2439513-1-joey.go...@arm.com
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/tiny/simpledrm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index ff86ba1ae1b8..8ea120eb8674 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -745,7 +745,7 @@ static struct simpledrm_device
*simpledrm_device_create(struct drm_driver *drv,
ret = devm_aperture_acquire_from_firmware(dev, res->start,
resource_size(res));
if (ret) {
- drm_err(dev, "could not acquire memory range %pr:
%d\n", , ret);
+ drm_err(dev, "could not acquire memory range %pr:
%d\n", res, ret);
return ERR_PTR(ret);
}
--
2.42.0
