kernel/linux.git/drivers/video/fbdev/matrox, branch v5.15.209

fbdev: matroxfb: Mark variable with __maybe_unused to avoid W=1 build break

2026-06-01T15:35:30+00:00

[ Upstream commit caf6144053b4e1c815aa56afb54745a176f999df ] Clang is not happy about set but unused variable: drivers/video/fbdev/matrox/g450_pll.c:412:18: error: variable 'mnp' set but not used 412 | unsigned int mnp; | ^ 1 error generated. Since the commit 7b987887f97b ("video: fbdev: matroxfb: remove dead code and set but not used variable") the 'mnp' became unused, but eliminating that code might have side-effects. The question here is what should we do with 'mnp'? The easiest way out is just mark it with __maybe_unused which will shut the compiler up and won't change any possible IO flow. So does this change. A dive into the history of the driver: The problem was revealed when the #if 0 guarded code along with unused pixel_vco variable was removed. That code was introduced in the original commit 213d22146d1f ("[PATCH] (1/3) matroxfb for 2.5.3"). And then guarded in the commit 705e41f82988 ("matroxfb DVI updates: Handle DVI output on G450/G550. Powerdown unused portions of G450/G550 DAC. Split G450/G550 DAC from older DAC1064 handling. Modify PLL setting when both CRTCs use same pixel clocks."). NOTE: The two commits mentioned above pre-date Git era and available in history.git repository for archaeological purposes. Even without that guard the modern compilers may see that the pixel_vco wasn't ever used and seems a leftover after some debug or review made 25 years ago. The g450_mnp2vco() doesn't have any IO and as Jason said doesn't seem to have any side effects either than some unneeded CPU processing during runtime. I agree that's unlikely that timeout (or heating up the CPU) has any effect on the HW (GPU/display) functionality. Fixes: 7b987887f97b ("video: fbdev: matroxfb: remove dead code and set but not used variable") Signed-off-by: Andy Shevchenko Reviewed-by: Jason Yan Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

fbdev: matroxfb: G200eW: Increase max memory from 1 MB to 16 MB

2023-01-12T10:59:17+00:00

commit f685dd7a8025f2554f73748cfdb8143a21fb92c7 upstream. Commit 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to the same as vbG200 to avoid black screen") accidently decreases the maximum memory size for the Matrox G200eW (102b:0532) from 8 MB to 1 MB by missing one zero. This caused the driver initialization to fail with the messages below, as the minimum required VRAM size is 2 MB: [ 9.436420] matroxfb: Matrox MGA-G200eW (PCI) detected [ 9.444502] matroxfb: cannot determine memory size [ 9.449316] matroxfb: probe of 0000:0a:03.0 failed with error -1 So, add the missing 0 to make it the intended 16 MB. Successfully tested on the Dell PowerEdge R910/0KYD3D, BIOS 2.10.0 08/29/2013, that the warning is gone. While at it, add a leading 0 to the maxdisplayable entry, so it’s aligned properly. The value could probably also be increased from 8 MB to 16 MB, as the G200 uses the same values, but I have not checked any datasheet. Note, matroxfb is obsolete and superseded by the maintained DRM driver mga200, which is used by default on most systems where both drivers are available. Therefore, on most systems it was only a cosmetic issue. Fixes: 62d89a7d49af ("video: fbdev: matroxfb: set maxvram of vbG200eW to the same as vbG200 to avoid black screen") Link: https://lore.kernel.org/linux-fbdev/972999d3-b75d-5680-fcef-6e6905c52ac5@suse.de/T/#mb6953a9995ebd18acc8552f99d6db39787aec775 Cc: it+linux-fbdev@molgen.mpg.de Cc: Z. Liu Cc: Rich Felker Cc: stable@vger.kernel.org Signed-off-by: Paul Menzel Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman

video: fbdev: matroxfb: set maxvram of vbG200eW to the same as vbG200 to avoid black screen

2022-04-08T12:23:14+00:00

[ Upstream commit 62d89a7d49afe46e6b9bbe9e23b004ad848dbde4 ] Start from commit 11be60bd66d54 "matroxfb: add Matrox MGA-G200eW board support", when maxvram is 0x800000, monitor become black w/ error message said: "The current input timing is not supported by the monitor display. Please change your input timing to 1920x1080@60Hz ...". Fixes: 11be60bd66d5 ("matroxfb: add Matrox MGA-G200eW board support") Signed-off-by: Z. Liu Signed-off-by: Helge Deller Signed-off-by: Sasha Levin

fbdev: matrox: use modern module_init()

2021-05-26T19:31:19+00:00

This is one of the last drivers with a global init_module() function instead of the modern module_init() annotation. Convert it over. Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20210514213316.635070-1-arnd@kernel.org

treewide: remove editor modelines and cruft

2021-05-07T07:26:34+00:00

The section "19) Editor modelines and other cruft" in Documentation/process/coding-style.rst clearly says, "Do not include any of these in source files." I recently receive a patch to explicitly add a new one. Let's do treewide cleanups, otherwise some people follow the existing code and attempt to upstream their favoriate editor setups. It is even nicer if scripts/checkpatch.pl can check it. If we like to impose coding style in an editor-independent manner, I think editorconfig (patch [1]) is a saner solution. [1] https://lore.kernel.org/lkml/20200703073143.423557-1-danny@kdrag0n.dev/ Link: https://lkml.kernel.org/r/20210324054457.1477489-1-masahiroy@kernel.org Signed-off-by: Masahiro Yamada Acked-by: Geert Uytterhoeven Reviewed-by: Miguel Ojeda [auxdisplay] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

matroxfb: avoid -Warray-bounds warning

2020-10-27T06:56:19+00:00

The open-coded list_for_each_entry() causes a harmless warning: drivers/video/fbdev/matrox/matroxfb_base.c: In function 'matroxfb_register_driver': include/linux/kernel.h:856:3: warning: array subscript -98 is outside array bounds of 'struct list_head[1]' [-Warray-bounds] Use the normal list_for_each_entry instead. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20201026194010.3817166-1-arnd@kernel.org

treewide: Remove uninitialized_var() usage

2020-07-16T19:35:15+00:00

Using uninitialized_var() is dangerous as it papers over real bugs[1] (or can in the future), and suppresses unrelated compiler warnings (e.g. "unused variable"). If the compiler thinks it is uninitialized, either simply initialize the variable or make compiler changes. In preparation for removing[2] the[3] macro[4], remove all remaining needless uses with the following script: git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \ xargs perl -pi -e \ 's/\buninitialized_var$([^$]+)\)/\1/g; s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;' drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid pathological white-space. No outstanding warnings were found building allmodconfig with GCC 9.3.0 for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64, alpha, and m68k. [1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/ [2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/ [3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/ [4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/ Reviewed-by: Leon Romanovsky # drivers/infiniband and mlx4/mlx5 Acked-by: Jason Gunthorpe # IB Acked-by: Kalle Valo # wireless drivers Reviewed-by: Chao Yu # erofs Signed-off-by: Kees Cook

video: fbdev: matroxfb: remove dead code and set but not used variable

2020-04-08T10:09:10+00:00

Fix the following gcc warning: drivers/video/fbdev/matrox/g450_pll.c:336:15: warning: variable ‘pixel_vco’ set but not used [-Wunused-but-set-variable] unsigned int pixel_vco; ^~~~~~~~~ Reported-by: Hulk Robot Signed-off-by: Jason Yan Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200403021609.20968-1-yanaijie@huawei.com

fbdev: matrox: fix -Wextra build warnings

2020-03-20T13:29:09+00:00

When 'DEBUG' is not defined, modify the dprintk() macro to use the no_printk() macro instead of using . This fixes build warnings when -Wextra is used and provides printk format checking: ../drivers/video/fbdev/matrox/matroxfb_base.c:635:77: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] ../drivers/video/fbdev/matrox/matroxfb_Ti3026.c:632:54: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body] ../drivers/video/fbdev/matrox/matroxfb_Ti3026.c:654:53: warning: suggest braces around empty body in an ‘else’ statement [-Wempty-body] Signed-off-by: Randy Dunlap Cc: Antonino Daplas Cc: Florian Tobias Schandinat Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20200315041002.24473-4-rdunlap@infradead.org

matroxfb: add Matrox MGA-G200eW board support

2020-03-02T15:32:13+00:00

It's needed to support the onboard video on my Spectre-free Atom S1260 server board. Signed-off-by: Rich Felker Cc: Greg Kroah-Hartman Cc: Thomas Gleixner [b.zolnierkie: patch description fixup] Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20200125195506.GA16638@brightrain.aerifal.cx