summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--Documentation/CodingStyle2
-rw-r--r--Documentation/DocBook/Makefile2
-rw-r--r--Documentation/SubmittingPatches10
-rw-r--r--Documentation/arm/Samsung/Bootloader-interface.txt15
-rw-r--r--Documentation/email-clients.txt2
-rw-r--r--Documentation/filesystems/btrfs.txt16
-rw-r--r--Documentation/filesystems/debugfs.txt40
-rw-r--r--Documentation/kernel-doc-nano-HOWTO.txt2
-rw-r--r--Documentation/men-chameleon-bus.txt163
-rw-r--r--Documentation/networking/can.txt4
-rw-r--r--Documentation/powerpc/cxl.txt2
-rw-r--r--Documentation/powerpc/dscr.txt6
-rw-r--r--Documentation/powerpc/qe_firmware.txt2
-rw-r--r--Documentation/pps/pps.txt2
-rw-r--r--Documentation/sysctl/vm.txt10
-rw-r--r--MAINTAINERS2
-rw-r--r--README2
17 files changed, 249 insertions, 33 deletions
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index b713c35f8543..c06f817b3091 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -929,13 +929,11 @@ The C Programming Language, Second Edition
by Brian W. Kernighan and Dennis M. Ritchie.
Prentice Hall, Inc., 1988.
ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
-URL: http://cm.bell-labs.com/cm/cs/cbook/
The Practice of Programming
by Brian W. Kernighan and Rob Pike.
Addison-Wesley, Inc., 1999.
ISBN 0-201-61586-X.
-URL: http://cm.bell-labs.com/cm/cs/tpop/
GNU manuals - where in compliance with K&R and this text - for cpp, gcc,
gcc internals and indent, all available from http://www.gnu.org/manual/
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 11a41456b943..b7d2110298de 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -60,7 +60,7 @@ mandocs: $(MAN)
installmandocs: mandocs
mkdir -p /usr/local/man/man9/
- install $(obj)/man/*.9.gz /usr/local/man/man9/
+ install -m 644 $(obj)/man/*.9.gz /usr/local/man/man9/
###
#External programs used
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 27e7e5edeca8..80b9f54f87ef 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -90,11 +90,11 @@ patch.
Make sure your patch does not include any extra files which do not
belong in a patch submission. Make sure to review your patch -after-
-generated it with diff(1), to ensure accuracy.
+generating it with diff(1), to ensure accuracy.
If your changes produce a lot of deltas, you need to split them into
individual patches which modify things in logical stages; see section
-#3. This will facilitate easier reviewing by other kernel developers,
+#3. This will facilitate review by other kernel developers,
very important if you want your patch accepted.
If you're using git, "git rebase -i" can help you with this process. If
@@ -267,7 +267,7 @@ You should always copy the appropriate subsystem maintainer(s) on any patch
to code that they maintain; look through the MAINTAINERS file and the
source code revision history to see who those maintainers are. The
script scripts/get_maintainer.pl can be very useful at this step. If you
-cannot find a maintainer for the subsystem your are working on, Andrew
+cannot find a maintainer for the subsystem you are working on, Andrew
Morton (akpm@linux-foundation.org) serves as a maintainer of last resort.
You should also normally choose at least one mailing list to receive a copy
@@ -340,7 +340,7 @@ on the changes you are submitting. It is important for a kernel
developer to be able to "quote" your changes, using standard e-mail
tools, so that they may comment on specific portions of your code.
-For this reason, all patches should be submitting e-mail "inline".
+For this reason, all patches should be submitted by e-mail "inline".
WARNING: Be wary of your editor's word-wrap corrupting your patch,
if you choose to cut-n-paste your patch.
@@ -796,7 +796,7 @@ NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
<https://lkml.org/lkml/2005/7/11/336>
Kernel Documentation/CodingStyle:
- <http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>
+ <Documentation/CodingStyle>
Linus Torvalds's mail on the canonical patch format:
<http://lkml.org/lkml/2005/4/7/183>
diff --git a/Documentation/arm/Samsung/Bootloader-interface.txt b/Documentation/arm/Samsung/Bootloader-interface.txt
index b96ead9a6919..df8d4fb85939 100644
--- a/Documentation/arm/Samsung/Bootloader-interface.txt
+++ b/Documentation/arm/Samsung/Bootloader-interface.txt
@@ -15,6 +15,7 @@ executing kernel.
1. Non-Secure mode
+
Address: sysram_ns_base_addr
Offset Value Purpose
=============================================================================
@@ -28,6 +29,7 @@ Offset Value Purpose
2. Secure mode
+
Address: sysram_base_addr
Offset Value Purpose
=============================================================================
@@ -40,14 +42,25 @@ Offset Value Purpose
Address: pmu_base_addr
Offset Value Purpose
=============================================================================
-0x0800 exynos_cpu_resume AFTR
+0x0800 exynos_cpu_resume AFTR, suspend
+0x0800 mcpm_entry_point (Exynos542x with MCPM) AFTR, suspend
+0x0804 0xfcba0d10 (Magic cookie) AFTR
+0x0804 0x00000bad (Magic cookie) System suspend
0x0814 exynos4_secondary_startup (Exynos4210 r1.1) Secondary CPU boot
0x0818 0xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR
0x081C exynos_cpu_resume (Exynos4210 r1.1) AFTR
3. Other (regardless of secure/non-secure mode)
+
Address: pmu_base_addr
Offset Value Purpose
=============================================================================
0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator
+
+
+4. Glossary
+
+AFTR - ARM Off Top Running, a low power mode, Cortex cores and many other
+modules are power gated, except the TOP modules
+MCPM - Multi-Cluster Power Management
diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt
index c7d49b885559..3fa450881ecb 100644
--- a/Documentation/email-clients.txt
+++ b/Documentation/email-clients.txt
@@ -93,7 +93,7 @@ Evolution (GUI)
Some people use this successfully for patches.
When composing mail select: Preformat
- from Format->Heading->Preformatted (Ctrl-7)
+ from Format->Paragraph Style->Preformatted (Ctrl-7)
or the toolbar
Then use:
diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt
index d11cc2f8077b..c772b47e7ef0 100644
--- a/Documentation/filesystems/btrfs.txt
+++ b/Documentation/filesystems/btrfs.txt
@@ -61,7 +61,7 @@ Options with (*) are default options and will not show in the mount options.
check_int enables the integrity checker module, which examines all
block write requests to ensure on-disk consistency, at a large
- memory and CPU cost.
+ memory and CPU cost.
check_int_data includes extent data in the integrity checks, and
implies the check_int option.
@@ -113,7 +113,7 @@ Options with (*) are default options and will not show in the mount options.
Disable/enable debugging option to be more verbose in some ENOSPC conditions.
fatal_errors=<action>
- Action to take when encountering a fatal error:
+ Action to take when encountering a fatal error:
"bug" - BUG() on a fatal error. This is the default.
"panic" - panic() on a fatal error.
@@ -132,10 +132,10 @@ Options with (*) are default options and will not show in the mount options.
max_inline=<bytes>
Specify the maximum amount of space, in bytes, that can be inlined in
- a metadata B-tree leaf. The value is specified in bytes, optionally
+ a metadata B-tree leaf. The value is specified in bytes, optionally
with a K, M, or G suffix, case insensitive. In practice, this value
is limited by the root sector size, with some space unavailable due
- to leaf headers. For a 4k sectorsize, max inline data is ~3900 bytes.
+ to leaf headers. For a 4k sector size, max inline data is ~3900 bytes.
metadata_ratio=<value>
Specify that 1 metadata chunk should be allocated after every <value>
@@ -170,7 +170,7 @@ Options with (*) are default options and will not show in the mount options.
recovery
Enable autorecovery attempts if a bad tree root is found at mount time.
- Currently this scans a list of several previous tree roots and tries to
+ Currently this scans a list of several previous tree roots and tries to
use the first readable.
rescan_uuid_tree
@@ -194,7 +194,7 @@ Options with (*) are default options and will not show in the mount options.
ssd_spread
Options to control ssd allocation schemes. By default, BTRFS will
enable or disable ssd allocation heuristics depending on whether a
- rotational or nonrotational disk is in use. The ssd and nossd options
+ rotational or non-rotational disk is in use. The ssd and nossd options
can override this autodetection.
The ssd_spread mount option attempts to allocate into big chunks
@@ -216,13 +216,13 @@ Options with (*) are default options and will not show in the mount options.
This allows mounting of subvolumes which are not in the root of the mounted
filesystem.
You can use "btrfs subvolume show " to see the object ID for a subvolume.
-
+
thread_pool=<number>
The number of worker threads to allocate. The default number is equal
to the number of CPUs + 2, or 8, whichever is smaller.
user_subvol_rm_allowed
- Allow subvolumes to be deleted by a non-root user. Use with caution.
+ Allow subvolumes to be deleted by a non-root user. Use with caution.
MAILING LIST
============
diff --git a/Documentation/filesystems/debugfs.txt b/Documentation/filesystems/debugfs.txt
index 88ab81c79109..463f595733e8 100644
--- a/Documentation/filesystems/debugfs.txt
+++ b/Documentation/filesystems/debugfs.txt
@@ -51,6 +51,17 @@ operations should be provided; others can be included as needed. Again,
the return value will be a dentry pointer to the created file, NULL for
error, or ERR_PTR(-ENODEV) if debugfs support is missing.
+Create a file with an initial size, the following function can be used
+instead:
+
+ struct dentry *debugfs_create_file_size(const char *name, umode_t mode,
+ struct dentry *parent, void *data,
+ const struct file_operations *fops,
+ loff_t file_size);
+
+file_size is the initial file size. The other parameters are the same
+as the function debugfs_create_file.
+
In a number of cases, the creation of a set of file operations is not
actually necessary; the debugfs code provides a number of helper functions
for simple situations. Files containing a single integer value can be
@@ -100,6 +111,14 @@ A read on the resulting file will yield either Y (for non-zero values) or
N, followed by a newline. If written to, it will accept either upper- or
lower-case values, or 1 or 0. Any other input will be silently ignored.
+Also, atomic_t values can be placed in debugfs with:
+
+ struct dentry *debugfs_create_atomic_t(const char *name, umode_t mode,
+ struct dentry *parent, atomic_t *value)
+
+A read of this file will get atomic_t values, and a write of this file
+will set atomic_t values.
+
Another option is exporting a block of arbitrary binary data, with
this structure and function:
@@ -147,6 +166,27 @@ The "base" argument may be 0, but you may want to build the reg32 array
using __stringify, and a number of register names (macros) are actually
byte offsets over a base for the register block.
+If you want to dump an u32 array in debugfs, you can create file with:
+
+ struct dentry *debugfs_create_u32_array(const char *name, umode_t mode,
+ struct dentry *parent,
+ u32 *array, u32 elements);
+
+The "array" argument provides data, and the "elements" argument is
+the number of elements in the array. Note: Once array is created its
+size can not be changed.
+
+There is a helper function to create device related seq_file:
+
+ struct dentry *debugfs_create_devm_seqfile(struct device *dev,
+ const char *name,
+ struct dentry *parent,
+ int (*read_fn)(struct seq_file *s,
+ void *data));
+
+The "dev" argument is the device related to this debugfs file, and
+the "read_fn" is a function pointer which to be called to print the
+seq_file content.
There are a couple of other directory-oriented helper functions:
diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt
index acbc1a3d0d91..78f69cdc9b3f 100644
--- a/Documentation/kernel-doc-nano-HOWTO.txt
+++ b/Documentation/kernel-doc-nano-HOWTO.txt
@@ -128,7 +128,7 @@ are:
special place-holders for where the extracted documentation should
go.
-- scripts/basic/docproc.c
+- scripts/docproc.c
This is a program for converting SGML template files into SGML
files. When a file is referenced it is searched for symbols
diff --git a/Documentation/men-chameleon-bus.txt b/Documentation/men-chameleon-bus.txt
new file mode 100644
index 000000000000..30ded732027e
--- /dev/null
+++ b/Documentation/men-chameleon-bus.txt
@@ -0,0 +1,163 @@
+ MEN Chameleon Bus
+ =================
+
+Table of Contents
+=================
+1 Introduction
+ 1.1 Scope of this Document
+ 1.2 Limitations of the current implementation
+2 Architecture
+ 2.1 MEN Chameleon Bus
+ 2.2 Carrier Devices
+ 2.3 Parser
+3 Resource handling
+ 3.1 Memory Resources
+ 3.2 IRQs
+4 Writing an MCB driver
+ 4.1 The driver structure
+ 4.2 Probing and attaching
+ 4.3 Initializing the driver
+
+
+1 Introduction
+===============
+ This document describes the architecture and implementation of the MEN
+ Chameleon Bus (called MCB throughout this document).
+
+1.1 Scope of this Document
+---------------------------
+ This document is intended to be a short overview of the current
+ implementation and does by no means describe the complete possibilities of MCB
+ based devices.
+
+1.2 Limitations of the current implementation
+----------------------------------------------
+ The current implementation is limited to PCI and PCIe based carrier devices
+ that only use a single memory resource and share the PCI legacy IRQ. Not
+ implemented are:
+ - Multi-resource MCB devices like the VME Controller or M-Module carrier.
+ - MCB devices that need another MCB device, like SRAM for a DMA Controller's
+ buffer descriptors or a video controller's video memory.
+ - A per-carrier IRQ domain for carrier devices that have one (or more) IRQs
+ per MCB device like PCIe based carriers with MSI or MSI-X support.
+
+2 Architecture
+===============
+ MCB is divided into 3 functional blocks:
+ - The MEN Chameleon Bus itself,
+ - drivers for MCB Carrier Devices and
+ - the parser for the Chameleon table.
+
+2.1 MEN Chameleon Bus
+----------------------
+ The MEN Chameleon Bus is an artificial bus system that attaches to a so
+ called Chameleon FPGA device found on some hardware produced my MEN Mikro
+ Elektronik GmbH. These devices are multi-function devices implemented in a
+ single FPGA and usually attached via some sort of PCI or PCIe link. Each
+ FPGA contains a header section describing the content of the FPGA. The
+ header lists the device id, PCI BAR, offset from the beginning of the PCI
+ BAR, size in the FPGA, interrupt number and some other properties currently
+ not handled by the MCB implementation.
+
+2.2 Carrier Devices
+--------------------
+ A carrier device is just an abstraction for the real world physical bus the
+ Chameleon FPGA is attached to. Some IP Core drivers may need to interact with
+ properties of the carrier device (like querying the IRQ number of a PCI
+ device). To provide abstraction from the real hardware bus, an MCB carrier
+ device provides callback methods to translate the driver's MCB function calls
+ to hardware related function calls. For example a carrier device may
+ implement the get_irq() method which can be translated into a hardware bus
+ query for the IRQ number the device should use.
+
+2.3 Parser
+-----------
+ The parser reads the first 512 bytes of a Chameleon device and parses the
+ Chameleon table. Currently the parser only supports the Chameleon v2 variant
+ of the Chameleon table but can easily be adopted to support an older or
+ possible future variant. While parsing the table's entries new MCB devices
+ are allocated and their resources are assigned according to the resource
+ assignment in the Chameleon table. After resource assignment is finished, the
+ MCB devices are registered at the MCB and thus at the driver core of the
+ Linux kernel.
+
+3 Resource handling
+====================
+ The current implementation assigns exactly one memory and one IRQ resource
+ per MCB device. But this is likely going to change in the future.
+
+3.1 Memory Resources
+---------------------
+ Each MCB device has exactly one memory resource, which can be requested from
+ the MCB bus. This memory resource is the physical address of the MCB device
+ inside the carrier and is intended to be passed to ioremap() and friends. It
+ is already requested from the kernel by calling request_mem_region().
+
+3.2 IRQs
+---------
+ Each MCB device has exactly one IRQ resource, which can be requested from the
+ MCB bus. If a carrier device driver implements the ->get_irq() callback
+ method, the IRQ number assigned by the carrier device will be returned,
+ otherwise the IRQ number inside the Chameleon table will be returned. This
+ number is suitable to be passed to request_irq().
+
+4 Writing an MCB driver
+=======================
+
+4.1 The driver structure
+-------------------------
+ Each MCB driver has a structure to identify the device driver as well as
+ device ids which identify the IP Core inside the FPGA. The driver structure
+ also contains callback methods which get executed on driver probe and
+ removal from the system.
+
+
+ static const struct mcb_device_id foo_ids[] = {
+ { .device = 0x123 },
+ { }
+ };
+ MODULE_DEVICE_TABLE(mcb, foo_ids);
+
+ static struct mcb_driver foo_driver = {
+ driver = {
+ .name = "foo-bar",
+ .owner = THIS_MODULE,
+ },
+ .probe = foo_probe,
+ .remove = foo_remove,
+ .id_table = foo_ids,
+ };
+
+4.2 Probing and attaching
+--------------------------
+ When a driver is loaded and the MCB devices it services are found, the MCB
+ core will call the driver's probe callback method. When the driver is removed
+ from the system, the MCB core will call the driver's remove callback method.
+
+
+ static init foo_probe(struct mcb_device *mdev, const struct mcb_device_id *id);
+ static void foo_remove(struct mcb_device *mdev);
+
+4.3 Initializing the driver
+----------------------------
+ When the kernel is booted or your foo driver module is inserted, you have to
+ perform driver initialization. Usually it is enough to register your driver
+ module at the MCB core.
+
+
+ static int __init foo_init(void)
+ {
+ return mcb_register_driver(&foo_driver);
+ }
+ module_init(foo_init);
+
+ static void __exit foo_exit(void)
+ {
+ mcb_unregister_driver(&foo_driver);
+ }
+ module_exit(foo_exit);
+
+ The module_mcb_driver() macro can be used to reduce the above code.
+
+
+ module_mcb_driver(foo_driver);
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index b48d4a149411..fd1a1aad49a9 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -510,7 +510,7 @@ solution for a couple of reasons:
4.1.2 RAW socket option CAN_RAW_ERR_FILTER
- As described in chapter 3.4 the CAN interface driver can generate so
+ As described in chapter 3.3 the CAN interface driver can generate so
called Error Message Frames that can optionally be passed to the user
application in the same way as other CAN frames. The possible
errors are divided into different error classes that may be filtered
@@ -1152,7 +1152,7 @@ solution for a couple of reasons:
$ ip link set canX type can restart
Note that a restart will also create a CAN error message frame (see
- also chapter 3.4).
+ also chapter 3.3).
6.6 CAN FD (flexible data rate) driver support
diff --git a/Documentation/powerpc/cxl.txt b/Documentation/powerpc/cxl.txt
index 2a230d01cd8c..205c1b81625c 100644
--- a/Documentation/powerpc/cxl.txt
+++ b/Documentation/powerpc/cxl.txt
@@ -133,7 +133,7 @@ User API
The following file operations are supported on both slave and
master devices.
- A userspace library libcxl is avaliable here:
+ A userspace library libcxl is available here:
https://github.com/ibm-capi/libcxl
This provides a C interface to this kernel API.
diff --git a/Documentation/powerpc/dscr.txt b/Documentation/powerpc/dscr.txt
index 1ff4400c57b3..ece300c64f76 100644
--- a/Documentation/powerpc/dscr.txt
+++ b/Documentation/powerpc/dscr.txt
@@ -4,7 +4,7 @@
DSCR register in powerpc allows user to have some control of prefetch of data
stream in the processor. Please refer to the ISA documents or related manual
for more detailed information regarding how to use this DSCR to attain this
-control of the pefetches . This document here provides an overview of kernel
+control of the prefetches . This document here provides an overview of kernel
support for DSCR, related kernel objects, it's functionalities and exported
user interface.
@@ -44,7 +44,7 @@ user interface.
value into every CPU's DSCR register right away and updates the current
thread's DSCR value as well.
- Changing the CPU specif DSCR default value in the sysfs does exactly
+ Changing the CPU specific DSCR default value in the sysfs does exactly
the same thing as above but unlike the global one above, it just changes
stuff for that particular CPU instead for all the CPUs on the system.
@@ -62,7 +62,7 @@ user interface.
Accessing DSCR through user level SPR (0x03) from user space will first
create a facility unavailable exception. Inside this exception handler
- all mfspr isntruction based read attempts will get emulated and returned
+ all mfspr instruction based read attempts will get emulated and returned
where as the first mtspr instruction based write attempts will enable
the DSCR facility for the next time around (both for read and write) by
setting DSCR facility in the FSCR register.
diff --git a/Documentation/powerpc/qe_firmware.txt b/Documentation/powerpc/qe_firmware.txt
index 2031ddb33d09..e7ac24aec4ff 100644
--- a/Documentation/powerpc/qe_firmware.txt
+++ b/Documentation/powerpc/qe_firmware.txt
@@ -117,7 +117,7 @@ specific been defined. This table describes the structure.
Extended Modes
This is a double word bit array (64 bits) that defines special functionality
-which has an impact on the softwarew drivers. Each bit has its own impact
+which has an impact on the software drivers. Each bit has its own impact
and has special instructions for the s/w associated with it. This structure is
described in this table:
diff --git a/Documentation/pps/pps.txt b/Documentation/pps/pps.txt
index c508cceeee7d..7cb7264ad598 100644
--- a/Documentation/pps/pps.txt
+++ b/Documentation/pps/pps.txt
@@ -125,7 +125,7 @@ The same function may also run the defined echo function
(pps_ktimer_echo(), passing to it the "ptr" pointer) if the user
asked for that... etc..
-Please see the file drivers/pps/clients/ktimer.c for example code.
+Please see the file drivers/pps/clients/pps-ktimer.c for example code.
SYSFS support
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 9832ec52f859..9c3f2f8054b5 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -225,11 +225,11 @@ with your system. To disable them, echo 4 (bit 3) into drop_caches.
extfrag_threshold
This parameter affects whether the kernel will compact memory or direct
-reclaim to satisfy a high-order allocation. /proc/extfrag_index shows what
-the fragmentation index for each order is in each zone in the system. Values
-tending towards 0 imply allocations would fail due to lack of memory,
-values towards 1000 imply failures are due to fragmentation and -1 implies
-that the allocation will succeed as long as watermarks are met.
+reclaim to satisfy a high-order allocation. The extfrag/extfrag_index file in
+debugfs shows what the fragmentation index for each order is in each zone in
+the system. Values tending towards 0 imply allocations would fail due to lack
+of memory, values towards 1000 imply failures are due to fragmentation and -1
+implies that the allocation will succeed as long as watermarks are met.
The kernel will not compact memory in a zone if the
fragmentation index is <= extfrag_threshold. The default value is 500.
diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cefb6b6e..11e2516c2712 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3440,6 +3440,7 @@ X: Documentation/devicetree/
X: Documentation/acpi
X: Documentation/power
X: Documentation/spi
+X: Documentation/DocBook/media
T: git git://git.lwn.net/linux-2.6.git docs-next
DOUBLETALK DRIVER
@@ -6665,6 +6666,7 @@ M: Johannes Thumshirn <morbidrsa@gmail.com>
S: Maintained
F: drivers/mcb/
F: include/linux/mcb.h
+F: Documentation/men-chameleon-bus.txt
MEN F21BMC (Board Management Controller)
M: Andreas Werner <andreas.werner@men.de>
diff --git a/README b/README
index 69c68fb4a109..a326a6a6a46f 100644
--- a/README
+++ b/README
@@ -161,7 +161,7 @@ CONFIGURING the kernel:
"make xconfig" X windows (Qt) based configuration tool.
- "make gconfig" X windows (Gtk) based configuration tool.
+ "make gconfig" X windows (GTK+) based configuration tool.
"make oldconfig" Default all questions based on the contents of
your existing ./.config file and asking about
generated by cgit v1.2.3 (git 2.46.0) at 2025-07-17 22:40:23 +0000