dri-devel May 2022

dri-devel@lists.freedesktop.org

344 participants
736 discussions

[PATCH v1 0/2] eDP/DP Phy vdda realted function
by Kuogee Hsieh 18 May '22

18 May '22

1) add regulator_set_load() to eDP/DP phy 2) remove vdda related function out of eDP/DP controller Kuogee Hsieh (2): phy/qcom: add regulator_set_load to edp/dp phy drm/msm/dp: delete vdda regulator related functions from eDP/DP controller drivers/gpu/drm/msm/dp/dp_parser.c | 14 ------ drivers/gpu/drm/msm/dp/dp_parser.h | 6 --- drivers/gpu/drm/msm/dp/dp_power.c | 95 +------------------------------------ drivers/phy/qualcomm/phy-qcom-edp.c | 25 ++++++++-- drivers/phy/qualcomm/phy-qcom-qmp.c | 24 ++++++++++ 5 files changed, 47 insertions(+), 117 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 5

[V2 0/3] Expose max and current bpc via debugfs
by Bhanuprakash Modem 18 May '22

18 May '22

This series will expose the Connector's max supported bpc via connector debugfs and Crtc's current bpc via crtc debugfs. Also move the existing vendor specific "output_bpc" logic to drm. Test-with: 20220411094147.1650859-2-bhanuprakash.modem(a)intel.com Bhanuprakash Modem (3): drm/debug: Expose connector's max supported bpc via debugfs drm/i915/display/debug: Expose crtc current bpc via debugfs drm/amd/display: Move connector debugfs to drm .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 -- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 38 +++++++------------ .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.h | 2 - drivers/gpu/drm/drm_debugfs.c | 21 ++++++++++ .../drm/i915/display/intel_display_debugfs.c | 28 ++++++++++++++ 5 files changed, 62 insertions(+), 31 deletions(-) -- 2.35.1

6 21

[PATCH] [v2] Kbuild: move to -std=gnu11
by Arnd Bergmann 18 May '22

18 May '22

From: Arnd Bergmann <arnd(a)arndb.de> During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99, which allows using variable declaration inside of a for() loop. While the C99, C11 and later standards introduce many other features, most of these are already available in gnu89 as GNU extensions as well. An earlier attempt to do this when gcc-5 started defaulting to -std=gnu11 failed because at the time that caused warnings about designated initializers with older compilers. Now that gcc-5.1 is the minimum compiler version used for building kernels, that is no longer a concern. Similarly, the behavior of 'inline' functions changes between gnu89 and gnu11, but this was taken care of by defining 'inline' to include __attribute__((gnu_inline)) in order to allow building with clang a while ago. One minor issue that remains is an added gcc warning for shifts of negative integers when building with -Werror, which happens with the 'make W=1' option, as well as for three drivers in the kernel that always enable -Werror, but it was only observed with the i915 driver so far. To be on the safe side, add -Wno-shift-negative-value to any -Wextra in a Makefile. Nathan Chancellor reported an additional -Wdeclaration-after-statement warning that appears in a system header on arm, this still needs a workaround. The differences between gnu99, gnu11, gnu1x and gnu17 are fairly minimal and mainly impact warnings at the -Wpedantic level that the kernel never enables. Between these, gnu11 is the newest version that is supported by all supported compiler versions, though it is only the default on gcc-5, while all other supported versions of gcc or clang default to gnu1x/gnu17. Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbV… Link: https://github.com/ClangBuiltLinux/linux/issues/1603 Suggested-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Masahiro Yamada <masahiroy(a)kernel.org> Cc: linux-kbuild(a)vger.kernel.org Cc: llvm(a)lists.linux.dev Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- [v2] - added -std=gnu11 back, rather than just relying on the default - minor changes to changelog text --- Documentation/process/programming-language.rst | 4 ++-- .../translations/it_IT/process/programming-language.rst | 4 ++-- .../translations/zh_CN/process/programming-language.rst | 4 ++-- .../translations/zh_TW/process/programming-language.rst | 4 ++-- Makefile | 6 +++--- arch/arm64/kernel/vdso32/Makefile | 2 +- drivers/gpu/drm/i915/Makefile | 1 + drivers/staging/greybus/tools/Makefile | 3 ++- fs/btrfs/Makefile | 1 + scripts/Makefile.extrawarn | 1 + 10 files changed, 17 insertions(+), 13 deletions(-) diff --git a/Documentation/process/programming-language.rst b/Documentation/process/programming-language.rst index ec474a70a02f..894f2a6eb9db 100644 --- a/Documentation/process/programming-language.rst +++ b/Documentation/process/programming-language.rst @@ -5,8 +5,8 @@ Programming Language The kernel is written in the C programming language [c-language]_. More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 -(including some C99 features). ``clang`` [clang]_ is also supported, see +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11 +(including some C17 features). ``clang`` [clang]_ is also supported, see docs on :ref:`Building Linux with Clang/LLVM <kbuild_llvm>`. This dialect contains many extensions to the language [gnu-extensions]_, diff --git a/Documentation/translations/it_IT/process/programming-language.rst b/Documentation/translations/it_IT/process/programming-language.rst index 41db2598ce11..aa21097737ae 100644 --- a/Documentation/translations/it_IT/process/programming-language.rst +++ b/Documentation/translations/it_IT/process/programming-language.rst @@ -10,8 +10,8 @@ Linguaggio di programmazione Il kernel è scritto nel linguaggio di programmazione C [it-c-language]_. Più precisamente, il kernel viene compilato con ``gcc`` [it-gcc]_ usando -l'opzione ``-std=gnu89`` [it-gcc-c-dialect-options]_: il dialetto GNU -dello standard ISO C90 (con l'aggiunta di alcune funzionalità da C99). +l'opzione ``-std=gnu11`` [it-gcc-c-dialect-options]_: il dialetto GNU +dello standard ISO C11 (con l'aggiunta di alcune funzionalità da C17). Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione :ref:`Building Linux with Clang/LLVM <kbuild_llvm>`. diff --git a/Documentation/translations/zh_CN/process/programming-language.rst b/Documentation/translations/zh_CN/process/programming-language.rst index 2a47a1d2ec20..58d2b3bd2d85 100644 --- a/Documentation/translations/zh_CN/process/programming-language.rst +++ b/Documentation/translations/zh_CN/process/programming-language.rst @@ -9,8 +9,8 @@ ============ 内核是用C语言 :ref:`c-language <cn_c-language>` 编写的。更准确地说，内核通常是用 :ref:`gcc <cn_gcc>` -在 ``-std=gnu89`` :ref:`gcc-c-dialect-options <cn_gcc-c-dialect-options>` 下编译的：ISO C90的 GNU 方言（ -包括一些C99特性） +在 ``-std=gnu11`` :ref:`gcc-c-dialect-options <cn_gcc-c-dialect-options>` 下编译的：ISO C11的 GNU 方言（ +包括一些C17特性）这种方言包含对语言 :ref:`gnu-extensions <cn_gnu-extensions>` 的许多扩展，当然，它们许多都在内核中使用。 diff --git a/Documentation/translations/zh_TW/process/programming-language.rst b/Documentation/translations/zh_TW/process/programming-language.rst index 54e3699eadf8..235de05f7e2c 100644 --- a/Documentation/translations/zh_TW/process/programming-language.rst +++ b/Documentation/translations/zh_TW/process/programming-language.rst @@ -12,8 +12,8 @@ ============ 內核是用C語言 :ref:`c-language <tw_c-language>` 編寫的。更準確地說，內核通常是用 :ref:`gcc <tw_gcc>` -在 ``-std=gnu89`` :ref:`gcc-c-dialect-options <tw_gcc-c-dialect-options>` 下編譯的：ISO C90的 GNU 方言（ -包括一些C99特性） +在 ``-std=gnu11`` :ref:`gcc-c-dialect-options <tw_gcc-c-dialect-options>` 下編譯的：ISO C11的 GNU 方言（ +包括一些C17特性）這種方言包含對語言 :ref:`gnu-extensions <tw_gnu-extensions>` 的許多擴展，當然，它們許多都在內核中使用。 diff --git a/Makefile b/Makefile index 289ce2be8032..66496eaeb9ec 100644 --- a/Makefile +++ b/Makefile @@ -432,7 +432,7 @@ HOSTCXX = g++ endif export KBUILD_USERCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \ - -O2 -fomit-frame-pointer -std=gnu89 + -O2 -fomit-frame-pointer -std=gnu11 export KBUILD_USERLDFLAGS := KBUILD_HOSTCFLAGS := $(KBUILD_USERCFLAGS) $(HOST_LFS_CFLAGS) $(HOSTCFLAGS) @@ -515,7 +515,7 @@ KBUILD_CFLAGS := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE \ -Werror=implicit-function-declaration -Werror=implicit-int \ -Werror=return-type -Wno-format-security \ - -std=gnu89 + -std=gnu11 KBUILD_CPPFLAGS := -D__KERNEL__ KBUILD_AFLAGS_KERNEL := KBUILD_CFLAGS_KERNEL := @@ -782,7 +782,7 @@ KBUILD_CFLAGS += $(KBUILD_CFLAGS-y) $(CONFIG_CC_IMPLICIT_FALLTHROUGH) ifdef CONFIG_CC_IS_CLANG KBUILD_CPPFLAGS += -Qunused-arguments -# The kernel builds with '-std=gnu89' so use of GNU extensions is acceptable. +# The kernel builds with '-std=gnu11' so use of GNU extensions is acceptable. KBUILD_CFLAGS += -Wno-gnu # CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the # source of a reference will be _MergedGlobals and not on of the whitelisted names. diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile index 6c01b63ff56d..9378ea055bf2 100644 --- a/arch/arm64/kernel/vdso32/Makefile +++ b/arch/arm64/kernel/vdso32/Makefile @@ -68,7 +68,7 @@ VDSO_CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \ -fno-strict-aliasing -fno-common \ -Werror-implicit-function-declaration \ -Wno-format-security \ - -std=gnu89 + -std=gnu11 VDSO_CFLAGS += -O2 # Some useful compiler-dependent flags from top-level Makefile VDSO_CFLAGS += $(call cc32-option,-Wdeclaration-after-statement,) diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 1b62b9f65196..1618a6e0af4e 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -17,6 +17,7 @@ subdir-ccflags-y += -Wno-unused-parameter subdir-ccflags-y += -Wno-type-limits subdir-ccflags-y += -Wno-missing-field-initializers subdir-ccflags-y += -Wno-sign-compare +subdir-ccflags-y += -Wno-shift-negative-value subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable) subdir-ccflags-y += $(call cc-disable-warning, frame-address) subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror diff --git a/drivers/staging/greybus/tools/Makefile b/drivers/staging/greybus/tools/Makefile index ad0ae8053b79..a3bbd73171f2 100644 --- a/drivers/staging/greybus/tools/Makefile +++ b/drivers/staging/greybus/tools/Makefile @@ -12,7 +12,8 @@ CFLAGS += -std=gnu99 -Wall -Wextra -g \ -Wredundant-decls \ -Wcast-align \ -Wsign-compare \ - -Wno-missing-field-initializers + -Wno-missing-field-initializers \ + -Wno-shift-negative-value CC := $(CROSS_COMPILE)gcc diff --git a/fs/btrfs/Makefile b/fs/btrfs/Makefile index 4188ba3fd8c3..99f9995670ea 100644 --- a/fs/btrfs/Makefile +++ b/fs/btrfs/Makefile @@ -17,6 +17,7 @@ subdir-ccflags-y += $(condflags) subdir-ccflags-y += -Wno-missing-field-initializers subdir-ccflags-y += -Wno-sign-compare subdir-ccflags-y += -Wno-type-limits +subdir-ccflags-y += -Wno-shift-negative-value obj-$(CONFIG_BTRFS_FS) := btrfs.o diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn index 8be892887d71..650d0b8ceec3 100644 --- a/scripts/Makefile.extrawarn +++ b/scripts/Makefile.extrawarn @@ -36,6 +36,7 @@ KBUILD_CFLAGS += $(call cc-option, -Wstringop-truncation) KBUILD_CFLAGS += -Wno-missing-field-initializers KBUILD_CFLAGS += -Wno-sign-compare KBUILD_CFLAGS += -Wno-type-limits +KBUILD_CFLAGS += -Wno-shift-negative-value KBUILD_CPPFLAGS += -DKBUILD_EXTRA_WARN1 -- 2.29.2

14 25

(no subject)
by Christian König 18 May '22

18 May '22

Just sending that to intel-gfx to let the CI systems take a look at it. Regards, Christian.

1 5

[PATCH AUTOSEL 5.17 13/23] drm/amd/display: undo clearing of z10 related function pointers
by Sasha Levin 18 May '22

18 May '22

From: Eric Yang <Eric.Yang2(a)amd.com> [ Upstream commit 9b9bd3f640640f94272a461b2dfe558f91b322c5 ] [Why] Z10 and S0i3 have some shared path. Previous code clean up , incorrectly removed these pointers, which breaks s0i3 restore [How] Do not clear the function pointers based on Z10 disable. Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas(a)amd.com> Acked-by: Pavle Kotarac <Pavle.Kotarac(a)amd.com> Signed-off-by: Eric Yang <Eric.Yang2(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c index d7559e5a99ce..e708f07fe75a 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c +++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_init.c @@ -153,9 +153,4 @@ void dcn31_hw_sequencer_construct(struct dc *dc) dc->hwss.init_hw = dcn20_fpga_init_hw; dc->hwseq->funcs.init_pipes = NULL; } - if (dc->debug.disable_z10) { - /*hw not support z10 or sw disable it*/ - dc->hwss.z10_restore = NULL; - dc->hwss.z10_save_init = NULL; - } } -- 2.35.1

3 2

[PATCH v7, 0/7] support mt8195 decoder
by Yunfei Dong 18 May '22

18 May '22

Firstly, add mt8195 soc lat hardware and compatible, then add documents. For vp8 only support MM21 mode, H264/vp9 support MT21C, need to separate them. Lastly, enable H264 inner racing mode to reduce hardware latency. Patch 1~4 add mt8195 soc lat hardware and compatible, then add documents. Patch 5 using different format for different codecs. Patch 6 prevent kernel crash when scp reboot. Patch 7 enable H264 inner racing mode to reduce hardware latency. --- This patch depends on "add h264 decoder driver for mt8186"[1] [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20220512034620.30… --- changed with v6: - add detail error message in patch 6. changed with v5: - fix __iomem not reasonable, align share memory to dram. changed with v4: - fix sparse and smatch check fail for patch 7. changed with v3: - rebase driver to the latest media_stage. changed with v2: - add detail explanation for lat soc hardware for patch 1. changed with v1: - separate "Init VP9 stateless decode params" patch and remove it to another one. - add reviewed-by in patch v3/v4/v6 --- Yunfei Dong (7): dt-bindings: media: mediatek: vcodec: Adds decoder dt-bindings for lat soc media: mediatek: vcodec: Add to support lat soc hardware dt-bindings: media: mediatek: vcodec: Adds decoder dt-bindings for mt8195 media: mediatek: vcodec: Adds compatible for mt8195 media: mediatek: vcodec: Different codec using different capture format media: mediatek: vcodec: prevent kernel crash when scp ipi timeout media: mediatek: vcodec: Add to support H264 inner racing mode .../media/mediatek,vcodec-subdev-decoder.yaml | 52 +++++++++++++------ .../platform/mediatek/vcodec/mtk_vcodec_dec.c | 41 +++++++++++++++ .../mediatek/vcodec/mtk_vcodec_dec_drv.c | 8 +++ .../mediatek/vcodec/mtk_vcodec_dec_hw.c | 12 +++-- .../mediatek/vcodec/mtk_vcodec_dec_hw.h | 2 + .../mediatek/vcodec/mtk_vcodec_dec_pm.c | 50 ++++++++++++++++++ .../platform/mediatek/vcodec/mtk_vcodec_drv.h | 12 +++++ .../vcodec/vdec/vdec_h264_req_multi_if.c | 25 +++++++-- .../platform/mediatek/vcodec/vdec_vpu_if.c | 5 ++ 9 files changed, 183 insertions(+), 24 deletions(-) -- 2.18.0

1 7

[PATCH AUTOSEL 5.15 07/17] fbdev: Prevent possible use-after-free in fb_release()
by Sasha Levin 18 May '22

18 May '22

From: Daniel Vetter <daniel.vetter(a)ffwll.ch> [ Upstream commit 89bfd4017e58faaf70411555e7f508495114e90b ] Most fbdev drivers have issues with the fb_info lifetime, because call to framebuffer_release() from their driver's .remove callback, rather than doing from fbops.fb_destroy callback. Doing that will destroy the fb_info too early, while references to it may still exist, leading to a use-after-free error. To prevent this, check the fb_info reference counter when attempting to kfree the data structure in framebuffer_release(). That will leak it but at least will prevent the mentioned error. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann(a)suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220505220413.365977-1-javie… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/video/fbdev/core/fbsysfs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c index 65dae05fff8e..ce699396d6ba 100644 --- a/drivers/video/fbdev/core/fbsysfs.c +++ b/drivers/video/fbdev/core/fbsysfs.c @@ -80,6 +80,10 @@ void framebuffer_release(struct fb_info *info) { if (!info) return; + + if (WARN_ON(refcount_read(&info->count))) + return; + kfree(info->apertures); kfree(info); } -- 2.35.1

1 0

[PATCH AUTOSEL 5.15 06/17] Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"
by Sasha Levin 18 May '22

18 May '22

From: Javier Martinez Canillas <javierm(a)redhat.com> [ Upstream commit 135332f34ba2662bc1e32b5c612e06a8cc41a053 ] This reverts commit aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a. That commit attempted to fix a NULL pointer dereference, caused by the struct fb_info associated with a framebuffer device to not longer be valid when the file descriptor was closed. The issue was exposed by commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal"), which added a new path that goes through the struct device removal instead of directly unregistering the fb. Most fbdev drivers have issues with the fb_info lifetime, because call to framebuffer_release() from their driver's .remove callback, rather than doing from fbops.fb_destroy callback. This meant that due to this switch, the fb_info was now destroyed too early, while references still existed, while before it was simply leaked. The patch we're reverting here reinstated that leak, hence "fixed" the regression. But the proper solution is to fix the drivers to not release the fb_info too soon. Suggested-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220504115917.758787-1-javie… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/video/fbdev/core/fbmem.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 8e38a7a5cf2f..0371ad233fdf 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1436,10 +1436,7 @@ fb_release(struct inode *inode, struct file *file) __acquires(&info->lock) __releases(&info->lock) { - struct fb_info * const info = file_fb_info(file); - - if (!info) - return -ENODEV; + struct fb_info * const info = file->private_data; lock_fb_info(info); if (info->fbops->fb_release) -- 2.35.1

1 0

[PATCH AUTOSEL 5.17 08/23] fbdev: Prevent possible use-after-free in fb_release()
by Sasha Levin 18 May '22

18 May '22

From: Daniel Vetter <daniel.vetter(a)ffwll.ch> [ Upstream commit 89bfd4017e58faaf70411555e7f508495114e90b ] Most fbdev drivers have issues with the fb_info lifetime, because call to framebuffer_release() from their driver's .remove callback, rather than doing from fbops.fb_destroy callback. Doing that will destroy the fb_info too early, while references to it may still exist, leading to a use-after-free error. To prevent this, check the fb_info reference counter when attempting to kfree the data structure in framebuffer_release(). That will leak it but at least will prevent the mentioned error. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann(a)suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220505220413.365977-1-javie… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/video/fbdev/core/fbsysfs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c index 26892940c213..82e31a2d845e 100644 --- a/drivers/video/fbdev/core/fbsysfs.c +++ b/drivers/video/fbdev/core/fbsysfs.c @@ -80,6 +80,10 @@ void framebuffer_release(struct fb_info *info) { if (!info) return; + + if (WARN_ON(refcount_read(&info->count))) + return; + kfree(info->apertures); kfree(info); } -- 2.35.1

1 0

[PATCH AUTOSEL 5.17 07/23] Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"
by Sasha Levin 18 May '22

18 May '22

From: Javier Martinez Canillas <javierm(a)redhat.com> [ Upstream commit 135332f34ba2662bc1e32b5c612e06a8cc41a053 ] This reverts commit aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a. That commit attempted to fix a NULL pointer dereference, caused by the struct fb_info associated with a framebuffer device to not longer be valid when the file descriptor was closed. The issue was exposed by commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal"), which added a new path that goes through the struct device removal instead of directly unregistering the fb. Most fbdev drivers have issues with the fb_info lifetime, because call to framebuffer_release() from their driver's .remove callback, rather than doing from fbops.fb_destroy callback. This meant that due to this switch, the fb_info was now destroyed too early, while references still existed, while before it was simply leaked. The patch we're reverting here reinstated that leak, hence "fixed" the regression. But the proper solution is to fix the drivers to not release the fb_info too soon. Suggested-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220504115917.758787-1-javie… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/video/fbdev/core/fbmem.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index 10a9369c9dea..00f0f282e7a1 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -1438,10 +1438,7 @@ fb_release(struct inode *inode, struct file *file) __acquires(&info->lock) __releases(&info->lock) { - struct fb_info * const info = file_fb_info(file); - - if (!info) - return -ENODEV; + struct fb_info * const info = file->private_data; lock_fb_info(info); if (info->fbops->fb_release) -- 2.35.1

1 0

← Newer
1
...
36
37
38
39
40
41
42
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2022