* [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
@ 2023-04-04 19:40 Daniel Vetter
2023-04-04 19:40 ` [Intel-gfx] [PATCH 2/3] drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par() Daniel Vetter
` (5 more replies)
0 siblings, 6 replies; 16+ messages in thread
From: Daniel Vetter @ 2023-04-04 19:40 UTC (permalink / raw)
To: DRI Development
Cc: Thomas Zimmermann, Daniel Vetter, Intel Graphics Development,
syzbot+20dcf81733d43ddff661, Javier Martinez Canillas, stable,
Daniel Vetter, Daniel Vetter
Drivers are supposed to fix this up if needed if they don't outright
reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
sizes in fb_set_var()").
Reported-by: syzbot+20dcf81733d43ddff661@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=c5faf983bfa4a607de530cd3bb008888bf06cefc
Cc: stable@vger.kernel.org # v5.4+
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/drm_fb_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 59409820f424..eb4ece3e0027 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1595,6 +1595,9 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
return -EINVAL;
}
+ var->xres_virtual = fb->width;
+ var->yres_virtual = fb->height;
+
/*
* Workaround for SDL 1.2, which is known to be setting all pixel format
* fields values to zero in some cases. We treat this situation as a
--
2.40.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Intel-gfx] [PATCH 2/3] drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par()
2023-04-04 19:40 [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Daniel Vetter
@ 2023-04-04 19:40 ` Daniel Vetter
2023-04-05 10:23 ` Javier Martinez Canillas
2023-04-04 19:40 ` [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var Daniel Vetter
` (4 subsequent siblings)
5 siblings, 1 reply; 16+ messages in thread
From: Daniel Vetter @ 2023-04-04 19:40 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Maxime Ripard,
Thomas Zimmermann, Daniel Vetter
The fb_check_var hook is supposed to validate all this stuff. Any
errors from fb_set_par are considered driver/hw issues and resulting
in dmesg warnings.
Luckily we do fix up the pixclock already, so this is all fine.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/drm_fb_helper.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index eb4ece3e0027..b9696d13a741 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1647,11 +1647,6 @@ int drm_fb_helper_set_par(struct fb_info *info)
if (oops_in_progress)
return -EBUSY;
- if (var->pixclock != 0) {
- drm_err(fb_helper->dev, "PIXEL CLOCK SET\n");
- return -EINVAL;
- }
-
/*
* Normally we want to make sure that a kms master takes precedence over
* fbdev, to avoid fbdev flickering and occasionally stealing the
--
2.40.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var
2023-04-04 19:40 [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Daniel Vetter
2023-04-04 19:40 ` [Intel-gfx] [PATCH 2/3] drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par() Daniel Vetter
@ 2023-04-04 19:40 ` Daniel Vetter
2023-04-05 10:52 ` Javier Martinez Canillas
2023-04-04 22:42 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Patchwork
` (3 subsequent siblings)
5 siblings, 1 reply; 16+ messages in thread
From: Daniel Vetter @ 2023-04-04 19:40 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Maxime Ripard,
Thomas Zimmermann, Daniel Vetter
Apparently drivers need to check all this stuff themselves, which for
most things makes sense I guess. And for everything else we luck out,
because modern distros stopped supporting any other fbdev drivers than
drm ones and I really don't want to argue anymore about who needs to
check stuff. Therefore fixing all this just for drm fbdev emulation is
good enough.
Note that var->active is not set or validated. This is just control
flow for fbmem.c and needs to be validated in there as needed.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/gpu/drm/drm_fb_helper.c | 49 +++++++++++++++++++++++++--------
1 file changed, 38 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b9696d13a741..ef4eb8b12766 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1543,6 +1543,27 @@ static void drm_fb_helper_fill_pixel_fmt(struct fb_var_screeninfo *var,
}
}
+static void __fill_var(struct fb_var_screeninfo *var,
+ struct drm_framebuffer *fb)
+{
+ int i;
+
+ var->xres_virtual = fb->width;
+ var->yres_virtual = fb->height;
+ var->accel_flags = FB_ACCELF_TEXT;
+ var->bits_per_pixel = drm_format_info_bpp(fb->format, 0);
+
+ var->height = var->width = 0;
+ var->left_margin = var->right_margin = 0;
+ var->upper_margin = var->lower_margin = 0;
+ var->hsync_len = var->vsync_len = 0;
+ var->sync = var->vmode = 0;
+ var->rotate = 0;
+ var->colorspace = 0;
+ for (i = 0; i < 4; i++)
+ var->reserved[i] = 0;
+}
+
/**
* drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
* @var: screeninfo to check
@@ -1595,8 +1616,22 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
return -EINVAL;
}
- var->xres_virtual = fb->width;
- var->yres_virtual = fb->height;
+ __fill_var(var, fb);
+
+ /*
+ * fb_pan_display() validates this, but fb_set_par() doesn't and just
+ * falls over. Note that __fill_var above adjusts y/res_virtual.
+ */
+ if (var->yoffset > var->yres_virtual - var->yres ||
+ var->xoffset > var->xres_virtual - var->xres)
+ return -EINVAL;
+
+ /* We neither support grayscale nor FOURCC (also stored in here). */
+ if (var->grayscale > 0)
+ return -EINVAL;
+
+ if (var->nonstd)
+ return -EINVAL;
/*
* Workaround for SDL 1.2, which is known to be setting all pixel format
@@ -1612,11 +1647,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
drm_fb_helper_fill_pixel_fmt(var, format);
}
- /*
- * Likewise, bits_per_pixel should be rounded up to a supported value.
- */
- var->bits_per_pixel = bpp;
-
/*
* drm fbdev emulation doesn't support changing the pixel format at all,
* so reject all pixel format changing requests.
@@ -2040,12 +2070,9 @@ static void drm_fb_helper_fill_var(struct fb_info *info,
}
info->pseudo_palette = fb_helper->pseudo_palette;
- info->var.xres_virtual = fb->width;
- info->var.yres_virtual = fb->height;
- info->var.bits_per_pixel = drm_format_info_bpp(format, 0);
- info->var.accel_flags = FB_ACCELF_TEXT;
info->var.xoffset = 0;
info->var.yoffset = 0;
+ __fill_var(&info->var, fb);
info->var.activate = FB_ACTIVATE_NOW;
drm_fb_helper_fill_pixel_fmt(&info->var, format);
--
2.40.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
2023-04-04 19:40 [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Daniel Vetter
2023-04-04 19:40 ` [Intel-gfx] [PATCH 2/3] drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par() Daniel Vetter
2023-04-04 19:40 ` [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var Daniel Vetter
@ 2023-04-04 22:42 ` Patchwork
2023-04-04 22:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
` (2 subsequent siblings)
5 siblings, 0 replies; 16+ messages in thread
From: Patchwork @ 2023-04-04 22:42 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== Series Details ==
Series: series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
URL : https://patchwork.freedesktop.org/series/116109/
State : warning
== Summary ==
Error: dim checkpatch failed
8b9227e2090f drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
-:7: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 6c11df58fd1a ("fbmem: Check virtual screen sizes in fb_set_var()")'
#7:
reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
-:31: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 1 errors, 1 warnings, 0 checks, 9 lines checked
c7187f14b77e drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par()
-:33: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 11 lines checked
07636f85167e drm/fb-helper: fix input validation gaps in check_var
-:39: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#39: FILE: drivers/gpu/drm/drm_fb_helper.c:1550:
+ var->height = var->width = 0;
-:40: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#40: FILE: drivers/gpu/drm/drm_fb_helper.c:1551:
+ var->left_margin = var->right_margin = 0;
-:41: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#41: FILE: drivers/gpu/drm/drm_fb_helper.c:1552:
+ var->upper_margin = var->lower_margin = 0;
-:42: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#42: FILE: drivers/gpu/drm/drm_fb_helper.c:1553:
+ var->hsync_len = var->vsync_len = 0;
-:43: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#43: FILE: drivers/gpu/drm/drm_fb_helper.c:1554:
+ var->sync = var->vmode = 0;
-:103: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 5 checks, 75 lines checked
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
2023-04-04 19:40 [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Daniel Vetter
` (2 preceding siblings ...)
2023-04-04 22:42 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Patchwork
@ 2023-04-04 22:52 ` Patchwork
2023-04-05 8:28 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-04-05 10:21 ` [Intel-gfx] [PATCH 1/3] " Javier Martinez Canillas
5 siblings, 0 replies; 16+ messages in thread
From: Patchwork @ 2023-04-04 22:52 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 5644 bytes --]
== Series Details ==
Series: series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
URL : https://patchwork.freedesktop.org/series/116109/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12966 -> Patchwork_116109v1
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/index.html
Participating hosts (37 -> 36)
------------------------------
Missing (1): fi-snb-2520m
Known issues
------------
Here are the changes found in Patchwork_116109v1 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_suspend@basic-s0@smem:
- bat-dg2-9: [PASS][1] -> [DMESG-WARN][2] ([i915#6704])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-dg2-9/igt@gem_exec_suspend@basic-s0@smem.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-dg2-9/igt@gem_exec_suspend@basic-s0@smem.html
* igt@i915_selftest@live@execlists:
- fi-bsw-nick: [PASS][3] -> [ABORT][4] ([i915#7911] / [i915#7913])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-bsw-nick/igt@i915_selftest@live@execlists.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/fi-bsw-nick/igt@i915_selftest@live@execlists.html
* igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][5] -> [ABORT][6] ([i915#7981])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-rpls-1/igt@i915_selftest@live@reset.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-rpls-1/igt@i915_selftest@live@reset.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-rpls-2: [PASS][7] -> [ABORT][8] ([i915#6687] / [i915#7978])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-rpls-2/igt@i915_suspend@basic-s3-without-i915.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-rpls-2/igt@i915_suspend@basic-s3-without-i915.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-dg2-11: NOTRUN -> [SKIP][9] ([i915#7828])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-dg2-11/igt@kms_chamelium_hpd@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1:
- bat-dg2-8: [PASS][10] -> [FAIL][11] ([i915#7932])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-d-dp-1.html
* igt@kms_pipe_crc_basic@read-crc:
- bat-dg2-11: NOTRUN -> [SKIP][12] ([i915#5354]) +1 similar issue
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-dg2-11/igt@kms_pipe_crc_basic@read-crc.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u: [FAIL][13] ([fdo#103375]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-skl-6600u/igt@gem_exec_suspend@basic-s3@smem.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/fi-skl-6600u/igt@gem_exec_suspend@basic-s3@smem.html
* igt@i915_selftest@live@gt_lrc:
- bat-dg2-11: [INCOMPLETE][15] ([i915#7609] / [i915#7913]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/bat-dg2-11/igt@i915_selftest@live@gt_lrc.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-hdmi-a-1:
- fi-rkl-11600: [FAIL][17] ([fdo#103375]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-hdmi-a-1.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/fi-rkl-11600/igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-hdmi-a-1.html
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#6704]: https://gitlab.freedesktop.org/drm/intel/issues/6704
[i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
[i915#7981]: https://gitlab.freedesktop.org/drm/intel/issues/7981
Build changes
-------------
* Linux: CI_DRM_12966 -> Patchwork_116109v1
CI-20190529: 20190529
CI_DRM_12966: 202141796dba6058f9f7623c0ee48ff4ebcc2607 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116109v1: 202141796dba6058f9f7623c0ee48ff4ebcc2607 @ git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
fcee1d1c7a64 drm/fb-helper: fix input validation gaps in check_var
e2f20a6fc9c5 drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par()
96d461c04aac drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/index.html
[-- Attachment #2: Type: text/html, Size: 6632 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
2023-04-04 19:40 [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Daniel Vetter
` (3 preceding siblings ...)
2023-04-04 22:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
@ 2023-04-05 8:28 ` Patchwork
2023-04-05 10:21 ` [Intel-gfx] [PATCH 1/3] " Javier Martinez Canillas
5 siblings, 0 replies; 16+ messages in thread
From: Patchwork @ 2023-04-05 8:28 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 17469 bytes --]
== Series Details ==
Series: series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
URL : https://patchwork.freedesktop.org/series/116109/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12966_full -> Patchwork_116109v1_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
------------------------------
No changes in participating hosts
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_116109v1_full:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_rotation_crc@sprite-rotation-270:
- {shard-rkl}: [PASS][1] -> [ABORT][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-rkl-4/igt@kms_rotation_crc@sprite-rotation-270.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-rkl-4/igt@kms_rotation_crc@sprite-rotation-270.html
Known issues
------------
Here are the changes found in Patchwork_116109v1_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_endless@dispatch@rcs0:
- shard-apl: [PASS][3] -> [TIMEOUT][4] ([i915#3778])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-apl4/igt@gem_exec_endless@dispatch@rcs0.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl3/igt@gem_exec_endless@dispatch@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: NOTRUN -> [FAIL][5] ([i915#2842])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-glk7/igt@gem_exec_fair@basic-throttle@rcs0.html
* igt@gem_huc_copy@huc-copy:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-glk7/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@massive:
- shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl1/igt@gem_lmem_swapping@massive.html
* igt@i915_pm_rpm@system-suspend-devices:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271]) +24 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-snb4/igt@i915_pm_rpm@system-suspend-devices.html
* igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3886]) +4 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl1/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3886]) +2 similar issues
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-glk5/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_chamelium_color@ctm-0-75:
- shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271]) +87 similar issues
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl1/igt@kms_chamelium_color@ctm-0-75.html
* igt@kms_content_protection@legacy@pipe-a-dp-1:
- shard-apl: NOTRUN -> [TIMEOUT][12] ([i915#7173])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl1/igt@kms_content_protection@legacy@pipe-a-dp-1.html
* igt@kms_flip@flip-vs-suspend@a-dp1:
- shard-apl: [PASS][13] -> [ABORT][14] ([i915#180]) +1 similar issue
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-apl6/igt@kms_flip@flip-vs-suspend@a-dp1.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl3/igt@kms_flip@flip-vs-suspend@a-dp1.html
* igt@kms_flip@plain-flip-ts-check@c-hdmi-a1:
- shard-glk: [PASS][15] -> [FAIL][16] ([i915#2122])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-glk5/igt@kms_flip@plain-flip-ts-check@c-hdmi-a1.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-glk3/igt@kms_flip@plain-flip-ts-check@c-hdmi-a1.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-gtt:
- shard-glk: NOTRUN -> [SKIP][17] ([fdo#109271]) +49 similar issues
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-glk7/igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-gtt.html
* igt@kms_plane_alpha_blend@alpha-basic@pipe-c-hdmi-a-1:
- shard-glk: NOTRUN -> [FAIL][18] ([i915#7862]) +1 similar issue
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-glk7/igt@kms_plane_alpha_blend@alpha-basic@pipe-c-hdmi-a-1.html
* igt@kms_plane_alpha_blend@alpha-opaque-fb@pipe-a-dp-1:
- shard-apl: NOTRUN -> [FAIL][19] ([i915#4573]) +1 similar issue
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl1/igt@kms_plane_alpha_blend@alpha-opaque-fb@pipe-a-dp-1.html
* igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf:
- shard-glk: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#658])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-glk7/igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-fully-sf.html
* igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-sf:
- shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#658])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl1/igt@kms_psr2_sf@cursor-plane-move-continuous-exceed-sf.html
#### Possible fixes ####
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-dg1}: [ABORT][22] ([i915#8234]) -> [PASS][23]
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-dg1-15/igt@gem_barrier_race@remote-request@rcs0.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-dg1-15/igt@gem_barrier_race@remote-request@rcs0.html
- shard-apl: [ABORT][24] ([i915#8211] / [i915#8234]) -> [PASS][25]
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-apl2/igt@gem_barrier_race@remote-request@rcs0.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl6/igt@gem_barrier_race@remote-request@rcs0.html
- shard-glk: [ABORT][26] ([i915#8211]) -> [PASS][27]
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-glk4/igt@gem_barrier_race@remote-request@rcs0.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-glk5/igt@gem_barrier_race@remote-request@rcs0.html
* igt@gem_eio@in-flight-contexts-immediate:
- shard-apl: [TIMEOUT][28] ([i915#3063]) -> [PASS][29]
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-apl6/igt@gem_eio@in-flight-contexts-immediate.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl6/igt@gem_eio@in-flight-contexts-immediate.html
* igt@gem_exec_fair@basic-none@vecs0:
- {shard-rkl}: [FAIL][30] ([i915#2842]) -> [PASS][31]
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-rkl-4/igt@gem_exec_fair@basic-none@vecs0.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-rkl-3/igt@gem_exec_fair@basic-none@vecs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [FAIL][32] ([i915#2842]) -> [PASS][33]
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-apl7/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl2/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [ABORT][34] ([i915#5566]) -> [PASS][35]
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-glk3/igt@gen9_exec_parse@allowed-single.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-glk7/igt@gen9_exec_parse@allowed-single.html
* igt@i915_module_load@reload-with-fault-injection:
- shard-snb: [ABORT][36] ([i915#4528]) -> [PASS][37]
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-snb7/igt@i915_module_load@reload-with-fault-injection.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-snb4/igt@i915_module_load@reload-with-fault-injection.html
* igt@i915_pm_rpm@modeset-lpsp-stress:
- {shard-dg1}: [SKIP][38] ([i915#1397]) -> [PASS][39] +1 similar issue
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-dg1-17/igt@i915_pm_rpm@modeset-lpsp-stress.html
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-dg1-14/igt@i915_pm_rpm@modeset-lpsp-stress.html
* igt@i915_pm_rps@reset:
- shard-snb: [DMESG-FAIL][40] ([i915#8319]) -> [PASS][41]
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-snb5/igt@i915_pm_rps@reset.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-snb4/igt@i915_pm_rps@reset.html
* igt@i915_suspend@fence-restore-untiled:
- shard-snb: [DMESG-WARN][42] ([i915#5090]) -> [PASS][43]
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-snb4/igt@i915_suspend@fence-restore-untiled.html
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-snb4/igt@i915_suspend@fence-restore-untiled.html
* igt@kms_cursor_crc@cursor-suspend@pipe-c-dp-1:
- shard-apl: [ABORT][44] ([i915#180]) -> [PASS][45]
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-apl3/igt@kms_cursor_crc@cursor-suspend@pipe-c-dp-1.html
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl6/igt@kms_cursor_crc@cursor-suspend@pipe-c-dp-1.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: [FAIL][46] ([i915#72]) -> [PASS][47]
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-glk2/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-glk9/igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy.html
#### Warnings ####
* igt@kms_content_protection@atomic@pipe-a-dp-1:
- shard-apl: [FAIL][48] ([i915#7173]) -> [TIMEOUT][49] ([i915#7173])
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12966/shard-apl2/igt@kms_content_protection@atomic@pipe-a-dp-1.html
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/shard-apl1/igt@kms_content_protection@atomic@pipe-a-dp-1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#1902]: https://gitlab.freedesktop.org/drm/intel/issues/1902
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2433]: https://gitlab.freedesktop.org/drm/intel/issues/2433
[i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437
[i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
[i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
[i915#2587]: https://gitlab.freedesktop.org/drm/intel/issues/2587
[i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
[i915#284]: https://gitlab.freedesktop.org/drm/intel/issues/284
[i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
[i915#3063]: https://gitlab.freedesktop.org/drm/intel/issues/3063
[i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
[i915#3359]: https://gitlab.freedesktop.org/drm/intel/issues/3359
[i915#3458]: https://gitlab.freedesktop.org/drm/intel/issues/3458
[i915#3539]: https://gitlab.freedesktop.org/drm/intel/issues/3539
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3638]: https://gitlab.freedesktop.org/drm/intel/issues/3638
[i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#3778]: https://gitlab.freedesktop.org/drm/intel/issues/3778
[i915#3840]: https://gitlab.freedesktop.org/drm/intel/issues/3840
[i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
[i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213
[i915#426]: https://gitlab.freedesktop.org/drm/intel/issues/426
[i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
[i915#4349]: https://gitlab.freedesktop.org/drm/intel/issues/4349
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4538]: https://gitlab.freedesktop.org/drm/intel/issues/4538
[i915#4565]: https://gitlab.freedesktop.org/drm/intel/issues/4565
[i915#4573]: https://gitlab.freedesktop.org/drm/intel/issues/4573
[i915#4579]: https://gitlab.freedesktop.org/drm/intel/issues/4579
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4812]: https://gitlab.freedesktop.org/drm/intel/issues/4812
[i915#4833]: https://gitlab.freedesktop.org/drm/intel/issues/4833
[i915#4852]: https://gitlab.freedesktop.org/drm/intel/issues/4852
[i915#4860]: https://gitlab.freedesktop.org/drm/intel/issues/4860
[i915#4880]: https://gitlab.freedesktop.org/drm/intel/issues/4880
[i915#4881]: https://gitlab.freedesktop.org/drm/intel/issues/4881
[i915#5090]: https://gitlab.freedesktop.org/drm/intel/issues/5090
[i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
[i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
[i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
[i915#5325]: https://gitlab.freedesktop.org/drm/intel/issues/5325
[i915#5461]: https://gitlab.freedesktop.org/drm/intel/issues/5461
[i915#5563]: https://gitlab.freedesktop.org/drm/intel/issues/5563
[i915#5566]: https://gitlab.freedesktop.org/drm/intel/issues/5566
[i915#5784]: https://gitlab.freedesktop.org/drm/intel/issues/5784
[i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095
[i915#6301]: https://gitlab.freedesktop.org/drm/intel/issues/6301
[i915#6524]: https://gitlab.freedesktop.org/drm/intel/issues/6524
[i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
[i915#6946]: https://gitlab.freedesktop.org/drm/intel/issues/6946
[i915#6953]: https://gitlab.freedesktop.org/drm/intel/issues/6953
[i915#7173]: https://gitlab.freedesktop.org/drm/intel/issues/7173
[i915#72]: https://gitlab.freedesktop.org/drm/intel/issues/72
[i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561
[i915#7701]: https://gitlab.freedesktop.org/drm/intel/issues/7701
[i915#7711]: https://gitlab.freedesktop.org/drm/intel/issues/7711
[i915#7742]: https://gitlab.freedesktop.org/drm/intel/issues/7742
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7862]: https://gitlab.freedesktop.org/drm/intel/issues/7862
[i915#8150]: https://gitlab.freedesktop.org/drm/intel/issues/8150
[i915#8211]: https://gitlab.freedesktop.org/drm/intel/issues/8211
[i915#8234]: https://gitlab.freedesktop.org/drm/intel/issues/8234
[i915#8253]: https://gitlab.freedesktop.org/drm/intel/issues/8253
[i915#8319]: https://gitlab.freedesktop.org/drm/intel/issues/8319
Build changes
-------------
* Linux: CI_DRM_12966 -> Patchwork_116109v1
CI-20190529: 20190529
CI_DRM_12966: 202141796dba6058f9f7623c0ee48ff4ebcc2607 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_7236: bac5a4cc31b3212a205219a6cbc45a173d30d04b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116109v1: 202141796dba6058f9f7623c0ee48ff4ebcc2607 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116109v1/index.html
[-- Attachment #2: Type: text/html, Size: 15474 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
2023-04-04 19:40 [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Daniel Vetter
` (4 preceding siblings ...)
2023-04-05 8:28 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
@ 2023-04-05 10:21 ` Javier Martinez Canillas
2023-04-05 13:25 ` Daniel Vetter
5 siblings, 1 reply; 16+ messages in thread
From: Javier Martinez Canillas @ 2023-04-05 10:21 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Thomas Zimmermann, Daniel Vetter, Intel Graphics Development,
syzbot+20dcf81733d43ddff661, stable, Daniel Vetter,
Daniel Vetter
Daniel Vetter <daniel.vetter@ffwll.ch> writes:
> Drivers are supposed to fix this up if needed if they don't outright
> reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
> sizes in fb_set_var()").
>
Should have a Fixes: tag ? I understand what was uncovered by that commit
but it help distros to figure out if something has to be cherry-picked by
them. So I believe that would be useful to have it.
The patch looks good to me.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par()
2023-04-04 19:40 ` [Intel-gfx] [PATCH 2/3] drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par() Daniel Vetter
@ 2023-04-05 10:23 ` Javier Martinez Canillas
0 siblings, 0 replies; 16+ messages in thread
From: Javier Martinez Canillas @ 2023-04-05 10:23 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Thomas Zimmermann,
Daniel Vetter
Daniel Vetter <daniel.vetter@ffwll.ch> writes:
> The fb_check_var hook is supposed to validate all this stuff. Any
> errors from fb_set_par are considered driver/hw issues and resulting
> in dmesg warnings.
>
> Luckily we do fix up the pixclock already, so this is all fine.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Makes sense to drop this.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var
2023-04-04 19:40 ` [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var Daniel Vetter
@ 2023-04-05 10:52 ` Javier Martinez Canillas
2023-04-05 13:23 ` Daniel Vetter
0 siblings, 1 reply; 16+ messages in thread
From: Javier Martinez Canillas @ 2023-04-05 10:52 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Thomas Zimmermann,
Daniel Vetter
Daniel Vetter <daniel.vetter@ffwll.ch> writes:
> Apparently drivers need to check all this stuff themselves, which for
> most things makes sense I guess. And for everything else we luck out,
> because modern distros stopped supporting any other fbdev drivers than
> drm ones and I really don't want to argue anymore about who needs to
> check stuff. Therefore fixing all this just for drm fbdev emulation is
> good enough.
>
Agreed.
> Note that var->active is not set or validated. This is just control
> flow for fbmem.c and needs to be validated in there as needed.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> ---
[...]
>
> +static void __fill_var(struct fb_var_screeninfo *var,
> + struct drm_framebuffer *fb)
> +{
> + int i;
> +
> + var->xres_virtual = fb->width;
> + var->yres_virtual = fb->height;
> + var->accel_flags = FB_ACCELF_TEXT;
> + var->bits_per_pixel = drm_format_info_bpp(fb->format, 0);
> +
> + var->height = var->width = 0;
> + var->left_margin = var->right_margin = 0;
> + var->upper_margin = var->lower_margin = 0;
> + var->hsync_len = var->vsync_len = 0;
> + var->sync = var->vmode = 0;
> + var->rotate = 0;
> + var->colorspace = 0;
> + for (i = 0; i < 4; i++)
> + var->reserved[i] = 0;
> +}
> +
> /**
> * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
> * @var: screeninfo to check
> @@ -1595,8 +1616,22 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
> return -EINVAL;
> }
>
> - var->xres_virtual = fb->width;
> - var->yres_virtual = fb->height;
> + __fill_var(var, fb);
> +
[...]
There is the following here (in latest drm-misc/drm-misc-next at least):
/*
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
*/
bpp = drm_format_info_bpp(format, 0);
if (var->bits_per_pixel > bpp ||
var->xres > fb->width || var->yres > fb->height ||
var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
drm_dbg_kms(dev, "fb requested width/height/bpp can't fit in current fb "
"request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
var->xres, var->yres, var->bits_per_pixel,
var->xres_virtual, var->yres_virtual,
fb->width, fb->height, bpp);
return -EINVAL;
}
but only the 'var->xres > fb->width || var->yres > fb->height' from the
conditions checked could be false after your __fill_var() call above.
You should drop the 'var->bits_per_pixel > bpp', 'var->xres_virtual >
fb->width' and 'var->yres_virtual > fb->height' checks I believe since
those will always be true.
> + /*
> + * fb_pan_display() validates this, but fb_set_par() doesn't and just
> + * falls over. Note that __fill_var above adjusts y/res_virtual.
> + */
> + if (var->yoffset > var->yres_virtual - var->yres ||
> + var->xoffset > var->xres_virtual - var->xres)
> + return -EINVAL;
> +
> + /* We neither support grayscale nor FOURCC (also stored in here). */
> + if (var->grayscale > 0)
> + return -EINVAL;
> +
> + if (var->nonstd)
> + return -EINVAL;
>
> /*
> * Workaround for SDL 1.2, which is known to be setting all pixel format
> @@ -1612,11 +1647,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
> drm_fb_helper_fill_pixel_fmt(var, format);
> }
>
Other than what I mentioned, the patch makes sense to me.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var
2023-04-05 10:52 ` Javier Martinez Canillas
@ 2023-04-05 13:23 ` Daniel Vetter
2023-04-05 16:27 ` Javier Martinez Canillas
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Vetter @ 2023-04-05 13:23 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Daniel Vetter, Intel Graphics Development, Thomas Zimmermann,
DRI Development, Daniel Vetter
On Wed, Apr 05, 2023 at 12:52:12PM +0200, Javier Martinez Canillas wrote:
> Daniel Vetter <daniel.vetter@ffwll.ch> writes:
>
> > Apparently drivers need to check all this stuff themselves, which for
> > most things makes sense I guess. And for everything else we luck out,
> > because modern distros stopped supporting any other fbdev drivers than
> > drm ones and I really don't want to argue anymore about who needs to
> > check stuff. Therefore fixing all this just for drm fbdev emulation is
> > good enough.
> >
>
> Agreed.
>
> > Note that var->active is not set or validated. This is just control
> > flow for fbmem.c and needs to be validated in there as needed.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: Maxime Ripard <mripard@kernel.org>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > ---
>
> [...]
>
> >
> > +static void __fill_var(struct fb_var_screeninfo *var,
> > + struct drm_framebuffer *fb)
> > +{
> > + int i;
> > +
> > + var->xres_virtual = fb->width;
> > + var->yres_virtual = fb->height;
> > + var->accel_flags = FB_ACCELF_TEXT;
> > + var->bits_per_pixel = drm_format_info_bpp(fb->format, 0);
> > +
> > + var->height = var->width = 0;
> > + var->left_margin = var->right_margin = 0;
> > + var->upper_margin = var->lower_margin = 0;
> > + var->hsync_len = var->vsync_len = 0;
> > + var->sync = var->vmode = 0;
> > + var->rotate = 0;
> > + var->colorspace = 0;
> > + for (i = 0; i < 4; i++)
> > + var->reserved[i] = 0;
> > +}
> > +
> > /**
> > * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
> > * @var: screeninfo to check
> > @@ -1595,8 +1616,22 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
> > return -EINVAL;
> > }
> >
> > - var->xres_virtual = fb->width;
> > - var->yres_virtual = fb->height;
> > + __fill_var(var, fb);
> > +
>
> [...]
>
> There is the following here (in latest drm-misc/drm-misc-next at least):
>
> /*
> * Changes struct fb_var_screeninfo are currently not pushed back
> * to KMS, hence fail if different settings are requested.
> */
> bpp = drm_format_info_bpp(format, 0);
> if (var->bits_per_pixel > bpp ||
> var->xres > fb->width || var->yres > fb->height ||
> var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
> drm_dbg_kms(dev, "fb requested width/height/bpp can't fit in current fb "
> "request %dx%d-%d (virtual %dx%d) > %dx%d-%d\n",
> var->xres, var->yres, var->bits_per_pixel,
> var->xres_virtual, var->yres_virtual,
> fb->width, fb->height, bpp);
> return -EINVAL;
> }
>
> but only the 'var->xres > fb->width || var->yres > fb->height' from the
> conditions checked could be false after your __fill_var() call above.
>
> You should drop the 'var->bits_per_pixel > bpp', 'var->xres_virtual >
> fb->width' and 'var->yres_virtual > fb->height' checks I believe since
> those will always be true.
The __fill_var is after this. I'm honestly not sure what the exact
semantics are supposed to be, but essentially if userspace asks for too
big virtual size, we reject it. And for anything else we then tell it
(with __fill_var) how big the actually available space is.
What I'm wondering now is whether too small x/yres won't lead to problems
of some sorts ... For multi-screen we set the virtual size to be big
enough for all crtc, and then just set x/yres to be the smallest output.
That way fbcon knows to only draw as much as is visible on all screens.
But if you then pan that too much, the bigger screens might not have a big
enough buffer anymore and things fail (but shouldn't).
Not sure how to fix that tbh.
-Daniel
>
> > + /*
> > + * fb_pan_display() validates this, but fb_set_par() doesn't and just
> > + * falls over. Note that __fill_var above adjusts y/res_virtual.
> > + */
> > + if (var->yoffset > var->yres_virtual - var->yres ||
> > + var->xoffset > var->xres_virtual - var->xres)
> > + return -EINVAL;
> > +
> > + /* We neither support grayscale nor FOURCC (also stored in here). */
> > + if (var->grayscale > 0)
> > + return -EINVAL;
> > +
> > + if (var->nonstd)
> > + return -EINVAL;
> >
> > /*
> > * Workaround for SDL 1.2, which is known to be setting all pixel format
> > @@ -1612,11 +1647,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
> > drm_fb_helper_fill_pixel_fmt(var, format);
> > }
> >
>
> Other than what I mentioned, the patch makes sense to me.
>
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>
> --
> Best regards,
>
> Javier Martinez Canillas
> Core Platforms
> Red Hat
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var
2023-04-05 10:21 ` [Intel-gfx] [PATCH 1/3] " Javier Martinez Canillas
@ 2023-04-05 13:25 ` Daniel Vetter
0 siblings, 0 replies; 16+ messages in thread
From: Daniel Vetter @ 2023-04-05 13:25 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Thomas Zimmermann, Daniel Vetter, Intel Graphics Development,
syzbot+20dcf81733d43ddff661, stable, DRI Development,
Daniel Vetter, Daniel Vetter
On Wed, Apr 05, 2023 at 12:21:11PM +0200, Javier Martinez Canillas wrote:
> Daniel Vetter <daniel.vetter@ffwll.ch> writes:
>
> > Drivers are supposed to fix this up if needed if they don't outright
> > reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
> > sizes in fb_set_var()").
> >
>
> Should have a Fixes: tag ? I understand what was uncovered by that commit
> but it help distros to figure out if something has to be cherry-picked by
> them. So I believe that would be useful to have it.
>
> The patch looks good to me.
The cc: stable should go far enough back for that. Or that was at least my
idea ... I can add the Fixes: back since I had it but dropped it
intentionally because it's not really a bug in the fbmem patch.
-Daniel
> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
>
> --
> Best regards,
>
> Javier Martinez Canillas
> Core Platforms
> Red Hat
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var
2023-04-05 13:23 ` Daniel Vetter
@ 2023-04-05 16:27 ` Javier Martinez Canillas
2023-04-05 17:20 ` Daniel Vetter
0 siblings, 1 reply; 16+ messages in thread
From: Javier Martinez Canillas @ 2023-04-05 16:27 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Intel Graphics Development, Thomas Zimmermann,
DRI Development, Daniel Vetter
Daniel Vetter <daniel@ffwll.ch> writes:
[...]
>>
>> but only the 'var->xres > fb->width || var->yres > fb->height' from the
>> conditions checked could be false after your __fill_var() call above.
>>
>> You should drop the 'var->bits_per_pixel > bpp', 'var->xres_virtual >
>> fb->width' and 'var->yres_virtual > fb->height' checks I believe since
>> those will always be true.
>
> The __fill_var is after this. I'm honestly not sure what the exact
Ah, your patch adds it after that indeed. Please ignore my comment then.
> semantics are supposed to be, but essentially if userspace asks for too
> big virtual size, we reject it. And for anything else we then tell it
> (with __fill_var) how big the actually available space is.
>
> What I'm wondering now is whether too small x/yres won't lead to problems
> of some sorts ... For multi-screen we set the virtual size to be big
> enough for all crtc, and then just set x/yres to be the smallest output.
> That way fbcon knows to only draw as much as is visible on all screens.
> But if you then pan that too much, the bigger screens might not have a big
> enough buffer anymore and things fail (but shouldn't).
>
> Not sure how to fix that tbh.
Would this be a problem in practice?
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var
2023-04-05 16:27 ` Javier Martinez Canillas
@ 2023-04-05 17:20 ` Daniel Vetter
2023-04-05 17:42 ` Javier Martinez Canillas
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Vetter @ 2023-04-05 17:20 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Thomas Zimmermann, Daniel Vetter, Intel Graphics Development,
DRI Development, Daniel Vetter, Daniel Vetter
On Wed, Apr 05, 2023 at 06:27:17PM +0200, Javier Martinez Canillas wrote:
> Daniel Vetter <daniel@ffwll.ch> writes:
>
> [...]
>
> >>
> >> but only the 'var->xres > fb->width || var->yres > fb->height' from the
> >> conditions checked could be false after your __fill_var() call above.
> >>
> >> You should drop the 'var->bits_per_pixel > bpp', 'var->xres_virtual >
> >> fb->width' and 'var->yres_virtual > fb->height' checks I believe since
> >> those will always be true.
> >
> > The __fill_var is after this. I'm honestly not sure what the exact
>
> Ah, your patch adds it after that indeed. Please ignore my comment then.
So rb: you?
> > semantics are supposed to be, but essentially if userspace asks for too
> > big virtual size, we reject it. And for anything else we then tell it
> > (with __fill_var) how big the actually available space is.
> >
> > What I'm wondering now is whether too small x/yres won't lead to problems
> > of some sorts ... For multi-screen we set the virtual size to be big
> > enough for all crtc, and then just set x/yres to be the smallest output.
> > That way fbcon knows to only draw as much as is visible on all screens.
> > But if you then pan that too much, the bigger screens might not have a big
> > enough buffer anymore and things fail (but shouldn't).
> >
> > Not sure how to fix that tbh.
>
> Would this be a problem in practice?
I'm frankly not sure. You'd get a black screen for fbcon/fbdev across all
outputs, but only if you have userspace doing this intentionally.
In a way it's just another artifact of the drm fbdev emulation not using
ATOMIC_TEST_ONLY in the various places where it should, and so doesn't
really know whether a configuration change will work out.
We already have this in obscure mulit-monitor cases where adding another
screen kills fbcon, because the display hw is running out of fifo or
clocks or whatever, and because the drm fbdev code doesn't check but just
blindly commits the entire thing as an atomic commit, the overall commit
fails.
This worked "better" with legacy kms because there we commit per-crtc, so
if any specific crtc runs into a limit check, only that one fails to light
up.
Imo given that no one cared enough yet to write up atomic TEST_ONLY
support for fbdev emulation I think we can continue to just ignore this
problem.
What should not happen is that fbcon code blows up drawing out of bounds
or something like that, resulting in a kernel crash. So from that pov I
think it's "safe" :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var
2023-04-05 17:20 ` Daniel Vetter
@ 2023-04-05 17:42 ` Javier Martinez Canillas
2023-04-05 20:44 ` Daniel Vetter
0 siblings, 1 reply; 16+ messages in thread
From: Javier Martinez Canillas @ 2023-04-05 17:42 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Zimmermann, Daniel Vetter, Intel Graphics Development,
DRI Development, Daniel Vetter, Daniel Vetter
Daniel Vetter <daniel@ffwll.ch> writes:
> On Wed, Apr 05, 2023 at 06:27:17PM +0200, Javier Martinez Canillas wrote:
>> Daniel Vetter <daniel@ffwll.ch> writes:
[...]
>> >
>> > The __fill_var is after this. I'm honestly not sure what the exact
>>
>> Ah, your patch adds it after that indeed. Please ignore my comment then.
>
> So rb: you?
>
Yes, I already provided it in my previous email and has been picked by
patchwork. I could do again but probably will confuse dim when applying.
The only patch from your series that is missing an {r,a}b is #1 right now:
https://patchwork.kernel.org/project/dri-devel/list/?series=736966&archived=both
[...]
>> > What I'm wondering now is whether too small x/yres won't lead to problems
>> > of some sorts ... For multi-screen we set the virtual size to be big
>> > enough for all crtc, and then just set x/yres to be the smallest output.
>> > That way fbcon knows to only draw as much as is visible on all screens.
>> > But if you then pan that too much, the bigger screens might not have a big
>> > enough buffer anymore and things fail (but shouldn't).
>> >
>> > Not sure how to fix that tbh.
>>
>> Would this be a problem in practice?
>
> I'm frankly not sure. You'd get a black screen for fbcon/fbdev across all
> outputs, but only if you have userspace doing this intentionally.
>
> In a way it's just another artifact of the drm fbdev emulation not using
> ATOMIC_TEST_ONLY in the various places where it should, and so doesn't
> really know whether a configuration change will work out.
>
> We already have this in obscure mulit-monitor cases where adding another
> screen kills fbcon, because the display hw is running out of fifo or
> clocks or whatever, and because the drm fbdev code doesn't check but just
> blindly commits the entire thing as an atomic commit, the overall commit
> fails.
>
> This worked "better" with legacy kms because there we commit per-crtc, so
> if any specific crtc runs into a limit check, only that one fails to light
> up.
>
> Imo given that no one cared enough yet to write up atomic TEST_ONLY
> support for fbdev emulation I think we can continue to just ignore this
> problem.
>
Agreed. If that ends being a problem for people in practice then I guess
someone can type atomic TEST_ONLY support for the fbdev emulation layer.
> What should not happen is that fbcon code blows up drawing out of bounds
> or something like that, resulting in a kernel crash. So from that pov I
> think it's "safe" :-)
Great. Thanks a lot for your explanations.
> -Daniel
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var
2023-04-05 17:42 ` Javier Martinez Canillas
@ 2023-04-05 20:44 ` Daniel Vetter
2023-04-05 21:09 ` Javier Martinez Canillas
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Vetter @ 2023-04-05 20:44 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Thomas Zimmermann, Daniel Vetter, Intel Graphics Development,
DRI Development, Daniel Vetter, Daniel Vetter
On Wed, Apr 05, 2023 at 07:42:08PM +0200, Javier Martinez Canillas wrote:
> Daniel Vetter <daniel@ffwll.ch> writes:
>
> > On Wed, Apr 05, 2023 at 06:27:17PM +0200, Javier Martinez Canillas wrote:
> >> Daniel Vetter <daniel@ffwll.ch> writes:
>
> [...]
>
> >> >
> >> > The __fill_var is after this. I'm honestly not sure what the exact
> >>
> >> Ah, your patch adds it after that indeed. Please ignore my comment then.
> >
> > So rb: you?
> >
>
> Yes, I already provided it in my previous email and has been picked by
> patchwork. I could do again but probably will confuse dim when applying.
Yeah just wanted to confirm I cleared up all your questions. Merged the
entire series to drm-misc-next, thanks for the review.
> The only patch from your series that is missing an {r,a}b is #1 right now:
>
> https://patchwork.kernel.org/project/dri-devel/list/?series=736966&archived=both
That's a different one :-)
I'll respin with your comments and then let you&Thomas duke it out about
patch 1.
-Daniel
>
> [...]
>
> >> > What I'm wondering now is whether too small x/yres won't lead to problems
> >> > of some sorts ... For multi-screen we set the virtual size to be big
> >> > enough for all crtc, and then just set x/yres to be the smallest output.
> >> > That way fbcon knows to only draw as much as is visible on all screens.
> >> > But if you then pan that too much, the bigger screens might not have a big
> >> > enough buffer anymore and things fail (but shouldn't).
> >> >
> >> > Not sure how to fix that tbh.
> >>
> >> Would this be a problem in practice?
> >
> > I'm frankly not sure. You'd get a black screen for fbcon/fbdev across all
> > outputs, but only if you have userspace doing this intentionally.
> >
> > In a way it's just another artifact of the drm fbdev emulation not using
> > ATOMIC_TEST_ONLY in the various places where it should, and so doesn't
> > really know whether a configuration change will work out.
> >
> > We already have this in obscure mulit-monitor cases where adding another
> > screen kills fbcon, because the display hw is running out of fifo or
> > clocks or whatever, and because the drm fbdev code doesn't check but just
> > blindly commits the entire thing as an atomic commit, the overall commit
> > fails.
> >
> > This worked "better" with legacy kms because there we commit per-crtc, so
> > if any specific crtc runs into a limit check, only that one fails to light
> > up.
> >
> > Imo given that no one cared enough yet to write up atomic TEST_ONLY
> > support for fbdev emulation I think we can continue to just ignore this
> > problem.
> >
>
> Agreed. If that ends being a problem for people in practice then I guess
> someone can type atomic TEST_ONLY support for the fbdev emulation layer.
>
> > What should not happen is that fbcon code blows up drawing out of bounds
> > or something like that, resulting in a kernel crash. So from that pov I
> > think it's "safe" :-)
>
> Great. Thanks a lot for your explanations.
>
> > -Daniel
>
> --
> Best regards,
>
> Javier Martinez Canillas
> Core Platforms
> Red Hat
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var
2023-04-05 20:44 ` Daniel Vetter
@ 2023-04-05 21:09 ` Javier Martinez Canillas
0 siblings, 0 replies; 16+ messages in thread
From: Javier Martinez Canillas @ 2023-04-05 21:09 UTC (permalink / raw)
To: Daniel Vetter
Cc: Thomas Zimmermann, Daniel Vetter, Intel Graphics Development,
DRI Development, Daniel Vetter, Daniel Vetter
Daniel Vetter <daniel@ffwll.ch> writes:
> On Wed, Apr 05, 2023 at 07:42:08PM +0200, Javier Martinez Canillas wrote:
[...]
>> >> Ah, your patch adds it after that indeed. Please ignore my comment then.
>> >
>> > So rb: you?
>> >
>>
>> Yes, I already provided it in my previous email and has been picked by
>> patchwork. I could do again but probably will confuse dim when applying.
>
> Yeah just wanted to confirm I cleared up all your questions. Merged the
> entire series to drm-misc-next, thanks for the review.
>
You are welcome.
>> The only patch from your series that is missing an {r,a}b is #1 right now:
>>
>> https://patchwork.kernel.org/project/dri-devel/list/?series=736966&archived=both
>
> That's a different one :-)
>
Oh, sorry about that. Somehow I switched threads in my head in the middle
of the response.
> I'll respin with your comments and then let you&Thomas duke it out about
> patch 1.
> -Daniel
>
Perfect, thanks! It would be good to finally have that issue fixed.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2023-04-05 21:09 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-04 19:40 [Intel-gfx] [PATCH 1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Daniel Vetter
2023-04-04 19:40 ` [Intel-gfx] [PATCH 2/3] drm/fb-helper: drop redundant pixclock check from drm_fb_helper_set_par() Daniel Vetter
2023-04-05 10:23 ` Javier Martinez Canillas
2023-04-04 19:40 ` [Intel-gfx] [PATCH 3/3] drm/fb-helper: fix input validation gaps in check_var Daniel Vetter
2023-04-05 10:52 ` Javier Martinez Canillas
2023-04-05 13:23 ` Daniel Vetter
2023-04-05 16:27 ` Javier Martinez Canillas
2023-04-05 17:20 ` Daniel Vetter
2023-04-05 17:42 ` Javier Martinez Canillas
2023-04-05 20:44 ` Daniel Vetter
2023-04-05 21:09 ` Javier Martinez Canillas
2023-04-04 22:42 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/fb-helper: set x/yres_virtual in drm_fb_helper_check_var Patchwork
2023-04-04 22:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-04-05 8:28 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-04-05 10:21 ` [Intel-gfx] [PATCH 1/3] " Javier Martinez Canillas
2023-04-05 13:25 ` Daniel Vetter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).