dri-devel August 2019

dri-devel@lists.freedesktop.org

318 participants
2338 discussions

[PATCH] drm: connector: Clarify drm_connecter.ddc field documentation
by Laurent Pinchart 05 Aug '19

05 Aug '19

Improve the documentation of the ddc field by using DDC and I2C consistently, and explaining more clearly what the field points to. Signed-off-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> --- include/drm/drm_connector.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h index fc5d08438333..0d01662aa40e 100644 --- a/include/drm/drm_connector.h +++ b/include/drm/drm_connector.h @@ -1315,10 +1315,10 @@ struct drm_connector { /** * @ddc: associated ddc adapter. - * A connector usually has its associated ddc adapter. If a driver uses - * this field, then an appropriate symbolic link is created in connector - * sysfs directory to make it easy for the user to tell which i2c - * adapter is for a particular display. + * When the connector carries DDC signals, this field points to the I2C + * adapter connected to the DDC signals, if any. When this field is not + * NULL a symbolic link is created in the connector's sysfs directory + * to expose the I2C adapter used by the connector. * * The field should be set by calling drm_connector_init_with_ddc(). */ -- Regards, Laurent Pinchart

2 3

[engineering.redhat.com #494100] Question on submitting patch for a security bug
by Red Hat Product Security 05 Aug '19

05 Aug '19

Hello Navid, On Thu, 18 Jul 2019 01:30:20 GMT, emamd001(a)umn.edu wrote: > I've found a null dereference bug in the Linux kernel source code. I was > wondering should I cc the patch to you as well (along with the > maintainers)? No. Please do not cc <secalert(a)redhat.com> on the upstream kernel patches. It is meant for reporting security issues only. Going through the patches here 1. Issues in ../staging/ drivers are not considered for CVE, they are not to be used in production environment. 2. Many of the patches listed fix NULL pointer dereference when memory allocation fails and returns NULL. 3. Do you happen to have reproducers for these issues? Could an unprivileged user trigger them? > Also, I was wondering what are the steps to get CVE for the bug (this is > the first time I am reporting a bug)? Generally CVE is assigned after confirming that a given issue really is a security issue. And it may have impact ranging from information leakage, DoS to privilege escalation or maybe arbitrary code execution. Every NULL pointer dereference is not security issue. Hope it helps. Thank you. --- Prasad J Pandit / Red Hat Product Security Team

1 0

[PATCH v2] drm: rcar_lvds: Fix dual link mode operations
by Jacopo Mondi 05 Aug '19

05 Aug '19

The R-Car LVDS encoder units support dual-link operations by splitting the pixel output between the primary encoder and the companion one. Currently the companion encoder fails at probe time, causing the registration of the primary to fail as well, preventing the whole DU unit from being registered at all. Fix this by not bailing out from probe with error if the "renesas,companion" property is not specified. Fixes: fa440d870358 ("drm: rcar-du: lvds: Add support for dual-link mode") Reported-by: Fabrizio Castro <fabrizio.castro(a)bp.renesas.com> Signed-off-by: Jacopo Mondi <jacopo+renesas(a)jmondi.org> --- drivers/gpu/drm/rcar-du/rcar_lvds.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c index bada7ee98544..0b872d00760b 100644 --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c @@ -662,10 +662,8 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds) /* Locate the companion LVDS encoder for dual-link operation, if any. */ companion = of_parse_phandle(dev->of_node, "renesas,companion", 0); - if (!companion) { - dev_err(dev, "Companion LVDS encoder not found\n"); - return -ENXIO; - } + if (!companion) + return 0; /* * Sanity check: the companion encoder must have the same compatible -- 2.22.0

2 1

Re: The issue with page allocation 5.3 rc1-rc2 (seems drm culprit here)
by Mikhail Gavrilov 05 Aug '19

05 Aug '19

On Mon, 5 Aug 2019 at 08:21, Hillf Danton <hdanton(a)sina.com> wrote: > > > > Try to fix the failure above using vmalloc + kmalloc. > > --- a/drivers/gpu/drm/amd/display/dc/core/dc.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c > @@ -1174,8 +1174,12 @@ struct dc_state *dc_create_state(struct > struct dc_state *context = kzalloc(sizeof(struct dc_state), > GFP_KERNEL); > > - if (!context) > - return NULL; > + if (!context) { > + context = kvzalloc(sizeof(struct dc_state), > + GFP_KERNEL); > + if (!context) > + return NULL; > + } > /* Each context must have their own instance of VBA and in order to > * initialize and obtain IP and SOC the base DML instance from DC is > * initially copied into every context > @@ -1195,8 +1199,13 @@ struct dc_state *dc_copy_state(struct dc > struct dc_state *new_ctx = kmemdup(src_ctx, > sizeof(struct dc_state), GFP_KERNEL); > > - if (!new_ctx) > - return NULL; > + if (!new_ctx) { > + new_ctx = kvmalloc(sizeof(*new_ctx), GFP_KERNEL); > + if (new_ctx) > + *new_ctx = *src_ctx; > + else > + return NULL; > + } > > for (i = 0; i < MAX_PIPES; i++) { > struct pipe_ctx *cur_pipe = &new_ctx->res_ctx.pipe_ctx[i]; > @@ -1230,7 +1239,7 @@ static void dc_state_free(struct kref *k > { > struct dc_state *context = container_of(kref, struct dc_state, refcount); > dc_resource_state_destruct(context); > - kfree(context); > + kvfree(context); > } > > void dc_release_state(struct dc_state *context) > -- Unfortunately couldn't check this patch because, with the patch, the kernel did not compile. Here is compile error messages: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function 'dc_create_state': drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1178:13: error: implicit declaration of function 'kvzalloc'; did you mean 'kzalloc'? [-Werror=implicit-function-declaration] 1178 | context = kvzalloc(sizeof(struct dc_state), | ^~~~~~~~ | kzalloc drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1178:11: warning: assignment to 'struct dc_state *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 1178 | context = kvzalloc(sizeof(struct dc_state), | ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function 'dc_copy_state': drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1203:13: error: implicit declaration of function 'kvmalloc'; did you mean 'kmalloc'? [-Werror=implicit-function-declaration] 1203 | new_ctx = kvmalloc(sizeof(*new_ctx), GFP_KERNEL); | ^~~~~~~~ | kmalloc drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1203:11: warning: assignment to 'struct dc_state *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 1203 | new_ctx = kvmalloc(sizeof(*new_ctx), GFP_KERNEL); | ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function 'dc_state_free': drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1242:2: error: implicit declaration of function 'kvfree'; did you mean 'kzfree'? [-Werror=implicit-function-declaration] 1242 | kvfree(context); | ^~~~~~ | kzfree cc1: some warnings being treated as errors make[4]: *** [scripts/Makefile.build:274: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.o] Error 1 make[4]: *** Waiting for unfinished jobs.... make[3]: *** [scripts/Makefile.build:490: drivers/gpu/drm/amd/amdgpu] Error 2 make[3]: *** Waiting for unfinished jobs.... make: *** [Makefile:1084: drivers] Error 2 -- Best Regards, Mike Gavrilov.

1 0

[PATCH -next] drm/pl111: Fix unused variable warning
by Shaokun Zhang 05 Aug '19

05 Aug '19

vers/gpu/drm/pl111/pl111_display.c: In function ‘pl111_display_init’: drivers/gpu/drm/pl111/pl111_display.c:551:17: warning: unused variable ‘dev’ [-Wunused-variable] struct device *dev = drm->dev; ^ Fixes: d6781e490179 ("drm/pl111: Drop special pads config check") Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: Eric Anholt <eric(a)anholt.net> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Signed-off-by: Shaokun Zhang <zhangshaokun(a)hisilicon.com> --- drivers/gpu/drm/pl111/pl111_display.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/pl111/pl111_display.c b/drivers/gpu/drm/pl111/pl111_display.c index 8fe65969b7b8..9a153125e5d2 100644 --- a/drivers/gpu/drm/pl111/pl111_display.c +++ b/drivers/gpu/drm/pl111/pl111_display.c @@ -548,7 +548,6 @@ pl111_init_clock_divider(struct drm_device *drm) int pl111_display_init(struct drm_device *drm) { struct pl111_drm_dev_private *priv = drm->dev_private; - struct device *dev = drm->dev; int ret; ret = pl111_init_clock_divider(drm); -- 2.7.4

2 1

[PATCH] dma-buf: fix stack corruption in dma_fence_chain_release
by Christian König 05 Aug '19

05 Aug '19

We can't free up the chain using recursion or we run into a stack overflow. Manually free up the dangling chain nodes to avoid recursion. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/dma-fence-chain.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c index b5089f64be2a..44a741677d25 100644 --- a/drivers/dma-buf/dma-fence-chain.c +++ b/drivers/dma-buf/dma-fence-chain.c @@ -178,8 +178,30 @@ static bool dma_fence_chain_signaled(struct dma_fence *fence) static void dma_fence_chain_release(struct dma_fence *fence) { struct dma_fence_chain *chain = to_dma_fence_chain(fence); + struct dma_fence *prev; + + /* Manually unlink the chain as much as possible to avoid recursion + * and potential stack overflow. + */ + while ((prev = rcu_dereference_protected(chain->prev, true))) { + struct dma_fence_chain *prev_chain; + + if (kref_read(&prev->refcount) > 1) + break; + + prev_chain = to_dma_fence_chain(prev); + if (!prev_chain) + break; + + /* No need for atomic operations since we hold the last + * reference to prev_chain. + */ + chain->prev = prev_chain->prev; + RCU_INIT_POINTER(prev_chain->prev, NULL); + dma_fence_put(prev); + } + dma_fence_put(prev); - dma_fence_put(rcu_dereference_protected(chain->prev, true)); dma_fence_put(chain->fence); dma_fence_free(fence); } -- 2.17.1

3 5

[PATCH] drm/bridge/megachips: Drop GPIO header
by Linus Walleij 05 Aug '19

05 Aug '19

This file isn't using any interfaces from <linux/gpio.h> so just drop the include. Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c b/drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c index 823db80cbd19..b40ce484244a 100644 --- a/drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c +++ b/drivers/gpu/drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c @@ -19,7 +19,6 @@ * Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output */ -#include <linux/gpio.h> #include <linux/i2c.h> #include <linux/module.h> #include <linux/of.h> -- 2.21.0

4 5

[PATCH] drm/rockchip: Suspend DP late
by Douglas Anderson 05 Aug '19

05 Aug '19

In commit fe64ba5c6323 ("drm/rockchip: Resume DP early") we moved resume to be early but left suspend at its normal time. This seems like it could be OK, but casues problems if a suspend gets interrupted partway through. The OS only balances matching suspend/resume levels. ...so if suspend was called then resume will be called. If suspend late was called then resume early will be called. ...but if suspend was called resume early might not get called. This leads to an unbalance in the clock enables / disables. Lets take the simple fix and just move suspend to be late to match. This makes the PM core take proper care in keeping things balanced. Fixes: fe64ba5c6323 ("drm/rockchip: Resume DP early") Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c index 7d7cb57410fc..f38f5e113c6b 100644 --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c @@ -436,7 +436,7 @@ static int rockchip_dp_resume(struct device *dev) static const struct dev_pm_ops rockchip_dp_pm_ops = { #ifdef CONFIG_PM_SLEEP - .suspend = rockchip_dp_suspend, + .suspend_late = rockchip_dp_suspend, .resume_early = rockchip_dp_resume, #endif }; -- 2.22.0.770.g0f2c4a37fd-goog

2 2

[PATCH v5 00/18] drm/ttm: make ttm bo a gem bo subclass
by Gerd Hoffmann 05 Aug '19

05 Aug '19

v5: - rebase to latest drm-misc-next, adapt to reservation changes. - cc to intel-gfx for CI coverage. - all patches are acked now, so unless CI throws errors I'll go push this tomorrow. v4: - rebase to latest drm-misc-next, adapt to vram helper changes. v3: - comment updates - rebased on daniels resv series (https://patchwork.freedesktop.org/series/62735/) v2: - build fixes. - also drop ttm_buffer_object->resv Gerd Hoffmann (18): drm/ttm: add gem base object drm/vram: use embedded gem object drm/qxl: use embedded gem object drm/radeon: use embedded gem object drm/amdgpu: use embedded gem object drm/nouveau: use embedded gem object drm/ttm: use gem reservation object drm/ttm: use gem vma_node drm/ttm: set both resv and base.resv pointers drm/ttm: switch ttm core from bo->resv to bo->base.resv [fixup] ttm drm/radeon: switch driver from bo->resv to bo->base.resv drm/vmwgfx: switch driver from bo->resv to bo->base.resv drm/amdgpu: switch driver from bo->resv to bo->base.resv drm/nouveau: switch driver from bo->resv to bo->base.resv drm/qxl: switch driver from bo->resv to bo->base.resv drm/virtio: switch driver from bo->resv to bo->base.resv drm/ttm: drop ttm_buffer_object->resv drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 3 +- drivers/gpu/drm/nouveau/nouveau_bo.h | 5 - drivers/gpu/drm/nouveau/nouveau_gem.h | 2 +- drivers/gpu/drm/qxl/qxl_drv.h | 6 +- drivers/gpu/drm/qxl/qxl_object.h | 6 +- drivers/gpu/drm/radeon/radeon.h | 3 +- drivers/gpu/drm/radeon/radeon_object.h | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +- include/drm/drm_gem_vram_helper.h | 3 +- include/drm/ttm/ttm_bo_api.h | 29 +++- include/drm/ttm/ttm_bo_driver.h | 12 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 14 +- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 30 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 30 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 2 +- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- drivers/gpu/drm/ast/ast_main.c | 2 +- drivers/gpu/drm/drm_gem_vram_helper.c | 20 +-- drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 4 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 9 +- drivers/gpu/drm/nouveau/nouveau_display.c | 10 +- drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 19 +-- drivers/gpu/drm/nouveau/nouveau_prime.c | 4 +- drivers/gpu/drm/qxl/qxl_cmd.c | 4 +- drivers/gpu/drm/qxl/qxl_debugfs.c | 4 +- drivers/gpu/drm/qxl/qxl_display.c | 8 +- drivers/gpu/drm/qxl/qxl_gem.c | 2 +- drivers/gpu/drm/qxl/qxl_object.c | 20 +-- drivers/gpu/drm/qxl/qxl_release.c | 8 +- drivers/gpu/drm/qxl/qxl_ttm.c | 4 +- drivers/gpu/drm/radeon/radeon_benchmark.c | 4 +- drivers/gpu/drm/radeon/radeon_cs.c | 4 +- drivers/gpu/drm/radeon/radeon_display.c | 6 +- drivers/gpu/drm/radeon/radeon_gem.c | 8 +- drivers/gpu/drm/radeon/radeon_mn.c | 2 +- drivers/gpu/drm/radeon/radeon_object.c | 23 ++- drivers/gpu/drm/radeon/radeon_prime.c | 2 +- drivers/gpu/drm/radeon/radeon_test.c | 8 +- drivers/gpu/drm/radeon/radeon_ttm.c | 4 +- drivers/gpu/drm/radeon/radeon_uvd.c | 2 +- drivers/gpu/drm/radeon/radeon_vm.c | 6 +- drivers/gpu/drm/ttm/ttm_bo.c | 135 +++++++++--------- drivers/gpu/drm/ttm/ttm_bo_util.c | 18 +-- drivers/gpu/drm/ttm/ttm_bo_vm.c | 15 +- drivers/gpu/drm/ttm/ttm_execbuf_util.c | 20 +-- drivers/gpu/drm/ttm/ttm_tt.c | 2 +- drivers/gpu/drm/vboxvideo/vbox_main.c | 2 +- drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +- drivers/gpu/drm/virtio/virtgpu_plane.c | 2 +- drivers/gpu/drm/virtio/virtgpu_prime.c | 3 - drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 12 +- drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 6 +- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 +- 67 files changed, 312 insertions(+), 301 deletions(-) -- 2.18.1

1 19

[Bug 107877] deepin-desktop: xdg-email: no method available for opening 'mailto:'
by bugzilla-daemon＠freedesktop.org 05 Aug '19

05 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=107877 Andre Klapper <a9016009(a)gmx.de> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.linksys-extender | |setup.com/ | -- You are receiving this mail because: You are the assignee for the bug.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2019