Changes in Makefile

27ad64ea - fbdev: Rename FB_SYS_FOPS token to FB_SYSMEM_FOPS

Mon, 27 Nov 2023 13:15:56 +0000

fbdev: Rename FB_SYS_FOPS token to FB_SYSMEM_FOPSRename the token to harmonize naming among various helpers. Forexample, I/O-memory helpers use FB_IOMEM_FOPS.Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20231127131655.4020-28-tzimmermann@suse.de List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

6b180f66 - fbdev: Provide I/O-memory helpers as module

Wed, 27 Sep 2023 07:26:34 +0000

fbdev: Provide I/O-memory helpers as moduleProvide helpers for accessing I/O memory in a helper module. The fbdevcore uses these helpers, so select the module unconditionally for fbdev.Drivers will later be able to select the module individually and thehelpers will become optional.Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230927074722.6197-2-tzimmermann@suse.de List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

8887086e - fbdev/core: Move logo functions into separate source file

Thu, 07 Sep 2023 08:52:04 +0000

fbdev/core: Move logo functions into separate source fileMove the fbdev function for displaying boot-up logos into theirown file fb_logo.c. Only build fb_logo.c if CONFIG_LOGO has beenselected. No functional changes.v2: * include fb_internal.h (kernel test robot) * simplify option-parsing ifdefs * build fb_logo.o iff CONFIG_LOGO has been setSigned-off-by: Thomas Zimmermann Acked-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230907085408.9354-6-tzimmermann@suse.de List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

55bffc81 - fbdev: Split frame buffer support in FB and FB_CORE symbols

Wed, 19 Jul 2023 08:15:37 +0000

fbdev: Split frame buffer support in FB and FB_CORE symbolsCurrently the CONFIG_FB option has to be enabled even if no legacy fbdevdrivers are needed (e.g: only to have support for framebuffer consoles).The DRM subsystem has a fbdev emulation layer, but depends on CONFIG_FBand so it can only be enabled if that dependency is enabled as well.That means fbdev drivers have to be explicitly disabled if users want toenable CONFIG_FB, only to use fbcon and/or the DRM fbdev emulation layer.This patch introduces a non-visible CONFIG_FB_CORE symbol that could beenabled just to have core support needed for CONFIG_DRM_FBDEV_EMULATION,allowing CONFIG_FB to be disabled (and automatically disabling all thefbdev drivers).Nothing from fb_backlight.o and fbmon.o is used by the DRM fbdev emulationlayer so these two objects can be compiled out when CONFIG_FB is disabled.Signed-off-by: Javier Martinez Canillas Reviewed-by: Arnd Bergmann Tested-by: Arnd Bergmann Acked-by: Helge Deller Link: https://patchwork.freedesktop.org/patch/msgid/20230719081544.741051-4-javierm@redhat.com List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

701d2054 - fbdev: Make support for userspace interfaces configurable

Tue, 13 Jun 2023 11:07:13 +0000

fbdev: Make support for userspace interfaces configurableAdd Kconfig option CONFIG_FB_DEVICE and make the virtual fbdevdevice optional. If the new option has not been selected, fbdevdoes not create files in devfs, sysfs or procfs.Most modern Linux systems run a DRM-based graphics stack that usesthe kernel's framebuffer console, but has otherwise deprecated fbdevsupport. Yet fbdev userspace interfaces are still present.The option makes it possible to use the fbdev subsystem as consoleimplementation without support for userspace. This closes potentialentry points to manipulate kernel or I/O memory via framebuffers. Italso prevents the execution of driver code via ioctl or sysfs, bothof which might allow malicious software to exploit bugs in the fbdevcode.A small number of fbdev drivers require struct fbinfo.dev to beinitialized, usually for the support of sysfs interface. Make thesedrivers depend on FB_DEVICE. They can later be fixed if necessary.v3: * effect -> affect in Kconfig help (Daniel)v2: * set FB_DEVICE default to y (Geert) * comment on {get,put}_device() (Sam) * Kconfig fixes (Sam) * add TODO item about FB_DEVICE dependencies (Sam)Signed-off-by: Thomas Zimmermann Acked-by: Greg Kroah-Hartman Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-39-tzimmermann@suse.de List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

588b3563 - fbdev/core: Move file-I/O code into separate file

Tue, 13 Jun 2023 11:07:11 +0000

fbdev/core: Move file-I/O code into separate fileMove fbdev's file-I/O code into a separate file and contain it ininit and cleanup helpers. No functional changes.v3: * add missing file fb_chrdev.cv2: * rename source file (Sam) * include (Javier, kernel test robot)Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-37-tzimmermann@suse.de List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

abcc2f3c - fbdev/core: Move procfs code to separate file

Tue, 13 Jun 2023 11:07:10 +0000

fbdev/core: Move procfs code to separate fileMove fbdev's procfs code into a separate file and contain it ininit and cleanup helpers. For the cleanup, replace remove_proc_entry()with proc_remove(). It is equivalent in functionality, but looksmore like an inverse of proc_create_seq().v2: * document proc_remove() usage (Sam) * revert unrelated removal of for_each_registered_fb()Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-36-tzimmermann@suse.de List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

f0f6839b - fbdev/core: Move framebuffer and backlight helpers into separate files

Tue, 13 Jun 2023 11:07:08 +0000

fbdev/core: Move framebuffer and backlight helpers into separate filesMove framebuffer and backlight helpers into separate files. Leavefbsysfs.c to sysfs-related code. No functional changes.The framebuffer helpers are not in fbmem.c because they are underGPL-2.0-or-later copyright, while fbmem.c is GPL-2.0.v2: * include (Sam)Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20230613110953.24176-34-tzimmermann@suse.de List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

6121cd9e - fbdev: Move I/O read and write code into helper functions

Fri, 28 Apr 2023 12:24:51 +0000

fbdev: Move I/O read and write code into helper functionsMove the existing I/O read and write code for I/O memory intothe new helpers fb_cfb_read() and fb_cfb_write(). Make them thedefault fp_ops. No functional changes.In the near term, the new functions will be useful to the DRMsubsystem, which currently provides it's own implementation. Itcan then use the shared code. In the longer term, it might makesense to revise the I/O helper's default status and make themopt-in by the driver. Systems that don't use them would notcontain the code any longer.v2: * add detailed commit message (Javier) * rename fb_cfb_() to fb_io_() (Geert) * add fixes that got lost while moving the code (Geert)Signed-off-by: Thomas Zimmermann Tested-by: Sui Jingfeng Reviewed-by: Javier Martinez Canillas Acked-by: Helge Deller Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20230428122452.4856-19-tzimmermann@suse.de List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

93604a5a - fbdev: Handle video= parameter in video/cmdline.c

Thu, 09 Feb 2023 13:55:06 +0000

fbdev: Handle video= parameter in video/cmdline.cHandle the command-line parameter video= in video/cmdline.c. Implementthe fbdev helper fb_get_options() on top. Will allows to handle thekernel parameter in DRM without fbdev dependencies.Note that __video_get_options() has the meaning of its return valueinverted compared to fb_get_options(). The new helper returns true ifthe adapter has been enabled, and false otherwise.There is the ofonly parameter, which disables output for non-OF-basedframebuffers. It is only for offb and looks like a workaround. The actualpurpose it not clear to me. Use 'video=off' or 'nomodeset' instead.Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Link: https://patchwork.freedesktop.org/patch/msgid/20230209135509.7786-9-tzimmermann@suse.de List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

31a2a329 - fbdev: remove object duplication in Makefile

Mon, 06 Jan 2020 08:13:52 +0000

fbdev: remove object duplication in MakefileThe objects in $(fb-objs) $(fb-y) $(fb-m) are linked to fb.ko .This line adds $(fb-y) to fb-objs, so the objects from $(fb-y) arelisted twice as the dependency of the module.It works because Kbuild trims the duplicated objects from linking,but there is no good reason to have this line.Signed-off-by: Masahiro Yamada Signed-off-by: Bartlomiej Zolnierkiewicz Link: https://patchwork.freedesktop.org/patch/msgid/20200106081352.27730-1-masahiroy@kernel.org List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

f2f4946b - fbcon: Remove dmi quirk table

Sat, 25 Nov 2017 19:35:53 +0000

fbcon: Remove dmi quirk tableThis is now all handled in the drivers and communicated throughfb_info.fbcon_rotate_hint.Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-8-hdegoede@redhat.com List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

b0d8e409 - video/console: Add dmi quirk table for x86 systems which need fbcon rotation

Fri, 18 Aug 2017 17:56:39 +0000

video/console: Add dmi quirk table for x86 systems which need fbcon rotationSome x86 clamshell design devices use portrait tablet screens and adisplay engine which cannot rotate in hardware, so we need to rotatethe fbcon to compensate.This commit adds a DMI based quirk table which is initially populated with4 such devices: The Asus T100HA, GPD Pocket, the GPD win and the I.T.WorksTW891, so that the console comes up in the right orientation on thesedevices OOTB.Unfortunately these (cheap) devices also typically have quite generic DMIdata, so we match on a combination of DMI data, screen resolution and alist of known BIOS dates to avoid false positives.Suggested-by: Jean Delvare Signed-off-by: Hans de Goede Reviewed-by: Jean Delvare [b.zolnierkie: ported over fbcon changes]Signed-off-by: Bartlomiej Zolnierkiewicz List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

6104c370 - fbcon: Make fbcon a built-time depency for fbdev

Tue, 01 Aug 2017 15:32:07 +0000

fbcon: Make fbcon a built-time depency for fbdevThere's a bunch of folks who're trying to make printk lesscontended and faster, but there's a problem: printk uses theconsole_lock, and the console lock has become the BKL for all thingsfbdev/fbcon, which in turn pulled in half the drm subsystem under thatlock. That's awkward.There reasons for that is probably just a historical accident:- fbcon is a runtime option of fbdev, i.e. at runtime you can pick whether your fbdev driver instances are used as kernel consoles. Unfortunately this wasn't implemented with some module option, but through some module loading magic: As long as you don't load fbcon.ko, there's no fbdev console support, but loading it (in any order wrt fbdev drivers) will create console instances for all fbdev drivers.- This was implemented through a notifier chain. fbcon.ko enumerates all fbdev instances at load time and also registers itself as listener in the fbdev notifier. The fbdev core tries to register new fbdev instances with fbcon using the notifier.- On top of that the modifier chain is also used at runtime by the fbdev subsystem to e.g. control backlights for panels.- The problem is that the notifier puts a mutex locking context between fbdev and fbcon, which mixes up the locking contexts for both the runtime usage and the register time usage to notify fbcon. And at runtime fbcon (through the fbdev core) might call into the notifier from a printk critical section while console_lock is held.- This means console_lock must be an outer lock for the entire fbdev subsystem, which also means it must be acquired when registering a new framebuffer driver as the outermost lock since we might call into fbcon (through the notifier) which would result in a locking inversion if fbcon would acquire the console_lock from its notifier callback (which it needs to register the console).- console_lock can be held anywhere, since printk can be called anywhere, and through the above story, plus drm/kms being an fbdev driver, we pull in a shocking amount of locking hiercharchy underneath the console_lock. Which makes cleaning up printk really hard (not even splitting console_lock into an rwsem is all that useful due to this).There's various ways to address this, but the cleanest would be tomake fbcon a compile-time option, where fbdev directly calls the fbconregister functions from register_framebuffer, or dummy static inlineversions if fbcon is disabled. Maybe augmented with a runtime knob todisable fbcon, if that's needed (for debugging perhaps).But this could break some users who rely on the magic "loadingfbcon.ko enables/disables fbdev framebuffers at runtime" thing, evenif that's unlikely. Hence we must be careful:1. Create a compile-time dependency between fbcon and fbdev in theleast minimal way. This is what this patch does.2. Wait at least 1 year to give possible users time to scream abouthow we broke their setup. Unlikely, since all distros make fbconcompile-in, and embedded platforms only compile stuff they know theyneed anyway. But still.3. Convert the notifier to direct functions calls, with dummy staticinlines if fbcon is disabled. We'll still need the fb notifier for theother uses (like backlights), but we can probably move it into the fbcore (atm it must be built-into vmlinux).4. Push console_lock down the call-chain, until it is down inconsole_register again.5. Finally start to clean up and rework the printk/console locking.For context of this saga seecommit 50e244cc793d511b86adea24972f3a7264cae114Author: Alan Cox Date: Fri Jan 25 10:28:15 2013 +1000 fb: rework locking to fix lock ordering on takeoverplus the pile of commits on top that tried to make this all workwithout terminally upsetting lockdep. We've uncovered all this whenconsole_lock lockdep annotations where added incommit daee779718a319ff9f83e1ba3339334ac650bb22Author: Daniel Vetter Date: Sat Sep 22 19:52:11 2012 +0200 console: implement lockdep support for console_lockOn the patch itself:- Switch CONFIG_FRAMEBUFFER_CONSOLE to be a boolean, using the overall CONFIG_FB tristate to decided whether it should be a module or built-in.- At first I thought I could force the build depency with just a dummy symbol that fbcon.ko exports and fb.ko uses. But that leads to a module depency cycle (it works fine when built-in). Since this tight binding is the entire goal the simplest solution is to move all the fbcon modules (and there's a bunch of optinal source-files which are each modules of their own, for no good reason) into the overall fb.ko core module. That's a bit more than what I would have liked to do in this patch, but oh well.Signed-off-by: Daniel Vetter Cc: Alan Cox Cc: Sergey Senozhatsky Cc: Steven Rostedt Reviewed-by: Sean Paul Signed-off-by: Bartlomiej Zolnierkiewicz List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

5ec96538 - fbdev: Make fb-notify a no-op if CONFIG_FB=n

Wed, 25 Nov 2015 03:11:48 +0000

fbdev: Make fb-notify a no-op if CONFIG_FB=nThere's no point in having support for framebuffer notificationsis CONFIG_FB is disabled. This commit adds the necessary stubsfor code to link properly when CONFIG_FB=n and moves fb-notify.oto be built only when CONFIG_FB=y.Signed-off-by: Ezequiel Garcia Signed-off-by: Tomi Valkeinen List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

a7c42990 - framebuffer: don't link fb_devio into kernel image unconditionally

Tue, 28 Apr 2015 11:17:49 +0000

framebuffer: don't link fb_devio into kernel image unconditionallyCONFIG_FB_DEFERRED_IO is defined as bool while CONFIG_FB is defined astristate. Currently fb_defio.o is linked into the kernel image even ifCONFIG_FB=m.I fix this by updating the Makefile to link fb_defio.o into fb.o and thusgo into one place with the other core framebuffer code.Signed-off-by: Harald Geyer Signed-off-by: Tomi Valkeinen List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

ea6763c1 - video/fbdev: Always built-in video= cmdline parsing

Wed, 06 Aug 2014 09:36:38 +0000

video/fbdev: Always built-in video= cmdline parsingIn drm/i915 we want to get at the video= cmdline modes even when wedon't have fbdev support enabled, so that users can always overridethe kernel's initial mode selection.But that gives us a direct depency upon the parsing code in the fbdevsubsystem. Since it's so little code just extract these 2 functionsand always build them in.Whiel at it fix the checkpatch fail in this code.v2: Also move fb_mode_option. Spotted by the kbuild.v3: Review from Geert:- Keep the old copyright notice from fb_mem.c, although I have noidea what exactly applies.- Only compile this when needed.Cc: Geert Uytterhoeven Cc: Plagniol-Villard Cc: Tomi Valkeinen Cc: linux-fbdev@vger.kernel.orgSigned-off-by: Daniel Vetter --I prefer if we can merge this through drm-next since we'll use itthere in follow-up patches.-Daniel List of files: /linux-6.15/drivers/video/fbdev/core/Makefile

19757fc8 - fbdev: move fbdev core files to separate directory

Thu, 13 Feb 2014 14:24:55 +0000

fbdev: move fbdev core files to separate directoryInstead of having fbdev framework core files at the root fbdevdirectory, mixed with random fbdev device drivers, move the fbdev corefiles to a separate core directory. This makes it much clearer which ofthe files are actually part of the fbdev framework, and which are partof device drivers.Signed-off-by: Tomi Valkeinen Acked-by: Laurent Pinchart Acked-by: Geert Uytterhoeven Acked-by: Rob Clark Acked-by: Jingoo Han Acked-by: Daniel Vetter List of files: /linux-6.15/drivers/video/fbdev/core/Makefile