[PATCH V4] fbcon: fix fbcon out-of-bounds write in sys_imageblit

From: Haimin Zhang yres and vyres can be controlled by user mode parameters, and cause p->vrows to become a negative value. While this value be passed to real_y function, the ypos will be out of screen range.This is an out-of-bounds write bug. some driver will check xres and yres in fb_check_var

Re: [PATCH 2/3] drm/etnaviv: fix dma configuration of the virtual device

Re: [PATCH v3 0/3] Remove all strcpy() uses

Re: [Intel-gfx] [PATCH v10 03/11] drm/ttm: Add a generic TTM memcpy move for page-based iomem

Hi! On 8/30/21 8:16 AM, Christian König wrote: Am 30.08.21 um 03:54 schrieb Dave Airlie: I've just been talking with Ben about nouveau having some issues since this path, ttm_resource can be subclassed by drivers, and the code below that copies ttm_resources around pretty much seems to destroy

[PATCH] drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource

The code was making a copy of a struct ttm_resource. However, recently the struct ttm_resources were allowed to be subclassed and also were allowed to be malloced, hence the driver could end up assuming the copy we handed it was subclassed and worse, the original could have been freed at this point

Re: [Intel-gfx] [PATCH v10 03/11] drm/ttm: Add a generic TTM memcpy move for page-based iomem

Hi! On 8/30/21 8:16 AM, Christian König wrote: Am 30.08.21 um 03:54 schrieb Dave Airlie: I've just been talking with Ben about nouveau having some issues since this path, ttm_resource can be subclassed by drivers, and the code below that copies ttm_resources around pretty much seems to destroy

Re: [PATCH V4] fbcon: fix fbcon out-of-bounds write in sys_imageblit

On Mon, Aug 30, 2021 at 11:30:23AM +0800, tcs.ker...@gmail.com wrote: > From: Haimin Zhang > > yres and vyres can be controlled by user mode parameters, and cause > p->vrows to become a negative value. While this value be passed to real_y > function, the ypos will be out of screen range.This is a

Re: [PATCH] drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource

Am 30.08.21 um 09:48 schrieb Thomas Hellström: The code was making a copy of a struct ttm_resource. However, recently the struct ttm_resources were allowed to be subclassed and also were allowed to be malloced, hence the driver could end up assuming the copy we handed it was subclassed and wor

Re: [Intel-gfx] [PATCH v2] drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup

On Fri, Aug 27, 2021 at 03:44:42PM +0100, Tvrtko Ursulin wrote: > > On 27/08/2021 15:39, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > > > In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa) > > when rendering is done on Intel dgfx and scanout/composition on Intel > > ig

Re: [PATCH] drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource

On Mon, 30 Aug 2021 at 17:48, Thomas Hellström wrote: > > The code was making a copy of a struct ttm_resource. However, > recently the struct ttm_resources were allowed to be subclassed and > also were allowed to be malloced, hence the driver could end up assuming > the copy we handed it was subcl

[PATCH 02/12] drm/ttm: add back a reference to the bdev to the res manager

It is simply a lot cleaner to have this around instead of adding the device throughout the call chain. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c

[PATCH 05/12] drm/ttm: move the LRU into resource handling

This way we finally fix the problem that new resource are not immediately evict-able after allocation. That has caused numerous problems including OOM on GDS handling and not being able to use TTM as general resource manager. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_

[PATCH 04/12] drm/ttm: add common accounting to the resource mgr

It makes sense to have this in the common manager for debugging and accounting of how much resources are used. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_resource.c | 8 include/drm/ttm/ttm_resource.h | 18 ++ 2 files changed, 26 insertions(+) diff

[PATCH 06/12] drm/ttm: add resource iterator

Instead of duplicating that at different places add an iterator over all the resources in a resource manager. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 41 +++ drivers/gpu/drm/ttm/ttm_device.c | 34 -- drivers/gpu/drm/tt

[PATCH 03/12] drm/ttm: add a weak BO reference to the resource v3

Keep track for which BO a resource was allocated. This is necessary to move the LRU handling into the resources. A bit problematic is i915 since it tries to use the resource interface without a BO which is illegal from the conceptional point of view. v2: Document that this is a weak reference and

[PATCH 01/12] drm/ttm: add ttm_resource_fini

Make sure we call the common cleanup function in all implementations of the resource manager. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c| 2 ++

[PATCH 07/12] drm/radeon: use ttm_resource_manager_debug

Instead of calling the debug operation directly. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 7793249bc549..9c45d8eb8

[PATCH 09/12] drm/amdgpu: use ttm_resource_manager_debug

Instead of calling the debug operation directly. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index 489e

[PATCH 08/12] drm/radeon: remove resource accounting

Use the one provided by TTM instead. Signed-off-by: Christian König --- drivers/gpu/drm/radeon/radeon.h| 2 -- drivers/gpu/drm/radeon/radeon_kms.c| 7 -- drivers/gpu/drm/radeon/radeon_object.c | 30 +++--- drivers/gpu/drm/radeon/radeon_object.h | 1 - drive

[PATCH 11/12] drm/amdgpu: remove VRAM accounting

This is provided by TTM now. Also switch man->size to bytes instead of pages and fix the double printing of size and usage in debugfs. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- drivers/gpu/drm/a

[PATCH 10/12] drm/amdgpu: remove GTT accounting

This is provided by TTM now. Also switch man->size to bytes instead of pages and fix the double printing of size and usage in debugfs. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 50 + drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 +--

[PATCH 12/12] drm/amdgpu: drop amdgpu_gtt_node

We have the BO pointer in the base structure now as well. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 49 - 1 file changed, 18 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c b/drivers/gpu/drm/amd/

Re: [PATCH v3 1/4] drm/ttm: Create pinned list

Am 27.08.21 um 22:39 schrieb Andrey Grodzovsky: This list will be used to capture all non VRAM BOs not on LRU so when device is hot unplugged we can iterate the list and unmap DMA mappings before device is removed. v2: Reanme function to ttm_bo_move_to_pinned v3: Move the pinned list to ttm devi

Re: [PATCH v5 12/20] drm/msm: Use scheduler dependency handling

On Thu, Aug 05, 2021 at 12:46:57PM +0200, Daniel Vetter wrote: > drm_sched_job_init is already at the right place, so this boils down > to deleting code. > > Signed-off-by: Daniel Vetter > Cc: Rob Clark > Cc: Sean Paul > Cc: Sumit Semwal > Cc: "Christian König" > Cc: linux-arm-...@vger.kernel

Re: [PATCH v5 16/20] drm/msm: Don't break exclusive fence ordering

On Thu, Aug 26, 2021 at 09:16:25AM -0700, Rob Clark wrote: > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote: > > > > There's only one exclusive slot, and we must not break the ordering. > > > > Adding a new exclusive fence drops all previous fences from the > > dma_resv. To avoid violating the

Re: [PATCH] drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource

On Mon, Aug 30, 2021 at 09:48:35AM +0200, Thomas Hellström wrote: > The code was making a copy of a struct ttm_resource. However, > recently the struct ttm_resources were allowed to be subclassed and > also were allowed to be malloced, hence the driver could end up assuming > the copy we handed it

Re: [PATCH 2/2] drm/bridge: it66121: Wait for next bridge to be probed

On 27/08/2021 18:39, Paul Cercueil wrote: > If run before the next bridge is initialized, of_drm_find_bridge() will > give us a NULL pointer. > > If that's the case, return -EPROBE_DEFER; we may have more luck next > time. > Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver") > Signed-off-b

Re: [PATCH 1/2] drm/bridge: it66121: Initialize {device,vendor}_ids

On 27/08/2021 18:39, Paul Cercueil wrote: > These two arrays are populated with data read from the I2C device > through regmap_read(), and the data is then compared with hardcoded > vendor/product ID values of supported chips. > > However, the return value of regmap_read() was never checked. This

[PATCH v2 1/2] drm/probe-helper: Create a HPD IRQ event helper for a single connector

The drm_helper_hpd_irq_event() function is iterating over all the connectors when an hotplug event is detected. During that iteration, it will call each connector detect function and figure out if its status changed. Finally, if any connector changed, it will notify the user-space and the clients

[PATCH] dma-buf: heaps: remove duplicated cache sync

From: Guangming Cao Current flow, one dmabuf maybe call cache sync many times if it has beed mapped more than one time. Is there any case that attachments of one dmabuf will points to different memory? If not, seems do sync only one time is more better. Signed-off-by: Guangming Cao --- driver

Re: [PATCH V4] fbcon: fix fbcon out-of-bounds write in sys_imageblit

On 2021/08/30 17:16, Daniel Vetter wrote: > On Mon, Aug 30, 2021 at 11:30:23AM +0800, tcs.ker...@gmail.com wrote: >> From: Haimin Zhang >> >> yres and vyres can be controlled by user mode parameters, and cause >> p->vrows to become a negative value. While this value be passed to real_y >> function

[PATCH 0/5] drm/displayid: VESA vendor block and drm/i915 MSO use of it

We need the DisplayID VESA vendor block data for properly configuring eDP MSO (Multi-SST Operation) pixel overlap. I haven't actually tested this on a panel that requires the overlap, but this is all pretty straightforward to prepare for that use case. BR, Jani. Jani Nikula (5): drm/displayid:

[PATCH 1/5] drm/displayid: re-align data block macros

Make the values easier to read. Also add DisplayID Structure version and revision information (this is different from the spec version). Signed-off-by: Jani Nikula --- include/drm/drm_displayid.h | 57 +++-- 1 file changed, 29 insertions(+), 28 deletions(-) diff

[PATCH 3/5] drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO

The VESA Organization Vendor-Specific Data Block, defined in VESA DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO) stream count and segment pixel overlap. DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension, describing how DisplayID sections may be embedded in EDID ex

[PATCH 4/5] drm/i915/edp: postpone MSO init until after EDID read

MSO will require segment pixel overlap information from the EDID. Postpone MSO init until after we've read and cached the EDID. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/dis

[PATCH 5/5] drm/i915/edp: use MSO pixel overlap from DisplayID data

Now that we have MSO pixel overlap in display info, use it. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dp.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index

[PATCH 2/5] drm/displayid: add DisplayID v2.0 data blocks and primary use cases

DisplayID v2.0 changes the data block identifiers and product types (now called primary use cases). Signed-off-by: Jani Nikula --- include/drm/drm_displayid.h | 29 + 1 file changed, 29 insertions(+) diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayi

Re: [PATCH 3/5] drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO

On Mon, 30 Aug 2021, Jani Nikula wrote: > The VESA Organization Vendor-Specific Data Block, defined in VESA > DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO) > stream count and segment pixel overlap. > > DisplayID v1.3 has Appendix B: DisplayID as an EDID Extension, > describi

[PATCH AUTOSEL 5.13 01/14] gpu: ipu-v3: Fix i.MX IPU-v3 offset calculations for (semi)planar U/V formats

From: Krzysztof Hałasa [ Upstream commit 7cca7c8096e2c8a4149405438329b5035d0744f0 ] Video captured in 1400x1050 resolution (bytesperline aka stride = 1408 bytes) is invalid. Fix it. Signed-off-by: Krzysztof Halasa Link: https://lore.kernel.org/r/m3y2bmq7a4@t19.piap.pl [p.za...@pengutronix.

[PATCH AUTOSEL 5.10 01/11] gpu: ipu-v3: Fix i.MX IPU-v3 offset calculations for (semi)planar U/V formats

From: Krzysztof Hałasa [ Upstream commit 7cca7c8096e2c8a4149405438329b5035d0744f0 ] Video captured in 1400x1050 resolution (bytesperline aka stride = 1408 bytes) is invalid. Fix it. Signed-off-by: Krzysztof Halasa Link: https://lore.kernel.org/r/m3y2bmq7a4@t19.piap.pl [p.za...@pengutronix.

[PATCH AUTOSEL 5.4 01/10] gpu: ipu-v3: Fix i.MX IPU-v3 offset calculations for (semi)planar U/V formats

From: Krzysztof Hałasa [ Upstream commit 7cca7c8096e2c8a4149405438329b5035d0744f0 ] Video captured in 1400x1050 resolution (bytesperline aka stride = 1408 bytes) is invalid. Fix it. Signed-off-by: Krzysztof Halasa Link: https://lore.kernel.org/r/m3y2bmq7a4@t19.piap.pl [p.za...@pengutronix.

Re: [syzbot] BUG: unable to handle kernel paging request in vga16fb_fillrect

Hi Testsuo, On Mon, Aug 30, 2021 at 4:27 AM Tetsuo Handa wrote: > On 2021/08/30 9:24, Randy Dunlap wrote: > > Note that yres_virtual is set to 0x1000. Is there no practical limit > > (hence limit check) that can be used here? > > > > Also, in vga16fb_check_var(), beginning at line 404: > > >

[PATCH AUTOSEL 4.19 1/8] gpu: ipu-v3: Fix i.MX IPU-v3 offset calculations for (semi)planar U/V formats

From: Krzysztof Hałasa [ Upstream commit 7cca7c8096e2c8a4149405438329b5035d0744f0 ] Video captured in 1400x1050 resolution (bytesperline aka stride = 1408 bytes) is invalid. Fix it. Signed-off-by: Krzysztof Halasa Link: https://lore.kernel.org/r/m3y2bmq7a4@t19.piap.pl [p.za...@pengutronix.

Re: [PATCH 2/7] drm/format-helper: Add drm_fb_xrgb8888_to_rgb332()

Den 17.08.2021 15.56, skrev Daniel Vetter: > On Tue, Aug 17, 2021 at 02:29:12PM +0200, Noralf Trønnes wrote: >> Add XRGB emulation support for devices that can only do RGB332. >> >> Cc: Thomas Zimmermann >> Signed-off-by: Noralf Trønnes >> --- >> drivers/gpu/drm/drm_format_helper.c | 47 +

Re: [PATCH AUTOSEL 5.13 20/26] drm/nouveau: recognise GA107

On Tue, Aug 24, 2021 at 01:08:28PM -0400, Lyude Paul wrote: This is more hardware enablement, I'm not sure this should be going into stable either. Ben? We take this sort of hardware enablement patches (where the platform code is already there, and we just add quirks/ids/etc. -- Thanks, Sasha

Re: [PATCH AUTOSEL 4.14 6/7] drm/nouveau: block a bunch of classes from userspace

On Tue, Aug 24, 2021 at 01:05:32PM -0400, Lyude Paul wrote: This isn't at all intended to be a fix to be backported, so I don't think this should be included. I don't know about 5/7, but I'll let Benjamin comment on that one I'll drop it, thanks! -- Thanks, Sasha

Re: [PATCH] drm/radeon: Make use of the helper macro SET_RUNTIME_PM_OPS()

On Sat, Aug 28, 2021 at 4:51 AM Cai Huoqing wrote: > > Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose > operators ".runtime_suspend/.runtime_resume/.runtime_idle", because > the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought > in to make code a little clearer,

Re: [PATCH 1/2] dt-bindings: panel: ili9341: correct indentation

On Mon, Aug 23, 2021 at 3:11 PM Sam Ravnborg wrote: > > On Thu, Aug 19, 2021 at 12:10:19PM +0200, Krzysztof Kozlowski wrote: > > Correct indentation warning: > > ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but > > found 8 (indentation) > > > > Signed-off-by: Krzysztof Koz

Re: [PATCH] drm/radeon: Make use of the helper macro SET_RUNTIME_PM_OPS()

On 30 Aug 21 08:21:52, Alex Deucher wrote: > On Sat, Aug 28, 2021 at 4:51 AM Cai Huoqing wrote: > > > > Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose > > operators ".runtime_suspend/.runtime_resume/.runtime_idle", because > > the SET_RUNTIME_PM_OPS() is a nice helper macro that

Re: [PATCH] dma-buf: heaps: remove duplicated cache sync

Am 30.08.21 um 12:01 schrieb guangming@mediatek.com: From: Guangming Cao Current flow, one dmabuf maybe call cache sync many times if it has beed mapped more than one time. Well I'm not an expert on DMA heaps, but this will most likely not work correctly. Is there any case that attach

Re: [PATCH] drm/radeon: Make use of the helper macro SET_RUNTIME_PM_OPS()

Am 28.08.21 um 10:50 schrieb Cai Huoqing: Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose operators ".runtime_suspend/.runtime_resume/.runtime_idle", because the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought in to make code a little clearer, a little more conc

Re: [syzbot] BUG: unable to handle kernel paging request in vga16fb_fillrect

On Mon, Aug 30, 2021 at 02:00:21PM +0200, Geert Uytterhoeven wrote: > Hi Testsuo, > > On Mon, Aug 30, 2021 at 4:27 AM Tetsuo Handa > wrote: > > On 2021/08/30 9:24, Randy Dunlap wrote: > > > Note that yres_virtual is set to 0x1000. Is there no practical limit > > > (hence limit check) that can

Re: [PATCH] drm/amdgpu: Make use of the helper macro SET_RUNTIME_PM_OPS()

On Sat, Aug 28, 2021 at 4:41 AM Cai Huoqing wrote: > > Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose > operators ".runtime_suspend/.runtime_resume/.runtime_idle", because > the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought > in to make code a little clearer,

Re: [PATCH rdma-next v4 0/3] SG fix together with update to RDMA umem

On Mon, Aug 30, 2021 at 11:21:00AM +0300, Leon Romanovsky wrote: > On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote: > > From: Maor Gottlieb > > > > Changelog: > > v4: > > * Unify sg_free_table_entries with __sg_free_table > > v3: https://lore.kernel.org/lkml/cover.1627551226.git.le

Re: [syzbot] BUG: unable to handle kernel paging request in vga16fb_fillrect

On 2021/08/30 22:00, Dan Carpenter wrote: >>> diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c >>> index e2757ff1c23d..e483a3f5fd47 100644 >>> --- a/drivers/video/fbdev/vga16fb.c >>> +++ b/drivers/video/fbdev/vga16fb.c >>> @@ -403,7 +403,7 @@ static int vga16fb_check_var(s

[Bug 214029] [NAVI] Several memory leaks in amdgpu and ttm

https://bugzilla.kernel.org/show_bug.cgi?id=214029 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #298269|0 |1 is obsolete|

[Bug 214029] [NAVI] Several memory leaks in amdgpu and ttm

https://bugzilla.kernel.org/show_bug.cgi?id=214029 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #298265|0 |1 is obsolete|

Re: [syzbot] BUG: unable to handle kernel paging request in vga16fb_fillrect

On Mon, Aug 30, 2021 at 10:37:31PM +0900, Tetsuo Handa wrote: > On 2021/08/30 22:00, Dan Carpenter wrote: > >>> diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c > >>> index e2757ff1c23d..e483a3f5fd47 100644 > >>> --- a/drivers/video/fbdev/vga16fb.c > >>> +++ b/drivers/vide

Re: [PATCH v3 0/2] GPD Win Max display fixes

Hi, On Tue, Aug 17, 2021 at 10:43 PM Anisse Astier wrote: > > This patch series is for making the GPD Win Max display usable with > Linux. > > The GPD Win Max is a small laptop, and its eDP panel does not send an > EDID over DPCD; the EDID is instead available in the intel opregion, in > mailbox

[Bug 214029] [NAVI] Several memory leaks in amdgpu and ttm

https://bugzilla.kernel.org/show_bug.cgi?id=214029 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Attachment #298267|0 |1 is obsolete|

Re: [PATCH rdma-next v4 0/3] SG fix together with update to RDMA umem

On Mon, Aug 30, 2021 at 10:31:28AM -0300, Jason Gunthorpe wrote: > On Mon, Aug 30, 2021 at 11:21:00AM +0300, Leon Romanovsky wrote: > > On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote: > > > From: Maor Gottlieb > > > > > > Changelog: > > > v4: > > > * Unify sg_free_table_entries wi

Re: [PATCH rdma-next v4 0/3] SG fix together with update to RDMA umem

On Tue, Aug 24, 2021 at 05:25:28PM +0300, Maor Gottlieb wrote: > From: Maor Gottlieb > > Changelog: > v4: > * Unify sg_free_table_entries with __sg_free_table > v3: https://lore.kernel.org/lkml/cover.1627551226.git.leo...@nvidia.com/ > * Rewrote to new API suggestion > * Split for more patches

Re: [PATCH v3 1/4] drm/ttm: Create pinned list

On 2021-08-30 4:58 a.m., Christian König wrote: Am 27.08.21 um 22:39 schrieb Andrey Grodzovsky: This list will be used to capture all non VRAM BOs not on LRU so when device is hot unplugged we can iterate the list and unmap DMA mappings before device is removed. v2: Reanme function to ttm_bo_

Re: [PATCH 2/3] drm/msm/dsi: Use "ref" fw clock instead of global name for VCO parent

Hi Dmitry, On Mon, Aug 30, 2021 at 04:17:32AM +0300, Dmitry Baryshkov wrote: > On Mon, 30 Aug 2021 at 00:53, Marijn Suijten > wrote: > > > > Hi Dmitry, > > > > On 8/29/21 10:39 PM, Dmitry Baryshkov wrote: > > > Hi, > > > > > > On Sun, 29 Aug 2021 at 23:30, Marijn Suijten > > > wrote: > > >> > >

Re: [syzbot] BUG: unable to handle kernel paging request in vga16fb_fillrect

On 2021/08/30 22:47, Dan Carpenter wrote: > On Mon, Aug 30, 2021 at 10:37:31PM +0900, Tetsuo Handa wrote: >> On 2021/08/30 22:00, Dan Carpenter wrote: > diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c > index e2757ff1c23d..e483a3f5fd47 100644 > --- a/drivers/v

Re: [syzbot] BUG: unable to handle kernel paging request in vga16fb_fillrect

On Mon, Aug 30, 2021 at 11:25:51PM +0900, Tetsuo Handa wrote: > On 2021/08/30 22:47, Dan Carpenter wrote: > > On Mon, Aug 30, 2021 at 10:37:31PM +0900, Tetsuo Handa wrote: > >> On 2021/08/30 22:00, Dan Carpenter wrote: > > diff --git a/drivers/video/fbdev/vga16fb.c > > b/drivers/video/fbde

Re: [syzbot] BUG: unable to handle kernel paging request in vga16fb_fillrect

Hi Tetsuo, On Mon, Aug 30, 2021 at 4:26 PM Tetsuo Handa wrote: > On 2021/08/30 22:47, Dan Carpenter wrote: > > On Mon, Aug 30, 2021 at 10:37:31PM +0900, Tetsuo Handa wrote: > >> On 2021/08/30 22:00, Dan Carpenter wrote: > > diff --git a/drivers/video/fbdev/vga16fb.c > > b/drivers/video/f

Re: [PATCH] drm/tidss: Make use of the helper macro SET_RUNTIME_PM_OPS()

Hi Cai, On Sat, Aug 28, 2021 at 04:52:52PM +0800, Cai Huoqing wrote: > Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose > operators ".runtime_suspend/.runtime_resume", because the > SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought > in to make code a little clearer

Re: [syzbot] BUG: unable to handle kernel paging request in vga16fb_fillrect

On 2021/08/30 23:30, Geert Uytterhoeven wrote: > The highest possible value of maxmem inside vga16fb_check_var() > is 65536. Yes. > > So I believe > > if (array_size(vxres, vyres) > maxmem) > > should work fine. My intent is to check at common path than individual module so that we don't

Re: [syzbot] BUG: unable to handle kernel paging request in vga16fb_fillrect

Hi Tetsuo, On Mon, Aug 30, 2021 at 4:38 PM Tetsuo Handa wrote: > On 2021/08/30 23:30, Geert Uytterhoeven wrote: > > The highest possible value of maxmem inside vga16fb_check_var() > > is 65536. > > Yes. > > > > > So I believe > > > > if (array_size(vxres, vyres) > maxmem) > > > > should work

Re: [PATCH V4] fbcon: fix fbcon out-of-bounds write in sys_imageblit

Hi Tetsuo, On Mon, Aug 30, 2021 at 12:25 PM Tetsuo Handa wrote: > On 2021/08/30 17:16, Daniel Vetter wrote: > > On Mon, Aug 30, 2021 at 11:30:23AM +0800, tcs.ker...@gmail.com wrote: > >> From: Haimin Zhang > >> > >> yres and vyres can be controlled by user mode parameters, and cause > >> p->vrow

Re: [syzbot] BUG: unable to handle kernel paging request in vga16fb_fillrect

Hi Tetsuo, On Mon, Aug 30, 2021 at 4:53 PM Geert Uytterhoeven wrote: > On Mon, Aug 30, 2021 at 4:38 PM Tetsuo Handa > wrote: > > On 2021/08/30 23:30, Geert Uytterhoeven wrote: > > > The highest possible value of maxmem inside vga16fb_check_var() > > > is 65536. > > > > Yes. > > > > > > > > So I

Re: [PATCH 3/5] drm/edid: parse the DisplayID v2.0 VESA vendor block for MSO

On Mon, Aug 30, 2021 at 01:29:01PM +0300, Jani Nikula wrote: > The VESA Organization Vendor-Specific Data Block, defined in VESA > DisplayID Standard v2.0, specifies the eDP Multi-SST Operation (MSO) > stream count and segment pixel overlap. > > DisplayID v1.3 has Appendix B: DisplayID as an EDID

Re: [PATCH v3] drm/dp_mst: Fix return code on sideband message failure

On 2021-08-25 09:26, Lyude Paul wrote: The patch was pushed yes (was part of drm-misc-next-2021-07-29), seems like it just hasn't trickled down to linus's branch quite yet. Hi Stephen B, Would you mind back porting this patch to V5.10 branch? It will have lots of helps for us to support displ

Re: [RFC] drm/msm/dp: Allow attaching a drm_panel

Hi, On Sat, Aug 28, 2021 at 7:40 AM Bjorn Andersson wrote: > > On Fri 27 Aug 15:52 CDT 2021, Doug Anderson wrote: > > > Hi, > > > > On Mon, Jul 26, 2021 at 4:15 PM Bjorn Andersson > > wrote: > > > > > > +static int dp_parser_find_panel(struct dp_parser *parser) > > > +{ > > > + struct devi

[PATCH v2] GPU:DRM: returning ENOMEM

check the return value and pass the proper error code. Signed-off-by: F.A. SULAIMAN --- drivers/gpu/drm/udl/udl_connector.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/udl/udl_connector.c b/drivers/gpu/drm/udl/udl_connector.c index cdc1c42e166

[PATCH] fbmem: don't allow too huge resolutions

syzbot is reporting page fault at vga16fb_fillrect() [1], for vga16fb_check_var() is failing to detect multiplication overflow. if (vxres * vyres > maxmem) { vyres = maxmem / vxres; if (vyres < yres) return -ENOMEM; } Since no module would accept too huge resolutions where multi

Re: [PATCH v2] GPU:DRM: returning ENOMEM

Maybe the commit message can be improved a bit? Add a prefix to make it clear this is about the udl driver, make it clear this is about the udl_get_edid_block function. The new `return ret` statement may return something different from ENOMEM. This would give something among these lines: drm/

Re: [PATCH] drm/amdgpu/swsmu: fix spelling mistake "minimun" -> "minimum"

Applied. Thanks! Alex On Fri, Aug 27, 2021 at 2:59 PM Colin King wrote: > > From: Colin Ian King > > There are three identical spelling mistakes in dev_err messages. > Fix these. > > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 +- > drivers/

Re: [PATCH][next] drm/amd/display: Fix unused initialization of pointer sink

Applied. Thanks! Alex On Sun, Aug 29, 2021 at 12:46 PM Colin King wrote: > > From: Colin Ian King > > Pointer sink is being inintialized with a value that is never read, > it is later being re-assigned a new value. Remove the redundant > initialization. > > Addresses-Coverity: ("Unused value")

Re: [PATCH] drm: remove zxdrm driver

On Thu, Aug 26, 2021 at 4:22 AM Daniel Vetter wrote: > > On Mon, Aug 23, 2021 at 01:51:30PM -0500, Rob Herring wrote: > > On Sat, 21 Aug 2021 11:13:57 +0800, Zenghui Yu wrote: > > > The zte zx platform had been removed in commit 89d4f98ae90d ("ARM: remove > > > zte zx platform"), so this driver is

Re: [v4 3/4] drm/panel: support for BOE and INX video mode panel

Hi, On Sun, Aug 29, 2021 at 7:39 PM yangcong wrote: > > Support for these two panels fits in nicely with the existing > panel-boe-tv101wum-nl6 driver as suggested by Sam [1]. The main things > we needed to handle were: > a) These panels need slightly longer delays in two places. Since these > new

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: Use max params for panels < eDP 1.4

On Thu, Aug 26, 2021 at 01:37:34PM -0400, Rodrigo Vivi wrote: > On Fri, Aug 20, 2021 at 08:26:14PM +0300, Ville Syrjälä wrote: > > On Fri, Aug 20, 2021 at 03:52:59PM +0800, Kai-Heng Feng wrote: > > > Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use > > > fast+narrow link on eDP

Re: [PATCH v3 1/4] drm/ttm: Create pinned list

Am 30.08.21 um 16:16 schrieb Andrey Grodzovsky: On 2021-08-30 4:58 a.m., Christian König wrote: Am 27.08.21 um 22:39 schrieb Andrey Grodzovsky: This list will be used to capture all non VRAM BOs not on LRU so when device is hot unplugged we can iterate the list and unmap DMA mappings before de

Re: [PATCH 05/12] drm/ttm: move the LRU into resource handling

On 2021-08-30 4:57 a.m., Christian König wrote: This way we finally fix the problem that new resource are not immediately evict-able after allocation. That has caused numerous problems including OOM on GDS handling and not being able to use TTM as general resource manager. Signed-off-by: Chri

Re: [PATCH 05/12] drm/ttm: move the LRU into resource handling

Am 30.08.21 um 18:53 schrieb Andrey Grodzovsky: On 2021-08-30 4:57 a.m., Christian König wrote: This way we finally fix the problem that new resource are not immediately evict-able after allocation. That has caused numerous problems including OOM on GDS handling and not being able to use TTM a

Re: [PATCH v3] drm/dp_mst: Fix return code on sideband message failure

On Mon, 2021-08-30 at 08:56 -0700, khs...@codeaurora.org wrote: > On 2021-08-25 09:26, Lyude Paul wrote: > > The patch was pushed yes (was part of drm-misc-next-2021-07-29), seems > > like it > > just hasn't trickled down to linus's branch quite yet. > > Hi Stephen B, > > Would you mind back por

Re: [PATCH 05/12] drm/ttm: move the LRU into resource handling

On 2021-08-30 12:55 p.m., Christian König wrote: Am 30.08.21 um 18:53 schrieb Andrey Grodzovsky: On 2021-08-30 4:57 a.m., Christian König wrote: This way we finally fix the problem that new resource are not immediately evict-able after allocation. That has caused numerous problems including

Re: [PATCH 05/12] drm/ttm: move the LRU into resource handling

Am 30.08.21 um 19:00 schrieb Andrey Grodzovsky: On 2021-08-30 12:55 p.m., Christian König wrote: Am 30.08.21 um 18:53 schrieb Andrey Grodzovsky: On 2021-08-30 4:57 a.m., Christian König wrote: This way we finally fix the problem that new resource are not immediately evict-able after allocati

Re: [PATCH v3 1/4] drm/ttm: Create pinned list

Am 30.08.21 um 19:02 schrieb Andrey Grodzovsky: On 2021-08-30 12:51 p.m., Christian König wrote: Am 30.08.21 um 16:16 schrieb Andrey Grodzovsky: On 2021-08-30 4:58 a.m., Christian König wrote: Am 27.08.21 um 22:39 schrieb Andrey Grodzovsky: This list will be used to capture all non VRAM

Re: [PATCH AUTOSEL 5.13 20/26] drm/nouveau: recognise GA107

ahhh-ok, that makes these patchs make a bit more sense then. If Ben doesn't have any objections I'd say these are fine to backport then On Mon, 2021-08-30 at 08:17 -0400, Sasha Levin wrote: > On Tue, Aug 24, 2021 at 01:08:28PM -0400, Lyude Paul wrote: > > This is more hardware enablement, I'm not

Re: [PATCH AUTOSEL 5.13 20/26] drm/nouveau: recognise GA107

oops-except for "drm/nouveau: block a bunch of classes from userspace" of course. the rest are fine though On Mon, 2021-08-30 at 13:08 -0400, Lyude Paul wrote: > ahhh-ok, that makes these patchs make a bit more sense then. If Ben doesn't > have any objections I'd say these are fine to backport the

Re: [PATCH v3 1/4] drm/ttm: Create pinned list

On 2021-08-30 12:51 p.m., Christian König wrote: Am 30.08.21 um 16:16 schrieb Andrey Grodzovsky: On 2021-08-30 4:58 a.m., Christian König wrote: Am 27.08.21 um 22:39 schrieb Andrey Grodzovsky: This list will be used to capture all non VRAM BOs not on LRU so when device is hot unplugged we c

Re: [PATCH v1 03/14] mm: add iomem vma selection for memory migration

Am 2021-08-30 um 4:28 a.m. schrieb Christoph Hellwig: > On Thu, Aug 26, 2021 at 06:27:31PM -0400, Felix Kuehling wrote: >> I think we're missing something here. As far as I can tell, all the work >> we did first with DEVICE_GENERIC and now DEVICE_PUBLIC always used >> normal pages. Are we missing s

Re: [PATCH v3 1/4] drm/ttm: Create pinned list

On 2021-08-30 1:05 p.m., Christian König wrote: Am 30.08.21 um 19:02 schrieb Andrey Grodzovsky: On 2021-08-30 12:51 p.m., Christian König wrote: Am 30.08.21 um 16:16 schrieb Andrey Grodzovsky: On 2021-08-30 4:58 a.m., Christian König wrote: Am 27.08.21 um 22:39 schrieb Andrey Grodzovsky

[PATCH v2 0/2] Use "ref" clocks from firmware for DSI PLL VCO parent

All DSI PHY/PLL drivers were referencing their VCO parent clock by a global name, most of which don't exist or have been renamed. These clock drivers seem to function fine without that except the 14nm driver for the sdm6xx [1]. At the same time all DTs provide a "ref" clock as per the requirement

[PATCH v2 1/2] drm/msm/dsi: Use "ref" fw clock instead of global name for VCO parent

All DSI PHY/PLL drivers were referencing their VCO parent clock by a global name, most of which don't exist or have been renamed. These clock drivers seem to function fine without that except the 14nm driver for the sdm6xx [1]. At the same time all DTs provide a "ref" clock as per the requirement

[PATCH v2 2/2] clk: qcom: gcc-sdm660: Remove transient global "xo" clock

The DSI PHY/PLL was relying on a global "xo" clock to be found, but the real clock is named "xo_board" in the DT. The standard nowadays is to never use global clock names anymore but require the firmware (DT) to provide every clock binding explicitly with .fw_name. The DSI PLLs have since been co

Re: [PATCH v5 20/20] dma-resv: Give the docs a do-over

On Thu, Aug 05, 2021 at 12:47:05PM +0200, Daniel Vetter wrote: > Specifically document the new/clarified rules around how the shared > fences do not have any ordering requirements against the exclusive > fence. > > But also document all the things a bit better, given how central > struct dma_resv

[PATCH 1/8] drm/i915/gt: Lock intel_engine_apply_whitelist with uncore->lock

Refactor intel_engine_apply_whitelist into locked and unlocked versions so that a caller who already has the lock can apply whitelist. v2: Fix sparse warning v3: (Chris) - Drop prefix and suffix for static function - Use longest to shortest line ordering for variable declaration Signed-off-by: Um

  1   2   >