Changes in Kconfig

a6021aa2 - ACPI: EC: make EC support compile-time conditional

Fri, 11 Oct 2024 06:18:17 +0000

ACPI: EC: make EC support compile-time conditionalThe embedded controller code is mainly used on x86 laptops and cannotwork without PC style I/O port access.Make this a user-visible configuration option that is default enabledon x86 but otherwise disabled, and that can never be enabled unlessCONFIG_HAS_IOPORT is also available.The empty stubs in internal.h help ignore the EC code in configurationsthat don't support it. In order to see those stubs, the sbshc code alsohas to include this header and drop duplicate declarations.All the direct callers of ec_read/ec_write already had an x86dependency and now also need to depend on APCI_EC.Signed-off-by: Arnd Bergmann Acked-by: Guenter Roeck Acked-by: Hans de Goede Link: https://patch.msgid.link/20241011061948.3211423-1-arnd@kernel.org[ rjw: Subject edits ]Signed-off-by: Rafael J. Wysocki List of files: /linux-6.15/drivers/char/Kconfig

cf8e8658 - arch: Remove Itanium (IA-64) architecture

Thu, 20 Oct 2022 13:54:33 +0000

arch: Remove Itanium (IA-64) architectureThe Itanium architecture is obsolete, and an informal survey [0] revealsthat any residual use of Itanium hardware in production is mostly HP-UXor OpenVMS based. The use of Linux on Itanium appears to be limited toenthusiasts that occasionally boot a fresh Linux kernel to see whetherthings are still working as intended, and perhaps to churn out somedistro packages that are rarely used in practice.None of the original companies behind Itanium still produce or supportany hardware or software for the architecture, and it is listed as'Orphaned' in the MAINTAINERS file, as apparently, none of the engineersthat contributed on behalf of those companies (nor anyone else, for thatmatter) have been willing to support or maintain the architectureupstream or even be responsible for applying the odd fix. The Intelfirmware team removed all IA-64 support from the Tianocore/EDK2reference implementation of EFI in 2018. (Itanium is the originalarchitecture for which EFI was developed, and the way Linux supports itdeviates significantly from other architectures.) Some distros, such asDebian and Gentoo, still maintain [unofficial] ia64 ports, but many havedropped support years ago.While the argument is being made [1] that there is a 'for the commongood' angle to being able to build and run existing projects such as theGrid Community Toolkit [2] on Itanium for interoperability testing, thefact remains that none of those projects are known to be deployed onLinux/ia64, and very few people actually have access to such a system inthe first place. Even if there were ways imaginable in which Linux/ia64could be put to good use today, what matters is whether anyone isactually doing that, and this does not appear to be the case.There are no emulators widely available, and so boot testing Itanium isgenerally infeasible for ordinary contributors. GCC still supports IA-64but its compile farm [3] no longer has any IA-64 machines. GLIBC wouldlike to get rid of IA-64 [4] too because it would permit some overduecode cleanups. In summary, the benefits to the ecosystem of having IA-64be part of it are mostly theoretical, whereas the maintenance overheadof keeping it supported is real.So let's rip off the band aid, and remove the IA-64 arch code entirely.This follows the timeline proposed by the Debian/ia64 maintainer [5],which removes support in a controlled manner, leaving IA-64 in a knowngood state in the most recent LTS release. Other projects will followonce the kernel support is removed.[0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/[1] https://lore.kernel.org/all/0075883c-7c51-00f5-2c2d-5119c1820410@web.de/[2] https://gridcf.org/gct-docs/latest/index.html[3] https://cfarm.tetaneutral.net/machines/list/[4] https://lore.kernel.org/all/87bkiilpc4.fsf@mid.deneb.enyo.de/[5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/Acked-by: Tony Luck Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/drivers/char/Kconfig

1fbb0b20 - char: add HAS_IOPORT dependencies

Mon, 22 May 2023 10:50:08 +0000

char: add HAS_IOPORT dependenciesIn a future patch HAS_IOPORT=n will result in inb()/outb() and friendsnot being declared. We thus need to add HAS_IOPORT as dependency forthose drivers using them.Co-developed-by: Arnd Bergmann Signed-off-by: Arnd Bergmann Signed-off-by: Niklas Schnelle Link: https://lore.kernel.org/r/20230522105049.1467313-4-schnelle@linux.ibm.comSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/char/Kconfig

9b12f050 - char: pcmcia: remove all the drivers

Wed, 22 Feb 2023 09:23:02 +0000

char: pcmcia: remove all the driversThese char PCMCIA drivers are buggy[1] and receive only minimal care. Itwas concluded[2], that we should try to remove most pcmcia driverscompletely. Let's start with these char broken one.Note that I also removed a UAPI header: include/uapi/linux/cm4000_cs.h.I found only coccinelle tests mentioning some ioctl constants from thatfile. But they are not actually used. Anyway, should someone complain,we may reintroduce the header (or its parts).[1] https://lore.kernel.org/all/f41c2765-80e0-48bc-b1e4-8cfd3230fd4a@www.fastmail.com/[2] https://lore.kernel.org/all/c5b39544-a4fb-4796-a046-0b9be9853787@app.fastmail.com/Signed-off-by: Jiri Slaby (SUSE) Cc: "Hyunwoo Kim" Cc: Harald Welte Cc: Lubomir Rintel Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Acked-by: Dominik Brodowski Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/20230222092302.6348-2-jirislaby@kernel.orgSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/char/Kconfig

b9b01a56 - random: use random.trust_{bootloader,cpu} command line option only

Tue, 01 Nov 2022 12:03:55 +0000

random: use random.trust_{bootloader,cpu} command line option onlyIt's very unusual to have both a command line option and a compile timeoption, and apparently that's confusing to people. Also, basicallyeverybody enables the compile time option now, which means people whowant to disable this wind up having to use the command line option toensure that anyway. So just reduce the number of moving pieces and nixthe compile time option in favor of the more versatile command lineoption.Signed-off-by: Jason A. Donenfeld List of files: /linux-6.15/drivers/char/Kconfig

1208ec59 - char: remove VR41XX related char driver

Sat, 16 Jul 2022 13:08:01 +0000

char: remove VR41XX related char driverCommit d3164e2f3b0a ("MIPS: Remove VR41xx support") removed supportfor MIPS VR41xx platform, so remove exclusive drivers for thisplatform, too.Signed-off-by: Thomas Bogendoerfer Link: https://lore.kernel.org/r/20220716130802.11660-1-tsbogend@alpha.franken.deSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/char/Kconfig

9592eef7 - random: remove CONFIG_ARCH_RANDOM

Tue, 05 Jul 2022 18:48:41 +0000

random: remove CONFIG_ARCH_RANDOMWhen RDRAND was introduced, there was much discussion on whether itshould be trusted and how the kernel should handle that. Initially, twomechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and"nordrand", a boot-time switch.Later the thinking evolved. With a properly designed RNG, using RDRANDvalues alone won't harm anything, even if the outputs are malicious.Rather, the issue is whether those values are being *trusted* to be goodor not. And so a new set of options were introduced as the realones that people use -- CONFIG_RANDOM_TRUST_CPU and "random.trust_cpu".With these options, RDRAND is used, but it's not always credited. So inthe worst case, it does nothing, and in the best case, maybe it helps.Along the way, CONFIG_ARCH_RANDOM's meaning got sort of pulled into thecenter and became something certain platforms force-select.The old options don't really help with much, and it's a bit odd to havespecial handling for these instructions when the kernel can deal finewith the existence or untrusted existence or broken existence ornon-existence of that CPU capability.Simplify the situation by removing CONFIG_ARCH_RANDOM and using theordinary asm-generic fallback pattern instead, keeping the two optionsthat are actually used. For now it leaves "nordrand" for now, as theremoval of that will take a different route.Acked-by: Michael Ellerman Acked-by: Catalin Marinas Acked-by: Borislav Petkov Acked-by: Heiko Carstens Acked-by: Greg Kroah-Hartman Signed-off-by: Jason A. Donenfeld List of files: /linux-6.15/drivers/char/Kconfig

846bb97e - random: credit cpu and bootloader seeds by default

Sun, 05 Jun 2022 16:30:46 +0000

random: credit cpu and bootloader seeds by defaultThis commit changes the default Kconfig values of RANDOM_TRUST_CPU andRANDOM_TRUST_BOOTLOADER to be Y by default. It does not change anyexisting configs or change any kernel behavior. The reason for this isseveral fold.As background, I recently had an email thread with the kernelmaintainers of Fedora/RHEL, Debian, Ubuntu, Gentoo, Arch, NixOS, Alpine,SUSE, and Void as recipients. I noted that some distros trust RDRAND,some trust EFI, and some trust both, and I asked why or why not. Therewasn't really much of a "debate" but rather an interesting discussion ofwhat the historical reasons have been for this, and it came up that somedistros just missed the introduction of the bootloader Kconfig knob,while another didn't want to enable it until there was a boot timeswitch to turn it off for more concerned users (which has since beenadded). The result of the rather uneventful discussion is that everymajor Linux distro enables these two options by default.While I didn't have really too strong of an opinion going into thisthread -- and I mostly wanted to learn what the distros' thinking wasone way or another -- ultimately I think their choice was a decentenough one for a default option (which can be disabled at boot time).I'll try to summarize the pros and cons:Pros:- The RNG machinery gets initialized super quickly, and there's no messing around with subsequent blocking behavior.- The bootloader mechanism is used by kexec in order for the prior kernel to initialize the RNG of the next kernel, which increases the entropy available to early boot daemons of the next kernel.- Previous objections related to backdoors centered around Dual_EC_DRBG-like kleptographic systems, in which observing some amount of the output stream enables an adversary holding the right key to determine the entire output stream. This used to be a partially justified concern, because RDRAND output was mixed into the output stream in varying ways, some of which may have lacked pre-image resistance (e.g. XOR or an LFSR). But this is no longer the case. Now, all usage of RDRAND and bootloader seeds go through a cryptographic hash function. This means that the CPU would have to compute a hash pre-image, which is not considered to be feasible (otherwise the hash function would be terribly broken).- More generally, if the CPU is backdoored, the RNG is probably not the realistic vector of choice for an attacker.- These CPU or bootloader seeds are far from being the only source of entropy. Rather, there is generally a pretty huge amount of entropy, not all of which is credited, especially on CPUs that support instructions like RDRAND. In other words, assuming RDRAND outputs all zeros, an attacker would *still* have to accurately model every single other entropy source also in use.- The RNG now reseeds itself quite rapidly during boot, starting at 2 seconds, then 4, then 8, then 16, and so forth, so that other sources of entropy get used without much delay.- Paranoid users can set random.trust_{cpu,bootloader}=no in the kernel command line, and paranoid system builders can set the Kconfig options to N, so there's no reduction or restriction of optionality.- It's a practical default.- All the distros have it set this way. Microsoft and Apple trust it too. Bandwagon.Cons:- RDRAND *could* still be backdoored with something like a fixed key or limited space serial number seed or another indexable scheme like that. (However, it's hard to imagine threat models where the CPU is backdoored like this, yet people are still okay making *any* computations with it or connecting it to networks, etc.)- RDRAND *could* be defective, rather than backdoored, and produce garbage that is in one way or another insufficient for crypto.- Suggesting a *reduction* in paranoia, as this commit effectively does, may cause some to question my personal integrity as a "security person".- Bootloader seeds and RDRAND are generally very difficult if not all together impossible to audit.Keep in mind that this doesn't actually change any behavior. Thisis just a change in the default Kconfig value. The distros already areshipping kernels that set things this way.Ard made an additional argument in [1]: We're at the mercy of firmware and micro-architecture anyway, given that we are also relying on it to ensure that every instruction in the kernel's executable image has been faithfully copied to memory, and that the CPU implements those instructions as documented. So I don't think firmware or ISA bugs related to RNGs deserve special treatment - if they are broken, we should quirk around them like we usually do. So enabling these by default is a step in the right direction IMHO.In [2], Phil pointed out that having this disabled masked a bug that CIotherwise would have caught: A clean 5.15.45 boots cleanly, whereas a downstream kernel shows the static key warning (but it does go on to boot). The significant difference is that our defconfigs set CONFIG_RANDOM_TRUST_BOOTLOADER=y defining that on top of multi_v7_defconfig demonstrates the issue on a clean 5.15.45. Conversely, not setting that option in a downstream kernel build avoids the warning[1] https://lore.kernel.org/lkml/CAMj1kXGi+ieviFjXv9zQBSaGyyzeGW_VpMpTLJK8PJb2QHEQ-w@mail.gmail.com/[2] https://lore.kernel.org/lkml/c47c42e3-1d56-5859-a6ad-976a1a3381c6@raspberrypi.com/Cc: Theodore Ts'o Reviewed-by: Ard Biesheuvel Signed-off-by: Jason A. Donenfeld List of files: /linux-6.15/drivers/char/Kconfig

7ea4aa70 - char: ttyprintk: register console

Tue, 15 Feb 2022 14:17:49 +0000

char: ttyprintk: register consoleRegister a console in the ttyprintk driver so that it can be selectedfor /dev/console with console=ttyprintk on the kernel command line,similar to other console drivers.Signed-off-by: Vincent Whitchurch Link: https://lore.kernel.org/r/20220215141750.92808-1-vincent.whitchurch@axis.comSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/char/Kconfig

d97c68d1 - random: treat bootloader trust toggle the same way as cpu trust toggle

Wed, 23 Mar 2022 03:43:12 +0000

random: treat bootloader trust toggle the same way as cpu trust toggleIf CONFIG_RANDOM_TRUST_CPU is set, the RNG initializes using RDRAND.But, the user can disable (or enable) this behavior by setting`random.trust_cpu=0/1` on the kernel command line. This allows systembuilders to do reasonable things while avoiding howls from tinfoilhatters. (Or vice versa.)CONFIG_RANDOM_TRUST_BOOTLOADER is basically the same thing, but regardsthe seed passed via EFI or device tree, which might come from RDRAND ora TPM or somewhere else. In order to allow distros to more easily enablethis while avoiding those same howls (or vice versa), this commit addsthe corresponding `random.trust_bootloader=0/1` toggle.Cc: Theodore Ts'o Cc: Graham Christensen Reviewed-by: Ard Biesheuvel Reviewed-by: Dominik Brodowski Link: https://github.com/NixOS/nixpkgs/pull/165355Signed-off-by: Jason A. Donenfeld List of files: /linux-6.15/drivers/char/Kconfig

9e1b28b7 - char: move RANDOM_TRUST_CPU & RANDOM_TRUST_BOOTLOADER into the Character devices menu

Mon, 16 Aug 2021 00:05:31 +0000

char: move RANDOM_TRUST_CPU & RANDOM_TRUST_BOOTLOADER into the Character devices menuInclude RANDOM_TRUST_CPU and RANDOM_TRUST_BOOTLOADER inside the"Character devices" menu so that they are listed (presented)with other Character devices.Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Hsin-Yi Wang Cc: Theodore Ts'o Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20210816000531.17934-1-rdunlap@infradead.orgSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/char/Kconfig

603e4922 - remove the raw driver

Mon, 31 May 2021 07:25:26 +0000

remove the raw driverThe raw driver used to provide direct unbuffered access to block devicesbefore O_DIRECT was invented. It has been obsolete for more than adecade.Acked-by: Greg Kroah-Hartman Acked-by: Arnd Bergmann Link: https://lore.kernel.org/lkml/Pine.LNX.4.64.0703180754060.6605@CPE00045a9c397f-CM001225dbafb6/Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20210531072526.97052-1-hch@lst.deSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/char/Kconfig

ed5aecd3 - tty: remove broken r3964 line discipline

Wed, 05 May 2021 09:18:54 +0000

tty: remove broken r3964 line disciplineNoone stepped up in the past two years since it was marked as BROKEN bycommit c7084edc3f6d (tty: mark Siemens R3964 line discipline as BROKEN).Remove the line discipline for good.Three remarks:* we remove also the uapi header (as noone is able to use that interface anyway)* we do *not* remove the N_R3964 constant definition from tty.h, so it remains reserved.* in_interrupt() check is now removed from vt's con_put_char. Noone else calls tty_operations::put_char from interrupt context.Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210505091928.22010-2-jslaby@suse.czSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/char/Kconfig

bbcd53c9 - drivers/char: remove /dev/kmem for good

Fri, 07 May 2021 01:05:55 +0000

drivers/char: remove /dev/kmem for goodPatch series "drivers/char: remove /dev/kmem for good".Exploring /dev/kmem and /dev/mem in the context of memory hot(un)plug andmemory ballooning, I started questioning the existence of /dev/kmem.Comparing it with the /proc/kcore implementation, it does not seem to beable to deal with things likea) Pages unmapped from the direct mapping (e.g., to be used by secretmem) -> kern_addr_valid(). virt_addr_valid() is not sufficient.b) Special cases like gart aperture memory that is not to be touched -> mem_pfn_is_ram()Unless I am missing something, it's at least broken in some cases and mightfault/crash the machine.Looks like its existence has been questioned before in 2005 and 2010 [1],after ~11 additional years, it might make sense to revive the discussion.CONFIG_DEVKMEM is only enabled in a single defconfig (on purpose or bymistake?). All distributions disable it: in Ubuntu it has been disabledfor more than 10 years, in Debian since 2.6.31, in Fedora at leaststarting with FC3, in RHEL starting with RHEL4, in SUSE starting from15sp2, and OpenSUSE has it disabled as well.1) /dev/kmem was popular for rootkits [2] before it got disabled basically everywhere. Ubuntu documents [3] "There is no modern user of /dev/kmem any more beyond attackers using it to load kernel rootkits.". RHEL documents in a BZ [5] "it served no practical purpose other than to serve as a potential security problem or to enable binary module drivers to access structures/functions they shouldn't be touching"2) /proc/kcore is a decent interface to have a controlled way to read kernel memory for debugging puposes. (will need some extensions to deal with memory offlining/unplug, memory ballooning, and poisoned pages, though)3) It might be useful for corner case debugging [1]. KDB/KGDB might be a better fit, especially, to write random memory; harder to shoot yourself into the foot.4) "Kernel Memory Editor" [4] hasn't seen any updates since 2000 and seems to be incompatible with 64bit [1]. For educational purposes, /proc/kcore might be used to monitor value updates -- or older kernels can be used.5) It's broken on arm64, and therefore, completely disabled there.Looks like it's essentially unused and has been replaced by bettersuited interfaces for individual tasks (/proc/kcore, KDB/KGDB). Let'sjust remove it.[1] https://lwn.net/Articles/147901/[2] https://www.linuxjournal.com/article/10505[3] https://wiki.ubuntu.com/Security/Features#A.2Fdev.2Fkmem_disabled[4] https://sourceforge.net/projects/kme/[5] https://bugzilla.redhat.com/show_bug.cgi?id=154796Link: https://lkml.kernel.org/r/20210324102351.6932-1-david@redhat.comLink: https://lkml.kernel.org/r/20210324102351.6932-2-david@redhat.comSigned-off-by: David Hildenbrand Acked-by: Michal Hocko Acked-by: Kees Cook Cc: Linus Torvalds Cc: Greg Kroah-Hartman Cc: "Alexander A. Klimov" Cc: Alexander Viro Cc: Alexandre Belloni Cc: Andrew Lunn Cc: Andrey Zhizhikin Cc: Arnd Bergmann Cc: Benjamin Herrenschmidt Cc: Brian Cain Cc: Christian Borntraeger Cc: Christophe Leroy Cc: Chris Zankel Cc: Corentin Labbe Cc: "David S. Miller" Cc: "Eric W. Biederman" Cc: Geert Uytterhoeven Cc: Gerald Schaefer Cc: Greentime Hu Cc: Gregory Clement Cc: Heiko Carstens Cc: Helge Deller Cc: Hillf Danton Cc: huang ying Cc: Ingo Molnar Cc: Ivan Kokshaysky Cc: "James E.J. Bottomley" Cc: James Troup Cc: Jiaxun Yang Cc: Jonas Bonn Cc: Jonathan Corbet Cc: Kairui Song Cc: Krzysztof Kozlowski Cc: Kuninori Morimoto Cc: Liviu Dudau Cc: Lorenzo Pieralisi Cc: Luc Van Oostenryck Cc: Luis Chamberlain Cc: Matthew Wilcox Cc: Matt Turner Cc: Max Filippov Cc: Michael Ellerman Cc: Mike Rapoport Cc: Mikulas Patocka Cc: Minchan Kim Cc: Niklas Schnelle Cc: Oleksiy Avramchenko Cc: openrisc@lists.librecores.orgCc: Palmer Dabbelt Cc: Paul Mackerras Cc: "Pavel Machek (CIP)" Cc: Pavel Machek Cc: "Peter Zijlstra (Intel)" Cc: Pierre Morel Cc: Randy Dunlap Cc: Richard Henderson Cc: Rich Felker Cc: Robert Richter Cc: Rob Herring Cc: Russell King Cc: Sam Ravnborg Cc: Sebastian Andrzej Siewior Cc: Sebastian Hesselbarth Cc: sparclinux@vger.kernel.orgCc: Stafford Horne Cc: Stefan Kristiansson Cc: Steven Rostedt Cc: Sudeep Holla Cc: Theodore Dubois Cc: Thomas Bogendoerfer Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Viresh Kumar Cc: William Cohen Cc: Xiaoming Ni Cc: Yoshinori Sato Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/drivers/char/Kconfig

9f30eb29 - char: virtio: Select VIRTIO from VIRTIO_CONSOLE.

Mon, 31 Aug 2020 16:58:50 +0000

char: virtio: Select VIRTIO from VIRTIO_CONSOLE.Make it possible to have virtio console built-in whenother virtio drivers are modular.Signed-off-by: Michal Suchanek Reviewed-by: Amit Shah Link: https://lore.kernel.org/r/20200831165850.26163-1-msuchanek@suse.deSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/char/Kconfig

4e74eeb2 - char: Replace HTTP links with HTTPS ones

Mon, 13 Jul 2020 10:44:53 +0000

char: Replace HTTP links with HTTPS onesRationale:Reduces attack surface on kernel devs opening the links for MITMas HTTPS traffic is much harder to manipulate.Deterministic algorithm:For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS.Signed-off-by: Alexander A. Klimov Link: https://lore.kernel.org/r/20200713104453.33414-1-grandmaster@al2klimov.deSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/char/Kconfig

a7f7f624 - treewide: replace '---help---' in Kconfig files with 'help'

Sat, 13 Jun 2020 16:50:22 +0000

treewide: replace '---help---' in Kconfig files with 'help'Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over'---help---'"), the number of '---help---' has been graduallydecreasing, but there are still more than 2400 instances.This commit finishes the conversion. While I touched the lines,I also fixed the indentation.There are a variety of indentation styles found. a) 4 spaces + '---help---' b) 7 spaces + '---help---' c) 8 spaces + '---help---' d) 1 space + 1 tab + '---help---' e) 1 tab + '---help---' (correct indentation) f) 1 tab + 1 space + '---help---' g) 1 tab + 2 spaces + '---help---'In order to convert all of them to 1 tab + 'help', I ran thefollowing commend: $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'Signed-off-by: Masahiro Yamada List of files: /linux-6.15/drivers/char/Kconfig

7ade8495 - powerpc: Remove Xilinx PPC405/PPC440 support

Thu, 21 May 2020 16:55:52 +0000

powerpc: Remove Xilinx PPC405/PPC440 supportThe latest Xilinx design tools called ISE and EDK has been released inOctober 2013. New tool doesn't support any PPC405/PPC440 new designs.These platforms are no longer supported and tested.PowerPC 405/440 port is orphan from 2013 bycommit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") andcommit 19624236cce1 ("MAINTAINERS: Update Grant's email address and maintainership")that's why it is time to remove the support fot these platforms.Signed-off-by: Michal Simek Signed-off-by: Christophe Leroy Acked-by: Arnd Bergmann Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/8c593895e2cb57d232d85ce4d8c3a1aa7f0869cc.1590079968.git.christophe.leroy@csgroup.eu List of files: /linux-6.15/drivers/char/Kconfig

f52ef24b - rtc/alpha: remove legacy rtc driver

Wed, 26 Feb 2020 22:43:22 +0000

rtc/alpha: remove legacy rtc driverThe old drivers/char/rtc.c driver was originally the implementationfor x86 PCs but got subsequently replaced by the rtc class driveron all architectures except alpha.Move alpha over to the portable driver and remove the old onefor good.The CONFIG_JS_RTC option was only ever used on SPARC32 buthas not been available for many years, this was used to buildthe same rtc driver with a different module name.Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: linux-alpha@vger.kernel.orgCc: Paul Gortmaker Signed-off-by: Arnd Bergmann Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20200226224322.187960-2-alexandre.belloni@bootlin.comSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/char/Kconfig

8067c0b0 - rtc/ia64: remove legacy efirtc driver

Wed, 26 Feb 2020 22:43:21 +0000

rtc/ia64: remove legacy efirtc driverThere are two EFI RTC drivers, the original drivers/char/efirtc.cdriver and the more modern drivers/rtc/rtc-efi.c.Both implement the same interface, but the new one does soin a more portable way.Move everything over to that one and remove the old one.Cc: linux-ia64@vger.kernel.orgCc: Fenghua Yu Cc: Tony Luck Cc: Stephane Eranian Signed-off-by: Arnd Bergmann Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20200226224322.187960-1-alexandre.belloni@bootlin.comSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/char/Kconfig