linux-stable.git/drivers/video, branch v6.6.53

fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes

2024-08-11T10:47:16+00:00

[ Upstream commit c2bc958b2b03e361f14df99983bc64a39a7323a3 ]

Test the vesa_attributes field in struct screen_info for compatibility
with VGA hardware. Vesafb currently tests bit 1 in screen_info's
capabilities field which indicates a 64-bit lfb address and is
unrelated to VGA compatibility.

Section 4.4 of the Vesa VBE 2.0 specifications defines that bit 5 in
the mode's attributes field signals VGA compatibility. The mode is
compatible with VGA hardware if the bit is clear. In that case, the
driver can access VGA state of the VBE's underlying hardware. The
vesafb driver uses this feature to program the color LUT in palette
modes. Without, colors might be incorrect.

The problem got introduced in commit 89ec4c238e7a ("[PATCH] vesafb: Fix
incorrect logo colors in x86_64"). It incorrectly stores the mode
attributes in the screen_info's capabilities field and updates vesafb
accordingly. Later, commit 5e8ddcbe8692 ("Video mode probing support for
the new x86 setup code") fixed the screen_info, but did not update vesafb.
Color output still tends to work, because bit 1 in capabilities is
usually 0.

Besides fixing the bug in vesafb, this commit introduces a helper that
reads the correct bit from screen_info.

Signed-off-by: Thomas Zimmermann 
Fixes: 5e8ddcbe8692 ("Video mode probing support for the new x86 setup code")
Reviewed-by: Javier Martinez Canillas 
Cc:  # v2.6.23+
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

firmware/sysfb: Update screen_info for relocated EFI framebuffers

2024-08-11T10:47:16+00:00

[ Upstream commit 78aa89d1dfba1e3cf4a2e053afa3b4c4ec622371 ]

On ARM PCI systems, the PCI hierarchy might be reconfigured during
boot and the firmware framebuffer might move as a result of that.
The values in screen_info will then be invalid.

Work around this problem by tracking the framebuffer's initial
location before it get relocated; then fix the screen_info state
between reloaction and creating the firmware framebuffer's device.

This functionality has been lifted from efifb. See the commit message
of commit 55d728a40d36 ("efi/fb: Avoid reconfiguration of BAR that
covers the framebuffer") for more information.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-8-tzimmermann@suse.de
Stable-dep-of: c2bc958b2b03 ("fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes")
Signed-off-by: Sasha Levin

video: Provide screen_info_get_pci_dev() to find screen_info's PCI device

2024-08-11T10:47:15+00:00

[ Upstream commit 036105e3a776b6fc2fe0d262896a23ff2cc2e6b1 ]

Add screen_info_get_pci_dev() to find the PCI device of an instance
of screen_info. Does nothing on systems without PCI bus.

v3:
	* search PCI device with pci_get_base_class() (Sui)
v2:
	* remove ret from screen_info_pci_dev() (Javier)

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-3-tzimmermann@suse.de
Stable-dep-of: c2bc958b2b03 ("fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes")
Signed-off-by: Sasha Levin

video: Add helpers for decoding screen_info

2024-08-11T10:47:15+00:00

[ Upstream commit 75fa9b7e375e35739663cde0252d31e586c6314a ]

The plain values as stored in struct screen_info need to be decoded
before being used. Add helpers that decode the type of video output
and the framebuffer I/O aperture.

Old or non-x86 systems may not set the type of video directly, but
only indicate the presence by storing 0x01 in orig_video_isVGA. The
decoding logic in screen_info_video_type() takes this into account.
It then follows similar code in vgacon's vgacon_startup() to detect
the video type from the given values.

A call to screen_info_resources() returns all known resources of the
given screen_info. The resources' values have been taken from existing
code in vgacon and vga16fb. These drivers can later be converted to
use the new interfaces.

v2:
	* return ssize_t from screen_info_resources()
	* don't call __screen_info_has_lfb() unnecessarily

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20240212090736.11464-2-tzimmermann@suse.de
Stable-dep-of: c2bc958b2b03 ("fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes")
Signed-off-by: Sasha Levin

fbdev/vesafb: Replace references to global screen_info by local pointer

2024-08-11T10:47:15+00:00

[ Upstream commit 3218286bbb78cac3dde713514529e0480d678173 ]

Get the global screen_info's address once and access the data via
this pointer. Limits the use of global state.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Javier Martinez Canillas 
Link: https://patchwork.freedesktop.org/patch/msgid/20231206135153.2599-4-tzimmermann@suse.de
Stable-dep-of: c2bc958b2b03 ("fbdev: vesafb: Detect VGA compatibility from screen info's VESA attributes")
Signed-off-by: Sasha Levin

video: logo: Drop full path of the input filename in generated file

2024-08-03T06:54:32+00:00

commit fb3b9c2d217f1f51fffe19fc0f4eaf55e2d4ea4f upstream.

Avoid this Yocto build warning to make build reproducible:

    WARNING: linux-foo-6.8-r0 do_package_qa: QA Issue:
    File /usr/src/debug/linux-foo/6.8-r0/drivers/video/logo/logo_linux_clut224.c
    in package linux-foo-src contains reference to TMPDIR

Helge modified the patch to drop the whole line.

Signed-off-by: Lucas Stach 
Signed-off-by: Helge Deller 
Cc: Fabio Estevam 
Signed-off-by: Greg Kroah-Hartman

fbdev: savage: Handle err return when savagefb_check_var failed

2024-06-16T11:47:37+00:00

commit 6ad959b6703e2c4c5d7af03b4cfd5ff608036339 upstream.

The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")
checks the value of pixclock to avoid divide-by-zero error. However
the function savagefb_probe doesn't handle the error return of
savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.

Fixes: 04e5eac8f3ab ("fbdev: savage: Error out if pixclock equals zero")
Signed-off-by: Cai Xinchen 
Cc: stable@vger.kernel.org
Signed-off-by: Helge Deller 
Signed-off-by: Greg Kroah-Hartman

pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()

2024-06-12T09:12:24+00:00

[ Upstream commit c748a6d77c06a78651030e17da6beb278a1c9470 ]

In order to introduce a pwm api which can be used from atomic context,
we will need two functions for applying pwm changes:

	int pwm_apply_might_sleep(struct pwm *, struct pwm_state *);
	int pwm_apply_atomic(struct pwm *, struct pwm_state *);

This commit just deals with renaming pwm_apply_state(), a following
commit will introduce the pwm_apply_atomic() function.

Acked-by: Uwe Kleine-König 
Acked-by: Guenter Roeck 
Acked-by: Mark Brown 
Acked-by: Dmitry Torokhov  # for input
Acked-by: Hans de Goede 
Acked-by: Jani Nikula 
Acked-by: Lee Jones 
Signed-off-by: Sean Young 
Signed-off-by: Thierry Reding 
Stable-dep-of: 974afccd3794 ("leds: pwm: Disable PWM when going to suspend")
Signed-off-by: Sasha Levin

fbdev: sh7760fb: allow modular build

2024-06-12T09:12:02+00:00

[ Upstream commit 51084f89d687e14d96278241e5200cde4b0985c7 ]

There is no reason to prohibit sh7760fb from being built as a
loadable module as suggested by Geert, so change the config symbol
from bool to tristate to allow that and change the FB dependency as
needed.

Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
Suggested-by: Geert Uytterhoeven 
Signed-off-by: Randy Dunlap 
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: John Paul Adrian Glaubitz 
Cc: Sam Ravnborg 
Cc: Helge Deller 
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Acked-by: John Paul Adrian Glaubitz 
Acked-by: Javier Martinez Canillas 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin

fbdev: sisfb: hide unused variables

2024-06-12T09:12:00+00:00

[ Upstream commit 688cf598665851b9e8cb5083ff1d208ce43d10ff ]

Building with W=1 shows that a couple of variables in this driver are only
used in certain configurations:

drivers/video/fbdev/sis/init301.c:239:28: error: 'SiS_Part2CLVX_6' defined but not used [-Werror=unused-const-variable=]
  239 | static const unsigned char SiS_Part2CLVX_6[] = {   /* 1080i */
      |                            ^~~~~~~~~~~~~~~
drivers/video/fbdev/sis/init301.c:230:28: error: 'SiS_Part2CLVX_5' defined but not used [-Werror=unused-const-variable=]
  230 | static const unsigned char SiS_Part2CLVX_5[] = {   /* 750p */
      |                            ^~~~~~~~~~~~~~~
drivers/video/fbdev/sis/init301.c:211:28: error: 'SiS_Part2CLVX_4' defined but not used [-Werror=unused-const-variable=]
  211 | static const unsigned char SiS_Part2CLVX_4[] = {   /* PAL */
      |                            ^~~~~~~~~~~~~~~
drivers/video/fbdev/sis/init301.c:192:28: error: 'SiS_Part2CLVX_3' defined but not used [-Werror=unused-const-variable=]
  192 | static const unsigned char SiS_Part2CLVX_3[] = {  /* NTSC, 525i, 525p */
      |                            ^~~~~~~~~~~~~~~
drivers/video/fbdev/sis/init301.c:184:28: error: 'SiS_Part2CLVX_2' defined but not used [-Werror=unused-const-variable=]
  184 | static const unsigned char SiS_Part2CLVX_2[] = {
      |                            ^~~~~~~~~~~~~~~
drivers/video/fbdev/sis/init301.c:176:28: error: 'SiS_Part2CLVX_1' defined but not used [-Werror=unused-const-variable=]
  176 | static const unsigned char SiS_Part2CLVX_1[] = {
      |                            ^~~~~~~~~~~~~~~

This started showing up after the definitions were moved into the
source file from the header, which was not flagged by the compiler.
Move the definition into the appropriate #ifdef block that already
exists next to them.

Fixes: 5908986ef348 ("video: fbdev: sis: avoid mismatched prototypes")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin