dri-devel January 2021

dri-devel@lists.freedesktop.org

322 participants
737 discussions

[PATCH RFC] drm/vc4: hdmi: Avoid ASoC error messages on startup
by Stefan Wahren 18 Jan '21

18 Jan '21

During startup of Raspberry Pi 4 there seems to be a race between VC4 probing and Pulseaudio trying to open its PCM device: ASoC: error at snd_soc_dai_startup on fef05700.hdmi: -19 Avoid these errors by returning EPROBE_DEFER in this situation. Signed-off-by: Stefan Wahren <stefan.wahren(a)i2se.com> --- drivers/gpu/drm/vc4/vc4_hdmi.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 5551062..e0f9357 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -909,12 +909,14 @@ static int vc4_hdmi_audio_startup(struct snd_pcm_substream *substream, vc4_hdmi->audio.substream = substream; + if (!encoder->crtc) + return -EPROBE_DEFER; + /* - * If the HDMI encoder hasn't probed, or the encoder is - * currently in DVI mode, treat the codec dai as missing. + * If the HDMI encoder is currently in DVI mode, + * treat the codec dai as missing. */ - if (!encoder->crtc || !(HDMI_READ(HDMI_RAM_PACKET_CONFIG) & - VC4_HDMI_RAM_PACKET_ENABLE)) + if (!(HDMI_READ(HDMI_RAM_PACKET_CONFIG) & VC4_HDMI_RAM_PACKET_ENABLE)) return -ENODEV; ret = snd_pcm_hw_constraint_eld(substream->runtime, connector->eld); -- 2.7.4

4 9

[PATCH] drm-buf: Add debug option
by Daniel Vetter 18 Jan '21

18 Jan '21

We have too many people abusing the struct page they can get at but really shouldn't in importers. Aside from that the backing page might simply not exist (for dynamic p2p mappings) looking at it and using it e.g. for mmap can also wreak the page handling of the exporter completely. Importers really must go through the proper interface like dma_buf_mmap for everything. I'm semi-tempted to enforce this for dynamic importers since those really have no excuse at all to break the rules. Unfortuantely we can't store the right pointers somewhere safe to make sure we oops on something recognizable, so best is to just wrangle them a bit by flipping all the bits. At least on x86 kernel addresses have all their high bits sets and the struct page array is fairly low in the kernel mapping, so flipping all the bits gives us a very high pointer in userspace and hence excellent chances for an invalid dereference. v2: Add a note to the @map_dma_buf hook that exporters shouldn't do fancy caching tricks, which would blow up with this address scrambling trick here (Chris) Enable by default when CONFIG_DMA_API_DEBUG is enabled. Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: David Stevens <stevensd(a)chromium.org> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org --- drivers/dma-buf/Kconfig | 8 +++++++ drivers/dma-buf/dma-buf.c | 49 +++++++++++++++++++++++++++++++++++---- include/linux/dma-buf.h | 6 +++++ 3 files changed, 59 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index 4f8224a6ac95..4e16c71c24b7 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -50,6 +50,14 @@ config DMABUF_MOVE_NOTIFY This is marked experimental because we don't yet have a consistent execution context and memory management between drivers. +config DMABUF_DEBUG + bool "DMA-BUF debug checks" + default y if DMA_API_DEBUG + help + This option enables additional checks for DMA-BUF importers and + exporters. Specifically it validates that importers do not peek at the + underlying struct page when they import a buffer. + config DMABUF_SELFTESTS tristate "Selftests for the dma-buf interfaces" default n diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 1c9bd51db110..6e4725f7dfde 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -666,6 +666,30 @@ void dma_buf_put(struct dma_buf *dmabuf) } EXPORT_SYMBOL_GPL(dma_buf_put); +static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach, + enum dma_data_direction direction) +{ + struct sg_table *sg_table; + + sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction); + +#if CONFIG_DMABUF_DEBUG + if (sg_table) { + int i; + struct scatterlist *sg; + + /* To catch abuse of the underlying struct page by importers mix + * up the bits, but take care to preserve the low SG_ bits to + * not corrupt the sgt. The mixing is undone in __unmap_dma_buf + * before passing the sgt back to the exporter. */ + for_each_sgtable_sg(sg_table, sg, i) + sg->page_link ^= ~0xffUL; + } +#endif + + return sg_table; +} + /** * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list * @dmabuf: [in] buffer to attach device to. @@ -737,7 +761,7 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev, goto err_unlock; } - sgt = dmabuf->ops->map_dma_buf(attach, DMA_BIDIRECTIONAL); + sgt = __map_dma_buf(attach, DMA_BIDIRECTIONAL); if (!sgt) sgt = ERR_PTR(-ENOMEM); if (IS_ERR(sgt)) { @@ -784,6 +808,23 @@ struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, } EXPORT_SYMBOL_GPL(dma_buf_attach); +static void __unmap_dma_buf(struct dma_buf_attachment *attach, + struct sg_table *sg_table, + enum dma_data_direction direction) +{ + +#if CONFIG_DMABUF_DEBUG + if (sg_table) { + int i; + struct scatterlist *sg; + + for_each_sgtable_sg(sg_table, sg, i) + sg->page_link ^= ~0xffUL; + } +#endif + attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); +} + /** * dma_buf_detach - Remove the given attachment from dmabuf's attachments list * @dmabuf: [in] buffer to detach from. @@ -802,7 +843,7 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct dma_buf_attachment *attach) if (dma_buf_is_dynamic(attach->dmabuf)) dma_resv_lock(attach->dmabuf->resv, NULL); - dmabuf->ops->unmap_dma_buf(attach, attach->sgt, attach->dir); + __unmap_dma_buf(attach, attach->sgt, attach->dir); if (dma_buf_is_dynamic(attach->dmabuf)) { dma_buf_unpin(attach); @@ -924,7 +965,7 @@ struct sg_table *dma_buf_map_attachment(struct dma_buf_attachment *attach, } } - sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction); + sg_table = __map_dma_buf(attach, direction); if (!sg_table) sg_table = ERR_PTR(-ENOMEM); @@ -987,7 +1028,7 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment *attach, if (dma_buf_is_dynamic(attach->dmabuf)) dma_resv_assert_held(attach->dmabuf->resv); - attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction); + __unmap_dma_buf(attach, sg_table, direction); if (dma_buf_is_dynamic(attach->dmabuf) && !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY)) diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 628681bf6c99..efdc56b9d95f 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -154,6 +154,12 @@ struct dma_buf_ops { * On failure, returns a negative error value wrapped into a pointer. * May also return -EINTR when a signal was received while being * blocked. + * + * Note that exporters should not try to cache the scatter list, or + * return the same one for multiple calls. Caching is done either by the + * DMA-BUF code (for non-dynamic importers) or the importer. Ownership + * of the scatter list is transferred to the caller, and returned by + * @unmap_dma_buf. */ struct sg_table * (*map_dma_buf)(struct dma_buf_attachment *, enum dma_data_direction); -- 2.29.2

6 11

[PATCH 1/3] drm/vmwgfx: Drop svga_lock
by Daniel Vetter 18 Jan '21

18 Jan '21

This isn't actually protecting anything becuase: - when running, ttm_resource_manager->use_type is protected through vmw_private->reservation_semaphore against concurrent execbuf or well anything else that might evict or reserve buffers - during suspend/resume there's nothing else running, hence vmw_pm_freeze and vmw_pm_restore do not need to take the same lock. - this also holds for the SVGA_REG_ENABLE register write Hence it is safe to just remove that spinlock. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: VMware Graphics <linux-graphics-maintainer(a)vmware.com> Cc: Roland Scheidegger <sroland(a)vmware.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 10 +--------- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 - 2 files changed, 1 insertion(+), 10 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 0008be02d31c..204f7a1830f0 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -672,7 +672,6 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) spin_lock_init(&dev_priv->hw_lock); spin_lock_init(&dev_priv->waiter_lock); spin_lock_init(&dev_priv->cap_lock); - spin_lock_init(&dev_priv->svga_lock); spin_lock_init(&dev_priv->cursor_lock); for (i = vmw_res_context; i < vmw_res_max; ++i) { @@ -1189,12 +1188,10 @@ static void __vmw_svga_enable(struct vmw_private *dev_priv) { struct ttm_resource_manager *man = ttm_manager_type(&dev_priv->bdev, TTM_PL_VRAM); - spin_lock(&dev_priv->svga_lock); if (!ttm_resource_manager_used(man)) { vmw_write(dev_priv, SVGA_REG_ENABLE, SVGA_REG_ENABLE); ttm_resource_manager_set_used(man, true); } - spin_unlock(&dev_priv->svga_lock); } /** @@ -1220,14 +1217,12 @@ static void __vmw_svga_disable(struct vmw_private *dev_priv) { struct ttm_resource_manager *man = ttm_manager_type(&dev_priv->bdev, TTM_PL_VRAM); - spin_lock(&dev_priv->svga_lock); if (ttm_resource_manager_used(man)) { ttm_resource_manager_set_used(man, false); vmw_write(dev_priv, SVGA_REG_ENABLE, SVGA_REG_ENABLE_HIDE | SVGA_REG_ENABLE_ENABLE); } - spin_unlock(&dev_priv->svga_lock); } /** @@ -1254,17 +1249,14 @@ void vmw_svga_disable(struct vmw_private *dev_priv) */ vmw_kms_lost_device(dev_priv->dev); ttm_write_lock(&dev_priv->reservation_sem, false); - spin_lock(&dev_priv->svga_lock); if (ttm_resource_manager_used(man)) { ttm_resource_manager_set_used(man, false); - spin_unlock(&dev_priv->svga_lock); if (ttm_resource_manager_evict_all(&dev_priv->bdev, man)) DRM_ERROR("Failed evicting VRAM buffers.\n"); vmw_write(dev_priv, SVGA_REG_ENABLE, SVGA_REG_ENABLE_HIDE | SVGA_REG_ENABLE_ENABLE); - } else - spin_unlock(&dev_priv->svga_lock); + } ttm_write_unlock(&dev_priv->reservation_sem); } diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h index 5b9a28157dd3..715f2bfee08a 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h @@ -596,7 +596,6 @@ struct vmw_private { bool stealth; bool enable_fb; - spinlock_t svga_lock; /** * PM management. -- 2.29.2

4 6

[PATCH 0/3] Fixes to bridge/panel and ingenic-drm
by Paul Cercueil 18 Jan '21

18 Jan '21

Hi, Here are three independent fixes. The first one addresses a use-after-free in bridge/panel.c; the second one addresses a use-after-free in the ingenic-drm driver; finally, the third one makes the ingenic-drm driver work again on older Ingenic SoCs. Cheers, -Paul Paul Cercueil (3): drm: bridge/panel: Cleanup connector on bridge detach drm/ingenic: Register devm action to cleanup encoders drm/ingenic: Fix non-OSD mode drivers/gpu/drm/bridge/panel.c | 4 ++++ drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 21 +++++++++++++++++---- 2 files changed, 21 insertions(+), 4 deletions(-) -- 2.29.2

3 7

[PATCH] drm/panel: panel-simple: add bus-format and connector-type to Innolux n116bge
by Heiko Stuebner 18 Jan '21

18 Jan '21

From: Heiko Stuebner <heiko.stuebner(a)theobroma-systems.com> The Innolux n116bge panel has an eDP connector and 3*6 bits bus format. Signed-off-by: Heiko Stuebner <heiko.stuebner(a)theobroma-systems.com> --- drivers/gpu/drm/panel/panel-simple.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 41bbec72b2da..a0b65d263dce 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -2265,6 +2265,8 @@ static const struct panel_desc innolux_n116bge = { .width = 256, .height = 144, }, + .bus_format = MEDIA_BUS_FMT_RGB666_1X18, + .connector_type = DRM_MODE_CONNECTOR_eDP, }; static const struct drm_display_mode innolux_n125hce_gn1_mode = { -- 2.29.2

2 2

Re: [BUG] DRM kernel NULL pointer dereference (linux-next 20210115)
by Thomas Zimmermann 18 Jan '21

18 Jan '21

(cc'ing dri-devel) Hi thanks for reporting the bug. Am 17.01.21 um 12:12 schrieb Andy Lavr: > Hey, > > > You forgot to add these commits to linux-next: > > > drm: Move struct drm_device.pdev to legacy > > https://patchwork.kernel.org/project/intel-gfx/cover/20210107080748.4768-1-… > > > I committed these patches to my local tree and that solved my problem. > > > * v3,4/8] drm/i915: Remove references to struct drm_device.pdev > <https://patchwork.kernel.org/project/intel-gfx/patch/20210107080748.4768-5-…> > * [v3,5/8] drm/i915/gt: Remove references to struct drm_device.pdev > <https://patchwork.kernel.org/project/intel-gfx/patch/20210107080748.4768-6-…> > * [v3,6/8] drm/i915/gvt: Remove references to struct drm_device.pdev > <https://patchwork.kernel.org/project/intel-gfx/patch/20210107080748.4768-7-…> > * [v3,8/8] drm: Upcast struct drm_device.dev to struct pci_device; > replace pdev > <https://patchwork.kernel.org/project/intel-gfx/patch/20210107080748.4768-9-…> These patches have not been merged yet as they have to wait for some preparation in the i915 driver. I reduced the final patch, so it should change the buggy code. Could you please apply only the attached patchfile and report if it fixes the issue? Best regards Thomas > > > > Thanks to all! > > > 16.01.2021 15:17, Andy Lavr: >> >> Hey, >> >> >> *linux-next 20210114 work fine.* >> >> >> *linux-next 20210115:* >> >> Jan 15 17:34:30 wip kernel: [ 35.185982] *BUG: kernel NULL pointer >> dereference, address: 0000000000000010* >> Jan 15 17:34:30 wip kernel: [ 35.186988] #PF: supervisor read access >> in kernel mode >> Jan 15 17:34:30 wip kernel: [ 35.187984] #PF: error_code(0x0000) - >> not-present page >> Jan 15 17:34:30 wip kernel: [ 35.189016] PGD 0 P4D 0 >> Jan 15 17:34:30 wip kernel: [ 35.190508] Oops: 0000 [#1] SMP PTI >> Jan 15 17:34:30 wip kernel: [ 35.191814] CPU: 6 PID: 1319 Comm: Xorg >> Not tainted 5.11.13-dragon-sandybridge #202101150001 >> Jan 15 17:34:30 wip kernel: [ 35.192847] Hardware name: Dell Inc. >> Precision M6600/04YY4M, BIOS A18 09/14/2018 >> Jan 15 17:34:30 wip kernel: [ 35.193877] *RIP: >> 0010:drm_pci_set_busid+0x1a/0x80 [drm]* >> Jan 15 17:34:30 wip kernel: [ 35.194950] Code: fc 06 f8 c8 00 00 00 >> 00 00 00 00 00 00 00 00 00 0f 1f 44 00 00 55 53 50 48 89 f3 31 d2 81 >> 3f 04 00 01 00 48 8b 87 78 01 00 00 <48> 8b 48 10 7c 09 48 8b 91 d0 01 >> 00 00 8b 12 0f b6 89 e0 01 00 00 >> Jan 15 17:34:30 wip kernel: [ 35.196094] RSP: 0018:ffffaacf485afd38 >> EFLAGS: 00010246 >> Jan 15 17:34:30 wip kernel: [ 35.197695] RAX: 0000000000000000 RBX: >> ffff95f1684e5000 RCX: ffffffff8b06f380 >> Jan 15 17:34:30 wip kernel: [ 35.198872] RDX: 0000000000000000 RSI: >> ffff95f1684e5000 RDI: ffff95f175240010 >> Jan 15 17:34:30 wip kernel: [ 35.200037] RBP: 00000000ffffffea R08: >> 000000000000e200 R09: 0000000000000001 >> Jan 15 17:34:30 wip kernel: [ 35.201205] R10: ffff95f16de88b00 R11: >> ffffffffc03e1990 R12: ffff95f1684e5000 >> Jan 15 17:34:30 wip kernel: [ 35.202383] R13: 00007fff8865e240 R14: >> ffff95f1752400a8 R15: ffff95f175240010 >> Jan 15 17:34:30 wip kernel: [ 35.203554] FS: 000070bcd696da40(0000) >> GS:ffff95f41db80000(0000) knlGS:0000000000000000 >> Jan 15 17:34:30 wip kernel: [ 35.204742] CS: 0010 DS: 0000 ES: 0000 >> CR0: 0000000080050033 >> Jan 15 17:34:30 wip kernel: [ 35.205936] CR2: 0000000000000010 CR3: >> 0000000186c28006 CR4: 00000000000606e0 >> Jan 15 17:34:30 wip kernel: [ 35.207144] Call Trace: >> Jan 15 17:34:30 wip kernel: [ 35.208370] drm_setversion+0x13e/0x170 >> [drm] >> Jan 15 17:34:30 wip kernel: [ 35.209596] ? drm_getstats+0x20/0x20 [drm] >> Jan 15 17:34:30 wip kernel: [ 35.210799] drm_ioctl_kernel+0xe2/0x150 >> [drm] >> Jan 15 17:34:30 wip kernel: [ 35.211989] drm_ioctl+0x30b/0x440 [drm] >> Jan 15 17:34:30 wip kernel: [ 35.213170] ? drm_getstats+0x20/0x20 [drm] >> Jan 15 17:34:30 wip kernel: [ 35.214351] amdgpu_drm_ioctl+0x44/0x80 >> [amdgpu] >> Jan 15 17:34:30 wip kernel: [ 35.215696] __se_sys_ioctl+0x78/0xc0 >> Jan 15 17:34:30 wip kernel: [ 35.216848] do_syscall_64+0x33/0x70 >> Jan 15 17:34:30 wip kernel: [ 35.218002] >> entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> Jan 15 17:34:30 wip kernel: [ 35.219177] RIP: 0033:0x70bcd6dd931b >> Jan 15 17:34:30 wip kernel: [ 35.220654] Code: 89 d8 49 8d 3c 1c 48 >> f7 d8 49 39 c4 72 b5 e8 1c ff ff ff 85 c0 78 ba 4c 89 e0 5b 5d 41 5c >> c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b >> 0d 1d 3b 0d 00 f7 d8 64 89 01 48 >> Jan 15 17:34:30 wip kernel: [ 35.222211] RSP: 002b:00007fff8865e208 >> EFLAGS: 00000202 ORIG_RAX: 0000000000000010 >> Jan 15 17:34:30 wip kernel: [ 35.223778] RAX: ffffffffffffffda RBX: >> 00007fff8865e240 RCX: 000070bcd6dd931b >> Jan 15 17:34:30 wip kernel: [ 35.225145] RDX: 00007fff8865e240 RSI: >> 00000000c0106407 RDI: 000000000000000c >> Jan 15 17:34:30 wip kernel: [ 35.226420] RBP: 00000000c0106407 R08: >> 0000000000000031 R09: 0000000000000000 >> Jan 15 17:34:30 wip kernel: [ 35.227691] R10: 000070bcd7850ec0 R11: >> 0000000000000202 R12: 00005b60f67cbb50 >> Jan 15 17:34:30 wip kernel: [ 35.228954] R13: 000000000000000c R14: >> 00005b60f67cbb90 R15: 0000000000000000 >> Jan 15 17:34:30 wip kernel: [ 35.229231] iwlwifi 0000:03:00.0: Radio >> type=0x0-0x3-0x1 >> Jan 15 17:34:30 wip kernel: [ 35.230218] Modules linked in: vfat fat >> intel_rapl_msr hid_generic mei_hdcp at24 dell_rbtn iwldvm dell_laptop >> dell_smm_hwmon mac80211 intel_rapl_common libarc4 snd_hda_codec_idt >> snd_hda_codec_generic x86_pkg_temp_thermal ledtrig_audio >> intel_powerclamp snd_hda_codec_hdmi crct10dif_pclmul iwlwifi >> crc32_pclmul ghash_clmulni_intel snd_hda_intel rapl snd_intel_dspcfg >> usbhid intel_cstate firewire_ohci dell_wmi sdhci_pci hid snd_hda_codec >> firewire_core dell_smbios crc_itu_t mei_me dcdbas cfg80211 >> sparse_keymap cqhci i2c_i801 sdhci snd_hda_core joydev e1000e >> snd_hwdep wmi_bmof dell_wmi_descriptor i2c_smbus mei tpm_tis >> tpm_tis_core tpm dell_smo8800 xt_hl ip6_tables ip6t_rt nf_log_ipv4 >> nf_log_common ipt_REJECT nf_reject_ipv4 xt_LOG nft_limit xt_limit >> xt_addrtype xt_tcpudp sch_cake tcp_yeah tcp_vegas xt_conntrack >> nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nft_counter >> coretemp nf_tables nfnetlink parport_pc ppdev lp parport binfmt_misc >> ip_tables x_tables xfs raid10 raid456 >> Jan 15 17:34:30 wip kernel: [ 35.232152] async_raid6_recov async_pq >> async_xor async_memcpy async_tx raid1 raid0 multipath linear amdgpu >> iommu_v2 gpu_sched drm_ttm_helper ttm i2c_algo_bit drm_kms_helper cec >> aesni_intel sysimgblt syscopyarea sysfillrect fb_sys_fops crypto_simd >> cryptd psmouse input_leds drm ahci serio_raw libahci wmi video mac_hid >> Jan 15 17:34:30 wip kernel: [ 35.242819] CR2: 0000000000000010 >> Jan 15 17:34:30 wip kernel: [ 35.244502] ---[ end trace >> 47eef7912dfa1ae6 ]--- >> Jan 15 17:34:30 wip kernel: [ 35.494899] *RIP: >> 0010:drm_pci_set_busid+0x1a/0x80 [drm]* >> Jan 15 17:34:30 wip kernel: [ 35.496577] Code: fc 06 f8 c8 00 00 00 >> 00 00 00 00 00 00 00 00 00 0f 1f 44 00 00 55 53 50 48 89 f3 31 d2 81 >> 3f 04 00 01 00 48 8b 87 78 01 00 00 <48> 8b 48 10 7c 09 48 8b 91 d0 01 >> 00 00 8b 12 0f b6 89 e0 01 00 00 >> Jan 15 17:34:30 wip kernel: [ 35.498313] RSP: 0018:ffffaacf485afd38 >> EFLAGS: 00010246 >> Jan 15 17:34:30 wip kernel: [ 35.500089] RAX: 0000000000000000 RBX: >> ffff95f1684e5000 RCX: ffffffff8b06f380 >> Jan 15 17:34:30 wip kernel: [ 35.501919] RDX: 0000000000000000 RSI: >> ffff95f1684e5000 RDI: ffff95f175240010 >> Jan 15 17:34:30 wip kernel: [ 35.503708] RBP: 00000000ffffffea R08: >> 000000000000e200 R09: 0000000000000001 >> Jan 15 17:34:30 wip kernel: [ 35.505483] R10: ffff95f16de88b00 R11: >> ffffffffc03e1990 R12: ffff95f1684e5000 >> Jan 15 17:34:30 wip kernel: [ 35.507276] R13: 00007fff8865e240 R14: >> ffff95f1752400a8 R15: ffff95f175240010 >> Jan 15 17:34:30 wip kernel: [ 35.509058] FS: 000070bcd696da40(0000) >> GS:ffff95f41db80000(0000) knlGS:0000000000000000 >> Jan 15 17:34:30 wip kernel: [ 35.510866] CS: 0010 DS: 0000 ES: 0000 >> CR0: 0000000080050033 >> Jan 15 17:34:30 wip kernel: [ 35.512647] CR2: 0000000000000010 CR3: >> 0000000186c28006 CR4: 00000000000606e0 >> >> >> >> -- >> Best regards, Andy Lavr. >> >> CONFIDENTIAL NOTE >> >> This email (including any attachments) is intended only for the person or entity to which it is addressed >> and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other >> use of, or taking of any action in reliance upon, this information by persons or entities other than the >> intended recipient is prohibited. If you received this in error, please notify the sender immediately and >> delete the material completely from your system. E-mail communication cannot be guaranteed to be reliable, >> secure, error-free or virus-free. Accordingly, we cannot accept liability for any damage sustained as a >> result of any virus, error or incompleteness of this e-mail or any failure to deliver promptly or at all >> information exchanged between you and us by this means. If you suspect that this e-mail may have been >> intercepted or amended, please contact the sender. Any views or opinions expressed in this email are solely >> those of the author and do not necessarily represent those of our entity or related/associated entities. > > -- > Best regards, Andy Lavr. > > CONFIDENTIAL NOTE > > This email (including any attachments) is intended only for the person or entity to which it is addressed > and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon, this information by persons or entities other than the > intended recipient is prohibited. If you received this in error, please notify the sender immediately and > delete the material completely from your system. E-mail communication cannot be guaranteed to be reliable, > secure, error-free or virus-free. Accordingly, we cannot accept liability for any damage sustained as a > result of any virus, error or incompleteness of this e-mail or any failure to deliver promptly or at all > information exchanged between you and us by this means. If you suspect that this e-mail may have been > intercepted or amended, please contact the sender. Any views or opinions expressed in this email are solely > those of the author and do not necessarily represent those of our entity or related/associated entities. > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer

2 3

[PATCH] drm/vc4: Unify PCM card's driver_name
by Nicolas Saenz Julienne 18 Jan '21

18 Jan '21

User-space ALSA matches a card's driver name against an internal list of aliases in order to select the correct configuration for the system. When the driver name isn't defined, the match is performed against the card's name. With the introduction of RPi4 we now have two HDMI ports with two distinct audio cards. This is reflected in their names, making them different from previous RPi versions. With this, ALSA ultimately misses the board's configuration on RPi4. In order to avoid this, set "card->driver_name" to "vc4-hdmi" unanimously. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne(a)suse.de> Fixes: f437bc1ec731 ("drm/vc4: drv: Support BCM2711") --- drivers/gpu/drm/vc4/vc4_hdmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index 97f368bc1c67..4bdc8e71b5e5 100644 --- a/drivers/gpu/drm/vc4/vc4_hdmi.c +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c @@ -1404,6 +1404,7 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi) card->dai_link = dai_link; card->num_links = 1; card->name = vc4_hdmi->variant->card_name; + card->driver_name = "vc4-hdmi"; card->dev = dev; card->owner = THIS_MODULE; -- 2.29.2

3 2

[PATCH] vgaarb: Remove unneeded semicolons
by Yue Zou 18 Jan '21

18 Jan '21

Remove superfluous semicolons after function definitions. Signed-off-by: Yue Zou <zouyue3(a)huawei.com> --- include/linux/vgaarb.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h index 977caf96c8d2..fc6dfeba04a5 100644 --- a/include/linux/vgaarb.h +++ b/include/linux/vgaarb.h @@ -121,9 +121,9 @@ extern struct pci_dev *vga_default_device(void); extern void vga_set_default_device(struct pci_dev *pdev); extern int vga_remove_vgacon(struct pci_dev *pdev); #else -static inline struct pci_dev *vga_default_device(void) { return NULL; }; -static inline void vga_set_default_device(struct pci_dev *pdev) { }; -static inline int vga_remove_vgacon(struct pci_dev *pdev) { return 0; }; +static inline struct pci_dev *vga_default_device(void) { return NULL; } +static inline void vga_set_default_device(struct pci_dev *pdev) { } +static inline int vga_remove_vgacon(struct pci_dev *pdev) { return 0; } #endif /* -- 2.25.1

2 1

[PATCH v5 1/2] drm/doc: fix drm_plane_type docs
by Simon Ser 18 Jan '21

18 Jan '21

The docs for enum drm_plane_type mention legacy IOCTLs, however the plane type is not tied to legacy IOCTLs, the drm_cursor.primary and cursor fields are. Add a small paragraph to reference these. Instead, document expectations for primary and cursor planes for non-legacy userspace. Note that these docs are for driver developers, not userspace developers, so internal kernel APIs are mentionned. Signed-off-by: Simon Ser <contact(a)emersion.fr> Reviewed-by: Daniel Vetter <daniel(a)ffwll.ch> Cc: Pekka Paalanen <ppaalanen(a)gmail.com> --- include/drm/drm_plane.h | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h index 8ef06ee1c8eb..95ab14a4336a 100644 --- a/include/drm/drm_plane.h +++ b/include/drm/drm_plane.h @@ -538,10 +538,14 @@ struct drm_plane_funcs { * * For compatibility with legacy userspace, only overlay planes are made * available to userspace by default. Userspace clients may set the - * DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that they + * &DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that they * wish to receive a universal plane list containing all plane types. See also * drm_for_each_legacy_plane(). * + * In addition to setting each plane's type, drivers need to setup the + * &drm_crtc.primary and optionally &drm_crtc.cursor pointers for legacy + * IOCTLs. See drm_crtc_init_with_planes(). + * * WARNING: The values of this enum is UABI since they're exposed in the "type" * property. */ @@ -557,19 +561,20 @@ enum drm_plane_type { /** * @DRM_PLANE_TYPE_PRIMARY: * - * Primary planes represent a "main" plane for a CRTC. Primary planes - * are the planes operated upon by CRTC modesetting and flipping - * operations described in the &drm_crtc_funcs.page_flip and - * &drm_crtc_funcs.set_config hooks. + * A primary plane attached to a CRTC is the most likely to be able to + * light up the CRTC when no scaling/cropping is used and the plane + * covers the whole CRTC. */ DRM_PLANE_TYPE_PRIMARY, /** * @DRM_PLANE_TYPE_CURSOR: * - * Cursor planes represent a "cursor" plane for a CRTC. Cursor planes - * are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and - * DRM_IOCTL_MODE_CURSOR2 IOCTLs. + * A cursor plane attached to a CRTC is more likely to be able to be + * enabled when no scaling/cropping is used and the framebuffer has the + * size indicated by &drm_mode_config.cursor_width and + * &drm_mode_config.cursor_height. Additionally, if the driver doesn't + * support modifiers, the framebuffer should have a linear layout. */ DRM_PLANE_TYPE_CURSOR, }; -- 2.30.0

3 4

BUG: unable to handle kernel NULL pointer dereference in fbcon_cursor
by syzbot 18 Jan '21

18 Jan '21

Hello, syzbot found the following issue on: HEAD commit: 6dd65e60 Add linux-next specific files for 20201110 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=1276af62500000 kernel config: https://syzkaller.appspot.com/x/.config?x=4fab43daf5c54712 dashboard link: https://syzkaller.appspot.com/bug?extid=b67aaae8d3a927f68d20 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+b67aaae8d3a927f68d20(a)syzkaller.appspotmail.com BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 4e683067 P4D 4e683067 PUD 14850067 PMD 0 Oops: 0010 [#1] PREEMPT SMP KASAN CPU: 0 PID: 9433 Comm: syz-executor.5 Not tainted 5.10.0-rc3-next-20201110-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffffc9000bca7858 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: ffff888144509000 RDI: ffff888010079000 RBP: ffff888010079000 R08: 0000000000000000 R09: ffffffff8cecc387 R10: 0000000000000003 R11: 0000000000000000 R12: ffff888144509000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000720 FS: 00007f5822bee700(0000) GS:ffff8880b9e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000004e973000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: fbcon_cursor+0x50e/0x620 drivers/video/fbdev/core/fbcon.c:1346 hide_cursor+0x85/0x280 drivers/tty/vt/vt.c:907 redraw_screen+0x5ed/0x790 drivers/tty/vt/vt.c:1012 vc_do_resize+0xed3/0x1150 drivers/tty/vt/vt.c:1326 fbcon_set_disp+0x831/0xda0 drivers/video/fbdev/core/fbcon.c:1413 con2fb_init_display drivers/video/fbdev/core/fbcon.c:816 [inline] set_con2fb_map+0x7a6/0xf80 drivers/video/fbdev/core/fbcon.c:887 fbcon_set_con2fb_map_ioctl+0x165/0x220 drivers/video/fbdev/core/fbcon.c:3072 do_fb_ioctl+0x5b6/0x690 drivers/video/fbdev/core/fbmem.c:1156 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45deb9 Code: 0d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f5822bedc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000000000e2c0 RCX: 000000000045deb9 RDX: 00000000200000c0 RSI: 0000000000004610 RDI: 0000000000000006 RBP: 000000000118bf60 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118bf2c R13: 00007ffe024fb66f R14: 00007f5822bee9c0 R15: 000000000118bf2c Modules linked in: CR2: 0000000000000000 BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 4e683067 P4D 4e683067 PUD 14850067 PMD 0 Oops: 0010 [#2] PREEMPT SMP KASAN CPU: 0 PID: 9433 Comm: syz-executor.5 Not tainted 5.10.0-rc3-next-20201110-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffffc9000bca7278 EFLAGS: 00010086 RAX: 0000000000000007 RBX: 0000000000000000 RCX: 0000000000000007 RDX: 0000000000000002 RSI: ffff888144509000 RDI: ffff888010079000 RBP: ffff888010079000 R08: 0000000000000000 R09: ffffffff8cecc387 R10: 0000000000000003 R11: 0000000000000001 R12: ffff888144509000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000720 FS: 00007f5822bee700(0000) GS:ffff8880b9e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000004e973000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: fbcon_cursor+0x50e/0x620 drivers/video/fbdev/core/fbcon.c:1346 hide_cursor+0x85/0x280 drivers/tty/vt/vt.c:907 redraw_screen+0x5ed/0x790 drivers/tty/vt/vt.c:1012 fbcon_blank+0x8c5/0xc30 drivers/video/fbdev/core/fbcon.c:2248 do_unblank_screen+0x25b/0x470 drivers/tty/vt/vt.c:4406 bust_spinlocks+0x5b/0xe0 lib/bust_spinlocks.c:26 oops_end+0x2b/0xe0 arch/x86/kernel/dumpstack.c:346 no_context+0x5f2/0xa20 arch/x86/mm/fault.c:752 __bad_area_nosemaphore+0xa9/0x400 arch/x86/mm/fault.c:840 do_user_addr_fault+0x7d7/0xba0 arch/x86/mm/fault.c:1340 handle_page_fault arch/x86/mm/fault.c:1434 [inline] exc_page_fault+0x9e/0x180 arch/x86/mm/fault.c:1490 asm_exc_page_fault+0x1e/0x30 arch/x86/include/asm/idtentry.h:580 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffffc9000bca7858 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: ffff888144509000 RDI: ffff888010079000 RBP: ffff888010079000 R08: 0000000000000000 R09: ffffffff8cecc387 R10: 0000000000000003 R11: 0000000000000000 R12: ffff888144509000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000720 Modules linked in: CR2: 0000000000000000 ---[ end trace 8931af4863156cb4 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffffc9000bca7858 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: ffff888144509000 RDI: ffff888010079000 RBP: ffff888010079000 R08: 0000000000000000 R09: ffffffff8cecc387 R10: 0000000000000003 R11: 0000000000000000 R12: ffff888144509000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000720 FS: 00007f5822bee700(0000) GS:ffff8880b9e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000004e973000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

2 3

← Newer
1
...
44
45
46
47
48
49
50
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2021