Merge tag 'docs-6.6' of git://git.lwn.net/linux

+1 -1

Documentation/ABI/stable/sysfs-block

··· 295 295 capable of executing requests targeting different sector ranges 296 296 in parallel. For instance, single LUN multi-actuator hard-disks 297 297 will have an independent_access_ranges directory if the device 298 - correctly advertizes the sector ranges of its actuators. 298 + correctly advertises the sector ranges of its actuators. 299 299 300 300 The independent_access_ranges directory contains one directory 301 301 per access range, with each range described using the sector

+1 -1

Documentation/ABI/stable/sysfs-class-infiniband

··· 356 356 pkeys/<n>: (RO) Displays the contents of the physical 357 357 key table n = 0..126 358 358 359 - mcgs/: (RO) Muticast group table 359 + mcgs/: (RO) Multicast group table 360 360 361 361 <m>/gid_idx/0: (RO) Display the GID mapping m = 1..2 362 362

+1 -1

Documentation/ABI/stable/sysfs-platform-wmi-bmof

··· 2 2 Date: Jun 2017 3 3 KernelVersion: 4.13 4 4 Description: 5 - Binary MOF metadata used to decribe the details of available ACPI WMI interfaces. 5 + Binary MOF metadata used to describe the details of available ACPI WMI interfaces. 6 6 7 7 See Documentation/wmi/devices/wmi-bmof.rst for details.

+1 -1

Documentation/ABI/testing/debugfs-driver-habanalabs

··· 95 95 Date: Oct 2022 96 96 KernelVersion: 6.2 97 97 Contact: ttayar@habana.ai 98 - Description: The watchdog timeout value in seconds for a device relese upon 98 + Description: The watchdog timeout value in seconds for a device release upon 99 99 certain error cases, after which the device is reset. 100 100 101 101 What: /sys/kernel/debug/habanalabs/hl<n>/dma_size

+1 -1

Documentation/ABI/testing/procfs-diskstats

··· 8 8 9 9 == =================================== 10 10 1 major number 11 - 2 minor mumber 11 + 2 minor number 12 12 3 device name 13 13 4 reads completed successfully 14 14 5 reads merged

+1 -1

Documentation/ABI/testing/sysfs-bus-coreboot

··· 21 21 Date: August 2022 22 22 Contact: Jack Rosenthal <jrosenth@chromium.org> 23 23 Description: 24 - This is the pyhsical memory address that the CBMEM entry's data 24 + This is the physical memory address that the CBMEM entry's data 25 25 begins at, in hexadecimal (e.g., ``0x76ffe000``). 26 26 27 27 What: /sys/bus/coreboot/devices/cbmem-<id>/size

+4 -4

Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x

··· 31 31 KernelVersion: 3.19 32 32 Contact: Mathieu Poirier <mathieu.poirier@linaro.org> 33 33 Description: (RW) Used in conjunction with @addr_idx. Specifies the range of 34 - addresses to trigger on. Inclusion or exclusion is specificed 34 + addresses to trigger on. Inclusion or exclusion is specified 35 35 in the corresponding access type register. 36 36 37 37 What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_single ··· 304 304 Date: September 2015 305 305 KernelVersion: 4.4 306 306 Contact: Mathieu Poirier <mathieu.poirier@linaro.org> 307 - Description: (RO) Print the content of the ETM Trace Start/Stop Conrol 307 + Description: (RO) Print the content of the ETM Trace Start/Stop Control 308 308 register (0x018). The value is read directly from the HW. 309 309 310 310 What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr1 311 311 Date: September 2015 312 312 KernelVersion: 4.4 313 313 Contact: Mathieu Poirier <mathieu.poirier@linaro.org> 314 - Description: (RO) Print the content of the ETM Enable Conrol #1 314 + Description: (RO) Print the content of the ETM Enable Control #1 315 315 register (0x024). The value is read directly from the HW. 316 316 317 317 What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr2 318 318 Date: September 2015 319 319 KernelVersion: 4.4 320 320 Contact: Mathieu Poirier <mathieu.poirier@linaro.org> 321 - Description: (RO) Print the content of the ETM Enable Conrol #2 321 + Description: (RO) Print the content of the ETM Enable Control #2 322 322 register (0x01c). The value is read directly from the HW.

+1 -1

Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x

··· 446 446 KernelVersion: 4.01 447 447 Contact: Mathieu Poirier <mathieu.poirier@linaro.org> 448 448 Description: (Read) Returns the maximum size of the data value, data address, 449 - VMID, context ID and instuction address in the trace unit 449 + VMID, context ID and instruction address in the trace unit 450 450 (0x1E8). The value is taken directly from the HW. 451 451 452 452 What: /sys/bus/coresight/devices/etm<N>/trcidr/trcidr3

+2 -2

Documentation/ABI/testing/sysfs-bus-event_source-devices-events

··· 47 47 If a <term> is specified alone (without an assigned value), it 48 48 is implied that 0x1 is assigned to that <term>. 49 49 50 - Examples (each of these lines would be in a seperate file): 50 + Examples (each of these lines would be in a separate file): 51 51 52 52 event=0x2abc 53 53 event=0x423,inv,cmask=0x3 ··· 83 83 84 84 A string representing a floating point value expressed in 85 85 scientific notation to be multiplied by the event count 86 - recieved from the kernel to match the unit specified in the 86 + received from the kernel to match the unit specified in the 87 87 <event>.unit file. 88 88 89 89 Example:

+2 -2

Documentation/ABI/testing/sysfs-bus-fsi-devices-sbefifo

··· 5 5 Indicates whether or not this SBE device has experienced a 6 6 timeout; i.e. the SBE did not respond within the time allotted 7 7 by the driver. A value of 1 indicates that a timeout has 8 - ocurred and no transfers have completed since the timeout. A 9 - value of 0 indicates that no timeout has ocurred, or if one 8 + occurred and no transfers have completed since the timeout. A 9 + value of 0 indicates that no timeout has occurred, or if one 10 10 has, more recent transfers have completed successful.

+1 -1

Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480

··· 8 8 NONE no device 9 9 USB USB device is attached 10 10 UART UART is attached 11 - CHARGER Charger is attaced 11 + CHARGER Charger is attached 12 12 JIG JIG is attached 13 13 ======= ====================== 14 14

+1 -1

Documentation/ABI/testing/sysfs-bus-nfit

··· 121 121 Contact: nvdimm@lists.linux.dev 122 122 Description: 123 123 (RO) ACPI specification 6.2 section 5.2.25.9, defines an 124 - identifier for an NVDIMM, which refelects the id attribute. 124 + identifier for an NVDIMM, which reflects the id attribute. 125 125 126 126 127 127 What: /sys/bus/nd/devices/nmemX/nfit/subsystem_vendor

+3 -1

Documentation/ABI/testing/sysfs-bus-nvdimm

··· 18 18 Each attribute under this group defines a bit range of the 19 19 perf_event_attr.config. Supported attribute is listed 20 20 below:: 21 + 21 22 event = "config:0-4" - event ID 22 23 23 24 For example:: 24 - ctl_res_cnt = "event=0x1" 25 + 26 + ctl_res_cnt = "event=0x1" 25 27 26 28 What: /sys/bus/event_source/devices/nmemX/events 27 29 Date: February 2022

+1 -1

Documentation/ABI/testing/sysfs-bus-papr-pmem

··· 30 30 Indicating that contents of the 31 31 NVDIMM have been scrubbed. 32 32 * "locked" 33 - Indicating that NVDIMM contents cant 33 + Indicating that NVDIMM contents can't 34 34 be modified until next power cycle. 35 35 36 36 What: /sys/bus/nd/devices/nmemX/papr/perf_stats

+1 -1

Documentation/ABI/testing/sysfs-bus-umc

··· 9 9 Controller (UMC). 10 10 11 11 The umc bus presents each of the individual 12 - capabilties as a device. 12 + capabilities as a device. 13 13 14 14 What: /sys/bus/umc/devices/.../capability_id 15 15 Date: July 2008

+1 -1

Documentation/ABI/testing/sysfs-class

··· 1 1 What: /sys/class/ 2 - Date: Febuary 2006 2 + Date: February 2006 3 3 Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 4 4 Description: 5 5 The /sys/class directory will consist of a group of

+2 -2

Documentation/ABI/testing/sysfs-class-cxl

··· 42 42 Date: September 2014 43 43 Contact: linuxppc-dev@lists.ozlabs.org 44 44 Description: read only 45 - Decimal value of the size of the MMIO space that may be mmaped 45 + Decimal value of the size of the MMIO space that may be mmapped 46 46 by userspace. 47 47 Users: https://github.com/ibm-capi/libcxl 48 48 ··· 155 155 Date: September 2014 156 156 Contact: linuxppc-dev@lists.ozlabs.org 157 157 Description: read only 158 - Decimal value of the size of the MMIO space that may be mmaped 158 + Decimal value of the size of the MMIO space that may be mmapped 159 159 by userspace. This includes all slave contexts space also. 160 160 Users: https://github.com/ibm-capi/libcxl 161 161

+1 -1

Documentation/ABI/testing/sysfs-class-mtd

··· 39 39 Contact: linux-mtd@lists.infradead.org 40 40 Description: 41 41 Major and minor numbers of the character device corresponding 42 - to the read-only variant of thie MTD device (in 42 + to the read-only variant of the MTD device (in 43 43 <major>:<minor> format). In this case <minor> will be odd. 44 44 45 45 What: /sys/class/mtd/mtdX/erasesize

+1 -1

Documentation/ABI/testing/sysfs-class-net

··· 82 82 Contact: netdev@vger.kernel.org 83 83 Description: 84 84 Indicates the current physical link state of the interface. 85 - Posssible values are: 85 + Possible values are: 86 86 87 87 == ===================== 88 88 0 physical link is down

+1 -1

Documentation/ABI/testing/sysfs-class-net-queues

··· 39 39 Description: 40 40 Mask of the CPU(s) currently enabled to participate into the 41 41 Transmit Packet Steering packet processing flow for this 42 - network device transmit queue. Possible vaules depend on the 42 + network device transmit queue. Possible values depend on the 43 43 number of available CPU(s) in the system. 44 44 45 45 What: /sys/class/<iface>/queues/tx-<queue>/xps_rxqs

+1 -1

Documentation/ABI/testing/sysfs-class-power-wilco

··· 22 22 Long Life: 23 23 Customized charge rate for last longer battery life. 24 24 On Wilco device this mode is pre-configured in the factory 25 - through EC's private PID. Swiching to a different mode will 25 + through EC's private PID. Switching to a different mode will 26 26 be denied by Wilco EC when Long Life mode is enabled. 27 27 28 28 What: /sys/class/power_supply/wilco-charger/charge_control_start_threshold

+1 -1

Documentation/ABI/testing/sysfs-class-remoteproc

··· 81 81 collected userspace will directly read from the remote 82 82 processor's device memory. Extra buffer will not be used to 83 83 copy the dump. Also recovery process will not proceed until 84 - all data is read by usersapce. 84 + all data is read by userspace. 85 85 86 86 What: /sys/class/remoteproc/.../recovery 87 87 Date: July 2020

+1 -1

Documentation/ABI/testing/sysfs-class-thermal

··· 4 4 This is given by thermal zone driver as part of registration. 5 5 E.g: "acpitz" indicates it's an ACPI thermal device. 6 6 In order to keep it consistent with hwmon sys attribute; this 7 - shouldbe a short, lowercase string, not containing spaces nor 7 + should be a short, lowercase string, not containing spaces nor 8 8 dashes. 9 9 10 10 RO, Required

+1 -1

Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc

··· 42 42 KernelVersion: 3.11 43 43 Contact: Thomas Pugliese <thomas.pugliese@gmail.com> 44 44 Description: 45 - The device notification time slot (DNTS) count and inverval in 45 + The device notification time slot (DNTS) count and interval in 46 46 milliseconds that the WUSB host should use. This controls how 47 47 often the devices will have the opportunity to send 48 48 notifications to the host.

+1 -1

Documentation/ABI/testing/sysfs-devices-online

··· 17 17 After a successful execution of the bus type's .offline() 18 18 callback the device cannot be used for any purpose until either 19 19 it is removed (i.e. device_del() is called for it), or its bus 20 - type's .online() is exeucted successfully. 20 + type's .online() is executed successfully.

+1 -1

Documentation/ABI/testing/sysfs-driver-ge-achc

··· 5 5 firmware via the EzPort interface. For this the kernel 6 6 will load "achc.bin" via the firmware API (so usually 7 7 from /lib/firmware). The write will block until the FW 8 - has either been flashed successfully or an error occured. 8 + has either been flashed successfully or an error occurred. 9 9 10 10 What: /sys/bus/spi/<dev>/reset 11 11 Date: Jul 2021

+1 -1

Documentation/ABI/testing/sysfs-driver-tegra-fuse

··· 3 3 Contact: Peter De Schrijver <pdeschrijver@nvidia.com> 4 4 Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114 5 5 and Tegra124 SoC's from NVIDIA. The efuses contain write once 6 - data programmed at the factory. The data is layed out in 32bit 6 + data programmed at the factory. The data is laid out in 32bit 7 7 words in LSB first format. Each bit represents a single value 8 8 as decoded from the fuse registers. Bits order/assignment 9 9 exactly matches the HW registers, including any unused bits.

+1 -1

Documentation/ABI/testing/sysfs-firmware-acpi

··· 84 84 hotplug events associated with the given class of 85 85 devices and will allow those devices to be ejected with 86 86 the help of the _EJ0 control method. Unsetting it 87 - effectively disables hotplug for the correspoinding 87 + effectively disables hotplug for the corresponding 88 88 class of devices. 89 89 ======== ======================================================= 90 90

+2 -2

Documentation/ABI/testing/sysfs-firmware-sgi_uv

··· 102 102 conn_port 103 103 104 104 The conn_hub entry contains a value representing the unique 105 - oridinal value of the hub on the other end of the fabric 105 + ordinal value of the hub on the other end of the fabric 106 106 cable plugged into the port. If the port is disconnected, 107 107 the value returned will be -1. 108 108 109 109 The conn_port entry contains a value representing the unique 110 - oridinal value of the port on the other end of the fabric cable 110 + ordinal value of the port on the other end of the fabric cable 111 111 plugged into the port. If the port is disconnected, the value 112 112 returned will be -1. 113 113

+4 -4

Documentation/ABI/testing/sysfs-fs-f2fs

··· 54 54 0x00 DISABLE disable IPU(=default option in LFS mode) 55 55 0x01 FORCE all the time 56 56 0x02 SSR if SSR mode is activated 57 - 0x04 UTIL if FS utilization is over threashold 57 + 0x04 UTIL if FS utilization is over threshold 58 58 0x08 SSR_UTIL if SSR mode is activated and FS utilization is over 59 - threashold 59 + threshold 60 60 0x10 FSYNC activated in fsync path only for high performance 61 61 flash storages. IPU will be triggered only if the 62 62 # of dirty pages over min_fsync_blocks. ··· 117 117 Contact: "Konstantin Vyshetsky" <vkon@google.com> 118 118 Description: Controls the number of discards a thread will issue at a time. 119 119 Higher number will allow the discard thread to finish its work 120 - faster, at the cost of higher latency for incomming I/O. 120 + faster, at the cost of higher latency for incoming I/O. 121 121 122 122 What: /sys/fs/f2fs/<disk>/min_discard_issue_time 123 123 Date: December 2021 ··· 334 334 state. 2048 trials is set by default. 335 335 336 336 What: /sys/fs/f2fs/<disk>/extension_list 337 - Date: Feburary 2018 337 + Date: February 2018 338 338 Contact: "Chao Yu" <yuchao0@huawei.com> 339 339 Description: Used to control configure extension list: 340 340 - Query: cat /sys/fs/f2fs/<disk>/extension_list

+1 -1

Documentation/ABI/testing/sysfs-kernel-mm-damon

··· 154 154 What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/min 155 155 Date: Mar 2022 156 156 Contact: SeongJae Park <sj@kernel.org> 157 - Description: Writing to and reading from this file sets and gets the mimimum 157 + Description: Writing to and reading from this file sets and gets the minimum 158 158 size of the scheme's target regions in bytes. 159 159 160 160 What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/max

+1 -1

Documentation/ABI/testing/sysfs-platform-dell-laptop

··· 15 15 Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>, 16 16 Pali Rohár <pali@kernel.org> 17 17 Description: 18 - This file allows to specifiy the on/off threshold value, 18 + This file allows to specify the on/off threshold value, 19 19 as reported by the ambient light sensor. 20 20 21 21 What: /sys/class/leds/dell::kbd_backlight/start_triggers

+1 -1

Documentation/ABI/testing/sysfs-platform-dfl-fme

··· 90 90 Contact: Wu Hao <hao.wu@intel.com> 91 91 Description: Read-Write. Read this file to get errors detected on FME. 92 92 Write this file to clear errors logged in fme_errors. Write 93 - fials with -EINVAL if input parsing fails or input error code 93 + fails with -EINVAL if input parsing fails or input error code 94 94 doesn't match. 95 95 96 96 What: /sys/bus/platform/devices/dfl-fme.0/errors/first_error

+1 -1

Documentation/ABI/testing/sysfs-platform-kim

··· 9 9 The device name flows down to architecture specific board 10 10 initialization file from the ATAGS bootloader 11 11 firmware. The name exposed is read from the user-space 12 - dameon and opens the device when install is requested. 12 + daemon and opens the device when install is requested. 13 13 14 14 What: /sys/devices/platform/kim/baud_rate 15 15 Date: January 2010

+1 -1

Documentation/ABI/testing/sysfs-platform-sst-atom

··· 4 4 Contact: "Sebastien Guiriec" <sebastien.guiriec@intel.com> 5 5 Description: 6 6 LPE Firmware version for SST driver on all atom 7 - plaforms (BYT/CHT/Merrifield/BSW). 7 + platforms (BYT/CHT/Merrifield/BSW). 8 8 If the FW has never been loaded it will display:: 9 9 10 10 "FW not yet loaded"

+16

Documentation/Makefile

··· 59 59 KERNELDOC = $(srctree)/scripts/kernel-doc 60 60 KERNELDOC_CONF = -D kerneldoc_srctree=$(srctree) -D kerneldoc_bin=$(KERNELDOC) 61 61 ALLSPHINXOPTS = $(KERNELDOC_CONF) $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) 62 + ifneq ($(wildcard $(srctree)/.config),) 63 + ifeq ($(CONFIG_RUST),y) 64 + # Let Sphinx know we will include rustdoc 65 + ALLSPHINXOPTS += -t rustdoc 66 + endif 67 + endif 62 68 # the i18n builder cannot share the environment and doctrees with the others 63 69 I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . 64 70 ··· 100 94 htmldocs: 101 95 @$(srctree)/scripts/sphinx-pre-install --version-check 102 96 @+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,html,$(var),,$(var))) 97 + 98 + # If Rust support is available and .config exists, add rustdoc generated contents. 99 + # If there are any, the errors from this make rustdoc will be displayed but 100 + # won't stop the execution of htmldocs 101 + 102 + ifneq ($(wildcard $(srctree)/.config),) 103 + ifeq ($(CONFIG_RUST),y) 104 + $(Q)$(MAKE) rustdoc || true 105 + endif 106 + endif 103 107 104 108 texinfodocs: 105 109 @$(srctree)/scripts/sphinx-pre-install --version-check

+1 -1

Documentation/accounting/psi.rst

··· 178 178 Cgroup2 interface 179 179 ================= 180 180 181 - In a system with a CONFIG_CGROUP=y kernel and the cgroup2 filesystem 181 + In a system with a CONFIG_CGROUPS=y kernel and the cgroup2 filesystem 182 182 mounted, pressure stall information is also tracked for tasks grouped 183 183 into cgroups. Each subdirectory in the cgroupfs mountpoint contains 184 184 cpu.pressure, memory.pressure, and io.pressure files; the format is

+1 -1

Documentation/admin-guide/cgroup-v1/memcg_test.rst

··· 62 62 63 63 At cancel(), simply usage -= PAGE_SIZE. 64 64 65 - Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y. 65 + Under below explanation, we assume CONFIG_SWAP=y. 66 66 67 67 4. Anonymous 68 68 ============

+13 -12

Documentation/admin-guide/kernel-parameters.rst

··· 80 80 so that "nohz_full=all" is the equivalent of "nohz_full=0-N". 81 81 82 82 The semantics of "N" and "all" is supported on a level of bitmaps and holds for 83 - all users of bitmap_parse(). 83 + all users of bitmap_parselist(). 84 84 85 85 This document may not be entirely up to date and comprehensive. The command 86 86 "modinfo -p ${modulename}" shows a current list of all parameters of a loadable ··· 89 89 parameters may be changed at runtime by the command 90 90 ``echo -n ${value} > /sys/module/${modulename}/parameters/${parm}``. 91 91 92 - The parameters listed below are only valid if certain kernel build options were 93 - enabled and if respective hardware is present. The text in square brackets at 94 - the beginning of each description states the restrictions within which a 95 - parameter is applicable:: 92 + The parameters listed below are only valid if certain kernel build options 93 + were enabled and if respective hardware is present. This list should be kept 94 + in alphabetical order. The text in square brackets at the beginning 95 + of each description states the restrictions within which a parameter 96 + is applicable:: 96 97 97 98 ACPI ACPI support is enabled. 98 99 AGP AGP (Accelerated Graphics Port) is enabled. ··· 128 127 KGDB Kernel debugger support is enabled. 129 128 KVM Kernel Virtual Machine support is enabled. 130 129 LIBATA Libata driver is enabled 131 - LP Printer support is enabled. 132 130 LOONGARCH LoongArch architecture is enabled. 133 131 LOOP Loopback device support is enabled. 132 + LP Printer support is enabled. 134 133 M68k M68k architecture is enabled. 135 134 These options have more detailed description inside of 136 135 Documentation/arch/m68k/kernel-options.rst. ··· 140 139 MSI Message Signaled Interrupts (PCI). 141 140 MTD MTD (Memory Technology Device) support is enabled. 142 141 NET Appropriate network support is enabled. 143 - NUMA NUMA support is enabled. 144 142 NFS Appropriate NFS support is enabled. 143 + NUMA NUMA support is enabled. 145 144 OF Devicetree is enabled. 146 - PV_OPS A paravirtualized kernel is enabled. 147 145 PARISC The PA-RISC architecture is enabled. 148 146 PCI PCI bus support is enabled. 149 147 PCIE PCI Express support is enabled. ··· 151 151 PPC PowerPC architecture is enabled. 152 152 PPT Parallel port support is enabled. 153 153 PS2 Appropriate PS/2 support is enabled. 154 + PV_OPS A paravirtualized kernel is enabled. 154 155 RAM RAM disk support is enabled. 155 - RISCV RISCV architecture is enabled. 156 156 RDT Intel Resource Director Technology. 157 + RISCV RISCV architecture is enabled. 157 158 S390 S390 architecture is enabled. 158 159 SCSI Appropriate SCSI support is enabled. 159 160 A lot of drivers have their options described inside ··· 165 164 SH SuperH architecture is enabled. 166 165 SMP The kernel is an SMP kernel. 167 166 SPARC Sparc architecture is enabled. 168 - SWSUSP Software suspend (hibernation) is enabled. 169 167 SUSPEND System suspend states are enabled. 168 + SWSUSP Software suspend (hibernation) is enabled. 170 169 TPM TPM drivers are enabled. 171 170 UMS USB Mass Storage support is enabled. 172 171 USB USB support is enabled. 173 172 USBHID USB Human Interface Device support is enabled. 174 173 V4L Video For Linux support is enabled. 175 - VMMIO Driver for memory mapped virtio devices is enabled. 176 174 VGA The VGA console has been enabled. 175 + VMMIO Driver for memory mapped virtio devices is enabled. 177 176 VT Virtual terminal support is enabled. 178 177 WDT Watchdog support is enabled. 179 178 X86-32 X86-32, aka i386 architecture is enabled. ··· 187 186 188 187 In addition, the following text indicates that the option:: 189 188 189 + BOOT Is a boot loader parameter. 190 190 BUGS= Relates to possible processor bugs on the said processor. 191 191 KNL Is a kernel start-up parameter. 192 - BOOT Is a boot loader parameter. 193 192 194 193 Parameters denoted with BOOT are actually interpreted by the boot 195 194 loader, and have no meaning to the kernel directly.

+23 -23

Documentation/admin-guide/kernel-parameters.txt

··· 418 418 arm64.nobti [ARM64] Unconditionally disable Branch Target 419 419 Identification support 420 420 421 - arm64.nopauth [ARM64] Unconditionally disable Pointer Authentication 422 - support 421 + arm64.nomops [ARM64] Unconditionally disable Memory Copy and Memory 422 + Set instructions support 423 423 424 424 arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension 425 425 support 426 426 427 - arm64.nosve [ARM64] Unconditionally disable Scalable Vector 428 - Extension support 427 + arm64.nopauth [ARM64] Unconditionally disable Pointer Authentication 428 + support 429 429 430 430 arm64.nosme [ARM64] Unconditionally disable Scalable Matrix 431 431 Extension support 432 432 433 - arm64.nomops [ARM64] Unconditionally disable Memory Copy and Memory 434 - Set instructions support 433 + arm64.nosve [ARM64] Unconditionally disable Scalable Vector 434 + Extension support 435 435 436 436 ataflop= [HW,M68k] 437 437 ··· 2655 2655 2656 2656 kvm-intel.flexpriority= 2657 2657 [KVM,Intel] Control KVM's use of FlexPriority feature 2658 - (TPR shadow). Default is 1 (enabled). Disalbe by KVM if 2658 + (TPR shadow). Default is 1 (enabled). Disable by KVM if 2659 2659 hardware lacks support for it. 2660 2660 2661 2661 kvm-intel.nested= ··· 3140 3140 [KNL,SH] Allow user to override the default size for 3141 3141 per-device physically contiguous DMA buffers. 3142 3142 3143 - memhp_default_state=online/offline 3143 + memhp_default_state=online/offline/online_kernel/online_movable 3144 3144 [KNL] Set the initial state for the memory hotplug 3145 3145 onlining policy. If not specified, the default value is 3146 3146 set according to the ··· 4073 4073 timeout < 0: reboot immediately 4074 4074 Format: <timeout> 4075 4075 4076 - panic_print= Bitmask for printing system info when panic happens. 4077 - User can chose combination of the following bits: 4078 - bit 0: print all tasks info 4079 - bit 1: print system memory info 4080 - bit 2: print timer info 4081 - bit 3: print locks info if CONFIG_LOCKDEP is on 4082 - bit 4: print ftrace buffer 4083 - bit 5: print all printk messages in buffer 4084 - bit 6: print all CPUs backtrace (if available in the arch) 4085 - *Be aware* that this option may print a _lot_ of lines, 4086 - so there are risks of losing older messages in the log. 4087 - Use this option carefully, maybe worth to setup a 4088 - bigger log buffer with "log_buf_len" along with this. 4089 - 4090 4076 panic_on_taint= Bitmask for conditionally calling panic() in add_taint() 4091 4077 Format: <hex>[,nousertaint] 4092 4078 Hexadecimal bitmask representing the set of TAINT flags ··· 4088 4102 4089 4103 panic_on_warn=1 panic() instead of WARN(). Useful to cause kdump 4090 4104 on a WARN(). 4105 + 4106 + panic_print= Bitmask for printing system info when panic happens. 4107 + User can chose combination of the following bits: 4108 + bit 0: print all tasks info 4109 + bit 1: print system memory info 4110 + bit 2: print timer info 4111 + bit 3: print locks info if CONFIG_LOCKDEP is on 4112 + bit 4: print ftrace buffer 4113 + bit 5: print all printk messages in buffer 4114 + bit 6: print all CPUs backtrace (if available in the arch) 4115 + *Be aware* that this option may print a _lot_ of lines, 4116 + so there are risks of losing older messages in the log. 4117 + Use this option carefully, maybe worth to setup a 4118 + bigger log buffer with "log_buf_len" along with this. 4091 4119 4092 4120 parkbd.port= [HW] Parallel port number the keyboard adapter is 4093 4121 connected to, default is 0. ··· 4222 4222 mode 0, bit 1 is for mode 1, and so on. Mode 0 only 4223 4223 allowed by default. 4224 4224 4225 - pause_on_oops= 4225 + pause_on_oops=<int> 4226 4226 Halt all CPUs after the first oops has been printed for 4227 4227 the specified number of seconds. This is to be used if 4228 4228 your oopses keep scrolling off the screen.

+2 -2

Documentation/admin-guide/mm/damon/usage.rst

··· 99 99 100 100 The root of the DAMON sysfs interface is ``<sysfs>/kernel/mm/damon/``, and it 101 101 has one directory named ``admin``. The directory contains the files for 102 - privileged user space programs' control of DAMON. User space tools or deamons 102 + privileged user space programs' control of DAMON. User space tools or daemons 103 103 having the root permission could use this directory. 104 104 105 105 kdamonds/ ··· 413 413 The statistics can be retrieved by reading the files under ``stats`` directory 414 414 (``nr_tried``, ``sz_tried``, ``nr_applied``, ``sz_applied``, and 415 415 ``qt_exceeds``), respectively. The files are not updated in real time, so you 416 - should ask DAMON sysfs interface to updte the content of the files for the 416 + should ask DAMON sysfs interface to update the content of the files for the 417 417 stats by writing a special keyword, ``update_schemes_stats`` to the relevant 418 418 ``kdamonds/<N>/state`` file. 419 419

+1 -1

Documentation/admin-guide/mm/numa_memory_policy.rst

··· 109 109 * A task may install a new VMA policy on a sub-range of a 110 110 previously mmap()ed region. When this happens, Linux splits 111 111 the existing virtual memory area into 2 or 3 VMAs, each with 112 - it's own policy. 112 + its own policy. 113 113 114 114 * By default, VMA policy applies only to pages allocated after 115 115 the policy is installed. Any pages already faulted into the

+1 -1

Documentation/admin-guide/module-signing.rst

··· 266 266 unsigned. Any module for which the kernel has a key, but which proves to have 267 267 a signature mismatch will not be permitted to load. 268 268 269 - Any module that has an unparseable signature will be rejected. 269 + Any module that has an unparsable signature will be rejected. 270 270 271 271 272 272 =========================================

+1 -1

Documentation/admin-guide/serial-console.rst

··· 59 59 the hardware is not available. 60 60 61 61 The result might be surprising. For example, the following two command 62 - lines have the same result: 62 + lines have the same result:: 63 63 64 64 console=ttyS1,9600 console=tty0 console=tty1 65 65 console=tty0 console=ttyS1,9600 console=tty1

+1 -1

Documentation/admin-guide/xfs.rst

··· 192 192 are any integer multiple of a valid ``sunit`` value. 193 193 194 194 Typically the only time these mount options are necessary if 195 - after an underlying RAID device has had it's geometry 195 + after an underlying RAID device has had its geometry 196 196 modified, such as adding a new disk to a RAID5 lun and 197 197 reshaping it. 198 198

+1 -1

Documentation/arch/arm/arm.rst

··· 141 141 `*configure` harddrive set to 2). I've got an internal 20MB and a great 142 142 big external 5.25" FH 64MB drive (who could ever want more :-) ). 143 143 144 - I've just got 240K/s off it (a dd with bs=128k); thats about half of what 144 + I've just got 240K/s off it (a dd with bs=128k); that's about half of what 145 145 RiscOS gets; but it's a heck of a lot better than the 50K/s I was getting 146 146 last week :-) 147 147

+2 -2

Documentation/arch/arm/ixp4xx.rst

··· 78 78 1) A direct mapped window from 0x48000000 to 0x4bffffff (64MB). 79 79 To access PCI via this space, we simply ioremap() the BAR 80 80 into the kernel and we can use the standard read[bwl]/write[bwl] 81 - macros. This is the preffered method due to speed but it 81 + macros. This is the preferred method due to speed but it 82 82 limits the system to just 64MB of PCI memory. This can be 83 - problamatic if using video cards and other memory-heavy devices. 83 + problematic if using video cards and other memory-heavy devices. 84 84 85 85 2) If > 64MB of memory space is required, the IXP4xx can be 86 86 configured to use indirect registers to access PCI This allows

+1 -1

Documentation/arch/arm/sunxi/clocks.rst

··· 5 5 This document contains useful bits of information that people tend to ask 6 6 about the sunxi clock system, as well as accompanying ASCII art when adequate. 7 7 8 - Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the 8 + Q: Why is the main 24MHz oscillator gateable? Wouldn't that break the 9 9 system? 10 10 11 11 A: The 24MHz oscillator allows gating to save power. Indeed, if gated

+1 -1

Documentation/arch/arm/swp_emulation.rst

··· 1 1 Software emulation of deprecated SWP instruction (CONFIG_SWP_EMULATE) 2 2 --------------------------------------------------------------------- 3 3 4 - ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommeds 4 + ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommends 5 5 moving to the load-locked/store-conditional instructions LDREX and STREX. 6 6 7 7 ARMv7 multiprocessing extensions introduce the ability to disable these

+1 -1

Documentation/arch/arm/tcm.rst

··· 71 71 72 72 - Have the remaining TCM RAM added to a special 73 73 allocation pool with gen_pool_create() and gen_pool_add() 74 - and provice tcm_alloc() and tcm_free() for this 74 + and provide tcm_alloc() and tcm_free() for this 75 75 memory. Such a heap is great for things like saving 76 76 device state when shutting off device power domains. 77 77

+3 -1

Documentation/arch/arm/uefi.rst

··· 50 50 following parameters: 51 51 52 52 ========================== ====== =========================================== 53 - Name Size Description 53 + Name Type Description 54 54 ========================== ====== =========================================== 55 55 linux,uefi-system-table 64-bit Physical address of the UEFI System Table. 56 56 ··· 67 67 68 68 kaslr-seed 64-bit Entropy used to randomize the kernel image 69 69 base address location. 70 + 71 + bootargs String Kernel command line 70 72 ========================== ====== ===========================================

+1 -1

Documentation/arch/arm/vlocks.rst

··· 155 155 optimisation. 156 156 157 157 If there are too many CPUs to read the currently_voting array in 158 - one transaction then multiple transations are still required. The 158 + one transaction then multiple transactions are still required. The 159 159 implementation uses a simple loop of word-sized loads for this 160 160 case. The number of transactions is still fewer than would be 161 161 required if bytes were loaded individually.

+1 -1

Documentation/arch/arm64/acpi_object_usage.rst

··· 45 45 46 46 **Arm Performance Monitoring Table** 47 47 48 - This table describes the properties of PMU support implmented by 48 + This table describes the properties of PMU support implemented by 49 49 components in the system. 50 50 51 51 BERT Section 18.3 (signature == "BERT")

+1 -1

Documentation/arch/arm64/arm-acpi.rst

··· 99 99 100 100 When a Linux driver or subsystem is first implemented using ACPI, it by 101 101 definition ends up requiring a specific version of the ACPI specification 102 - -- it's baseline. ACPI firmware must continue to work, even though it may 102 + -- its baseline. ACPI firmware must continue to work, even though it may 103 103 not be optimal, with the earliest kernel version that first provides support 104 104 for that baseline version of ACPI. There may be a need for additional drivers, 105 105 but adding new functionality (e.g., CPU power management) should not break

+2 -2

Documentation/arch/index.rst

··· 13 13 arm/index 14 14 arm64/index 15 15 ia64/index 16 - ../loongarch/index 16 + loongarch/index 17 17 m68k/index 18 - ../mips/index 18 + mips/index 19 19 nios2/index 20 20 openrisc/index 21 21 parisc/index

+2 -2

Documentation/arch/openrisc/openrisc_port.rst

··· 106 106 a much improved version with changes all around. 107 107 108 108 10-04-2004 Matjaz Breskvar (phoenix@bsemi.com) 109 - alot of bugfixes all over. 109 + a lot of bugfixes all over. 110 110 ethernet support, functional http and telnet servers. 111 111 running many standard linux apps. 112 112 ··· 114 114 port to 2.6.x 115 115 116 116 30-11-2004 Matjaz Breskvar (phoenix@bsemi.com) 117 - lots of bugfixes and enhancments. 117 + lots of bugfixes and enhancements. 118 118 added opencores framebuffer driver. 119 119 120 120 09-10-2010 Jonas Bonn (jonas@southpole.se)

+1 -1

Documentation/arch/s390/vfio-ap.rst

··· 422 422 Configuring the AP resources for a KVM guest will be performed when the 423 423 VFIO_GROUP_NOTIFY_SET_KVM notifier callback is invoked. The notifier 424 424 function is called when userspace connects to KVM. The guest's AP resources are 425 - configured via it's APCB by: 425 + configured via its APCB by: 426 426 427 427 * Setting the bits in the APM corresponding to the APIDs assigned to the 428 428 vfio_ap mediated device via its 'assign_adapter' interface.

+1 -1

Documentation/arch/x86/boot.rst

··· 1105 1105 code, nor should it be located in high memory. 1106 1106 1107 1107 1108 - Sample Boot Configuartion 1108 + Sample Boot Configuration 1109 1109 ========================= 1110 1110 1111 1111 As a sample configuration, assume the following layout of the real

+1 -1

Documentation/arch/x86/buslock.rst

··· 32 32 -------------------------------------- 33 33 34 34 Beginning with the Tremont Atom CPU split lock operations may raise an 35 - Alignment Check (#AC) exception when a split lock operation is attemped. 35 + Alignment Check (#AC) exception when a split lock operation is attempted. 36 36 37 37 #DB exception for bus lock detection 38 38 ------------------------------------

+1 -1

Documentation/arch/x86/mds.rst

··· 60 60 data 61 61 62 62 The existence of such a construct in the kernel cannot be excluded with 63 - 100% certainty, but the complexity involved makes it extremly unlikely. 63 + 100% certainty, but the complexity involved makes it extremely unlikely. 64 64 65 65 There is one exception, which is untrusted BPF. The functionality of 66 66 untrusted BPF is limited, but it needs to be thoroughly investigated

+1 -1

Documentation/arch/x86/sgx.rst

··· 245 245 limited. However, while this may be fatal to SGX, the rest of the kernel 246 246 is unlikely to be impacted and should continue to work. 247 247 248 - As a result, when this happpens, user should stop running any new 248 + As a result, when this happens, user should stop running any new 249 249 SGX workloads, (or just any new workloads), and migrate all valuable 250 250 workloads. Although a machine reboot can recover all EPC memory, the bug 251 251 should be reported to Linux developers.

+1 -1

Documentation/arch/xtensa/atomctl.rst

··· 23 23 operations. 24 24 25 25 For systems without an coherent cache controller, non-MX, we always 26 - use the memory controllers RCW, thought non-MX controlers likely 26 + use the memory controllers RCW, though non-MX controllers likely 27 27 support the Internal Operation. 28 28 29 29 CUSTOMER-WARNING:

+1 -1

Documentation/block/data-integrity.rst

··· 209 209 sector must be set, and the bio should have all data pages 210 210 added. It is up to the caller to ensure that the bio does not 211 211 change while I/O is in progress. 212 - Complete bio with error if prepare failed for some reson. 212 + Complete bio with error if prepare failed for some reason. 213 213 214 214 215 215 5.3 Passing Existing Integrity Metadata

+1 -1

Documentation/block/ublk.rst

··· 238 238 request of ``/dev/ublkb*``. 239 239 240 240 UAPI structure of ``ublksrv_io_desc`` is defined for describing each IO from 241 - the driver. A fixed mmaped area (array) on ``/dev/ublkc*`` is provided for 241 + the driver. A fixed mmapped area (array) on ``/dev/ublkc*`` is provided for 242 242 exporting IO info to the server; such as IO offset, length, OP/flags and 243 243 buffer address. Each ``ublksrv_io_desc`` instance can be indexed via queue id 244 244 and IO tag directly.

+1 -1

Documentation/bpf/cpumasks.rst

··· 364 364 ---- 365 365 366 366 Some example usages of these querying kfuncs were shown above. We will not 367 - replicate those exmaples here. Note, however, that all of the aforementioned 367 + replicate those examples here. Note, however, that all of the aforementioned 368 368 kfuncs are tested in `tools/testing/selftests/bpf/progs/cpumask_success.c`_, so 369 369 please take a look there if you're looking for more examples of how they can be 370 370 used.

+1 -1

Documentation/bpf/graph_ds_impl.rst

··· 23 23 24 24 The BPF map API has historically been the main way to expose data structures 25 25 of various types for use within BPF programs. Some data structures fit naturally 26 - with the map API (HASH, ARRAY), others less so. Consequentially, programs 26 + with the map API (HASH, ARRAY), others less so. Consequently, programs 27 27 interacting with the latter group of data structures can be hard to parse 28 28 for kernel programmers without previous BPF experience. 29 29

+1 -1

Documentation/core-api/genericirq.rst

··· 264 264 desc->irq_data.chip->irq_unmask(); 265 265 desc->status &= ~pending; 266 266 handle_irq_event(desc->action); 267 - } while (status & pending); 267 + } while (desc->status & pending); 268 268 desc->status &= ~running; 269 269 270 270

+1 -1

Documentation/devicetree/bindings/timer/ingenic,tcu.yaml

··· 8 8 9 9 description: | 10 10 For a description of the TCU hardware and drivers, have a look at 11 - Documentation/mips/ingenic-tcu.rst. 11 + Documentation/arch/mips/ingenic-tcu.rst. 12 12 13 13 maintainers: 14 14 - Paul Cercueil <paul@crapouillou.net>

+5 -5

Documentation/doc-guide/kernel-doc.rst

··· 151 151 line breaks, so if you try to format some text nicely, as in:: 152 152 153 153 * Return: 154 - * 0 - OK 155 - * -EINVAL - invalid argument 156 - * -ENOMEM - out of memory 154 + * %0 - OK 155 + * %-EINVAL - invalid argument 156 + * %-ENOMEM - out of memory 157 157 158 158 this will all run together and produce:: 159 159 ··· 163 163 ReST list, e. g.:: 164 164 165 165 * Return: 166 - * * 0 - OK to runtime suspend the device 167 - * * -EBUSY - Device should not be runtime suspended 166 + * * %0 - OK to runtime suspend the device 167 + * * %-EBUSY - Device should not be runtime suspended 168 168 169 169 #) If the descriptive text you provide has lines that begin with 170 170 some phrase followed by a colon, each of those phrases will be taken

+18 -9

Documentation/driver-api/basics.rst

··· 15 15 :no-identifiers: pci_device_id 16 16 17 17 18 - Delaying, scheduling, and timer routines 19 - ---------------------------------------- 18 + Delaying and scheduling routines 19 + -------------------------------- 20 20 21 21 .. kernel-doc:: include/linux/sched.h 22 22 :internal: ··· 33 33 .. kernel-doc:: include/linux/completion.h 34 34 :internal: 35 35 36 - .. kernel-doc:: kernel/time/timer.c 37 - :export: 36 + Time and timer routines 37 + ----------------------- 38 38 39 - Wait queues and Wake events 40 - --------------------------- 41 - 42 - .. kernel-doc:: include/linux/wait.h 39 + .. kernel-doc:: include/linux/jiffies.h 43 40 :internal: 44 41 45 - .. kernel-doc:: kernel/sched/wait.c 42 + .. kernel-doc:: kernel/time/time.c 43 + :export: 44 + 45 + .. kernel-doc:: kernel/time/timer.c 46 46 :export: 47 47 48 48 High-resolution timers ··· 55 55 :internal: 56 56 57 57 .. kernel-doc:: kernel/time/hrtimer.c 58 + :export: 59 + 60 + Wait queues and Wake events 61 + --------------------------- 62 + 63 + .. kernel-doc:: include/linux/wait.h 64 + :internal: 65 + 66 + .. kernel-doc:: kernel/sched/wait.c 58 67 :export: 59 68 60 69 Internal Functions

+18

Documentation/driver-api/infrastructure.rst

··· 8 8 :internal: 9 9 :no-identifiers: device_link_state 10 10 11 + .. kernel-doc:: include/linux/device/bus.h 12 + :identifiers: bus_type bus_notifier_event 13 + 14 + .. kernel-doc:: include/linux/device/class.h 15 + :identifiers: class 16 + 17 + .. kernel-doc:: include/linux/device/driver.h 18 + :identifiers: probe_type device_driver 19 + 11 20 Device Drivers Base 12 21 ------------------- 13 22 14 23 .. kernel-doc:: drivers/base/init.c 15 24 :internal: 25 + 26 + .. kernel-doc:: include/linux/device/driver.h 27 + :no-identifiers: probe_type device_driver 16 28 17 29 .. kernel-doc:: drivers/base/driver.c 18 30 :export: ··· 34 22 35 23 .. kernel-doc:: drivers/base/syscore.c 36 24 :export: 25 + 26 + .. kernel-doc:: include/linux/device/class.h 27 + :no-identifiers: class 37 28 38 29 .. kernel-doc:: drivers/base/class.c 39 30 :export: ··· 55 40 56 41 .. kernel-doc:: drivers/base/platform.c 57 42 :export: 43 + 44 + .. kernel-doc:: include/linux/device/bus.h 45 + :no-identifiers: bus_type bus_notifier_event 58 46 59 47 .. kernel-doc:: drivers/base/bus.c 60 48 :export:

+1 -1

Documentation/fault-injection/fault-injection.rst

··· 243 243 Error Injectable Functions 244 244 -------------------------- 245 245 246 - This part is for the kenrel developers considering to add a function to 246 + This part is for the kernel developers considering to add a function to 247 247 ALLOW_ERROR_INJECTION() macro. 248 248 249 249 Requirements for the Error Injectable Functions

+1 -1

Documentation/fb/deferred_io.rst

··· 9 9 10 10 - userspace app like Xfbdev mmaps framebuffer 11 11 - deferred IO and driver sets up fault and page_mkwrite handlers 12 - - userspace app tries to write to mmaped vaddress 12 + - userspace app tries to write to mmapped vaddress 13 13 - we get pagefault and reach fault handler 14 14 - fault handler finds and returns physical page 15 15 - we get page_mkwrite where we add this page to a list

+1 -1

Documentation/fb/sm712fb.rst

··· 31 31 ================ 32 32 (alias TODO list) 33 33 34 - * 2D acceleratrion 34 + * 2D acceleration 35 35 * dual-head support

+1 -1

Documentation/fb/sstfb.rst

··· 73 73 the device will be /dev/fb0. You can check this by doing a 74 74 cat /proc/fb. You can find a copy of con2fb in tools/ directory. 75 75 if you don't have another fb device, this step is superfluous, 76 - as the console subsystem automagicaly binds ttys to the fb. 76 + as the console subsystem automagically binds ttys to the fb. 77 77 #. switch to the virtual console you just mapped. "tadaaa" ... 78 78 79 79 Module removal

+1 -1

Documentation/features/core/thread-info-in-task/arch-support.txt

··· 1 1 # 2 2 # Feature name: thread-info-in-task 3 3 # Kconfig: THREAD_INFO_IN_TASK 4 - # description: arch makes use of the core kernel facility to embedd thread_info in task_struct 4 + # description: arch makes use of the core kernel facility to embed thread_info in task_struct 5 5 # 6 6 ----------------------- 7 7 | arch |status|

+1 -1

Documentation/features/debug/kprobes-on-ftrace/arch-support.txt

··· 13 13 | csky: | ok | 14 14 | hexagon: | TODO | 15 15 | ia64: | TODO | 16 - | loongarch: | TODO | 16 + | loongarch: | ok | 17 17 | m68k: | TODO | 18 18 | microblaze: | TODO | 19 19 | mips: | TODO |

+1 -1

Documentation/features/debug/kprobes/arch-support.txt

··· 13 13 | csky: | ok | 14 14 | hexagon: | TODO | 15 15 | ia64: | ok | 16 - | loongarch: | TODO | 16 + | loongarch: | ok | 17 17 | m68k: | TODO | 18 18 | microblaze: | TODO | 19 19 | mips: | ok |

+1 -1

Documentation/features/debug/kretprobes/arch-support.txt

··· 13 13 | csky: | ok | 14 14 | hexagon: | TODO | 15 15 | ia64: | ok | 16 - | loongarch: | TODO | 16 + | loongarch: | ok | 17 17 | m68k: | TODO | 18 18 | microblaze: | TODO | 19 19 | mips: | ok |

+1 -1

Documentation/features/debug/stackprotector/arch-support.txt

··· 13 13 | csky: | ok | 14 14 | hexagon: | TODO | 15 15 | ia64: | TODO | 16 - | loongarch: | TODO | 16 + | loongarch: | ok | 17 17 | m68k: | TODO | 18 18 | microblaze: | TODO | 19 19 | mips: | ok |

+1 -1

Documentation/features/debug/uprobes/arch-support.txt

··· 13 13 | csky: | ok | 14 14 | hexagon: | TODO | 15 15 | ia64: | TODO | 16 - | loongarch: | TODO | 16 + | loongarch: | ok | 17 17 | m68k: | TODO | 18 18 | microblaze: | TODO | 19 19 | mips: | ok |

+1 -1

Documentation/features/locking/lockdep/arch-support.txt

··· 19 19 | mips: | ok | 20 20 | nios2: | TODO | 21 21 | openrisc: | ok | 22 - | parisc: | TODO | 22 + | parisc: | ok | 23 23 | powerpc: | ok | 24 24 | riscv: | ok | 25 25 | s390: | ok |

+3 -2

Documentation/features/vm/ELF-ASLR/arch-support.txt

··· 1 1 # 2 2 # Feature name: ELF-ASLR 3 3 # Kconfig: ARCH_HAS_ELF_RANDOMIZE 4 + # Kconfig: ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT 4 5 # description: arch randomizes the stack, heap and binary images of ELF binaries 5 6 # 6 7 ----------------------- ··· 11 10 | arc: | TODO | 12 11 | arm: | ok | 13 12 | arm64: | ok | 14 - | csky: | TODO | 13 + | csky: | ok | 15 14 | hexagon: | TODO | 16 15 | ia64: | TODO | 17 - | loongarch: | TODO | 16 + | loongarch: | ok | 18 17 | m68k: | TODO | 19 18 | microblaze: | TODO | 20 19 | mips: | ok |

+1 -1

Documentation/filesystems/9p.rst

··· 79 79 80 80 cache=mode specifies a caching policy. By default, no caches are used. 81 81 The mode can be specified as a bitmask or by using one of the 82 - prexisting common 'shortcuts'. 82 + preexisting common 'shortcuts'. 83 83 The bitmask is described below: (unspecified bits are reserved) 84 84 85 85 ========== ====================================================

+1 -1

Documentation/filesystems/afs.rst

··· 44 44 45 45 CONFIG_AF_RXRPC - The RxRPC protocol transport 46 46 CONFIG_RXKAD - The RxRPC Kerberos security handler 47 - CONFIG_AFS - The AFS filesystem 47 + CONFIG_AFS_FS - The AFS filesystem 48 48 49 49 Additionally, the following can be turned on to aid debugging:: 50 50

+2 -2

Documentation/filesystems/befs.rst

··· 106 106 debug The driver will output debugging information to the syslog. 107 107 ============= =========================================================== 108 108 109 - How to Get Lastest Version 110 - ========================== 109 + How to Get Latest Version 110 + ========================= 111 111 112 112 The latest version is currently available at: 113 113 <http://befs-driver.sourceforge.net/>

+1 -1

Documentation/filesystems/caching/cachefiles.rst

··· 416 416 example). 417 417 418 418 The subjective security holds the active security properties of a process, and 419 - may be overridden. This is not seen externally, and is used whan a process 419 + may be overridden. This is not seen externally, and is used when a process 420 420 acts upon another object, for example SIGKILLing another process or opening a 421 421 file. 422 422

+3 -3

Documentation/filesystems/caching/netfs-api.rst

··· 59 59 60 60 The filesystem then acquires a cookie for each file within that volume using an 61 61 object key. Object keys are binary blobs and only need to be unique within 62 - their parent volume. The cache backend is reponsible for rendering the binary 62 + their parent volume. The cache backend is responsible for rendering the binary 63 63 blob into something it can use and may employ hash tables, trees or whatever to 64 64 improve its ability to find an object. This is transparent to the network 65 65 filesystem. ··· 91 91 Volume Registration 92 92 =================== 93 93 94 - The first step for a network filsystem is to acquire a volume cookie for the 94 + The first step for a network filesystem is to acquire a volume cookie for the 95 95 volume it wants to access:: 96 96 97 97 struct fscache_volume * ··· 119 119 be invalidated. 120 120 121 121 This function can return errors such as EBUSY if the volume key is already in 122 - use by an acquired volume or ENOMEM if an allocation failure occured. It may 122 + use by an acquired volume or ENOMEM if an allocation failure occurred. It may 123 123 also return a NULL volume cookie if fscache is not enabled. It is safe to 124 124 pass a NULL cookie to any function that takes a volume cookie. This will 125 125 cause that function to do nothing.

+1 -1

Documentation/filesystems/configfs.rst

··· 253 253 If binary attribute is readable and the config_item provides a 254 254 ct_item_ops->read_bin_attribute() method, that method will be called 255 255 whenever userspace asks for a read(2) on the attribute. The converse 256 - will happen for write(2). The reads/writes are bufferred so only a 256 + will happen for write(2). The reads/writes are buffered so only a 257 257 single read/write will occur; the attributes' need not concern itself 258 258 with it. 259 259

+1 -1

Documentation/filesystems/dax.rst

··· 291 291 mapped caches such as ARM, MIPS and SPARC. 292 292 293 293 Calling :c:func:`get_user_pages()` on a range of user memory that has been 294 - mmaped from a `DAX` file will fail when there are no 'struct page' to describe 294 + mmapped from a `DAX` file will fail when there are no 'struct page' to describe 295 295 those pages. This problem has been addressed in some device drivers 296 296 by adding optional struct page support for pages under the control of 297 297 the driver (see `CONFIG_NVDIMM_PFN` in ``drivers/nvdimm`` for an example of

+2 -2

Documentation/filesystems/devpts.rst

··· 5 5 ===================== 6 6 7 7 Each mount of the devpts filesystem is now distinct such that ptys 8 - and their indicies allocated in one mount are independent from ptys 9 - and their indicies in all other mounts. 8 + and their indices allocated in one mount are independent from ptys 9 + and their indices in all other mounts. 10 10 11 11 All mounts of the devpts filesystem now create a ``/dev/pts/ptmx`` node 12 12 with permissions ``0000``.

+1 -1

Documentation/filesystems/ext4/super.rst

··· 772 772 * - 0x0010 773 773 - Do not support 32-bit UIDs. (EXT4_DEFM_UID16) 774 774 * - 0x0020 775 - - All data and metadata are commited to the journal. 775 + - All data and metadata are committed to the journal. 776 776 (EXT4_DEFM_JMODE_DATA) 777 777 * - 0x0040 778 778 - All data are flushed to the disk before metadata are committed to the

+3 -3

Documentation/filesystems/f2fs.rst

··· 359 359 ====================== =============== =============== ======== 360 360 mode continue remount-ro panic 361 361 ====================== =============== =============== ======== 362 - access ops normal noraml N/A 362 + access ops normal normal N/A 363 363 syscall errors -EIO -EROFS N/A 364 364 mount option rw ro N/A 365 365 pending dir write keep keep N/A ··· 480 480 481 481 sload.f2fs 482 482 ---------- 483 - The sload.f2fs gives a way to insert files and directories in the exisiting disk 483 + The sload.f2fs gives a way to insert files and directories in the existing disk 484 484 image. This tool is useful when building f2fs images given compiled files. 485 485 486 486 Note: please refer to the manpage of sload.f2fs(8) to get full option list. ··· 792 792 as a method of optimally implementing that function. 793 793 794 794 However, once F2FS receives ioctl(fd, F2FS_IOC_SET_PIN_FILE) in prior to 795 - fallocate(fd, DEFAULT_MODE), it allocates on-disk block addressess having 795 + fallocate(fd, DEFAULT_MODE), it allocates on-disk block addresses having 796 796 zero or random data, which is useful to the below scenario where: 797 797 798 798 1. create(fd)

+1 -1

Documentation/filesystems/gfs2-glocks.rst

··· 78 78 grant for which we ignore remote demote requests. This is in order to 79 79 prevent a situation where locks are being bounced around the cluster 80 80 from node to node with none of the nodes making any progress. This 81 - tends to show up most with shared mmaped files which are being written 81 + tends to show up most with shared mmapped files which are being written 82 82 to by multiple nodes. By delaying the demotion in response to a 83 83 remote callback, that gives the userspace program time to make 84 84 some progress before the pages are unmapped.

+7 -7

Documentation/filesystems/idmappings.rst

··· 36 36 From a mathematical viewpoint ``U`` and ``K`` are well-ordered sets and an 37 37 idmapping is an order isomorphism from ``U`` into ``K``. So ``U`` and ``K`` are 38 38 order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of 39 - the set of all possible ids useable on a given system. 39 + the set of all possible ids usable on a given system. 40 40 41 41 Looking at this mathematically briefly will help us highlight some properties 42 42 that make it easier to understand how we can translate between idmappings. For ··· 47 47 k10002 -> u24 48 48 49 49 Given that we are dealing with order isomorphisms plus the fact that we're 50 - dealing with subsets we can embedd idmappings into each other, i.e. we can 50 + dealing with subsets we can embed idmappings into each other, i.e. we can 51 51 sensibly translate between different idmappings. For example, assume we've been 52 52 given the three idmappings:: 53 53 ··· 60 60 61 61 Because we're dealing with order isomorphic subsets it is meaningful to ask 62 62 what id ``k11000`` corresponds to in the second or third idmapping. The 63 - straightfoward algorithm to use is to apply the inverse of the first idmapping, 63 + straightforward algorithm to use is to apply the inverse of the first idmapping, 64 64 mapping ``k11000`` up to ``u1000``. Afterwards, we can map ``u1000`` down using 65 65 either the second idmapping mapping or third idmapping mapping. The second 66 66 idmapping would map ``u1000`` down to ``21000``. The third idmapping would map ··· 368 368 written to disk. If it can't the kernel will refuse the creation request to not 369 369 even remotely risk filesystem corruption. 370 370 371 - The astute reader will have realized that this is simply a varation of the 371 + The astute reader will have realized that this is simply a variation of the 372 372 crossmapping algorithm we mentioned above in a previous section. First, the 373 373 kernel maps the caller's userspace id down into a kernel id according to the 374 374 caller's idmapping and then maps that kernel id up according to the ··· 466 466 consequences. 467 467 468 468 First, that we can't allow a caller to ultimately write to disk with another 469 - userspace id. We could only do this if we were to mount the whole fileystem 469 + userspace id. We could only do this if we were to mount the whole filesystem 470 470 with the caller's or another idmapping. But that solution is limited to a few 471 471 filesystems and not very flexible. But this is a use-case that is pretty 472 472 important in containerized workloads. ··· 597 597 598 598 In both cases changing ownership recursively has grave implications. The most 599 599 obvious one is that ownership is changed globally and permanently. In the home 600 - directory case this change in ownership would even need to happen everytime the 600 + directory case this change in ownership would even need to happen every time the 601 601 user switches from their home to their work machine. For really large sets of 602 602 files this becomes increasingly costly. 603 603 ··· 670 670 To illustrate why this helper currently exists, consider what happens when we 671 671 change ownership of an inode from an idmapped mount. After we generated 672 672 a ``vfsuid_t`` or ``vfsgid_t`` based on the mount idmapping we later commit to 673 - this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesytem wide ownership. 673 + this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesystem wide ownership. 674 674 Thus, we are turning the ``vfsuid_t`` or ``vfsgid_t`` into a global ``kuid_t`` 675 675 or ``kgid_t``. And this can be done by using ``vfsuid_into_kuid()`` and 676 676 ``vfsgid_into_kgid()``.

-1

Documentation/filesystems/locking.rst

··· 518 518 ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); 519 519 ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); 520 520 int (*iopoll) (struct kiocb *kiocb, bool spin); 521 - int (*iterate) (struct file *, struct dir_context *); 522 521 int (*iterate_shared) (struct file *, struct dir_context *); 523 522 __poll_t (*poll) (struct file *, struct poll_table_struct *); 524 523 long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);

+1 -1

Documentation/filesystems/netfs_library.rst

··· 155 155 an error occurs after calling the helper. 156 156 157 157 The helpers manage the read request, calling back into the network filesystem 158 - through the suppplied table of operations. Waits will be performed as 158 + through the supplied table of operations. Waits will be performed as 159 159 necessary before returning for helpers that are meant to be synchronous. 160 160 161 161 If an error occurs, the ->free_request() will be called to clean up the

+1 -1

Documentation/filesystems/nfs/client-identifier.rst

··· 131 131 the node name by itself is not adequately unique, and can change 132 132 unexpectedly. Problematic situations include: 133 133 134 - - NFS-root (diskless) clients, where the local DCHP server (or 134 + - NFS-root (diskless) clients, where the local DHCP server (or 135 135 equivalent) does not provide a unique host name. 136 136 137 137 - "Containers" within a single Linux host. If each container has

+1 -1

Documentation/filesystems/nfs/rpc-cache.rst

··· 78 78 include taking references to shared objects. 79 79 80 80 void update(struct cache_head \*orig, struct cache_head \*new) 81 - Set the 'content' fileds in 'new' from 'orig'. 81 + Set the 'content' fields in 'new' from 'orig'. 82 82 83 83 int cache_show(struct seq_file \*m, struct cache_detail \*cd, struct cache_head \*h) 84 84 Optional. Used to provide a /proc file that lists the

+1 -1

Documentation/filesystems/nfs/rpc-server-gss.rst

··· 29 29 depends on GSSAPI extensions that are KRB5 specific. 30 30 31 31 GSSAPI is a complex library, and implementing it completely in kernel is 32 - unwarranted. However GSSAPI operations are fundementally separable in 2 32 + unwarranted. However GSSAPI operations are fundamentally separable in 2 33 33 parts: 34 34 35 35 - initial context establishment

+1 -1

Documentation/filesystems/nilfs2.rst

··· 231 231 232 232 233 233 The logs include regular files, directory files, symbolic link files 234 - and several meta data files. The mata data files are the files used 234 + and several meta data files. The meta data files are the files used 235 235 to maintain file system meta data. The current version of NILFS2 uses 236 236 the following meta data files:: 237 237

+1 -1

Documentation/filesystems/ntfs3.rst

··· 112 112 Todo list 113 113 ========= 114 114 - Full journaling support over JBD. Currently journal replaying is supported 115 - which is not necessarily as effectice as JBD would be. 115 + which is not necessarily as effective as JBD would be. 116 116 117 117 References 118 118 ==========

+1 -1

Documentation/filesystems/orangefs.rst

··· 274 274 of kcalloced memory. This memory is used as an array of pointers 275 275 to each of the pages in the IO buffer through a call to get_user_pages. 276 276 * desc_array - a pointer to ``desc_count * (sizeof(struct orangefs_bufmap_desc))`` 277 - bytes of kcalloced memory. This memory is further intialized: 277 + bytes of kcalloced memory. This memory is further initialized: 278 278 279 279 user_desc is the kernel's copy of the IO buffer's ORANGEFS_dev_map_desc 280 280 structure. user_desc->ptr points to the IO buffer.

+2 -2

Documentation/filesystems/overlayfs.rst

··· 195 195 196 196 1. return EXDEV error: this error is returned by rename(2) when trying to 197 197 move a file or directory across filesystem boundaries. Hence 198 - applications are usually prepared to hande this error (mv(1) for example 198 + applications are usually prepared to handle this error (mv(1) for example 199 199 recursively copies the directory tree). This is the default behavior. 200 200 201 201 2. If the "redirect_dir" feature is enabled, then the directory will be ··· 235 235 Redirects are not created and not followed. 236 236 - "redirect_dir=off": 237 237 If "redirect_always_follow" is enabled in the kernel/module config, 238 - this "off" traslates to "follow", otherwise it translates to "nofollow". 238 + this "off" translates to "follow", otherwise it translates to "nofollow". 239 239 240 240 When the NFS export feature is enabled, every copied up directory is 241 241 indexed by the file handle of the lower inode and a file handle of the

+3 -3

Documentation/filesystems/porting.rst

··· 177 177 **mandatory** 178 178 179 179 s_export_op is now required for exporting a filesystem. 180 - isofs, ext2, ext3, resierfs, fat 180 + isofs, ext2, ext3, reiserfs, fat 181 181 can be used as examples of very different filesystems. 182 182 183 183 --- ··· 470 470 **mandatory** 471 471 472 472 If you implement your own ->llseek() you must handle SEEK_HOLE and 473 - SEEK_DATA. You can hanle this by returning -EINVAL, but it would be nicer to 473 + SEEK_DATA. You can handle this by returning -EINVAL, but it would be nicer to 474 474 support it in some way. The generic handler assumes that the entire file is 475 475 data and there is a virtual hole at the end of the file. So if the provided 476 476 offset is less than i_size and SEEK_DATA is specified, return the same offset. ··· 517 517 518 518 ->create() doesn't take ``struct nameidata *``; unlike the previous 519 519 two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that 520 - local filesystems can ignore tha argument - they are guaranteed that the 520 + local filesystems can ignore this argument - they are guaranteed that the 521 521 object doesn't exist. It's remote/distributed ones that might care... 522 522 523 523 ---

+6 -6

Documentation/filesystems/proc.rst

··· 507 507 be lower than the real value due to optimizations used in the current 508 508 implementation. If this is not desirable please file a bug report. 509 509 510 - "AnonHugePages" shows the ammount of memory backed by transparent hugepage. 510 + "AnonHugePages" shows the amount of memory backed by transparent hugepage. 511 511 512 - "ShmemPmdMapped" shows the ammount of shared (shmem/tmpfs) memory backed by 512 + "ShmemPmdMapped" shows the amount of shared (shmem/tmpfs) memory backed by 513 513 huge pages. 514 514 515 - "Shared_Hugetlb" and "Private_Hugetlb" show the ammounts of memory backed by 515 + "Shared_Hugetlb" and "Private_Hugetlb" show the amounts of memory backed by 516 516 hugetlbfs page which is *not* counted in "RSS" or "PSS" field for historical 517 517 reasons. And these are not included in {Shared,Private}_{Clean,Dirty} field. 518 518 ··· 561 561 mm mixed map area 562 562 hg huge page advise flag 563 563 nh no huge page advise flag 564 - mg mergable advise flag 564 + mg mergeable advise flag 565 565 bt arm64 BTI guarded page 566 566 mt arm64 MTE allocation tags are enabled 567 567 um userfaultfd missing tracking ··· 1081 1081 AnonPages 1082 1082 Non-file backed pages mapped into userspace page tables 1083 1083 Mapped 1084 - files which have been mmaped, such as libraries 1084 + files which have been mmapped, such as libraries 1085 1085 Shmem 1086 1086 Total memory used by shared memory (shmem) and tmpfs 1087 1087 KReclaimable ··· 2229 2229 Chapter 5: Filesystem behavior 2230 2230 ============================== 2231 2231 2232 - Originally, before the advent of pid namepsace, procfs was a global file 2232 + Originally, before the advent of pid namespace, procfs was a global file 2233 2233 system. It means that there was only one procfs instance in the system. 2234 2234 2235 2235 When pid namespace was added, a separate procfs instance was mounted in

+1 -1

Documentation/filesystems/qnx6.rst

··· 135 135 136 136 Character and block special devices do not exist in QNX as those files 137 137 are handled by the QNX kernel/drivers and created in /dev independent of the 138 - underlaying filesystem. 138 + underlying filesystem. 139 139 140 140 Long filenames 141 141 --------------

+2 -2

Documentation/filesystems/seq_file.rst

··· 130 130 show() function (described below) to print a header at the top of the 131 131 output. SEQ_START_TOKEN should only be used if the offset is zero, 132 132 however. SEQ_START_TOKEN has no special meaning to the core seq_file 133 - code. It is provided as a convenience for a start() funciton to 133 + code. It is provided as a convenience for a start() function to 134 134 communicate with the next() and show() functions. 135 135 136 136 The next function to implement is called, amazingly, next(); its job is to ··· 217 217 is a reasonable thing to do. The seq_file code will also avoid taking any 218 218 other locks while the iterator is active. 219 219 220 - The iterater value returned by start() or next() is guaranteed to be 220 + The iterator value returned by start() or next() is guaranteed to be 221 221 passed to a subsequent next() or stop() call. This allows resources 222 222 such as locks that were taken to be reliably released. There is *no* 223 223 guarantee that the iterator will be passed to show(), though in practice

+1 -1

Documentation/filesystems/ubifs-authentication.rst

··· 130 130 Journal 131 131 ~~~~~~~ 132 132 133 - To avoid wearing out the flash, the index is only persisted (*commited*) when 133 + To avoid wearing out the flash, the index is only persisted (*committed*) when 134 134 certain conditions are met (eg. ``fsync(2)``). The journal is used to record 135 135 any changes (in form of inode nodes, data nodes etc.) between commits 136 136 of the index. During mount, the journal is read from the flash and replayed

+1 -1

Documentation/filesystems/vfat.rst

··· 50 50 Normally utime(2) checks current process is owner of 51 51 the file, or it has CAP_FOWNER capability. But FAT 52 52 filesystem doesn't have uid/gid on disk, so normal 53 - check is too unflexible. With this option you can 53 + check is too inflexible. With this option you can 54 54 relax it. 55 55 56 56 **codepage=###**

+2 -7

Documentation/filesystems/vfs.rst

··· 767 767 a file sync request is made. After an error has been reported on one 768 768 request, subsequent requests on the same file descriptor should return 769 769 0, unless further writeback errors have occurred since the previous file 770 - syncronization. 770 + synchronization. 771 771 772 772 Ideally, the kernel would report errors only on file descriptions on 773 773 which writes were done that subsequently failed to be written back. The ··· 1080 1080 ssize_t (*read_iter) (struct kiocb *, struct iov_iter *); 1081 1081 ssize_t (*write_iter) (struct kiocb *, struct iov_iter *); 1082 1082 int (*iopoll)(struct kiocb *kiocb, bool spin); 1083 - int (*iterate) (struct file *, struct dir_context *); 1084 1083 int (*iterate_shared) (struct file *, struct dir_context *); 1085 1084 __poll_t (*poll) (struct file *, struct poll_table_struct *); 1086 1085 long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); ··· 1131 1132 ``iopoll`` 1132 1133 called when aio wants to poll for completions on HIPRI iocbs 1133 1134 1134 - ``iterate`` 1135 - called when the VFS needs to read the directory contents 1136 - 1137 1135 ``iterate_shared`` 1138 - called when the VFS needs to read the directory contents when 1139 - filesystem supports concurrent dir iterators 1136 + called when the VFS needs to read the directory contents 1140 1137 1141 1138 ``poll`` 1142 1139 called by the VFS when a process wants to check if there is

+10 -10

Documentation/filesystems/xfs-online-fsck-design.rst

··· 293 293 Before starting repairs, the summary counters are checked and any necessary 294 294 repairs are performed so that subsequent repairs will not fail the resource 295 295 reservation step due to wildly incorrect summary counters. 296 - Unsuccesful repairs are requeued as long as forward progress on repairs is 296 + Unsuccessful repairs are requeued as long as forward progress on repairs is 297 297 made somewhere in the filesystem. 298 298 Free space in the filesystem is trimmed at the end of phase 4 if the 299 299 filesystem is clean. ··· 542 542 543 543 Inspiration for quota and file link count repair strategies were drawn from 544 544 sections 2.12 ("Online Index Operations") through 2.14 ("Incremental View 545 - Maintenace") of G. Graefe, `"Concurrent Queries and Updates in Summary Views 545 + Maintenance") of G. Graefe, `"Concurrent Queries and Updates in Summary Views 546 546 and Their Indexes" 547 547 <http://www.odbms.org/wp-content/uploads/2014/06/Increment-locks.pdf>`_, 2011. 548 548 ··· 605 605 The cron job does not have this protection. 606 606 607 607 - **Fuzz Kiddiez**: There are many people now who seem to think that running 608 - automated fuzz testing of ondisk artifacts to find mischevious behavior and 608 + automated fuzz testing of ondisk artifacts to find mischievous behavior and 609 609 spraying exploit code onto the public mailing list for instant zero-day 610 610 disclosure is somehow of some social benefit. 611 611 In the view of this author, the benefit is realized only when the fuzz ··· 1351 1351 rooted at block 0) is created to map hashes of the attribute names to leaf 1352 1352 blocks in the attr fork. 1353 1353 1354 - Checking an extended attribute structure is not so straightfoward due to the 1354 + Checking an extended attribute structure is not so straightforward due to the 1355 1355 lack of separation between attr blocks and index blocks. 1356 1356 Scrub must read each block mapped by the attr fork and ignore the non-leaf 1357 1357 blocks: ··· 1401 1401 beyond one block, then a dabtree is used to map hashes of dirent names to 1402 1402 directory data blocks. 1403 1403 1404 - Checking a directory is pretty straightfoward: 1404 + Checking a directory is pretty straightforward: 1405 1405 1406 1406 1. Walk the dabtree in the second partition (if present) to ensure that there 1407 1407 are no irregularities in the blocks or dabtree mappings that do not point to ··· 1524 1524 should be relatively rare as compared to filesystem change operations. 1525 1525 Online fsck coordinates with transaction chains as follows: 1526 1526 1527 - * For each AG, maintain a count of intent items targetting that AG. 1527 + * For each AG, maintain a count of intent items targeting that AG. 1528 1528 The count should be bumped whenever a new item is added to the chain. 1529 1529 The count should be dropped when the filesystem has locked the AG header 1530 1530 buffers and finished the work. ··· 2102 2102 kernel. 2103 2103 To sort records in a reasonably short amount of time, ``xfarray`` takes 2104 2104 advantage of the binary subpartitioning offered by quicksort, but it also uses 2105 - heapsort to hedge aginst performance collapse if the chosen quicksort pivots 2105 + heapsort to hedge against performance collapse if the chosen quicksort pivots 2106 2106 are poor. 2107 2107 Both algorithms are (in general) O(n * lg(n)), but there is a wide performance 2108 2108 gulf between the two implementations. ··· 2566 2566 The transaction rolling in steps 2c and 3 represent a weakness in the repair 2567 2567 algorithm, because a log flush and a crash before the end of the reap step can 2568 2568 result in space leaking. 2569 - Online repair functions minimize the chances of this occuring by using very 2570 - large transactions, which each can accomodate many thousands of block freeing 2569 + Online repair functions minimize the chances of this occurring by using very 2570 + large transactions, which each can accommodate many thousands of block freeing 2571 2571 instructions. 2572 2572 Repair moves on to reaping the old blocks, which will be presented in a 2573 2573 subsequent :ref:`section<reaping>` after a few case studies of bulk loading. ··· 5090 5090 counters) as phase 6. 5091 5091 The scan starts by calling ``FS_IOC_GETFSMAP`` to scan the filesystem space map 5092 5092 to find areas that are allocated to file data fork extents. 5093 - Gaps betweeen data fork extents that are smaller than 64k are treated as if 5093 + Gaps between data fork extents that are smaller than 64k are treated as if 5094 5094 they were data fork extents to reduce the command setup overhead. 5095 5095 When the space map scan accumulates a region larger than 32MB, a media 5096 5096 verification request is sent to the disk as a directio read of the raw block

+1 -1

Documentation/filesystems/zonefs.rst

··· 378 378 sequential zone files. Failure to do so can result in write errors. 379 379 * **max_active_seq_files**: This attribute reports the maximum number of 380 380 sequential zone files that are in an active state, that is, sequential zone 381 - files that are partially writen (not empty nor full) or that have a zone that 381 + files that are partially written (not empty nor full) or that have a zone that 382 382 is explicitly open (which happens only if the *explicit-open* mount option is 383 383 used). This number is always equal to the maximum number of active zones that 384 384 the device supports. A value of 0 means that the mounted device has no limit

+1 -1

Documentation/firmware-guide/acpi/osi.rst

··· 55 55 56 56 However this was discovered to be abused by other BIOS vendors to change 57 57 completely unrelated code on completely unrelated systems. This prompted 58 - an evaluation of all of it's uses. This uncovered that they aren't needed 58 + an evaluation of all of its uses. This uncovered that they aren't needed 59 59 for any of the original reasons. As such, the kernel will not respond to 60 60 any custom Linux-* strings by default. 61 61

+1 -1

Documentation/gpu/amdgpu/display/mpo-overview.rst

··· 178 178 179 179 AMDGPU supports display MPO when using multiple displays; however, this feature 180 180 behavior heavily relies on the compositor implementation. Keep in mind that 181 - usespace can define different policies. For example, some OSes can use MPO to 181 + userspace can define different policies. For example, some OSes can use MPO to 182 182 protect the plane that handles the video playback; notice that we don't have 183 183 many limitations for a single display. Nonetheless, this manipulation can have 184 184 many more restrictions for a multi-display scenario. The below example shows a

+1 -1

Documentation/gpu/drm-kms-helpers.rst

··· 378 378 HDMI Infoframes Helper Reference 379 379 ================================ 380 380 381 - Strictly speaking this is not a DRM helper library but generally useable 381 + Strictly speaking this is not a DRM helper library but generally usable 382 382 by any driver interfacing with HDMI outputs like v4l or alsa drivers. 383 383 But it nicely fits into the overall topic of mode setting helper 384 384 libraries and hence is also included here.

+3 -3

Documentation/gpu/drm-kms.rst

··· 66 66 For the output routing the first step is encoders (represented by 67 67 :c:type:`struct drm_encoder <drm_encoder>`, see `Encoder Abstraction`_). Those 68 68 are really just internal artifacts of the helper libraries used to implement KMS 69 - drivers. Besides that they make it unecessarily more complicated for userspace 69 + drivers. Besides that they make it unnecessarily more complicated for userspace 70 70 to figure out which connections between a CRTC and a connector are possible, and 71 71 what kind of cloning is supported, they serve no purpose in the userspace API. 72 72 Unfortunately encoders have been exposed to userspace, hence can't remove them 73 - at this point. Futhermore the exposed restrictions are often wrongly set by 73 + at this point. Furthermore the exposed restrictions are often wrongly set by 74 74 drivers, and in many cases not powerful enough to express the real restrictions. 75 75 A CRTC can be connected to multiple encoders, and for an active CRTC there must 76 76 be at least one encoder. ··· 260 260 drm_crtc_state <drm_crtc_state>` for CRTCs and :c:type:`struct 261 261 drm_connector_state <drm_connector_state>` for connectors. These are the only 262 262 objects with userspace-visible and settable state. For internal state drivers 263 - can subclass these structures through embeddeding, or add entirely new state 263 + can subclass these structures through embedding, or add entirely new state 264 264 structures for their globally shared hardware functions, see :c:type:`struct 265 265 drm_private_state<drm_private_state>`. 266 266

+2 -2

Documentation/gpu/drm-usage-stats.rst

··· 8 8 `fops->show_fdinfo()` as part of the driver specific file operations registered 9 9 in the `struct drm_driver` object registered with the DRM core. 10 10 11 - One purpose of this output is to enable writing as generic as practicaly 11 + One purpose of this output is to enable writing as generic as practically 12 12 feasible `top(1)` like userspace monitoring tools. 13 13 14 14 Given the differences between various DRM drivers the specification of the ··· 119 119 engine. Taken together with drm-cycles-<keystr>, this can be used to calculate 120 120 percentage utilization of the engine, whereas drm-engine-<keystr> only reflects 121 121 time active without considering what frequency the engine is operating as a 122 - percentage of it's maximum frequency. 122 + percentage of its maximum frequency. 123 123 124 124 Memory 125 125 ^^^^^^

+2 -2

Documentation/gpu/i915.rst

··· 304 304 and the only way to synchronize across contexts (even from the same 305 305 file descriptor) is through the use of fences. At least as far back as 306 306 Gen4, also have that a context carries with it a GPU HW context; 307 - the HW context is essentially (most of atleast) the state of a GPU. 307 + the HW context is essentially (most of at least) the state of a GPU. 308 308 In addition to the ordering guarantees, the kernel will restore GPU 309 309 state via HW context when commands are issued to a context, this saves 310 - user space the need to restore (most of atleast) the GPU state at the 310 + user space the need to restore (most of at least) the GPU state at the 311 311 start of each batchbuffer. The non-deprecated ioctls to submit batchbuffer 312 312 work can pass that ID (in the lower bits of drm_i915_gem_execbuffer2::rsvd1) 313 313 to identify what context to use with the command.

+1 -1

Documentation/gpu/kms-properties.csv

··· 17 17 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an X offset for a connector 18 18 ,,“suggested Y”,RANGE,"Min=0, Max=0xffffffff",Connector,property to suggest an Y offset for a connector 19 19 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" }",Connector,TDB 20 - i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normaly in the range 0..1.0 are remapped to the range 16/255..235/255." 20 + i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is set, the hardware will be programmed with the result of the multiplication of CTM by the limited range matrix to ensure the pixels normally in the range 0..1.0 are remapped to the range 16/255..235/255." 21 21 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD 22 22 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } etc.",Connector,TBD 23 23 ,,"""left_margin""",RANGE,"Min=0, Max= SDVO dependent",Connector,TBD

+2 -2

Documentation/gpu/komeda-kms.rst

··· 328 328 achieve this, split the komeda device into two layers: CORE and CHIP. 329 329 330 330 - CORE: for common features and capabilities handling. 331 - - CHIP: for register programing and HW specific feature (limitation) handling. 331 + - CHIP: for register programming and HW specific feature (limitation) handling. 332 332 333 333 CORE can access CHIP by three chip function structures: 334 334 ··· 481 481 Now we have two level devices: 482 482 483 483 - komeda_dev: describes the real display hardware. 484 - - komeda_kms_dev: attachs or connects komeda_dev to DRM-KMS. 484 + - komeda_kms_dev: attaches or connects komeda_dev to DRM-KMS. 485 485 486 486 All komeda operations are supplied or operated by komeda_dev or komeda_kms_dev, 487 487 the module driver is only a simple wrapper to pass the Linux command

+1 -1

Documentation/gpu/msm-crash-dump.rst

··· 23 23 The module that generated the crashdump. 24 24 25 25 time 26 - The kernel time at crash formated as seconds.microseconds. 26 + The kernel time at crash formatted as seconds.microseconds. 27 27 28 28 comm 29 29 Comm string for the binary that generated the fault.

+1 -1

Documentation/gpu/rfc/i915_scheduler.rst

··· 37 37 * Watchdog hooks into DRM scheduler 38 38 * Lots of complexity of the GuC backend can be pulled out once 39 39 integrated with DRM scheduler (e.g. state machine gets 40 - simplier, locking gets simplier, etc...) 40 + simpler, locking gets simpler, etc...) 41 41 * Execlists backend will minimum required to hook in the DRM scheduler 42 42 * Legacy interface 43 43 * Features like timeslicing / preemption / virtual engines would

+1 -1

Documentation/gpu/rfc/i915_vm_bind.rst

··· 90 90 path (where required mappings are already bound) submission latency is O(1) 91 91 w.r.t the number of VM private BOs. 92 92 93 - VM_BIND locking hirarchy 93 + VM_BIND locking hierarchy 94 94 ------------------------- 95 95 The locking design here supports the older (execlist based) execbuf mode, the 96 96 newer VM_BIND mode, the VM_BIND mode with GPU page faults and possible future

+4 -4

Documentation/gpu/todo.rst

··· 69 69 --------------------------------------------------------- 70 70 71 71 We have a helper to get this right with drm_plane_helper_check_update(), but 72 - it's not consistently used. This should be fixed, preferrably in the atomic 72 + it's not consistently used. This should be fixed, preferably in the atomic 73 73 helpers (and drivers then moved over to clipped coordinates). Probably the 74 74 helper should also be moved from drm_plane_helper.c to the atomic helpers, to 75 75 avoid confusion - the other helpers in that file are all deprecated legacy ··· 185 185 186 186 To solve this we need one standard per-object locking mechanism, which is 187 187 dma_resv_lock(). This lock needs to be called as the outermost lock, with all 188 - other driver specific per-object locks removed. The problem is tha rolling out 188 + other driver specific per-object locks removed. The problem is that rolling out 189 189 the actual change to the locking contract is a flag day, due to struct dma_buf 190 190 buffer sharing. 191 191 192 192 Level: Expert 193 193 194 - Convert logging to drm_* functions with drm_device paramater 194 + Convert logging to drm_* functions with drm_device parameter 195 195 ------------------------------------------------------------ 196 196 197 197 For drivers which could have multiple instances, it is necessary to ··· 248 248 Benchmark and optimize blitting and format-conversion function 249 249 -------------------------------------------------------------- 250 250 251 - Drawing to dispay memory quickly is crucial for many applications' 251 + Drawing to display memory quickly is crucial for many applications' 252 252 performance. 253 253 254 254 On at least x86-64, sys_imageblit() is significantly slower than

+1 -1

Documentation/hwmon/pmbus-core.rst

··· 345 345 346 346 Some PMBus chips don't respond with valid data when reading the CAPABILITY 347 347 register. For such chips, this flag should be set so that the PMBus core 348 - driver doesn't use CAPABILITY to determine it's behavior. 348 + driver doesn't use CAPABILITY to determine its behavior. 349 349 350 350 PMBUS_READ_STATUS_AFTER_FAILED_CHECK 351 351

+1 -1

Documentation/input/devices/iforce-protocol.rst

··· 49 49 == ==== 50 50 51 51 The 2B, LEN and CS fields have disappeared, probably because USB handles 52 - frames and data corruption is handled or unsignificant. 52 + frames and data corruption is handled or insignificant. 53 53 54 54 First, I describe effects that are sent by the device to the computer 55 55

+3 -4

Documentation/input/devices/pxrc.rst

··· 5 5 :Author: Marcus Folkesson <marcus.folkesson@gmail.com> 6 6 7 7 This driver let you use your own RC controller plugged into the 8 - adapter that comes with PhoenixRC [1]_ or other compatible adapters. 8 + adapter that comes with PhoenixRC or other compatible adapters. 9 9 10 10 The adapter supports 7 analog channels and 1 digital input switch. 11 11 ··· 41 41 ============== 42 42 43 43 To test this driver's functionality you may use `input-event` which is part of 44 - the `input layer utilities` suite [2]_. 44 + the `input layer utilities` suite [1]_. 45 45 46 46 For example:: 47 47 ··· 53 53 References 54 54 ========== 55 55 56 - .. [1] http://www.phoenix-sim.com/ 57 - .. [2] https://www.kraxel.org/cgit/input/ 56 + .. [1] https://www.kraxel.org/cgit/input/

+1 -1

Documentation/input/multi-touch-protocol.rst

··· 383 383 --------------- 384 384 385 385 The process of finger tracking, i.e., to assign a unique trackingID to each 386 - initiated contact on the surface, is a Euclidian Bipartite Matching 386 + initiated contact on the surface, is a Euclidean Bipartite Matching 387 387 problem. At each event synchronization, the set of actual contacts is 388 388 matched to the set of contacts from the previous synchronization. A full 389 389 implementation can be found in [#f3]_.

+2

Documentation/kbuild/kconfig.rst

··· 10 10 programs also have embedded help text. Be sure to check that for 11 11 navigation, search, and other general help text. 12 12 13 + The gconfig ('gconf') program has limited help text. 14 + 13 15 General 14 16 ------- 15 17

+1 -1

Documentation/livepatch/reliable-stacktrace.rst

··· 40 40 .. note:: 41 41 In some cases it is legitimate to omit specific functions from the trace, 42 42 but all other functions must be reported. These cases are described in 43 - futher detail below. 43 + further detail below. 44 44 45 45 Secondly, the reliable stacktrace function must be robust to cases where 46 46 the stack or other unwind state is corrupt or otherwise unreliable. The

+2 -2

Documentation/locking/lockdep-design.rst

··· 29 29 A lock-class's behavior is constructed by its instances collectively: 30 30 when the first instance of a lock-class is used after bootup the class 31 31 gets registered, then all (subsequent) instances will be mapped to the 32 - class and hence their usages and dependecies will contribute to those of 32 + class and hence their usages and dependencies will contribute to those of 33 33 the class. A lock-class does not go away when a lock instance does, but 34 34 it can be removed if the memory space of the lock class (static or 35 35 dynamic) is reclaimed, this happens for example when a module is ··· 105 105 +--------------+-------------+--------------+ 106 106 107 107 The character '-' suggests irq is disabled because if otherwise the 108 - charactor '?' would have been shown instead. Similar deduction can be 108 + character '?' would have been shown instead. Similar deduction can be 109 109 applied for '+' too. 110 110 111 111 Unused locks (e.g., mutexes) cannot be part of the cause of an error.

+1 -1

Documentation/locking/locktorture.rst

··· 113 113 without pausing. 114 114 115 115 shuffle_interval 116 - The number of seconds to keep the test threads affinitied 116 + The number of seconds to keep the test threads affinitized 117 117 to a particular subset of the CPUs, defaults to 3 seconds. 118 118 Used in conjunction with test_no_idle_hz. 119 119

+1 -1

Documentation/locking/locktypes.rst

··· 500 500 Some bit spinlocks are replaced with regular spinlock_t for PREEMPT_RT 501 501 using conditional (#ifdef'ed) code changes at the usage site. In contrast, 502 502 usage-site changes are not needed for the spinlock_t substitution. 503 - Instead, conditionals in header files and the core locking implemementation 503 + Instead, conditionals in header files and the core locking implementation 504 504 enable the compiler to do the substitution transparently. 505 505 506 506

Documentation/loongarch/booting.rst Documentation/arch/loongarch/booting.rst

Documentation/loongarch/features.rst Documentation/arch/loongarch/features.rst

Documentation/loongarch/index.rst Documentation/arch/loongarch/index.rst

Documentation/loongarch/introduction.rst Documentation/arch/loongarch/introduction.rst

Documentation/loongarch/irq-chip-model.rst Documentation/arch/loongarch/irq-chip-model.rst

+15 -21

Documentation/maintainer/configure-git.rst

··· 1 - .. _configuregit: 2 - 3 - Configure Git 4 - ============= 1 + Configuring Git 2 + =============== 5 3 6 4 This chapter describes maintainer level git configuration. 7 5 8 - Tagged branches used in :ref:`Documentation/maintainer/pull-requests.rst 9 - <pullrequests>` should be signed with the developers public GPG key. Signed 10 - tags can be created by passing the ``-u`` flag to ``git tag``. However, 11 - since you would *usually* use the same key for the same project, you can 12 - set it once with 13 - :: 6 + Tagged branches used in pull requests (see 7 + Documentation/maintainer/pull-requests.rst) should be signed with the 8 + developers public GPG key. Signed tags can be created by passing 9 + ``-u <key-id>`` to ``git tag``. However, since you would *usually* use the same 10 + key for the project, you can set it in the configuration and use the ``-s`` 11 + flag. To set the default ``key-id`` use:: 14 12 15 13 git config user.signingkey "keyname" 16 14 17 - Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by hand: 18 - :: 15 + Alternatively, edit your ``.git/config`` or ``~/.gitconfig`` file by hand:: 19 16 20 17 [user] 21 18 name = Jane Developer 22 19 email = jd@domain.org 23 20 signingkey = jd@domain.org 24 21 25 - You may need to tell ``git`` to use ``gpg2`` 26 - :: 22 + You may need to tell ``git`` to use ``gpg2``:: 27 23 28 24 [gpg] 29 25 program = /path/to/gpg2 30 26 31 - You may also like to tell ``gpg`` which ``tty`` to use (add to your shell rc file) 32 - :: 27 + You may also like to tell ``gpg`` which ``tty`` to use (add to your shell 28 + rc file):: 33 29 34 30 export GPG_TTY=$(tty) 35 31 ··· 33 37 Creating commit links to lore.kernel.org 34 38 ---------------------------------------- 35 39 36 - The web site http://lore.kernel.org is meant as a grand archive of all mail 40 + The web site https://lore.kernel.org is meant as a grand archive of all mail 37 41 list traffic concerning or influencing the kernel development. Storing archives 38 42 of patches here is a recommended practice, and when a maintainer applies a 39 43 patch to a subsystem tree, it is a good idea to provide a Link: tag with a 40 44 reference back to the lore archive so that people that browse the commit 41 45 history can find related discussions and rationale behind a certain change. 42 - The link tag will look like this: 46 + The link tag will look like this:: 43 47 44 48 Link: https://lore.kernel.org/r/<message-id> 45 49 46 50 This can be configured to happen automatically any time you issue ``git am`` 47 - by adding the following hook into your git: 48 - 49 - .. code-block:: none 51 + by adding the following hook into your git:: 50 52 51 53 $ git config am.messageid true 52 54 $ cat >.git/hooks/applypatch-msg <<'EOF'

+155

Documentation/maintainer/feature-and-driver-maintainers.rst

··· 1 + .. SPDX-License-Identifier: GPL-2.0 2 + 3 + ============================== 4 + Feature and driver maintainers 5 + ============================== 6 + 7 + The term "maintainer" spans a very wide range of levels of engagement 8 + from people handling patches and pull requests as almost a full time job 9 + to people responsible for a small feature or a driver. 10 + 11 + Unlike most of the chapter, this section is meant for the latter (more 12 + populous) group. It provides tips and describes the expectations and 13 + responsibilities of maintainers of a small(ish) section of the code. 14 + 15 + Drivers and alike most often do not have their own mailing lists and 16 + git trees but instead send and review patches on the list of a larger 17 + subsystem. 18 + 19 + Responsibilities 20 + ================ 21 + 22 + The amount of maintenance work is usually proportional to the size 23 + and popularity of the code base. Small features and drivers should 24 + require relatively small amount of care and feeding. Nonetheless 25 + when the work does arrive (in form of patches which need review, 26 + user bug reports etc.) it has to be acted upon promptly. 27 + Even when a particular driver only sees one patch a month, or a quarter, 28 + a subsystem could well have a hundred such drivers. Subsystem 29 + maintainers cannot afford to wait a long time to hear from reviewers. 30 + 31 + The exact expectations on the response time will vary by subsystem. 32 + The patch review SLA the subsystem had set for itself can sometimes 33 + be found in the subsystem documentation. Failing that as a rule of thumb 34 + reviewers should try to respond quicker than what is the usual patch 35 + review delay of the subsystem maintainer. The resulting expectations 36 + may range from two working days for fast-paced subsystems (e.g. networking) 37 + to as long as a few weeks in slower moving parts of the kernel. 38 + 39 + Mailing list participation 40 + -------------------------- 41 + 42 + Linux kernel uses mailing lists as the primary form of communication. 43 + Maintainers must be subscribed and follow the appropriate subsystem-wide 44 + mailing list. Either by subscribing to the whole list or using more 45 + modern, selective setup like 46 + `lei <https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started>`_. 47 + 48 + Maintainers must know how to communicate on the list (plain text, no invasive 49 + legal footers, no top posting, etc.) 50 + 51 + Reviews 52 + ------- 53 + 54 + Maintainers must review *all* patches touching exclusively their drivers, 55 + no matter how trivial. If the patch is a tree wide change and modifies 56 + multiple drivers - whether to provide a review is left to the maintainer. 57 + 58 + When there are multiple maintainers for a piece of code an ``Acked-by`` 59 + or ``Reviewed-by`` tag (or review comments) from a single maintainer is 60 + enough to satisfy this requirement. 61 + 62 + If the review process or validation for a particular change will take longer 63 + than the expected review timeline for the subsystem, maintainer should 64 + reply to the submission indicating that the work is being done, and when 65 + to expect full results. 66 + 67 + Refactoring and core changes 68 + ---------------------------- 69 + 70 + Occasionally core code needs to be changed to improve the maintainability 71 + of the kernel as a whole. Maintainers are expected to be present and 72 + help guide and test changes to their code to fit the new infrastructure. 73 + 74 + Bug reports 75 + ----------- 76 + 77 + Maintainers must ensure severe problems in their code reported to them 78 + are resolved in a timely manner: regressions, kernel crashes, kernel warnings, 79 + compilation errors, lockups, data loss, and other bugs of similar scope. 80 + 81 + Maintainers furthermore should respond to reports about other kinds of 82 + bugs as well, if the report is of reasonable quality or indicates a 83 + problem that might be severe -- especially if they have *Supported* 84 + status of the codebase in the MAINTAINERS file. 85 + 86 + Selecting the maintainer 87 + ======================== 88 + 89 + The previous section described the expectations of the maintainer, 90 + this section provides guidance on selecting one and describes common 91 + misconceptions. 92 + 93 + The author 94 + ---------- 95 + 96 + Most natural and common choice of a maintainer is the author of the code. 97 + The author is intimately familiar with the code, so it is the best person 98 + to take care of it on an ongoing basis. 99 + 100 + That said, being a maintainer is an active role. The MAINTAINERS file 101 + is not a list of credits (in fact a separate CREDITS file exists), 102 + it is a list of those who will actively help with the code. 103 + If the author does not have the time, interest or ability to maintain 104 + the code, a different maintainer must be selected. 105 + 106 + Multiple maintainers 107 + -------------------- 108 + 109 + Modern best practices dictate that there should be at least two maintainers 110 + for any piece of code, no matter how trivial. It spreads the burden, helps 111 + people take vacations and prevents burnout, trains new members of 112 + the community etc. etc. Even when there is clearly one perfect candidate, 113 + another maintainer should be found. 114 + 115 + Maintainers must be human, therefore, it is not acceptable to add a mailing 116 + list or a group email as a maintainer. Trust and understanding are the 117 + foundation of kernel maintenance and one cannot build trust with a mailing 118 + list. Having a mailing list *in addition* to humans is perfectly fine. 119 + 120 + Corporate structures 121 + -------------------- 122 + 123 + To an outsider the Linux kernel may resemble a hierarchical organization 124 + with Linus as the CEO. While the code flows in a hierarchical fashion, 125 + the corporate template does not apply here. Linux is an anarchy held 126 + together by (rarely expressed) mutual respect, trust and convenience. 127 + 128 + All that is to say that managers almost never make good maintainers. 129 + The maintainer position more closely matches an on-call rotation 130 + than a position of power. 131 + 132 + The following characteristics of a person selected as a maintainer 133 + are clear red flags: 134 + 135 + - unknown to the community, never sent an email to the list before 136 + - did not author any of the code 137 + - (when development is contracted) works for a company which paid 138 + for the development rather than the company which did the work 139 + 140 + Non compliance 141 + ============== 142 + 143 + Subsystem maintainers may remove inactive maintainers from the MAINTAINERS 144 + file. If the maintainer was a significant author or played an important 145 + role in the development of the code, they should be moved to the CREDITS file. 146 + 147 + Removing an inactive maintainer should not be seen as a punitive action. 148 + Having an inactive maintainer has a real cost as all developers have 149 + to remember to include the maintainers in discussions and subsystem 150 + maintainers spend brain power figuring out how to solicit feedback. 151 + 152 + Subsystem maintainers may remove code for lacking maintenance. 153 + 154 + Subsystem maintainers may refuse accepting code from companies 155 + which repeatedly neglected their maintainership duties.

+1

Documentation/maintainer/index.rst

··· 9 9 .. toctree:: 10 10 :maxdepth: 2 11 11 12 + feature-and-driver-maintainers 12 13 configure-git 13 14 rebasing-and-merging 14 15 pull-requests

+1 -3

Documentation/maintainer/pull-requests.rst

··· 1 - .. _pullrequests: 2 - 3 1 Creating Pull Requests 4 2 ====================== 5 3 ··· 39 41 40 42 that will create a signed tag called ``char-misc-4.15-rc1`` based on the 41 43 last commit in the ``char-misc-next`` branch, and sign it with your gpg key 42 - (see :ref:`Documentation/maintainer/configure-git.rst <configuregit>`). 44 + (see Documentation/maintainer/configure-git.rst). 43 45 44 46 Linus will only accept pull requests based on a signed tag. Other 45 47 maintainers may differ.

Documentation/mips/booting.rst Documentation/arch/mips/booting.rst

Documentation/mips/features.rst Documentation/arch/mips/features.rst

Documentation/mips/index.rst Documentation/arch/mips/index.rst

Documentation/mips/ingenic-tcu.rst Documentation/arch/mips/ingenic-tcu.rst

+14 -11

Documentation/mm/highmem.rst

··· 51 51 The kernel contains several ways of creating temporary mappings. The following 52 52 list shows them in order of preference of use. 53 53 54 - * kmap_local_page(). This function is used to require short term mappings. 55 - It can be invoked from any context (including interrupts) but the mappings 56 - can only be used in the context which acquired them. 54 + * kmap_local_page(), kmap_local_folio() - These functions are used to create 55 + short term mappings. They can be invoked from any context (including 56 + interrupts) but the mappings can only be used in the context which acquired 57 + them. The only differences between them consist in the first taking a pointer 58 + to a struct page and the second taking a pointer to struct folio and the byte 59 + offset within the folio which identifies the page. 57 60 58 - This function should always be used, whereas kmap_atomic() and kmap() have 61 + These functions should always be used, whereas kmap_atomic() and kmap() have 59 62 been deprecated. 60 63 61 64 These mappings are thread-local and CPU-local, meaning that the mapping ··· 75 72 maps of the outgoing task are saved and those of the incoming one are 76 73 restored. 77 74 78 - kmap_local_page() always returns a valid virtual address and it is assumed 79 - that kunmap_local() will never fail. 75 + kmap_local_page(), as well as kmap_local_folio() always returns valid virtual 76 + kernel addresses and it is assumed that kunmap_local() will never fail. 80 77 81 - On CONFIG_HIGHMEM=n kernels and for low memory pages this returns the 78 + On CONFIG_HIGHMEM=n kernels and for low memory pages they return the 82 79 virtual address of the direct mapping. Only real highmem pages are 83 80 temporarily mapped. Therefore, users may call a plain page_address() 84 81 for pages which are known to not come from ZONE_HIGHMEM. However, it is 85 - always safe to use kmap_local_page() / kunmap_local(). 82 + always safe to use kmap_local_{page,folio}() / kunmap_local(). 86 83 87 - While it is significantly faster than kmap(), for the highmem case it 88 - comes with restrictions about the pointers validity. Contrary to kmap() 84 + While they are significantly faster than kmap(), for the highmem case they 85 + come with restrictions about the pointers validity. Contrary to kmap() 89 86 mappings, the local mappings are only valid in the context of the caller 90 87 and cannot be handed to other contexts. This implies that users must 91 88 be absolutely sure to keep the use of the return address local to the ··· 94 91 Most code can be designed to use thread local mappings. User should 95 92 therefore try to design their code to avoid the use of kmap() by mapping 96 93 pages in the same thread the address will be used and prefer 97 - kmap_local_page(). 94 + kmap_local_page() or kmap_local_folio(). 98 95 99 96 Nesting kmap_local_page() and kmap_atomic() mappings is allowed to a certain 100 97 extent (up to KMAP_TYPE_NR) but their invocations have to be strictly ordered

+2 -11

Documentation/mm/hmm.rst

··· 163 163 164 164 It will trigger a page fault on missing or read-only entries if write access is 165 165 requested (see below). Page faults use the generic mm page fault code path just 166 - like a CPU page fault. 167 - 168 - Both functions copy CPU page table entries into their pfns array argument. Each 169 - entry in that array corresponds to an address in the virtual range. HMM 170 - provides a set of flags to help the driver identify special CPU page table 171 - entries. 172 - 173 - Locking within the sync_cpu_device_pagetables() callback is the most important 174 - aspect the driver must respect in order to keep things properly synchronized. 175 - The usage pattern is:: 166 + like a CPU page fault. The usage pattern is:: 176 167 177 168 int driver_populate_range(...) 178 169 { ··· 408 417 resovled by replacing the entry with the original mapping. A driver gets 409 418 notified that the mapping has been changed by MMU notifiers, after which point 410 419 it will no longer have exclusive access to the page. Exclusive access is 411 - guranteed to last until the driver drops the page lock and page reference, at 420 + guaranteed to last until the driver drops the page lock and page reference, at 412 421 which point any CPU faults on the page may proceed as described. 413 422 414 423 Memory cgroup (memcg) and rss accounting

+1 -1

Documentation/mm/hwpoison.rst

··· 48 48 For the KVM use there was need for a new signal type so that 49 49 KVM can inject the machine check into the guest with the proper 50 50 address. This in theory allows other applications to handle 51 - memory failures too. The expection is that near all applications 51 + memory failures too. The expectation is that most applications 52 52 won't do that, but some very specialized ones might. 53 53 54 54 Failure recovery modes

+1 -1

Documentation/mm/page_migration.rst

··· 180 180 4. THP_MIGRATION_FAIL: A THP could not be migrated nor it could be split. 181 181 182 182 5. THP_MIGRATION_SPLIT: A THP was migrated, but not as such: first, the THP had 183 - to be split. After splitting, a migration retry was used for it's sub-pages. 183 + to be split. After splitting, a migration retry was used for its sub-pages. 184 184 185 185 THP_MIGRATION_* events also update the appropriate PGMIGRATE_SUCCESS or 186 186 PGMIGRATE_FAIL events. For example, a THP migration failure will cause both

+1 -1

Documentation/mm/unevictable-lru.rst

··· 463 463 to the mmap() call. There is one important and subtle difference here, though. 464 464 mmap() + mlock() will fail if the range cannot be faulted in (e.g. because 465 465 mm_populate fails) and returns with ENOMEM while mmap(MAP_LOCKED) will not fail. 466 - The mmaped area will still have properties of the locked area - pages will not 466 + The mmapped area will still have properties of the locked area - pages will not 467 467 get swapped out - but major page faults to fault memory in might still happen. 468 468 469 469 Furthermore, any mmap() call or brk() call that expands the heap by a task

+3 -2

Documentation/mm/vmemmap_dedup.rst

··· 1 + 1 2 .. SPDX-License-Identifier: GPL-2.0 2 3 3 4 ========================================= ··· 11 10 This section is to explain how HugeTLB Vmemmap Optimization (HVO) works. 12 11 13 12 The ``struct page`` structures are used to describe a physical page frame. By 14 - default, there is a one-to-one mapping from a page frame to it's corresponding 13 + default, there is a one-to-one mapping from a page frame to its corresponding 15 14 ``struct page``. 16 15 17 16 HugeTLB pages consist of multiple base page size pages and is supported by many 18 17 architectures. See Documentation/admin-guide/mm/hugetlbpage.rst for more 19 18 details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB are 20 19 currently supported. Since the base page size on x86 is 4KB, a 2MB HugeTLB page 21 - consists of 512 base pages and a 1GB HugeTLB page consists of 4096 base pages. 20 + consists of 512 base pages and a 1GB HugeTLB page consists of 262144 base pages. 22 21 For each base page, there is a corresponding ``struct page``. 23 22 24 23 Within the HugeTLB subsystem, only the first 4 ``struct page`` are used to

+1 -1

Documentation/networking/bonding.rst

··· 1636 1636 ----------------------------------------- 1637 1637 1638 1638 This section applies to distros which use /etc/network/interfaces file 1639 - to describe network interface configuration, most notably Debian and it's 1639 + to describe network interface configuration, most notably Debian and its 1640 1640 derivatives. 1641 1641 1642 1642 The ifup and ifdown commands on Debian don't support bonding out of

+3 -3

Documentation/networking/devlink/devlink-port.rst

··· 376 376 Allows for usage of Weighted Fair Queuing arbitration scheme among 377 377 siblings. This arbitration scheme can be used simultaneously with the 378 378 strict priority. As a node is configured with a higher rate it gets more 379 - BW relative to it's siblings. Values are relative like a percentage 379 + BW relative to its siblings. Values are relative like a percentage 380 380 points, they basically tell how much BW should node take relative to 381 - it's siblings. 381 + its siblings. 382 382 383 383 ``parent`` 384 384 Parent node name. Parent node rate limits are considered as additional limits ··· 398 398 #. If group of nodes have the same priority perform WFQ arbitration on 399 399 that subgroup. Use ``tx_weight`` as a parameter for this arbitration. 400 400 401 - #. Select the winner node, and continue arbitration flow among it's children, 401 + #. Select the winner node, and continue arbitration flow among its children, 402 402 until leaf node is reached, and the winner is established. 403 403 404 404 #. If all the nodes from the highest priority sub-group are satisfied, or

+1 -1

Documentation/networking/packet_mmap.rst

··· 755 755 ============================ 756 756 757 757 AF_PACKET's TPACKET_V3 ring buffer can be configured to use non-static frame 758 - sizes by doing it's own memory management. It is based on blocks where polling 758 + sizes by doing its own memory management. It is based on blocks where polling 759 759 works on a per block basis instead of per ring as in TPACKET_V2 and predecessor. 760 760 761 761 It is said that TPACKET_V3 brings the following benefits:

+2 -2

Documentation/power/energy-model.rst

··· 87 87 Registration of 'advanced' EM 88 88 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 89 89 90 - The 'advanced' EM gets it's name due to the fact that the driver is allowed 90 + The 'advanced' EM gets its name due to the fact that the driver is allowed 91 91 to provide more precised power model. It's not limited to some implemented math 92 - formula in the framework (like it's in 'simple' EM case). It can better reflect 92 + formula in the framework (like it is in 'simple' EM case). It can better reflect 93 93 the real power measurements performed for each performance state. Thus, this 94 94 registration method should be preferred in case considering EM static power 95 95 (leakage) is important.

+1 -1

Documentation/powerpc/dscr.rst

··· 6 6 stream in the processor. Please refer to the ISA documents or related manual 7 7 for more detailed information regarding how to use this DSCR to attain this 8 8 control of the prefetches . This document here provides an overview of kernel 9 - support for DSCR, related kernel objects, it's functionalities and exported 9 + support for DSCR, related kernel objects, its functionalities and exported 10 10 user interface. 11 11 12 12 (A) Data Structures:

+1 -1

Documentation/powerpc/kasan.txt

··· 40 40 instrument any code that runs with translations off after booting. This is the 41 41 current approach. 42 42 43 - To avoid this limitiation, the KASAN shadow would have to be placed inside the 43 + To avoid this limitation, the KASAN shadow would have to be placed inside the 44 44 linear mapping, using the same high-bits trick we use for the rest of the linear 45 45 mapping. This is tricky: 46 46

+1 -1

Documentation/powerpc/papr_hcalls.rst

··· 22 22 On PPC64 arch a guest kernel running on top of a PAPR hypervisor is called 23 23 a *pSeries guest*. A pseries guest runs in a supervisor mode (HV=0) and must 24 24 issue hypercalls to the hypervisor whenever it needs to perform an action 25 - that is hypervisor priviledged [3]_ or for other services managed by the 25 + that is hypervisor privileged [3]_ or for other services managed by the 26 26 hypervisor. 27 27 28 28 Hence a Hypercall (hcall) is essentially a request by the pseries guest

+2 -2

Documentation/powerpc/qe_firmware.rst

··· 232 232 'extended_modes' is a bitfield that defines special functionality which has an 233 233 impact on the device drivers. Each bit has its own impact and has special 234 234 instructions for the driver associated with it. This field is stored in 235 - the QE library and available to any driver that calles qe_get_firmware_info(). 235 + the QE library and available to any driver that calls qe_get_firmware_info(). 236 236 237 237 'vtraps' is an array of 8 words that contain virtual trap values for each 238 238 virtual traps. As with 'extended_modes', this field is stored in the QE 239 - library and available to any driver that calles qe_get_firmware_info(). 239 + library and available to any driver that calls qe_get_firmware_info(). 240 240 241 241 'microcode' (type: struct qe_microcode): 242 242 For each RISC processor there is one 'microcode' structure. The first

+2 -2

Documentation/powerpc/vas-api.rst

··· 46 46 The application can then submit one or more requests to the engine by 47 47 using copy/paste instructions and pasting the CRBs to the virtual address 48 48 (aka paste_address) returned by mmap(). User space can close the 49 - established connection or send window by closing the file descriptior 49 + established connection or send window by closing the file descriptor 50 50 (close(fd)) or upon the process exit. 51 51 52 52 Note that applications can send several requests with the same window or ··· 240 240 siginfo.si_signo = SIGSEGV; 241 241 siginfo.si_errno = EFAULT; 242 242 siginfo.si_code = SEGV_MAPERR; 243 - siginfo.si_addr = CSB adress; 243 + siginfo.si_addr = CSB address; 244 244 245 245 In the case of multi-thread applications, NX send windows can be shared 246 246 across all threads. For example, a child thread can open a send window,

+1 -1

Documentation/process/botching-up-ioctls.rst

··· 208 208 it's much quicker to push a driver-private interface than engaging in 209 209 lengthy discussions for a more generic solution. And occasionally doing a 210 210 private interface to spearhead a new concept is what's required. But in the 211 - end, once the generic interface comes around you'll end up maintainer two 211 + end, once the generic interface comes around you'll end up maintaining two 212 212 interfaces. Indefinitely. 213 213 214 214 * Consider other interfaces than ioctls. A sysfs attribute is much better for

+6 -10

Documentation/process/changes.rst

··· 482 482 JFSutils 483 483 -------- 484 484 485 - - <http://jfs.sourceforge.net/> 485 + - <https://jfs.sourceforge.net/> 486 486 487 487 Reiserfsprogs 488 488 ------------- ··· 503 503 Quota-tools 504 504 ----------- 505 505 506 - - <http://sourceforge.net/projects/linuxquota/> 506 + - <https://sourceforge.net/projects/linuxquota/> 507 507 508 508 509 509 Intel P6 microcode ··· 524 524 mcelog 525 525 ------ 526 526 527 - - <http://www.mcelog.org/> 527 + - <https://www.mcelog.org/> 528 528 529 529 cpio 530 530 ---- ··· 544 544 NFS-utils 545 545 --------- 546 546 547 - - <http://sourceforge.net/project/showfiles.php?group_id=14> 547 + - <https://sourceforge.net/project/showfiles.php?group_id=14> 548 + - <https://nfs.sourceforge.net/> 548 549 549 550 Iptables 550 551 -------- ··· 560 559 OProfile 561 560 -------- 562 561 563 - - <http://oprofile.sf.net/download/> 564 - 565 - NFS-Utils 566 - --------- 567 - 568 - - <http://nfs.sourceforge.net/> 562 + - <https://oprofile.sf.net/download/> 569 563 570 564 Kernel documentation 571 565 ********************

+1 -1

Documentation/process/deprecated.rst

··· 77 77 If no 2-factor form is available, the saturate-on-overflow helpers should 78 78 be used:: 79 79 80 - bar = vmalloc(array_size(count, size)); 80 + bar = dma_alloc_coherent(dev, array_size(count, size), &dma, GFP_KERNEL); 81 81 82 82 Another common case to avoid is calculating the size of a structure with 83 83 a trailing array of others structures, as in::

+10 -1

Documentation/process/kernel-docs.rst

··· 29 29 30 30 The documents on each section of this document are ordered by its 31 31 published date, from the newest to the oldest. The maintainer(s) should 32 - periodically retire resources as they become obsolte or outdated; with 32 + periodically retire resources as they become obsolete or outdated; with 33 33 the exception of foundational books. 34 34 35 35 Docs at the Linux Kernel tree ··· 117 117 :Pages: 440 118 118 :ISBN: 978-0672329463 119 119 :Notes: Foundational book 120 + 121 + * Title: **Practical Linux System Administration: A Guide to Installation, Configuration, and Management, 1st Edition** 122 + 123 + :Author: Kenneth Hess 124 + :Publisher: O'Reilly Media 125 + :Date: May, 2023 126 + :Pages: 246 127 + :ISBN: 978-1098109035 128 + :Notes: System administration 120 129 121 130 .. _ldd3_published: 122 131

+27

Documentation/process/researcher-guidelines.rst

··· 44 44 involved. Developers cannot be interacted with/experimented on without 45 45 consent; this, too, is standard research ethics. 46 46 47 + Surveys 48 + ======= 49 + 50 + Research often takes the form of surveys sent to maintainers or 51 + contributors. As a general rule, though, the kernel community derives 52 + little value from these surveys. The kernel development process works 53 + because every developer benefits from their participation, even working 54 + with others who have different goals. Responding to a survey, though, is a 55 + one-way demand placed on busy developers with no corresponding benefit to 56 + themselves or to the kernel community as a whole. For this reason, this 57 + method of research is discouraged. 58 + 59 + Kernel community members already receive far too much email and are likely 60 + to perceive survey requests as just another demand on their time. Sending 61 + such requests deprives the community of valuable contributor time and is 62 + unlikely to yield a statistically useful response. 63 + 64 + As an alternative, researchers should consider attending developer events, 65 + hosting sessions where the research project and its benefits to the 66 + participants can be explained, and interacting directly with the community 67 + there. The information received will be far richer than that obtained from 68 + an email survey, and the community will gain from the ability to learn from 69 + your insights as well. 70 + 71 + Patches 72 + ======= 73 + 47 74 To help clarify: sending patches to developers *is* interacting 48 75 with them, but they have already consented to receiving *good faith 49 76 contributions*. Sending intentionally flawed/vulnerable patches or

+5 -8

Documentation/riscv/boot-image-header.rst

··· 7 7 8 8 This document only describes the boot image header details for RISC-V Linux. 9 9 10 - TODO: 11 - Write a complete booting guide. 12 - 13 10 The following 64-byte header is present in decompressed Linux kernel image:: 14 11 15 12 u32 code0; /* Executable code */ ··· 28 31 Notes 29 32 ===== 30 33 31 - - This header can also be reused to support EFI stub for RISC-V in future. EFI 32 - specification needs PE/COFF image header in the beginning of the kernel image 33 - in order to load it as an EFI application. In order to support EFI stub, 34 - code0 should be replaced with "MZ" magic string and res3(at offset 0x3c) should 35 - point to the rest of the PE/COFF header. 34 + - This header is also reused to support EFI stub for RISC-V. EFI specification 35 + needs PE/COFF image header in the beginning of the kernel image in order to 36 + load it as an EFI application. In order to support EFI stub, code0 is replaced 37 + with "MZ" magic string and res3(at offset 0x3c) points to the rest of the 38 + PE/COFF header. 36 39 37 40 - version field indicate header version number 38 41

+169

Documentation/riscv/boot.rst

··· 1 + .. SPDX-License-Identifier: GPL-2.0 2 + 3 + =============================================== 4 + RISC-V Kernel Boot Requirements and Constraints 5 + =============================================== 6 + 7 + :Author: Alexandre Ghiti <alexghiti@rivosinc.com> 8 + :Date: 23 May 2023 9 + 10 + This document describes what the RISC-V kernel expects from bootloaders and 11 + firmware, and also the constraints that any developer must have in mind when 12 + touching the early boot process. For the purposes of this document, the 13 + ``early boot process`` refers to any code that runs before the final virtual 14 + mapping is set up. 15 + 16 + Pre-kernel Requirements and Constraints 17 + ======================================= 18 + 19 + The RISC-V kernel expects the following of bootloaders and platform firmware: 20 + 21 + Register state 22 + -------------- 23 + 24 + The RISC-V kernel expects: 25 + 26 + * ``$a0`` to contain the hartid of the current core. 27 + * ``$a1`` to contain the address of the devicetree in memory. 28 + 29 + CSR state 30 + --------- 31 + 32 + The RISC-V kernel expects: 33 + 34 + * ``$satp = 0``: the MMU, if present, must be disabled. 35 + 36 + Reserved memory for resident firmware 37 + ------------------------------------- 38 + 39 + The RISC-V kernel must not map any resident memory, or memory protected with 40 + PMPs, in the direct mapping, so the firmware must correctly mark those regions 41 + as per the devicetree specification and/or the UEFI specification. 42 + 43 + Kernel location 44 + --------------- 45 + 46 + The RISC-V kernel expects to be placed at a PMD boundary (2MB aligned for rv64 47 + and 4MB aligned for rv32). Note that the EFI stub will physically relocate the 48 + kernel if that's not the case. 49 + 50 + Hardware description 51 + -------------------- 52 + 53 + The firmware can pass either a devicetree or ACPI tables to the RISC-V kernel. 54 + 55 + The devicetree is either passed directly to the kernel from the previous stage 56 + using the ``$a1`` register, or when booting with UEFI, it can be passed using the 57 + EFI configuration table. 58 + 59 + The ACPI tables are passed to the kernel using the EFI configuration table. In 60 + this case, a tiny devicetree is still created by the EFI stub. Please refer to 61 + "EFI stub and devicetree" section below for details about this devicetree. 62 + 63 + Kernel entry 64 + ------------ 65 + 66 + On SMP systems, there are 2 methods to enter the kernel: 67 + 68 + - ``RISCV_BOOT_SPINWAIT``: the firmware releases all harts in the kernel, one hart 69 + wins a lottery and executes the early boot code while the other harts are 70 + parked waiting for the initialization to finish. This method is mostly used to 71 + support older firmwares without SBI HSM extension and M-mode RISC-V kernel. 72 + - ``Ordered booting``: the firmware releases only one hart that will execute the 73 + initialization phase and then will start all other harts using the SBI HSM 74 + extension. The ordered booting method is the preferred booting method for 75 + booting the RISC-V kernel because it can support CPU hotplug and kexec. 76 + 77 + UEFI 78 + ---- 79 + 80 + UEFI memory map 81 + ~~~~~~~~~~~~~~~ 82 + 83 + When booting with UEFI, the RISC-V kernel will use only the EFI memory map to 84 + populate the system memory. 85 + 86 + The UEFI firmware must parse the subnodes of the ``/reserved-memory`` devicetree 87 + node and abide by the devicetree specification to convert the attributes of 88 + those subnodes (``no-map`` and ``reusable``) into their correct EFI equivalent 89 + (refer to section "3.5.4 /reserved-memory and UEFI" of the devicetree 90 + specification v0.4-rc1). 91 + 92 + RISCV_EFI_BOOT_PROTOCOL 93 + ~~~~~~~~~~~~~~~~~~~~~~~ 94 + 95 + When booting with UEFI, the EFI stub requires the boot hartid in order to pass 96 + it to the RISC-V kernel in ``$a1``. The EFI stub retrieves the boot hartid using 97 + one of the following methods: 98 + 99 + - ``RISCV_EFI_BOOT_PROTOCOL`` (**preferred**). 100 + - ``boot-hartid`` devicetree subnode (**deprecated**). 101 + 102 + Any new firmware must implement ``RISCV_EFI_BOOT_PROTOCOL`` as the devicetree 103 + based approach is deprecated now. 104 + 105 + Early Boot Requirements and Constraints 106 + ======================================= 107 + 108 + The RISC-V kernel's early boot process operates under the following constraints: 109 + 110 + EFI stub and devicetree 111 + ----------------------- 112 + 113 + When booting with UEFI, the devicetree is supplemented (or created) by the EFI 114 + stub with the same parameters as arm64 which are described at the paragraph 115 + "UEFI kernel support on ARM" in Documentation/arch/arm/uefi.rst. 116 + 117 + Virtual mapping installation 118 + ---------------------------- 119 + 120 + The installation of the virtual mapping is done in 2 steps in the RISC-V kernel: 121 + 122 + 1. ``setup_vm()`` installs a temporary kernel mapping in ``early_pg_dir`` which 123 + allows discovery of the system memory. Only the kernel text/data are mapped 124 + at this point. When establishing this mapping, no allocation can be done 125 + (since the system memory is not known yet), so ``early_pg_dir`` page table is 126 + statically allocated (using only one table for each level). 127 + 128 + 2. ``setup_vm_final()`` creates the final kernel mapping in ``swapper_pg_dir`` 129 + and takes advantage of the discovered system memory to create the linear 130 + mapping. When establishing this mapping, the kernel can allocate memory but 131 + cannot access it directly (since the direct mapping is not present yet), so 132 + it uses temporary mappings in the fixmap region to be able to access the 133 + newly allocated page table levels. 134 + 135 + For ``virt_to_phys()`` and ``phys_to_virt()`` to be able to correctly convert 136 + direct mapping addresses to physical addresses, they need to know the start of 137 + the DRAM. This happens after step 1, right before step 2 installs the direct 138 + mapping (see ``setup_bootmem()`` function in arch/riscv/mm/init.c). Any usage of 139 + those macros before the final virtual mapping is installed must be carefully 140 + examined. 141 + 142 + Devicetree mapping via fixmap 143 + ----------------------------- 144 + 145 + As the ``reserved_mem`` array is initialized with virtual addresses established 146 + by ``setup_vm()``, and used with the mapping established by 147 + ``setup_vm_final()``, the RISC-V kernel uses the fixmap region to map the 148 + devicetree. This ensures that the devicetree remains accessible by both virtual 149 + mappings. 150 + 151 + Pre-MMU execution 152 + ----------------- 153 + 154 + A few pieces of code need to run before even the first virtual mapping is 155 + established. These are the installation of the first virtual mapping itself, 156 + patching of early alternatives and the early parsing of the kernel command line. 157 + That code must be very carefully compiled as: 158 + 159 + - ``-fno-pie``: This is needed for relocatable kernels which use ``-fPIE``, 160 + since otherwise, any access to a global symbol would go through the GOT which 161 + is only relocated virtually. 162 + - ``-mcmodel=medany``: Any access to a global symbol must be PC-relative to 163 + avoid any relocations to happen before the MMU is setup. 164 + - *all* instrumentation must also be disabled (that includes KASAN, ftrace and 165 + others). 166 + 167 + As using a symbol from a different compilation unit requires this unit to be 168 + compiled with those flags, we advise, as much as possible, not to use external 169 + symbols.

+2 -2

Documentation/riscv/hwprobe.rst

··· 88 88 always extremely slow. 89 89 90 90 * :c:macro:`RISCV_HWPROBE_MISALIGNED_SLOW`: Misaligned accesses are supported 91 - in hardware, but are slower than the cooresponding aligned accesses 91 + in hardware, but are slower than the corresponding aligned accesses 92 92 sequences. 93 93 94 94 * :c:macro:`RISCV_HWPROBE_MISALIGNED_FAST`: Misaligned accesses are supported 95 - in hardware and are faster than the cooresponding aligned accesses 95 + in hardware and are faster than the corresponding aligned accesses 96 96 sequences. 97 97 98 98 * :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are

+1

Documentation/riscv/index.rst

··· 6 6 :maxdepth: 1 7 7 8 8 acpi 9 + boot 9 10 boot-image-header 10 11 vm-layout 11 12 hwprobe

+1 -1

Documentation/riscv/vector.rst

··· 13 13 Two new prctl() calls are added to allow programs to manage the enablement 14 14 status for the use of Vector in userspace. The intended usage guideline for 15 15 these interfaces is to give init systems a way to modify the availability of V 16 - for processes running under its domain. Calling thess interfaces is not 16 + for processes running under its domain. Calling these interfaces is not 17 17 recommended in libraries routines because libraries should not override policies 18 18 configured from the parant process. Also, users must noted that these interfaces 19 19 are not portable to non-Linux, nor non-RISC-V environments, so it is discourage

+8

Documentation/rust/index.rst

··· 6 6 Documentation related to Rust within the kernel. To start using Rust 7 7 in the kernel, please read the quick-start.rst guide. 8 8 9 + .. only:: rustdoc and html 10 + 11 + You can also browse `rustdoc documentation <rustdoc/kernel/index.html>`_. 12 + 13 + .. only:: not rustdoc and html 14 + 15 + This documentation does not include rustdoc generated information. 16 + 9 17 .. toctree:: 10 18 :maxdepth: 1 11 19

+1 -1

Documentation/scheduler/completion.rst

··· 157 157 158 158 /* run non-dependent code */ /* do setup */ 159 159 160 - wait_for_completion(&setup_done); complete(setup_done); 160 + wait_for_completion(&setup_done); complete(&setup_done); 161 161 162 162 This is not implying any particular order between wait_for_completion() and 163 163 the call to complete() - if the call to complete() happened before the call

+1 -1

Documentation/scheduler/sched-bwc.rst

··· 186 186 also limits the burst ability to no more than 1ms per cpu. This provides 187 187 better more predictable user experience for highly threaded applications with 188 188 small quota limits on high core count machines. It also eliminates the 189 - propensity to throttle these applications while simultanously using less than 189 + propensity to throttle these applications while simultaneously using less than 190 190 quota amounts of cpu. Another way to say this, is that by allowing the unused 191 191 portion of a slice to remain valid across periods we have decreased the 192 192 possibility of wastefully expiring quota on cpu-local silos that don't need a

+2 -2

Documentation/scheduler/sched-energy.rst

··· 82 82 The rest of platform knowledge used by EAS is directly read from the Energy 83 83 Model (EM) framework. The EM of a platform is composed of a power cost table 84 84 per 'performance domain' in the system (see Documentation/power/energy-model.rst 85 - for futher details about performance domains). 85 + for further details about performance domains). 86 86 87 87 The scheduler manages references to the EM objects in the topology code when the 88 88 scheduling domains are built, or re-built. For each root domain (rd), the ··· 281 281 From a general standpoint, the use-cases where EAS can help the most are those 282 282 involving a light/medium CPU utilization. Whenever long CPU-bound tasks are 283 283 being run, they will require all of the available CPU capacity, and there isn't 284 - much that can be done by the scheduler to save energy without severly harming 284 + much that can be done by the scheduler to save energy without severely harming 285 285 throughput. In order to avoid hurting performance with EAS, CPUs are flagged as 286 286 'over-utilized' as soon as they are used at more than 80% of their compute 287 287 capacity. As long as no CPUs are over-utilized in a root domain, load balancing

+1 -1

Documentation/scsi/ChangeLog.lpfc

··· 427 427 * Changed version number to 8.0.17 428 428 * Fix sparse warnings by adding __iomem markers to lpfc_compat.h. 429 429 * Fix some sparse warnings -- 0 used as NULL pointer. 430 - * Make sure there's a space between every if and it's (. 430 + * Make sure there's a space between every if and its (. 431 431 * Fix some overly long lines and make sure hard tabs are used for 432 432 indentation. 433 433 * Remove all trailing whitespace.

+1 -1

Documentation/security/digsig.rst

··· 82 82 to generate signatures, to load keys into the kernel keyring. 83 83 Keys can be in PEM or converted to the kernel format. 84 84 When the key is added to the kernel keyring, the keyid defines the name 85 - of the key: 5D2B05FC633EE3E8 in the example bellow. 85 + of the key: 5D2B05FC633EE3E8 in the example below. 86 86 87 87 Here is example output of the keyctl utility:: 88 88

+1 -1

Documentation/security/keys/core.rst

··· 869 869 870 870 - ``char *hashname`` specifies the NUL terminated string identifying 871 871 the hash used from the kernel crypto API and applied for the KDF 872 - operation. The KDF implemenation complies with SP800-56A as well 872 + operation. The KDF implementation complies with SP800-56A as well 873 873 as with SP800-108 (the counter KDF). 874 874 875 875 - ``char *otherinfo`` specifies the OtherInfo data as documented in

+1 -1

Documentation/security/secrets/coco.rst

··· 34 34 35 35 During the VM's launch, the virtual machine manager may inject a secret to that 36 36 area. In AMD SEV and SEV-ES this is performed using the 37 - ``KVM_SEV_LAUNCH_SECRET`` command (see [sev]_). The strucutre of the injected 37 + ``KVM_SEV_LAUNCH_SECRET`` command (see [sev]_). The structure of the injected 38 38 Guest Owner secret data should be a GUIDed table of secret values; the binary 39 39 format is described in ``drivers/virt/coco/efi_secret/efi_secret.c`` under 40 40 "Structure of the EFI secret area".

+1 -1

Documentation/sphinx/cdomain.py

··· 178 178 if len(arglist[0].split(" ")) > 1: 179 179 return False 180 180 181 - # This is a function-like macro, it's arguments are typeless! 181 + # This is a function-like macro, its arguments are typeless! 182 182 signode += addnodes.desc_name(fullname, fullname) 183 183 paramlist = addnodes.desc_parameterlist() 184 184 signode += paramlist

+1 -1

Documentation/spi/spi-lm70llp.rst

··· 69 69 and not grounded by the host via D7), the transistor conducts and switches 70 70 the collector to zero, which is reflected on pin 13 of the DB25 parport 71 71 connector. When SI/O is Low (driven by the LM70 or the host) on the other 72 - hand, the transistor is cut off and the voltage tied to it's collector is 72 + hand, the transistor is cut off and the voltage tied to its collector is 73 73 reflected on pin 13 as a High level. 74 74 75 75 So: the getmiso inline routine in this driver takes this fact into account,

+26 -12

Documentation/subsystem-apis.rst

··· 10 10 as needed (or at least as we managed to add it — probably *not* all that is 11 11 needed). 12 12 13 + Core subsystems 14 + --------------- 15 + 16 + .. toctree:: 17 + :maxdepth: 1 18 + 19 + core-api/index 20 + driver-api/index 21 + mm/index 22 + power/index 23 + scheduler/index 24 + timers/index 25 + locking/index 26 + 13 27 Human interfaces 14 28 ---------------- 15 29 ··· 35 21 sound/index 36 22 gpu/index 37 23 fb/index 24 + 25 + Networking interfaces 26 + --------------------- 27 + 28 + .. toctree:: 29 + :maxdepth: 1 30 + 31 + networking/index 32 + netlabel/index 33 + infiniband/index 34 + isdn/index 35 + mhi/index 38 36 39 37 Storage interfaces 40 38 ------------------ ··· 65 39 .. toctree:: 66 40 :maxdepth: 1 67 41 68 - driver-api/index 69 - core-api/index 70 - locking/index 71 42 accounting/index 72 43 cpu-freq/index 73 44 fpga/index 74 45 i2c/index 75 46 iio/index 76 - isdn/index 77 - infiniband/index 78 47 leds/index 79 - netlabel/index 80 - networking/index 81 48 pcmcia/index 82 - power/index 83 - timers/index 84 49 spi/index 85 50 w1/index 86 51 watchdog/index ··· 80 63 accel/index 81 64 security/index 82 65 crypto/index 83 - mm/index 84 66 bpf/index 85 67 usb/index 86 68 PCI/index 87 69 misc-devices/index 88 - scheduler/index 89 - mhi/index 90 70 peci/index 91 71 wmi/index

+1 -1

Documentation/tools/rtla/rtla-timerlat-top.rst

··· 117 117 The raw trace is saved in the **timerlat_trace.txt** file for further analysis. 118 118 119 119 Note that **rtla timerlat** was dispatched without changing *timerlat* tracer 120 - threads' priority. That is generally not needed because these threads hava 120 + threads' priority. That is generally not needed because these threads have 121 121 priority *FIFO:95* by default, which is a common priority used by real-time 122 122 kernel developers to analyze scheduling delays. 123 123

+1 -1

Documentation/trace/coresight/coresight-etm4x-reference.rst

··· 675 675 reconstructed using only conditional branches. 676 676 677 677 There is currently no support in Perf for supplying modified binaries to the decoder, so this 678 - feature is only inteded to be used for debugging purposes or with a 3rd party tool. 678 + feature is only intended to be used for debugging purposes or with a 3rd party tool. 679 679 680 680 Choosing this option will result in a significant increase in the amount of trace generated - 681 681 possible danger of overflows, or fewer instructions covered. Note, that this option also

+3 -3

Documentation/trace/events.rst

··· 915 915 916 916 To create a kprobe event, an empty or partially empty kprobe event 917 917 should first be created using kprobe_event_gen_cmd_start(). The name 918 - of the event and the probe location should be specfied along with one 918 + of the event and the probe location should be specified along with one 919 919 or args each representing a probe field should be supplied to this 920 920 function. Before calling kprobe_event_gen_cmd_start(), the user 921 921 should create and initialize a dynevent_cmd object using ··· 995 995 layer that can be used to generate trace event commands. The 996 996 generated command strings can then be passed to the command-parsing 997 997 and event creation code that already exists in the trace event 998 - subystem for creating the corresponding trace events. 998 + subsystem for creating the corresponding trace events. 999 999 1000 1000 In a nutshell, the way it works is that the higher-level interface 1001 1001 code creates a struct dynevent_cmd object, then uses a couple ··· 1068 1068 appended onto the end of the arg pair (here ';'). 1069 1069 1070 1070 There's also a dynevent_str_add() function that can be used to simply 1071 - add a string as-is, with no spaces, delimeters, or arg check. 1071 + add a string as-is, with no spaces, delimiters, or arg check. 1072 1072 1073 1073 Any number of dynevent_*_add() calls can be made to build up the string 1074 1074 (until its length surpasses cmd->maxlen). When all the arguments have

+1 -1

Documentation/trace/fprobe.rst

··· 113 113 the instruction pointer of @regs may be different from the @entry_ip 114 114 in the entry_handler. If you need traced instruction pointer, you need 115 115 to use @entry_ip. On the other hand, in the exit_handler, the instruction 116 - pointer of @regs is set to the currect return address. 116 + pointer of @regs is set to the current return address. 117 117 118 118 @entry_data 119 119 This is a local storage to share the data between entry and exit handlers.

+1 -1

Documentation/trace/ftrace.rst

··· 2725 2725 2726 2726 The return value of each traced function can be displayed after 2727 2727 an equal sign "=". When encountering system call failures, it 2728 - can be verfy helpful to quickly locate the function that first 2728 + can be very helpful to quickly locate the function that first 2729 2729 returns an error code. 2730 2730 2731 2731 - hide: echo nofuncgraph-retval > trace_options

+1 -1

Documentation/trace/hwlat_detector.rst

··· 14 14 kernel is highly latency sensitive. 15 15 16 16 SMIs are not serviced by the Linux kernel, which means that it does not 17 - even know that they are occuring. SMIs are instead set up by BIOS code 17 + even know that they are occurring. SMIs are instead set up by BIOS code 18 18 and are serviced by BIOS code, usually for "critical" events such as 19 19 management of thermal sensors and fans. Sometimes though, SMIs are used for 20 20 other tasks and those tasks can spend an inordinate amount of time in the

+1 -1

Documentation/trace/rv/da_monitor_synthesis.rst

··· 1 1 Deterministic Automata Monitor Synthesis 2 2 ======================================== 3 3 4 - The starting point for the application of runtime verification (RV) technics 4 + The starting point for the application of runtime verification (RV) techniques 5 5 is the *specification* or *modeling* of the desired (or undesired) behavior 6 6 of the system under scrutiny. 7 7

+1 -1

Documentation/trace/rv/monitor_wwnr.rst

··· 26 26 | running | -+ 27 27 +-------------+ 28 28 29 - This model is borken, the reason is that a task can be running 29 + This model is broken, the reason is that a task can be running 30 30 in the processor without being set as RUNNABLE. Think about a 31 31 task about to sleep:: 32 32

+1 -1

Documentation/trace/rv/runtime-verification.rst

··· 31 31 *RV monitor* abstraction. A *RV monitor* includes a reference model of the 32 32 system, a set of instances of the monitor (per-cpu monitor, per-task monitor, 33 33 and so on), and the helper functions that glue the monitor to the system via 34 - trace, as depicted bellow:: 34 + trace, as depicted below:: 35 35 36 36 Linux +---- RV Monitor ----------------------------------+ Formal 37 37 Realm | | Realm

+1 -1

Documentation/trace/uprobetracer.rst

··· 55 55 56 56 (\*1) only for return probe. 57 57 (\*2) this is useful for fetching a field of data structures. 58 - (\*3) Unlike kprobe event, "u" prefix will just be ignored, becuse uprobe 58 + (\*3) Unlike kprobe event, "u" prefix will just be ignored, because uprobe 59 59 events can access only user-space memory. 60 60 61 61 Types

+1 -1

Documentation/trace/user_events.rst

··· 93 93 94 94 **NOTE:** The event subsystem name by default is "user_events". Callers should 95 95 not assume it will always be "user_events". Operators reserve the right in the 96 - future to change the subsystem name per-process to accomodate event isolation. 96 + future to change the subsystem name per-process to accommodate event isolation. 97 97 98 98 Command Format 99 99 ^^^^^^^^^^^^^^

+120

Documentation/translations/sp_SP/process/contribution-maturity-model.rst

··· 1 + .. SPDX-License-Identifier: GPL-2.0 2 + .. include:: ../disclaimer-sp.rst 3 + 4 + :Original: Documentation/process/contribution-maturity-model.rst 5 + :Translator: Avadhut Naik <avadhut.naik@amd.com> 6 + 7 + ==================================================== 8 + Modelo de Madurez de Contribución al Kernel de Linux 9 + ==================================================== 10 + 11 + 12 + Los Antecedentes 13 + ================ 14 + 15 + Como parte de la cumbre de mantenedores del kernel de Linux 2021, hubo 16 + una `discusión <https://lwn.net/Articles/870581/>`_ sobre los desafíos 17 + en el reclutamiento de mantenedores del kernel, así como la sucesión de 18 + los mantenedores. Algunas de las conclusiones de esa discusión incluyeron 19 + que las empresas que forman parte de la comunidad del kernel de Linux 20 + necesitan permitir que los ingenieros sean mantenedores como parte de su 21 + trabajo, para que puedan convertirse en lideres respetados y finalmente, 22 + en mantenedores del kernel. Para apoyar una fuente solida de talento, se 23 + debe permitir y alentar a los desarrolladores a asumir contribuciones 24 + upstream, como revisar los parches de otras personas, reestructurar la 25 + infraestructura del kernel y escribir documentación. 26 + 27 + Con ese fin, Technical Advisory Board (TAB) de la Fundación Linux propone 28 + este Modelo de Madurez de Contribución al Kernel de Linux. Estas 29 + expectativas comunes para la participación con la comunidad upstream 30 + tienen como objetivo aumentar la influencia de los desarrolladores 31 + individuales, aumentar la colaboración de las organizaciones y mejorar 32 + la salud general del ecosistema del kernel de Linux. 33 + 34 + El TAB insta a las organizaciones a evaluar continuamente su modelo de 35 + madurez de Código Abierto y comprometerse a realizar mejoras para 36 + alinearse con este modelo. Para ser eficaz, esta evaluación debe 37 + incorporar la reacción de toda la organización, incluyendo la gerencia 38 + y los desarrolladores en todos los niveles de antigüedad. En el espíritu 39 + de Código Abierto, alentamos a las organizaciones a publicar sus 40 + evaluaciones y planes para mejorar su participación con la comunidad 41 + upstream. 42 + 43 + Nivel 0 44 + ======= 45 + 46 + * A los ingenieros de software no se les permite contribuir con parches 47 + al kernel de Linux. 48 + 49 + Nivel 1 50 + ======= 51 + 52 + * A los ingenieros de software se les permite contribuir con parches al 53 + kernel de Linux, ya sea como parte de sus responsabilidades de trabajo 54 + o en su propio tiempo. 55 + 56 + Nivel 2 57 + ======= 58 + 59 + * Se espera que los ingenieros de software contribuyan al kernel de Linux 60 + como parte de sus responsabilidades de trabajo. 61 + * Se proporcionará apoyo a los ingenieros de software para asistir a 62 + conferencias relacionadas con Linux como parte de su trabajo. 63 + * Las contribuciones de código upstream de un ingeniero de software se 64 + considerarán en la promoción y las revisiones de rendimiento. 65 + 66 + Nivel 3 67 + ======= 68 + 69 + * Se espera que los ingenieros de software revisen los parches (incluidos 70 + los parches escritos por ingenieros de otras empresas) como parte de 71 + sus responsabilidades de trabajo. 72 + * Contribuir con presentaciones o ponencias a conferencias relacionadas 73 + con Linux o académicas (como las organizadas por la Fundación Linux, 74 + Usenix, ACM, etc.), se consideran parte del trabajo de un ingeniero. 75 + * Las contribuciones a la comunidad de un ingeniero de software se 76 + considerarán en la promoción y las revisiones de rendimiento. 77 + * Las organizaciones informarán regularmente sobre las métricas de sus 78 + contribuciones de código abierto y harán un seguimiento de estas 79 + métricas a lo largo del tiempo. Estas métricas pueden publicarse 80 + solo internamente dentro de la organización, o a discreción de la 81 + organización, algunas o todas pueden publicarse externamente. Las 82 + métricas que se sugieren encarecidamente incluyen: 83 + 84 + * El número de contribuciones al kernel upstream por equipo u 85 + organización (por ejemplo, todas las personas que reportan a un 86 + gerente o director o vicepresidente). 87 + * El porcentaje de desarrolladores del kernel que han realizado 88 + contribuciones upstream relativo al total de desarrolladores 89 + del kernel en la organización. 90 + * El intervalo de tiempo entre los kernels utilizados en los servidores 91 + y/o productos de la organización y la fecha de publicación del kernel 92 + upstream en el que se basa el kernel interno. 93 + * El número de commits fuera del árbol de desarrollo presentes en los 94 + kernels internos. 95 + 96 + Nivel 4 97 + ======= 98 + 99 + * Se anima a los ingenieros de software a pasar una parte de su tiempo de 100 + trabajo centrado en el Trabajo Ascendente, que se define como revisar 101 + parches, servir en los comités de programas, mejorar la infraestructura 102 + del proyecto central como escribir o mantener pruebas, reducir la deuda 103 + de tecnología upstream, escribir documentación, etc. 104 + * Los ingenieros de software son apoyados para ayudar a organizar 105 + conferencias relacionadas con Linux. 106 + * Las organizaciones considerarán los comentarios de los miembros de la 107 + comunidad en las revisiones oficiales de rendimiento. 108 + 109 + Nivel 5 110 + ======= 111 + 112 + * El desarrollo del kernel upstream se considera un puesto de trabajo 113 + formal, con al menos un tercio del tiempo del ingeniero pasado a hacer 114 + el Trabajo Ascendente. 115 + * Las organizaciones buscarán activamente las reacciones de los miembros 116 + de la comunidad como un factor en las revisiones oficiales de 117 + rendimiento. 118 + * Las organizaciones informarán regularmente internamente sobre la ratio 119 + de trabajo upstream a trabajo enfocado en perseguir directamente los 120 + objetivos comerciales.

+2

Documentation/translations/sp_SP/process/index.rst

··· 20 20 programming-language 21 21 deprecated 22 22 adding-syscalls 23 + researcher-guidelines 24 + contribution-maturity-model

+150

Documentation/translations/sp_SP/process/researcher-guidelines.rst

··· 1 + .. SPDX-License-Identifier: GPL-2.0 2 + 3 + :Original: :ref:`Documentation/process/researcher-guidelines.rst` 4 + :Translator: Avadhut Naik <avadhut.naik@amd.com> 5 + 6 + Directrices para Investigadores 7 + ++++++++++++++++++++++++++++++++ 8 + 9 + La comunidad del kernel de Linux da la bienvenida a la investigación 10 + transparente sobre el kernel de Linux, las actividades involucradas 11 + en su producción, otros subproductos de su desarrollo. Linux se 12 + beneficia mucho de este tipo de investigación, y la mayoría de los 13 + aspectos de Linux son impulsados por investigación en una forma u otra. 14 + 15 + La comunidad agradece mucho si los investigadores pueden compartir 16 + los hallazgos preliminares antes de hacer públicos sus resultados, 17 + especialmente si tal investigación involucra seguridad. Involucrarse 18 + temprano ayuda a mejorar la calidad de investigación y la capacidad 19 + de Linux para mejorar a partir de ella. En cualquier caso, se recomienda 20 + compartir copias de acceso abierto de la investigación publicada con 21 + la comunidad. 22 + 23 + Este documento busca clarificar lo que la comunidad del kernel de Linux 24 + considera practicas aceptables y no aceptables al llevar a cabo 25 + investigación de este tipo. Por lo menos, dicha investigación y 26 + actividades afines deben seguir las reglas estándar de ética de la 27 + investigación. Para más información sobre la ética de la investigación 28 + en general, ética en la tecnología y la investigación de las comunidades 29 + de desarrolladores en particular, ver: 30 + 31 + 32 + * `Historia de la Ética en la Investigación <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_ 33 + * `Ética de la IEEE <https://www.ieee.org/about/ethics/index.html>`_ 34 + * `Perspectivas de Desarrolladores e Investigadores sobre la Ética de los Experimentos en Proyectos de Código Abierto <https://arxiv.org/pdf/2112.13217.pdf>`_ 35 + 36 + La comunidad del kernel de Linux espera que todos los que interactúan con 37 + el proyecto están participando en buena fe para mejorar Linux. La 38 + investigación sobre cualquier artefacto disponible públicamente (incluido, 39 + pero no limitado a código fuente) producido por la comunidad del kernel 40 + de Linux es bienvenida, aunque la investigación sobre los desarrolladores 41 + debe ser claramente opcional. 42 + 43 + La investigación pasiva que se basa completamente en fuentes disponibles 44 + públicamente, incluidas las publicaciones en listas de correo públicas y 45 + las contribuciones a los repositorios públicos, es claramente permitida. 46 + Aunque, como con cualquier investigación, todavía se debe seguir la ética 47 + estándar. 48 + 49 + La investigación activa sobre el comportamiento de los desarrolladores, 50 + sin embargo, debe hacerse con el acuerdo explícito y la divulgación 51 + completa a los desarrolladores individuales involucrados. No se puede 52 + interactuar / experimentar con los desarrolladores sin consentimiento; 53 + esto también es ética de investigación estándar. 54 + 55 + Para ayudar a aclarar: enviar parches a los desarrolladores es interactuar 56 + con ellos, pero ya han dado su consentimiento para recibir contribuciones 57 + en buena fe. No se ha dado consentimiento para enviar parches intencionalmente 58 + defectuosos / vulnerables o contribuir con la información engañosa a las 59 + discusiones. Dicha comunicación puede ser perjudicial al desarrollador (por 60 + ejemplo, agotar el tiempo, el esfuerzo, y la moral) y perjudicial para el 61 + proyecto al erosionar la confianza de toda la comunidad de desarrolladores en 62 + el colaborador (y la organización del colaborador en conjunto), socavando 63 + los esfuerzos para proporcionar reacciones constructivas a los colaboradores 64 + y poniendo a los usuarios finales en riesgo de fallas de software. 65 + 66 + La participación en el desarrollo de Linux en sí mismo por parte de 67 + investigadores, como con cualquiera, es bienvenida y alentada. La 68 + investigación del código de Linux es una práctica común, especialmente 69 + cuando se trata de desarrollar o ejecutar herramientas de análisis que 70 + producen resultados procesables. 71 + 72 + Cuando se interactúa con la comunidad de desarrolladores, enviar un 73 + parche ha sido tradicionalmente la mejor manera para hacer un impacto. 74 + Linux ya tiene muchos errores conocidos – lo que es mucho más útil es 75 + tener soluciones verificadas. Antes de contribuir, lea cuidadosamente 76 + la documentación adecuada. 77 + 78 + * Documentation/process/development-process.rst 79 + * Documentation/process/submitting-patches.rst 80 + * Documentation/admin-guide/reporting-issues.rst 81 + * Documentation/process/security-bugs.rst 82 + 83 + Entonces envíe un parche (incluyendo un registro de confirmación con 84 + todos los detalles enumerados abajo) y haga un seguimiento de cualquier 85 + comentario de otros desarrolladores. 86 + 87 + * ¿Cuál es el problema específico que se ha encontrado? 88 + * ¿Como podría llegar al problema en un sistema en ejecución? 89 + * ¿Qué efecto tendría encontrar el problema en el sistema? 90 + * ¿Como se encontró el problema? Incluya específicamente detalles sobre 91 + cualquier prueba, programas de análisis estáticos o dinámicos, y cualquier 92 + otra herramienta o método utilizado para realizar el trabajo. 93 + * ¿En qué versión de Linux se encontró el problema? Se prefiere usar la 94 + versión más reciente o una rama reciente de linux-next (ver 95 + Documentation/process/howto.rst). 96 + * ¿Que se cambió para solucionar el problema y por qué se cree es correcto? 97 + * ¿Como se probó el cambio para la complicación y el tiempo de ejecución? 98 + * ¿Qué confirmación previa corrige este cambio? Esto debería ir en un “Fixes:” 99 + etiqueta como se describe en la documentación. 100 + * ¿Quién más ha revisado este parche? Esto debería ir con la adecuada “Reviewed-by” 101 + etiqueta; Vea abajo. 102 + 103 + Por ejemplo (en inglés, pues es en las listas):: 104 + 105 + From: Author <author@email> 106 + Subject: [PATCH] drivers/foo_bar: Add missing kfree() 107 + 108 + The error path in foo_bar driver does not correctly free the allocated 109 + struct foo_bar_info. This can happen if the attached foo_bar device 110 + rejects the initialization packets sent during foo_bar_probe(). This 111 + would result in a 64 byte slab memory leak once per device attach, 112 + wasting memory resources over time. 113 + 114 + This flaw was found using an experimental static analysis tool we are 115 + developing, LeakMagic[1], which reported the following warning when 116 + analyzing the v5.15 kernel release: 117 + 118 + path/to/foo_bar.c:187: missing kfree() call? 119 + 120 + Add the missing kfree() to the error path. No other references to 121 + this memory exist outside the probe function, so this is the only 122 + place it can be freed. 123 + 124 + x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC 125 + 11.2 show no new warnings, and LeakMagic no longer warns about this 126 + code path. As we don't have a FooBar device to test with, no runtime 127 + testing was able to be performed. 128 + 129 + [1] https://url/to/leakmagic/details 130 + 131 + Reported-by: Researcher <researcher@email> 132 + Fixes: aaaabbbbccccdddd ("Introduce support for FooBar") 133 + Signed-off-by: Author <author@email> 134 + Reviewed-by: Reviewer <reviewer@email> 135 + 136 + Si usted es un colaborador por primera vez, se recomienda que el parche en 137 + si sea examinado por otros en privado antes de ser publicado en listas 138 + públicas. (Esto es necesario si se le ha dicho explícitamente que sus parches 139 + necesitan una revisión interna más cuidadosa.) Se espera que estas personas 140 + tengan su etiqueta “Reviewed-by” incluida en el parche resultante. Encontrar 141 + otro desarrollador con conocimiento de las contribuciones a Linux, especialmente 142 + dentro de su propia organización, y tener su ayuda con las revisiones antes de 143 + enviarlas a las listas de correo publico tiende a mejorar significativamente la 144 + calidad de los parches resultantes, y reduce así la carga de otros desarrolladores. 145 + 146 + Si no se puede encontrar a nadie para revisar internamente los parches y necesita 147 + ayuda para encontrar a esa persona, o si tiene alguna otra pregunta relacionada 148 + con este documento y las expectativas de la comunidad de desarrolladores, por 149 + favor contacte con la lista de correo privada Technical Advisory Board: 150 + <tech-board@lists.linux-foundation.org>.

+2 -2

Documentation/translations/zh_CN/arch/index.rst

··· 8 8 .. toctree:: 9 9 :maxdepth: 2 10 10 11 - ../mips/index 11 + mips/index 12 12 arm64/index 13 13 ../riscv/index 14 14 openrisc/index 15 15 parisc/index 16 - ../loongarch/index 16 + loongarch/index 17 17 18 18 TODOList: 19 19

+1 -1

Documentation/translations/zh_CN/dev-tools/testing-overview.rst

··· 3 3 .. include:: ../disclaimer-zh_CN.rst 4 4 5 5 :Original: Documentation/dev-tools/testing-overview.rst 6 - :Translator: 胡皓文 Hu Haowen <src.res@email.cn> 6 + :Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com> 7 7 8 8 ============ 9 9 内核测试指南

+2 -2

Documentation/translations/zh_CN/loongarch/booting.rst Documentation/translations/zh_CN/arch/loongarch/booting.rst

··· 1 1 .. SPDX-License-Identifier: GPL-2.0 2 2 3 - .. include:: ../disclaimer-zh_CN.rst 3 + .. include:: ../../disclaimer-zh_CN.rst 4 4 5 - :Original: Documentation/loongarch/booting.rst 5 + :Original: Documentation/arch/loongarch/booting.rst 6 6 7 7 :翻译: 8 8

+2 -2

Documentation/translations/zh_CN/loongarch/features.rst Documentation/translations/zh_CN/arch/loongarch/features.rst

··· 1 1 .. SPDX-License-Identifier: GPL-2.0 2 2 3 - .. include:: ../disclaimer-zh_CN.rst 3 + .. include:: ../../disclaimer-zh_CN.rst 4 4 5 - :Original: Documentation/loongarch/features.rst 5 + :Original: Documentation/arch/loongarch/features.rst 6 6 :Translator: Huacai Chen <chenhuacai@loongson.cn> 7 7 8 8 .. kernel-feat:: $srctree/Documentation/features loongarch

+2 -2

Documentation/translations/zh_CN/loongarch/index.rst Documentation/translations/zh_CN/arch/loongarch/index.rst

··· 1 1 .. SPDX-License-Identifier: GPL-2.0 2 2 3 - .. include:: ../disclaimer-zh_CN.rst 3 + .. include:: ../../disclaimer-zh_CN.rst 4 4 5 - :Original: Documentation/loongarch/index.rst 5 + :Original: Documentation/arch/loongarch/index.rst 6 6 :Translator: Huacai Chen <chenhuacai@loongson.cn> 7 7 8 8 =================

+2 -2

Documentation/translations/zh_CN/loongarch/introduction.rst Documentation/translations/zh_CN/arch/loongarch/introduction.rst

··· 1 1 .. SPDX-License-Identifier: GPL-2.0 2 2 3 - .. include:: ../disclaimer-zh_CN.rst 3 + .. include:: ../../disclaimer-zh_CN.rst 4 4 5 - :Original: Documentation/loongarch/introduction.rst 5 + :Original: Documentation/arch/loongarch/introduction.rst 6 6 :Translator: Huacai Chen <chenhuacai@loongson.cn> 7 7 8 8 =============

+2 -2

Documentation/translations/zh_CN/loongarch/irq-chip-model.rst Documentation/translations/zh_CN/arch/loongarch/irq-chip-model.rst

··· 1 1 .. SPDX-License-Identifier: GPL-2.0 2 2 3 - .. include:: ../disclaimer-zh_CN.rst 3 + .. include:: ../../disclaimer-zh_CN.rst 4 4 5 - :Original: Documentation/loongarch/irq-chip-model.rst 5 + :Original: Documentation/arch/loongarch/irq-chip-model.rst 6 6 :Translator: Huacai Chen <chenhuacai@loongson.cn> 7 7 8 8 ==================================

+2 -2

Documentation/translations/zh_CN/mips/booting.rst Documentation/translations/zh_CN/arch/mips/booting.rst

··· 1 1 .. SPDX-License-Identifier: GPL-2.0 2 2 3 - .. include:: ../disclaimer-zh_CN.rst 3 + .. include:: ../../disclaimer-zh_CN.rst 4 4 5 - :Original: Documentation/mips/booting.rst 5 + :Original: Documentation/arch/mips/booting.rst 6 6 7 7 :翻译: 8 8

+2 -2

Documentation/translations/zh_CN/mips/features.rst Documentation/translations/zh_CN/arch/mips/features.rst

··· 1 1 .. SPDX-License-Identifier: GPL-2.0 2 2 3 - .. include:: ../disclaimer-zh_CN.rst 3 + .. include:: ../../disclaimer-zh_CN.rst 4 4 5 - :Original: Documentation/mips/features.rst 5 + :Original: Documentation/arch/mips/features.rst 6 6 7 7 :翻译: 8 8

+2 -2

Documentation/translations/zh_CN/mips/index.rst Documentation/translations/zh_CN/arch/mips/index.rst

··· 1 1 .. SPDX-License-Identifier: GPL-2.0 2 2 3 - .. include:: ../disclaimer-zh_CN.rst 3 + .. include:: ../../disclaimer-zh_CN.rst 4 4 5 - :Original: Documentation/mips/index.rst 5 + :Original: Documentation/arch/mips/index.rst 6 6 7 7 :翻译: 8 8

+2 -2

Documentation/translations/zh_CN/mips/ingenic-tcu.rst Documentation/translations/zh_CN/arch/mips/ingenic-tcu.rst

··· 1 1 .. SPDX-License-Identifier: GPL-2.0 2 2 3 - .. include:: ../disclaimer-zh_CN.rst 3 + .. include:: ../../disclaimer-zh_CN.rst 4 4 5 - :Original: Documentation/mips/ingenic-tcu.rst 5 + :Original: Documentation/arch/mips/ingenic-tcu.rst 6 6 7 7 :翻译: 8 8

+2 -2

Documentation/translations/zh_CN/mm/hugetlbfs_reserv.rst

··· 296 296 调用代码执行全局检查和分配，以确定是否有足够的巨页使操作成功。 297 297 298 298 2) 299 - a) 如果操作能够成功，regi_add()将被调用，以实际修改先前传递给regi_chg()的相同范围 299 + a) 如果操作能够成功，region_add()将被调用，以实际修改先前传递给region_chg()的相同范围 300 300 [f, t]的预留映射。 301 301 b) 如果操作不能成功，region_abort被调用，在相同的范围[f, t]内中止操作。 302 302 ··· 307 307 如上所述，region_chg()确定该范围内当前没有在映射中表示的页面的数量。region_add()返回添加 308 308 到映射中的范围内的页数。在大多数情况下， region_add() 的返回值与 region_chg() 的返回值相 309 309 同。然而，在共享映射的情况下，有可能在调用 region_chg() 和 region_add() 之间对预留映射进 310 - 行更改。在这种情况下，regi_add()的返回值将与regi_chg()的返回值不符。在这种情况下，全局计数 310 + 行更改。在这种情况下，region_add()的返回值将与region_chg()的返回值不符。在这种情况下，全局计数 311 311 和子池计数很可能是不正确的，需要调整。检查这种情况并进行适当的调整是调用者的责任。 312 312 313 313 函数region_del()被调用以从预留映射中移除区域。

+4 -4

Documentation/translations/zh_TW/IRQ.txt

··· 7 7 or if there is a problem with the translation. 8 8 9 9 Maintainer: Eric W. Biederman <ebiederman@xmission.com> 10 - Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> 10 + Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> 11 11 --------------------------------------------------------------------- 12 12 Documentation/core-api/irq/index.rst 的繁體中文翻譯 13 13 ··· 16 16 者翻譯存在問題，請聯繫繁體中文版維護者。 17 17 18 18 英文版維護者： Eric W. Biederman <ebiederman@xmission.com> 19 - 繁體中文版維護者：胡皓文 Hu Haowen <src.res@email.cn> 20 - 繁體中文版翻譯者：胡皓文 Hu Haowen <src.res@email.cn> 21 - 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> 19 + 繁體中文版維護者：胡皓文 Hu Haowen <src.res.211@gmail.com> 20 + 繁體中文版翻譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 21 + 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 22 22 23 23 24 24 以下爲正文

+1 -1

Documentation/translations/zh_TW/admin-guide/README.rst

··· 7 7 :譯者: 8 8 9 9 吳想成 Wu XiangCheng <bobwxc@email.cn> 10 - 胡皓文 Hu Haowen <src.res@email.cn> 10 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 11 11 12 12 Linux內核5.x版本 <http://kernel.org/> 13 13 =========================================

+1 -1

Documentation/translations/zh_TW/admin-guide/bug-bisect.rst

··· 7 7 :譯者: 8 8 9 9 吳想成 Wu XiangCheng <bobwxc@email.cn> 10 - 胡皓文 Hu Haowen <src.res@email.cn> 10 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 11 11 12 12 二分（bisect）缺陷 13 13 +++++++++++++++++++

+1 -1

Documentation/translations/zh_TW/admin-guide/bug-hunting.rst

··· 7 7 :譯者: 8 8 9 9 吳想成 Wu XiangCheng <bobwxc@email.cn> 10 - 胡皓文 Hu Haowen <src.res@email.cn> 10 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 11 11 12 12 追蹤缺陷 13 13 =========

+1 -1

Documentation/translations/zh_TW/admin-guide/clearing-warn-once.rst

··· 2 2 3 3 .. include:: ../disclaimer-zh_TW.rst 4 4 5 - :Translator: 胡皓文 Hu Haowen <src.res@email.cn> 5 + :Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com> 6 6 7 7 清除 WARN_ONCE 8 8 --------------

+1 -1

Documentation/translations/zh_TW/admin-guide/cpu-load.rst

··· 2 2 3 3 .. include:: ../disclaimer-zh_TW.rst 4 4 5 - :Translator: 胡皓文 Hu Haowen <src.res@email.cn> 5 + :Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com> 6 6 7 7 ======== 8 8 CPU 負載

+1 -1

Documentation/translations/zh_TW/admin-guide/index.rst

··· 3 3 .. include:: ../disclaimer-zh_TW.rst 4 4 5 5 :Original: :doc:`../../../admin-guide/index` 6 - :Translator: 胡皓文 Hu Haowen <src.res@email.cn> 6 + :Translator: 胡皓文 Hu Haowen <src.res.211@gmail.com> 7 7 8 8 Linux 內核用戶和管理員指南 9 9 ==========================

+1 -1

Documentation/translations/zh_TW/admin-guide/init.rst

··· 7 7 :譯者: 8 8 9 9 吳想成 Wu XiangCheng <bobwxc@email.cn> 10 - 胡皓文 Hu Haowen <src.res@email.cn> 10 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 11 11 12 12 解釋「No working init found.」啓動掛起消息 13 13 ==========================================

+1 -1

Documentation/translations/zh_TW/admin-guide/reporting-issues.rst

··· 16 16 :譯者: 17 17 18 18 吳想成 Wu XiangCheng <bobwxc@email.cn> 19 - 胡皓文 Hu Haowen <src.res@email.cn> 19 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 20 20 21 21 22 22 報告問題

+1 -1

Documentation/translations/zh_TW/admin-guide/security-bugs.rst

··· 7 7 :譯者: 8 8 9 9 吳想成 Wu XiangCheng <bobwxc@email.cn> 10 - 胡皓文 Hu Haowen <src.res@email.cn> 10 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 11 11 12 12 安全缺陷 13 13 =========

+1 -1

Documentation/translations/zh_TW/admin-guide/tainted-kernels.rst

··· 7 7 :譯者: 8 8 9 9 吳想成 Wu XiangCheng <bobwxc@email.cn> 10 - 胡皓文 Hu Haowen <src.res@email.cn> 10 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 11 11 12 12 受汙染的內核 13 13 -------------

+1 -1

Documentation/translations/zh_TW/admin-guide/unicode.rst

··· 7 7 :譯者: 8 8 9 9 吳想成 Wu XiangCheng <bobwxc@email.cn> 10 - 胡皓文 Hu Haowen <src.res@email.cn> 10 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 11 11 12 12 Unicode（統一碼）支持 13 13 ======================

+1 -1

Documentation/translations/zh_TW/arch/arm64/amu.rst

··· 5 5 :Original: :ref:`Documentation/arch/arm64/amu.rst <amu_index>` 6 6 7 7 Translator: Bailu Lin <bailu.lin@vivo.com> 8 - Hu Haowen <src.res@email.cn> 8 + Hu Haowen <src.res.211@gmail.com> 9 9 10 10 ================================== 11 11 AArch64 Linux 中擴展的活動監控單元

+2 -2

Documentation/translations/zh_TW/arch/arm64/booting.txt

··· 10 10 11 11 M: Will Deacon <will.deacon@arm.com> 12 12 zh_CN: Fu Wei <wefu@redhat.com> 13 - zh_TW: Hu Haowen <src.res@email.cn> 13 + zh_TW: Hu Haowen <src.res.211@gmail.com> 14 14 C: 55f058e7574c3615dea4615573a19bdb258696c6 15 15 --------------------------------------------------------------------- 16 16 Documentation/arch/arm64/booting.rst 的中文翻譯 ··· 23 23 中文版維護者：傅煒 Fu Wei <wefu@redhat.com> 24 24 中文版翻譯者：傅煒 Fu Wei <wefu@redhat.com> 25 25 中文版校譯者：傅煒 Fu Wei <wefu@redhat.com> 26 - 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> 26 + 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 27 27 本文翻譯提交時的 Git 檢出點爲： 55f058e7574c3615dea4615573a19bdb258696c6 28 28 29 29 以下爲正文

+1 -1

Documentation/translations/zh_TW/arch/arm64/elf_hwcaps.rst

··· 5 5 :Original: :ref:`Documentation/arch/arm64/elf_hwcaps.rst <elf_hwcaps_index>` 6 6 7 7 Translator: Bailu Lin <bailu.lin@vivo.com> 8 - Hu Haowen <src.res@email.cn> 8 + Hu Haowen <src.res.211@gmail.com> 9 9 10 10 ================ 11 11 ARM64 ELF hwcaps

+1 -1

Documentation/translations/zh_TW/arch/arm64/hugetlbpage.rst

··· 5 5 :Original: :ref:`Documentation/arch/arm64/hugetlbpage.rst <hugetlbpage_index>` 6 6 7 7 Translator: Bailu Lin <bailu.lin@vivo.com> 8 - Hu Haowen <src.res@email.cn> 8 + Hu Haowen <src.res.211@gmail.com> 9 9 10 10 ===================== 11 11 ARM64中的 HugeTLBpage

+1 -1

Documentation/translations/zh_TW/arch/arm64/index.rst

··· 4 4 5 5 :Original: :ref:`Documentation/arch/arm64/index.rst <arm64_index>` 6 6 :Translator: Bailu Lin <bailu.lin@vivo.com> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_arm64_index: 10 10

+2 -2

Documentation/translations/zh_TW/arch/arm64/legacy_instructions.txt

··· 11 11 Maintainer: Punit Agrawal <punit.agrawal@arm.com> 12 12 Suzuki K. Poulose <suzuki.poulose@arm.com> 13 13 Chinese maintainer: Fu Wei <wefu@redhat.com> 14 - Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> 14 + Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> 15 15 --------------------------------------------------------------------- 16 16 Documentation/arch/arm64/legacy_instructions.rst 的中文翻譯 17 17 ··· 26 26 中文版維護者：傅煒 Fu Wei <wefu@redhat.com> 27 27 中文版翻譯者：傅煒 Fu Wei <wefu@redhat.com> 28 28 中文版校譯者：傅煒 Fu Wei <wefu@redhat.com> 29 - 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> 29 + 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 30 30 31 31 以下爲正文 32 32 ---------------------------------------------------------------------

+2 -2

Documentation/translations/zh_TW/arch/arm64/memory.txt

··· 10 10 11 11 Maintainer: Catalin Marinas <catalin.marinas@arm.com> 12 12 Chinese maintainer: Fu Wei <wefu@redhat.com> 13 - Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> 13 + Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> 14 14 --------------------------------------------------------------------- 15 15 Documentation/arch/arm64/memory.rst 的中文翻譯 16 16 ··· 24 24 中文版維護者：傅煒 Fu Wei <wefu@redhat.com> 25 25 中文版翻譯者：傅煒 Fu Wei <wefu@redhat.com> 26 26 中文版校譯者：傅煒 Fu Wei <wefu@redhat.com> 27 - 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> 27 + 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 28 28 29 29 以下爲正文 30 30 ---------------------------------------------------------------------

+1 -1

Documentation/translations/zh_TW/arch/arm64/perf.rst

··· 5 5 :Original: :ref:`Documentation/arch/arm64/perf.rst <perf_index>` 6 6 7 7 Translator: Bailu Lin <bailu.lin@vivo.com> 8 - Hu Haowen <src.res@email.cn> 8 + Hu Haowen <src.res.211@gmail.com> 9 9 10 10 ============= 11 11 Perf 事件屬性

+2 -2

Documentation/translations/zh_TW/arch/arm64/silicon-errata.txt

··· 10 10 11 11 M: Will Deacon <will.deacon@arm.com> 12 12 zh_CN: Fu Wei <wefu@redhat.com> 13 - zh_TW: Hu Haowen <src.res@email.cn> 13 + zh_TW: Hu Haowen <src.res.211@gmail.com> 14 14 C: 1926e54f115725a9248d0c4c65c22acaf94de4c4 15 15 --------------------------------------------------------------------- 16 16 Documentation/arch/arm64/silicon-errata.rst 的中文翻譯 ··· 23 23 中文版維護者：傅煒 Fu Wei <wefu@redhat.com> 24 24 中文版翻譯者：傅煒 Fu Wei <wefu@redhat.com> 25 25 中文版校譯者：傅煒 Fu Wei <wefu@redhat.com> 26 - 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> 26 + 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 27 27 本文翻譯提交時的 Git 檢出點爲： 1926e54f115725a9248d0c4c65c22acaf94de4c4 28 28 29 29 以下爲正文

+2 -2

Documentation/translations/zh_TW/arch/arm64/tagged-pointers.txt

··· 10 10 11 11 Maintainer: Will Deacon <will.deacon@arm.com> 12 12 Chinese maintainer: Fu Wei <wefu@redhat.com> 13 - Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> 13 + Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> 14 14 --------------------------------------------------------------------- 15 15 Documentation/arch/arm64/tagged-pointers.rst 的中文翻譯 16 16 ··· 22 22 中文版維護者：傅煒 Fu Wei <wefu@redhat.com> 23 23 中文版翻譯者：傅煒 Fu Wei <wefu@redhat.com> 24 24 中文版校譯者：傅煒 Fu Wei <wefu@redhat.com> 25 - 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> 25 + 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 26 26 27 27 以下爲正文 28 28 ---------------------------------------------------------------------

+1 -1

Documentation/translations/zh_TW/cpu-freq/core.rst

··· 4 4 5 5 :Original: :doc:`../../../cpu-freq/core` 6 6 :Translator: Yanteng Si <siyanteng@loongson.cn> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_core.rst: 10 10

+1 -1

Documentation/translations/zh_TW/cpu-freq/cpu-drivers.rst

··· 4 4 5 5 :Original: :doc:`../../../cpu-freq/cpu-drivers` 6 6 :Translator: Yanteng Si <siyanteng@loongson.cn> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_cpu-drivers.rst: 10 10

+1 -1

Documentation/translations/zh_TW/cpu-freq/cpufreq-stats.rst

··· 4 4 5 5 :Original: :doc:`../../../cpu-freq/cpufreq-stats` 6 6 :Translator: Yanteng Si <siyanteng@loongson.cn> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_cpufreq-stats.rst: 10 10

+1 -1

Documentation/translations/zh_TW/cpu-freq/index.rst

··· 4 4 5 5 :Original: :doc:`../../../cpu-freq/index` 6 6 :Translator: Yanteng Si <siyanteng@loongson.cn> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_index.rst: 10 10

+1 -1

Documentation/translations/zh_TW/disclaimer-zh_TW.rst

··· 7 7 8 8 .. note:: 9 9 如果您發現本文檔與原始文件有任何不同或者有翻譯問題，請聯繫該文件的譯者， 10 - 或者發送電子郵件給胡皓文以獲取幫助：<src.res@email.cn>。 10 + 或者發送電子郵件給胡皓文以獲取幫助：<src.res.211@gmail.com>。 11 11

+2 -2

Documentation/translations/zh_TW/filesystems/debugfs.rst

··· 14 14 中文版維護者：羅楚成 Chucheng Luo <luochucheng@vivo.com> 15 15 中文版翻譯者：羅楚成 Chucheng Luo <luochucheng@vivo.com> 16 16 中文版校譯者: 羅楚成 Chucheng Luo <luochucheng@vivo.com> 17 - 繁體中文版校譯者: 胡皓文 Hu Haowen <src.res@email.cn> 17 + 繁體中文版校譯者: 胡皓文 Hu Haowen <src.res.211@gmail.com> 18 18 19 19 20 20 21 21 版權所有2020 羅楚成 <luochucheng@vivo.com> 22 - 版權所有2021 胡皓文 Hu Haowen <src.res@email.cn> 22 + 版權所有2021 胡皓文 Hu Haowen <src.res.211@gmail.com> 23 23 24 24 25 25 Debugfs是內核開發人員在用戶空間獲取信息的簡單方法。與/proc不同，proc只提供進程

+1 -1

Documentation/translations/zh_TW/filesystems/index.rst

··· 4 4 5 5 :Original: :ref:`Documentation/filesystems/index.rst <filesystems_index>` 6 6 :Translator: Wang Wenhu <wenhu.wang@vivo.com> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_filesystems_index: 10 10

+1 -1

Documentation/translations/zh_TW/filesystems/sysfs.txt

··· 22 22 中文版維護者：傅煒 Fu Wei <tekkamanninja@gmail.com> 23 23 中文版翻譯者：傅煒 Fu Wei <tekkamanninja@gmail.com> 24 24 中文版校譯者：傅煒 Fu Wei <tekkamanninja@gmail.com> 25 - 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> 25 + 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 26 26 27 27 28 28 以下爲正文

+1 -1

Documentation/translations/zh_TW/filesystems/tmpfs.rst

··· 5 5 :Original: Documentation/filesystems/tmpfs.rst 6 6 7 7 Translated by Wang Qing <wangqing@vivo.com> 8 - and Hu Haowen <src.res@email.cn> 8 + and Hu Haowen <src.res.211@gmail.com> 9 9 10 10 ===== 11 11 Tmpfs

+1 -1

Documentation/translations/zh_TW/filesystems/virtiofs.rst

··· 11 11 中文版翻譯者：王文虎 Wang Wenhu <wenhu.wang@vivo.com> 12 12 中文版校譯者：王文虎 Wang Wenhu <wenhu.wang@vivo.com> 13 13 中文版校譯者：王文虎 Wang Wenhu <wenhu.wang@vivo.com> 14 - 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> 14 + 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 15 15 16 16 =========================================== 17 17 virtiofs: virtio-fs 主機<->客機共享文件系統

+4 -4

Documentation/translations/zh_TW/gpio.txt

··· 8 8 9 9 Maintainer: Grant Likely <grant.likely@secretlab.ca> 10 10 Linus Walleij <linus.walleij@linaro.org> 11 - Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> 11 + Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> 12 12 --------------------------------------------------------------------- 13 13 Documentation/admin-guide/gpio 的繁體中文翻譯 14 14 ··· 18 18 19 19 英文版維護者： Grant Likely <grant.likely@secretlab.ca> 20 20 Linus Walleij <linus.walleij@linaro.org> 21 - 繁體中文版維護者：胡皓文 Hu Haowen <src.res@email.cn> 22 - 繁體中文版翻譯者：胡皓文 Hu Haowen <src.res@email.cn> 23 - 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> 21 + 繁體中文版維護者：胡皓文 Hu Haowen <src.res.211@gmail.com> 22 + 繁體中文版翻譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 23 + 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 24 24 25 25 以下爲正文 26 26 ---------------------------------------------------------------------

+78 -122

Documentation/translations/zh_TW/index.rst

··· 15 15 16 16 .. note:: 17 17 內核文檔繁體中文版的翻譯工作正在進行中。如果您願意並且有時間參與這項工 18 - 作，歡迎提交補丁給胡皓文 <src.res@email.cn>。 18 + 作，歡迎提交補丁給胡皓文 <src.res.211@gmail.com>。 19 19 20 - 許可證文檔 21 - ---------- 20 + 與Linux 內核社區一起工作 21 + ------------------------ 22 22 23 - 下面的文檔介紹了Linux內核原始碼的許可證（GPLv2）、如何在原始碼樹中正確標記 24 - 單個文件的許可證、以及指向完整許可證文本的連結。 25 - 26 - Documentation/translations/zh_TW/process/license-rules.rst 27 - 28 - 用戶文檔 29 - -------- 30 - 31 - 下面的手冊是爲內核用戶編寫的——即那些試圖讓它在給定系統上以最佳方式工作的 32 - 用戶。 23 + 與內核開發社區進行協作並將工作推向上游的基本指南。 33 24 34 25 .. toctree:: 35 - :maxdepth: 2 26 + :maxdepth: 1 36 27 37 - admin-guide/index 28 + process/development-process 29 + process/submitting-patches 30 + 行爲準則 <process/code-of-conduct> 31 + 完整開發流程文檔 <process/index> 38 32 39 33 TODOList: 40 34 41 - * kbuild/index 35 + * maintainer/index 36 + 37 + 內部API文檔 38 + ----------- 39 + 40 + 開發人員使用的內核內部交互接口手冊。 41 + 42 + TODOList: 43 + 44 + * core-api/index 45 + * driver-api/index 46 + * 內核中的鎖 <locking/index> 47 + * subsystem-apis 48 + 49 + 開發工具和流程 50 + -------------- 51 + 52 + 爲所有內核開發人員提供有用信息的各種其他手冊。 53 + 54 + .. toctree:: 55 + :maxdepth: 1 56 + 57 + process/license-rules 58 + 59 + TODOList: 60 + 61 + * doc-guide/index 62 + * dev-tools/index 63 + * dev-tools/testing-overview 64 + * kernel-hacking/index 65 + * rust/index 66 + * trace/index 67 + * fault-injection/index 68 + * livepatch/index 69 + 70 + 面向用戶的文檔 71 + -------------- 72 + 73 + 下列手冊針對 74 + 希望內核在給定系統上以最佳方式工作的*用戶*， 75 + 和查找內核用戶空間API信息的程序開發人員。 76 + 77 + .. toctree:: 78 + :maxdepth: 1 79 + 80 + admin-guide/index 81 + admin-guide/reporting-issues.rst 82 + 83 + TODOList: 84 + 85 + * userspace-api/index 86 + * 內核構建系統 <kbuild/index> 87 + * 用戶空間工具 <tools/index> 88 + 89 + 也可參考獨立於內核文檔的 `Linux 手冊頁 <https://www.kernel.org/doc/man-pages/>`_ 。 42 90 43 91 固件相關文檔 44 92 ------------ 45 93 46 - 下列文檔描述了內核需要的平台固件相關信息。 94 + 下列文檔描述了內核需要的平臺固件相關信息。 47 95 48 96 TODOList: 49 97 50 - * firmware-guide/index 51 98 * devicetree/index 99 + * firmware-guide/index 52 100 53 - 應用程式開發人員文檔 54 - -------------------- 55 - 56 - 用戶空間API手冊涵蓋了描述應用程式開發人員可見內核接口方面的文檔。 57 - 58 - TODOlist: 59 - 60 - * userspace-api/index 61 - 62 - 內核開發簡介 101 + 體系結構文檔 63 102 ------------ 64 103 65 - 這些手冊包含有關如何開發內核的整體信息。內核社區非常龐大，一年下來有數千名 66 - 開發人員做出貢獻。與任何大型社區一樣，知道如何完成任務將使得更改合併的過程 67 - 變得更加容易。 68 - 69 - .. toctree:: 70 - :maxdepth: 2 71 - 72 - process/index 73 - 74 104 TODOList: 75 105 76 - * dev-tools/index 77 - * doc-guide/index 78 - * kernel-hacking/index 79 - * trace/index 80 - * maintainer/index 81 - * fault-injection/index 82 - * livepatch/index 83 - * rust/index 84 - 85 - 內核API文檔 86 - ----------- 87 - 88 - 以下手冊從內核開發人員的角度詳細介紹了特定的內核子系統是如何工作的。這裡的 89 - 大部分信息都是直接從內核原始碼獲取的，並根據需要添加補充材料（或者至少是在 90 - 我們設法添加的時候——可能不是所有的都是有需要的）。 91 - 92 - .. toctree:: 93 - :maxdepth: 2 94 - 95 - cpu-freq/index 96 - filesystems/index 97 - 98 - TODOList: 99 - 100 - * driver-api/index 101 - * core-api/index 102 - * locking/index 103 - * accounting/index 104 - * block/index 105 - * cdrom/index 106 - * ide/index 107 - * fb/index 108 - * fpga/index 109 - * hid/index 110 - * i2c/index 111 - * iio/index 112 - * isdn/index 113 - * infiniband/index 114 - * leds/index 115 - * netlabel/index 116 - * networking/index 117 - * pcmcia/index 118 - * power/index 119 - * target/index 120 - * timers/index 121 - * spi/index 122 - * w1/index 123 - * watchdog/index 124 - * virt/index 125 - * input/index 126 - * hwmon/index 127 - * gpu/index 128 - * security/index 129 - * sound/index 130 - * crypto/index 131 - * mm/index 132 - * bpf/index 133 - * usb/index 134 - * PCI/index 135 - * scsi/index 136 - * misc-devices/index 137 - * scheduler/index 138 - * mhi/index 139 - 140 - 體系結構無關文檔 141 - ---------------- 142 - 143 - TODOList: 144 - 145 - * asm-annotations 146 - 147 - 特定體系結構文檔 148 - ---------------- 149 - 150 - .. toctree:: 151 - :maxdepth: 2 152 - 153 - arch/arm64/index 154 - 155 - TODOList: 156 - 157 - * arch 106 + * arch/index 158 107 159 108 其他文檔 160 109 -------- 161 110 162 - 有幾份未排序的文檔似乎不適合放在文檔的其他部分，或者可能需要進行一些調整和/或 111 + 有幾份未分類的文檔似乎不適合放在文檔的其他部分，或者可能需要進行一些調整和/或 163 112 轉換爲reStructureText格式，也有可能太舊。 164 113 165 114 TODOList: 166 115 167 116 * staging/index 168 - * watch_queue 169 117 170 - 目錄和表格 118 + 術語表 119 + ------ 120 + 121 + TODOList: 122 + 123 + * glossary 124 + 125 + 126 + 索引和表格 171 127 ---------- 172 128 173 129 * :ref:`genindex`

+4 -4

Documentation/translations/zh_TW/io_ordering.txt

··· 6 6 help. Contact the Chinese maintainer if this translation is outdated 7 7 or if there is a problem with the translation. 8 8 9 - Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> 9 + Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> 10 10 --------------------------------------------------------------------- 11 11 Documentation/driver-api/io_ordering.rst 的繁體中文翻譯 12 12 ··· 14 14 交流有困難的話，也可以向繁體中文版維護者求助。如果本翻譯更新不及時或 15 15 者翻譯存在問題，請聯繫繁體中文版維護者。 16 16 17 - 繁體中文版維護者：胡皓文 Hu Haowen <src.res@email.cn> 18 - 繁體中文版翻譯者：胡皓文 Hu Haowen <src.res@email.cn> 19 - 繁體中文版校譯者：胡皓文 Hu Haowen <src.res@email.cn> 17 + 繁體中文版維護者：胡皓文 Hu Haowen <src.res.211@gmail.com> 18 + 繁體中文版翻譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 19 + 繁體中文版校譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 20 20 21 21 22 22 以下爲正文

+1 -1

Documentation/translations/zh_TW/process/1.Intro.rst

··· 11 11 :校譯: 12 12 13 13 吳想成 Wu XiangCheng <bobwxc@email.cn> 14 - 胡皓文 Hu Haowen <src.res@email.cn> 14 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 15 15 16 16 .. _tw_development_process_intro: 17 17

+1 -1

Documentation/translations/zh_TW/process/2.Process.rst

··· 11 11 :校譯: 12 12 13 13 吳想成 Wu XiangCheng <bobwxc@email.cn> 14 - 胡皓文 Hu Haowen <src.res@email.cn> 14 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 15 15 16 16 .. _tw_development_process: 17 17

+1 -1

Documentation/translations/zh_TW/process/3.Early-stage.rst

··· 11 11 :校譯: 12 12 13 13 吳想成 Wu XiangCheng <bobwxc@email.cn> 14 - 胡皓文 Hu Haowen <src.res@email.cn> 14 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 15 15 16 16 .. _tw_development_early_stage: 17 17

+1 -1

Documentation/translations/zh_TW/process/4.Coding.rst

··· 11 11 :校譯: 12 12 13 13 吳想成 Wu XiangCheng <bobwxc@email.cn> 14 - 胡皓文 Hu Haowen <src.res@email.cn> 14 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 15 15 16 16 .. _tw_development_coding: 17 17

+1 -1

Documentation/translations/zh_TW/process/5.Posting.rst

··· 11 11 :校譯: 12 12 13 13 吳想成 Wu XiangCheng <bobwxc@email.cn> 14 - 胡皓文 Hu Haowen <src.res@email.cn> 14 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 15 15 16 16 .. _tw_development_posting: 17 17

+1 -1

Documentation/translations/zh_TW/process/6.Followthrough.rst

··· 11 11 :校譯: 12 12 13 13 吳想成 Wu XiangCheng <bobwxc@email.cn> 14 - 胡皓文 Hu Haowen <src.res@email.cn> 14 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 15 15 16 16 .. _tw_development_followthrough: 17 17

+1 -1

Documentation/translations/zh_TW/process/7.AdvancedTopics.rst

··· 11 11 :校譯: 12 12 13 13 吳想成 Wu XiangCheng <bobwxc@email.cn> 14 - 胡皓文 Hu Haowen <src.res@email.cn> 14 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 15 15 16 16 .. _tw_development_advancedtopics: 17 17

+1 -1

Documentation/translations/zh_TW/process/8.Conclusion.rst

··· 10 10 :校譯: 11 11 12 12 吳想成 Wu XiangCheng <bobwxc@email.cn> 13 - 胡皓文 Hu Haowen <src.res@email.cn> 13 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 14 14 15 15 .. _tw_development_conclusion: 16 16

+1 -1

Documentation/translations/zh_TW/process/code-of-conduct-interpretation.rst

··· 4 4 5 5 :Original: :ref:`Documentation/process/code-of-conduct-interpretation.rst <code_of_conduct_interpretation>` 6 6 :Translator: Alex Shi <alex.shi@linux.alibaba.com> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_code_of_conduct_interpretation: 10 10

+1 -1

Documentation/translations/zh_TW/process/code-of-conduct.rst

··· 4 4 5 5 :Original: :ref:`Documentation/process/code-of-conduct.rst <code_of_conduct>` 6 6 :Translator: Alex Shi <alex.shi@linux.alibaba.com> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_code_of_conduct: 10 10

+1 -1

Documentation/translations/zh_TW/process/coding-style.rst

··· 15 15 管旭東 Xudong Guan <xudong.guan@gmail.com> 16 16 Li Zefan <lizf@cn.fujitsu.com> 17 17 Wang Chen <wangchen@cn.fujitsu.com> 18 - Hu Haowen <src.res@email.cn> 18 + Hu Haowen <src.res.211@gmail.com> 19 19 20 20 Linux 內核代碼風格 21 21 =========================

+1 -1

Documentation/translations/zh_TW/process/development-process.rst

··· 4 4 5 5 :Original: :ref:`Documentation/process/development-process.rst <development_process_main>` 6 6 :Translator: Alex Shi <alex.shi@linux.alibaba.com> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_development_process_main: 10 10

+1 -1

Documentation/translations/zh_TW/process/email-clients.rst

··· 14 14 中文版校譯者： Yinglin Luan <synmyth@gmail.com> 15 15 Xiaochen Wang <wangxiaochen0@gmail.com> 16 16 yaxinsn <yaxinsn@163.com> 17 - Hu Haowen <src.res@email.cn> 17 + Hu Haowen <src.res.211@gmail.com> 18 18 19 19 Linux郵件客戶端配置信息 20 20 =======================

+1 -1

Documentation/translations/zh_TW/process/embargoed-hardware-issues.rst

··· 4 4 5 5 :Original: :ref:`Documentation/process/embargoed-hardware-issues.rst <embargoed_hardware_issues>` 6 6 :Translator: Alex Shi <alex.shi@linux.alibaba.com> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 被限制的硬體問題 10 10 ================

+1 -1

Documentation/translations/zh_TW/process/howto.rst

··· 16 16 鍾宇 TripleX Chung <xxx.phy@gmail.com> 17 17 陳琦 Maggie Chen <chenqi@beyondsoft.com> 18 18 王聰 Wang Cong <xiyou.wangcong@gmail.com> 19 - 胡皓文 Hu Haowen <src.res@email.cn> 19 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 20 20 21 21 如何參與Linux內核開發 22 22 =====================

+1 -1

Documentation/translations/zh_TW/process/index.rst

··· 9 9 10 10 :Original: :ref:`Documentation/process/index.rst <process_index>` 11 11 :Translator: Alex Shi <alex.shi@linux.alibaba.com> 12 - Hu Haowen <src.res@email.cn> 12 + Hu Haowen <src.res.211@gmail.com> 13 13 14 14 .. _tw_process_index: 15 15

+1 -1

Documentation/translations/zh_TW/process/kernel-driver-statement.rst

··· 6 6 7 7 :Original: :ref:`Documentation/process/kernel-driver-statement.rst <process_statement_driver>` 8 8 :Translator: Alex Shi <alex.shi@linux.alibaba.com> 9 - Hu Haowen <src.res@email.cn> 9 + Hu Haowen <src.res.211@gmail.com> 10 10 11 11 內核驅動聲明 12 12 ------------

+1 -1

Documentation/translations/zh_TW/process/kernel-enforcement-statement.rst

··· 6 6 7 7 :Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>` 8 8 :Translator: Alex Shi <alex.shi@linux.alibaba.com> 9 - Hu Haowen <src.res@email.cn> 9 + Hu Haowen <src.res.211@gmail.com> 10 10 11 11 Linux 內核執行聲明 12 12 ------------------

+1 -1

Documentation/translations/zh_TW/process/license-rules.rst

··· 6 6 7 7 :Original: :ref:`Documentation/process/license-rules.rst <kernel_licensing>` 8 8 :Translator: Alex Shi <alex.shi@linux.alibaba.com> 9 - Hu Haowen <src.res@email.cn> 9 + Hu Haowen <src.res.211@gmail.com> 10 10 11 11 .. _tw_kernel_licensing: 12 12

+1 -1

Documentation/translations/zh_TW/process/magic-number.rst

··· 12 12 中文版維護者：賈威威 Jia Wei Wei <harryxiyou@gmail.com> 13 13 中文版翻譯者：賈威威 Jia Wei Wei <harryxiyou@gmail.com> 14 14 中文版校譯者：賈威威 Jia Wei Wei <harryxiyou@gmail.com> 15 - 胡皓文 Hu Haowen <src.res@email.cn> 15 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 16 16 17 17 Linux 魔術數 18 18 ============

+1 -1

Documentation/translations/zh_TW/process/management-style.rst

··· 4 4 5 5 :Original: :ref:`Documentation/process/management-style.rst <managementstyle>` 6 6 :Translator: Alex Shi <alex.shi@linux.alibaba.com> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_managementstyle: 10 10

+1 -1

Documentation/translations/zh_TW/process/programming-language.rst

··· 4 4 5 5 :Original: :ref:`Documentation/process/programming-language.rst <programming_language>` 6 6 :Translator: Alex Shi <alex.shi@linux.alibaba.com> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_programming_language: 10 10

+1 -1

Documentation/translations/zh_TW/process/stable-api-nonsense.rst

··· 12 12 中文版維護者：鍾宇 TripleX Chung <xxx.phy@gmail.com> 13 13 中文版翻譯者：鍾宇 TripleX Chung <xxx.phy@gmail.com> 14 14 中文版校譯者：李陽 Li Yang <leoyang.li@nxp.com> 15 - 胡皓文 Hu Haowen <src.res@email.cn> 15 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 16 16 17 17 Linux 內核驅動接口 18 18 ==================

+1 -1

Documentation/translations/zh_TW/process/stable-kernel-rules.rst

··· 15 15 中文版校譯者： 16 16 - 李陽 Li Yang <leoyang.li@nxp.com> 17 17 - Kangkai Yin <e12051@motorola.com> 18 - - 胡皓文 Hu Haowen <src.res@email.cn> 18 + - 胡皓文 Hu Haowen <src.res.211@gmail.com> 19 19 20 20 所有你想知道的事情 - 關於linux穩定版發布 21 21 ========================================

+1 -1

Documentation/translations/zh_TW/process/submit-checklist.rst

··· 4 4 5 5 :Original: :ref:`Documentation/process/submit-checklist.rst <submitchecklist>` 6 6 :Translator: Alex Shi <alex.shi@linux.alibaba.com> 7 - Hu Haowen <src.res@email.cn> 7 + Hu Haowen <src.res.211@gmail.com> 8 8 9 9 .. _tw_submitchecklist: 10 10

+1 -1

Documentation/translations/zh_TW/process/submitting-patches.rst

··· 13 13 時奎亮 Alex Shi <alex.shi@linux.alibaba.com> 14 14 中文版校譯者：李陽 Li Yang <leoyang.li@nxp.com> 15 15 王聰 Wang Cong <xiyou.wangcong@gmail.com> 16 - 胡皓文 Hu Haowen <src.res@email.cn> 16 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 17 17 18 18 19 19 如何讓你的改動進入內核

+1 -1

Documentation/translations/zh_TW/process/volatile-considered-harmful.rst

··· 17 17 中文版校譯者：張漢輝 Eugene Teo <eugeneteo@kernel.sg> 18 18 楊瑞 Dave Young <hidave.darkstar@gmail.com> 19 19 時奎亮 Alex Shi <alex.shi@linux.alibaba.com> 20 - 胡皓文 Hu Haowen <src.res@email.cn> 20 + 胡皓文 Hu Haowen <src.res.211@gmail.com> 21 21 22 22 爲什麼不應該使用「volatile」類型 23 23 ================================

+5 -5

Documentation/translations/zh_TW/sparse.txt

··· 6 6 help. Contact the Chinese maintainer if this translation is outdated 7 7 or if there is a problem with the translation. 8 8 9 - Traditional Chinese maintainer: Hu Haowen <src.res@email.cn> 9 + Traditional Chinese maintainer: Hu Haowen <src.res.211@gmail.com> 10 10 --------------------------------------------------------------------- 11 11 Documentation/dev-tools/sparse.rst 的繁體中文翻譯 12 12 ··· 14 14 交流有困難的話，也可以向繁體中文版維護者求助。如果本翻譯更新不及時或 15 15 者翻譯存在問題，請聯繫繁體中文版維護者。 16 16 17 - 繁體中文版維護者：胡皓文 Hu Haowen <src.res@email.cn> 18 - 繁體中文版翻譯者：胡皓文 Hu Haowen <src.res@email.cn> 17 + 繁體中文版維護者：胡皓文 Hu Haowen <src.res.211@gmail.com> 18 + 繁體中文版翻譯者：胡皓文 Hu Haowen <src.res.211@gmail.com> 19 19 20 20 以下爲正文 21 21 --------------------------------------------------------------------- ··· 66 66 67 67 你可以從 Sparse 的主頁獲取最新的發布版本： 68 68 69 - http://www.kernel.org/pub/linux/kernel/people/josh/sparse/ 69 + https://www.kernel.org/pub/software/devel/sparse/dist/ 70 70 71 71 或者，你也可以使用 git 克隆最新的 sparse 開發版本： 72 72 73 - git://git.kernel.org/pub/scm/linux/kernel/git/josh/sparse.git 73 + git://git.kernel.org/pub/scm/devel/sparse/sparse.git 74 74 75 75 一旦你下載了源碼，只要以普通用戶身份運行： 76 76

+1 -1

Documentation/usb/gadget_uvc.rst

··· 168 168 169 169 The UVC specification requires that Format and Frame descriptors be preceded by 170 170 Headers detailing things such as the number and cumulative size of the different 171 - Format descriptors that follow. This and similar operations are acheived in 171 + Format descriptors that follow. This and similar operations are achieved in 172 172 configfs by linking between the configfs item representing the header and the 173 173 config items representing those other descriptors, in this manner: 174 174

+1 -1

Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst

··· 3293 3293 3294 3294 .. c:type:: v4l2_av1_loop_restoration 3295 3295 3296 - AV1 Loop Restauration as described in section 6.10.15 "Loop restoration params 3296 + AV1 Loop Restoration as described in section 6.10.15 "Loop restoration params 3297 3297 semantics" of :ref:`av1`. 3298 3298 3299 3299 .. cssclass:: longtable

+1 -1

Documentation/userspace-api/media/v4l/metafmt-d4xx.rst

··· 237 237 camera projectors. As we have another field for "Laser Power" we introduced 238 238 "LED Power" for extra emitter. 239 239 240 - The "Laser mode" __u32 fiels has been split into: :: 240 + The "Laser mode" __u32 fields has been split into: :: 241 241 1 __u8 Emitter mode 242 242 2 __u8 RFU byte 243 243 3 __u16 LED Power

+1 -1

Documentation/userspace-api/netlink/intro.rst

··· 615 615 is defined by the 2 lowest bits of the message type, so commands for 616 616 new objects would always be allocated with a stride of 4. 617 617 618 - Each object would also have it's own fixed metadata shared by all request 618 + Each object would also have its own fixed metadata shared by all request 619 619 types (e.g. struct ifinfomsg for netdev requests, struct ifaddrmsg for address 620 620 requests, struct tcmsg for qdisc requests). 621 621

+1 -1

Documentation/virt/hyperv/clocks.rst

··· 60 60 entirely in user space. The vDSO is implemented by mapping the 61 61 shared page with scale and offset values into user space. User 62 62 space code performs the same algorithm of reading the TSC and 63 - appying the scale and offset to get the constant 10 MHz clock. 63 + applying the scale and offset to get the constant 10 MHz clock. 64 64 65 65 Linux clockevents are based on Hyper-V synthetic timer 0. While 66 66 Hyper-V offers 4 synthetic timers for each CPU, Linux only uses

+13 -13

Documentation/virt/kvm/api.rst

··· 578 578 RISC-V: 579 579 ^^^^^^^ 580 580 581 - Queues an external interrupt to be injected into the virutal CPU. This ioctl 581 + Queues an external interrupt to be injected into the virtual CPU. This ioctl 582 582 is overloaded with 2 different irq values: 583 583 584 584 a) KVM_INTERRUPT_SET ··· 2722 2722 a Guest VCPU runs. It will have ISA feature bits matching underlying host 2723 2723 set by default. 2724 2724 2725 - RISC-V core registers represent the general excution state of a Guest VCPU 2725 + RISC-V core registers represent the general execution state of a Guest VCPU 2726 2726 and it has the following id bit patterns:: 2727 2727 2728 2728 0x8020 0000 02 <index into the kvm_riscv_core struct:24> (32bit Host) ··· 5232 5232 Deregister the VM from the Ultravisor and reclaim the memory that had 5233 5233 been donated to the Ultravisor, making it usable by the kernel again. 5234 5234 All registered VCPUs are converted back to non-protected ones. If a 5235 - previous protected VM had been prepared for asynchonous teardown with 5235 + previous protected VM had been prepared for asynchronous teardown with 5236 5236 KVM_PV_ASYNC_CLEANUP_PREPARE and not subsequently torn down with 5237 5237 KVM_PV_ASYNC_CLEANUP_PERFORM, it will be torn down in this call 5238 5238 together with the current protected VM. ··· 5692 5692 5693 5693 ``KVM_SREGS2_FLAGS_PDPTRS_VALID`` 5694 5694 5695 - Indicates thats the struct contain valid PDPTR values. 5695 + Indicates that the struct contains valid PDPTR values. 5696 5696 5697 5697 5698 5698 4.132 KVM_SET_SREGS2 ··· 6263 6263 6264 6264 It is strongly recommended that userspace use ``KVM_EXIT_IO`` (x86) or 6265 6265 ``KVM_EXIT_MMIO`` (all except s390) to implement functionality that 6266 - requires a guest to interact with host userpace. 6266 + requires a guest to interact with host userspace. 6267 6267 6268 6268 .. note:: KVM_EXIT_IO is significantly faster than KVM_EXIT_MMIO. 6269 6269 ··· 6336 6336 } s390_ucontrol; 6337 6337 6338 6338 s390 specific. A page fault has occurred for a user controlled virtual 6339 - machine (KVM_VM_S390_UNCONTROL) on it's host page table that cannot be 6339 + machine (KVM_VM_S390_UNCONTROL) on its host page table that cannot be 6340 6340 resolved by the kernel. 6341 6341 The program code and the translation exception code that were placed 6342 6342 in the cpu's lowcore are presented here as defined by the z Architecture ··· 7510 7510 attribute is not supported by KVM. 7511 7511 7512 7512 KVM_CAP_SGX_ATTRIBUTE enables a userspace VMM to grant a VM access to one or 7513 - more priveleged enclave attributes. args[0] must hold a file handle to a valid 7513 + more privileged enclave attributes. args[0] must hold a file handle to a valid 7514 7514 SGX attribute file corresponding to an attribute that is supported/restricted 7515 7515 by KVM (currently only PROVISIONKEY). 7516 7516 ··· 7928 7928 7929 7929 This capability indicates that userspace can load HV_X64_MSR_VP_INDEX msr. Its 7930 7930 value is used to denote the target vcpu for a SynIC interrupt. For 7931 - compatibilty, KVM initializes this msr to KVM's internal vcpu index. When this 7931 + compatibility, KVM initializes this msr to KVM's internal vcpu index. When this 7932 7932 capability is absent, userspace can still query this msr's value. 7933 7933 7934 7934 8.13 KVM_CAP_S390_AIS_MIGRATION ··· 8118 8118 :Parameters: args[0] - size of the dirty log ring 8119 8119 8120 8120 KVM is capable of tracking dirty memory using ring buffers that are 8121 - mmaped into userspace; there is one dirty ring per vcpu. 8121 + mmapped into userspace; there is one dirty ring per vcpu. 8122 8122 8123 8123 The dirty ring is available to userspace as an array of 8124 - ``struct kvm_dirty_gfn``. Each dirty entry it's defined as:: 8124 + ``struct kvm_dirty_gfn``. Each dirty entry is defined as:: 8125 8125 8126 8126 struct kvm_dirty_gfn { 8127 8127 __u32 flags; ··· 8160 8160 | | 8161 8161 +------------------------------------------+ 8162 8162 8163 - To harvest the dirty pages, userspace accesses the mmaped ring buffer 8163 + To harvest the dirty pages, userspace accesses the mmapped ring buffer 8164 8164 to read the dirty GFNs. If the flags has the DIRTY bit set (at this stage 8165 8165 the RESET bit must be cleared), then it means this GFN is a dirty GFN. 8166 8166 The userspace should harvest this GFN and mark the flags from state ··· 8286 8286 and KVM_XEN_GET_ATTR ioctls. This controls whether KVM will set the 8287 8287 XEN_RUNSTATE_UPDATE flag in guest memory mapped vcpu_runstate_info during 8288 8288 updates of the runstate information. Note that versions of KVM which support 8289 - the RUNSTATE feature above, but not thie RUNSTATE_UPDATE_FLAG feature, will 8289 + the RUNSTATE feature above, but not the RUNSTATE_UPDATE_FLAG feature, will 8290 8290 always set the XEN_RUNSTATE_UPDATE flag when updating the guest structure, 8291 8291 which is perhaps counterintuitive. When this flag is advertised, KVM will 8292 8292 behave more correctly, not using the XEN_RUNSTATE_UPDATE flag until/unless ··· 8335 8335 8336 8336 When enabled, KVM will disable emulated Hyper-V features provided to the 8337 8337 guest according to the bits Hyper-V CPUID feature leaves. Otherwise, all 8338 - currently implmented Hyper-V features are provided unconditionally when 8338 + currently implemented Hyper-V features are provided unconditionally when 8339 8339 Hyper-V identification is set in the HYPERV_CPUID_INTERFACE (0x40000001) 8340 8340 leaf. 8341 8341

+1 -1

Documentation/virt/kvm/devices/vm.rst

··· 92 92 KVM does not enforce or limit the cpu model data in any form. Take the information 93 93 retrieved by means of KVM_S390_VM_CPU_MACHINE as hint for reasonable configuration 94 94 setups. Instruction interceptions triggered by additionally set facility bits that 95 - are not handled by KVM need to by imlemented in the VM driver code. 95 + are not handled by KVM need to by implemented in the VM driver code. 96 96 97 97 :Parameters: address of buffer to store/set the processor related cpu 98 98 data of type struct kvm_s390_vm_cpu_processor*.

+1 -1

Documentation/virt/kvm/devices/xive.rst

··· 50 50 51 51 When a device is passed-through into the guest, the source 52 52 interrupts are from a different HW controller (PHB4) and the ESB 53 - pages exposed to the guest should accommadate this change. 53 + pages exposed to the guest should accommodate this change. 54 54 55 55 The passthru_irq helpers, kvmppc_xive_set_mapped() and 56 56 kvmppc_xive_clr_mapped() are called when the device HW irqs are

+1 -1

Documentation/virt/kvm/halt-polling.rst

··· 14 14 Polling provides a latency advantage in cases where the guest can be run again 15 15 very quickly by at least saving us a trip through the scheduler, normally on 16 16 the order of a few micro-seconds, although performance benefits are workload 17 - dependant. In the event that no wakeup source arrives during the polling 17 + dependent. In the event that no wakeup source arrives during the polling 18 18 interval or some other task on the runqueue is runnable the scheduler is 19 19 invoked. Thus halt polling is especially useful on workloads with very short 20 20 wakeup periods where the time spent halt polling is minimised and the time

+1 -1

Documentation/virt/kvm/x86/mmu.rst

··· 245 245 unsynchronized children). 246 246 unsync_child_bitmap: 247 247 A bitmap indicating which sptes in spt point (directly or indirectly) at 248 - pages that may be unsynchronized. Used to quickly locate all unsychronized 248 + pages that may be unsynchronized. Used to quickly locate all unsynchronized 249 249 pages reachable from a given page. 250 250 clear_spte_count: 251 251 Only present on 32-bit hosts, where a 64-bit spte cannot be written

+1 -1

Documentation/virt/kvm/x86/running-nested-guests.rst

··· 169 169 $ modprobe kvm nested=1 170 170 171 171 .. note:: On s390x, the kernel parameter ``hpage`` is mutually exclusive 172 - with the ``nested`` paramter — i.e. to be able to enable 172 + with the ``nested`` parameter — i.e. to be able to enable 173 173 ``nested``, the ``hpage`` parameter *must* be disabled. 174 174 175 175 2. The guest hypervisor (L1) must be provided with the ``sie`` CPU

+1 -1

Documentation/virt/uml/user_mode_linux_howto_v2.rst

··· 1224 1224 security-wise. Allowing it as a loadable module parameter 1225 1225 isn't. 1226 1226 1227 - If such functionality is desireable for a particular application 1227 + If such functionality is desirable for a particular application 1228 1228 (e.g. loading BPF "firmware" for raw socket network transports), 1229 1229 it should be off by default and should be explicitly turned on 1230 1230 as a command line parameter at startup.

+1 -1

Documentation/w1/slaves/w1_therm.rst

··· 58 58 59 59 ``conv_time`` is used to get current conversion time (read), and 60 60 adjust it (write). A temperature conversion time depends on the device type and 61 - it's current resolution. Default conversion time is set by the driver according 61 + its current resolution. Default conversion time is set by the driver according 62 62 to the device datasheet. A conversion time for many original device clones 63 63 deviate from datasheet specs. There are three options: 1) manually set the 64 64 correct conversion time by writing a value in milliseconds to ``conv_time``; 2)

+1 -1

Documentation/w1/w1-generic.rst

··· 101 101 w1_master_slave_count (ro) the number of slaves found 102 102 w1_master_slaves (ro) the names of the slaves, one per line 103 103 w1_master_timeout (ro) the delay in seconds between searches 104 - w1_master_timeout_us (ro) the delay in microseconds beetwen searches 104 + w1_master_timeout_us (ro) the delay in microseconds between searches 105 105 ========================= ===================================================== 106 106 107 107 If you have a w1 bus that never changes (you don't add or remove devices),

+1 -1

Documentation/w1/w1-netlink.rst

··· 66 66 zero or more attached w1_netlink_cmd messages. 67 67 68 68 For event messages there are no w1_netlink_cmd embedded structures, 69 - only connector header and w1_netlink_msg strucutre with "len" field 69 + only connector header and w1_netlink_msg structure with "len" field 70 70 being zero and filled type (one of event types) and id: 71 71 either 8 bytes of slave unique id in host order, 72 72 or master's id, which is assigned to bus master device

+1 -1

Documentation/watchdog/watchdog-kernel-api.rst

··· 77 77 * groups: List of sysfs attribute groups to create when creating the watchdog 78 78 device. 79 79 * info: a pointer to a watchdog_info structure. This structure gives some 80 - additional information about the watchdog timer itself. (Like it's unique name) 80 + additional information about the watchdog timer itself. (Like its unique name) 81 81 * ops: a pointer to the list of watchdog operations that the watchdog supports. 82 82 * gov: a pointer to the assigned watchdog device pretimeout governor or NULL. 83 83 * timeout: the watchdog timer's timeout value (in seconds).

+2 -2

Documentation/wmi/devices/dell-wmi-ddv.rst

··· 185 185 WMI method BatteryeRawAnalytics() 186 186 --------------------------------- 187 187 188 - Returns a buffer usually containg 12 blocks of analytics data. 188 + Returns a buffer usually containing 12 blocks of analytics data. 189 189 Those blocks contain: 190 190 191 191 - a block number starting with 0 (u8) ··· 218 218 WMI method FanSensorInformation() 219 219 --------------------------------- 220 220 221 - Returns a buffer containg fan sensor entries, terminated 221 + Returns a buffer containing fan sensor entries, terminated 222 222 with a single ``0xff``. 223 223 Those entries contain: 224 224

+5 -5

MAINTAINERS

··· 6237 6237 M: Jonathan Corbet <corbet@lwn.net> 6238 6238 L: workflows@vger.kernel.org 6239 6239 S: Maintained 6240 + F: Documentation/maintainer/ 6240 6241 F: Documentation/process/ 6241 6242 6242 6243 DOCUMENTATION REPORTING ISSUES ··· 12308 12307 L: loongarch@lists.linux.dev 12309 12308 S: Maintained 12310 12309 T: git git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson.git 12311 - F: Documentation/loongarch/ 12312 - F: Documentation/translations/zh_CN/loongarch/ 12310 + F: Documentation/arch/loongarch/ 12311 + F: Documentation/translations/zh_CN/arch/loongarch/ 12313 12312 F: arch/loongarch/ 12314 12313 F: drivers/*/*loongarch* 12315 12314 ··· 14251 14250 Q: https://patchwork.kernel.org/project/linux-mips/list/ 14252 14251 T: git git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git 14253 14252 F: Documentation/devicetree/bindings/mips/ 14254 - F: Documentation/mips/ 14253 + F: Documentation/arch/mips/ 14255 14254 F: arch/mips/ 14256 14255 F: drivers/platform/mips/ 14257 14256 F: include/dt-bindings/mips/ ··· 21763 21762 F: kernel/trace/trace_sched_wakeup.c 21764 21763 21765 21764 TRADITIONAL CHINESE DOCUMENTATION 21766 - M: Hu Haowen <src.res@email.cn> 21767 - L: linux-doc-tw-discuss@lists.sourceforge.net (moderated for non-subscribers) 21765 + M: Hu Haowen <src.res.211@gmail.com> 21768 21766 S: Maintained 21769 21767 W: https://github.com/srcres258/linux-doc 21770 21768 T: git git://github.com/srcres258/linux-doc.git doc-zh-tw

+1 -1

drivers/irqchip/Kconfig

··· 567 567 help 568 568 Support for the LoongArch CPU Interrupt Controller. For details of 569 569 irq chip hierarchy on LoongArch platforms please read the document 570 - Documentation/loongarch/irq-chip-model.rst. 570 + Documentation/arch/loongarch/irq-chip-model.rst. 571 571 572 572 config LOONGSON_LIOINTC 573 573 bool "Loongson Local I/O Interrupt Controller"

+176 -21

include/linux/jiffies.h

··· 72 72 #endif 73 73 74 74 /* 75 - * The 64-bit value is not atomic - you MUST NOT read it 75 + * The 64-bit value is not atomic on 32-bit systems - you MUST NOT read it 76 76 * without sampling the sequence number in jiffies_lock. 77 77 * get_jiffies_64() will do this for you as appropriate. 78 + * 79 + * jiffies and jiffies_64 are at the same address for little-endian systems 80 + * and for 64-bit big-endian systems. 81 + * On 32-bit big-endian systems, jiffies is the lower 32 bits of jiffies_64 82 + * (i.e., at address @jiffies_64 + 4). 83 + * See arch/ARCH/kernel/vmlinux.lds.S 78 84 */ 79 85 extern u64 __cacheline_aligned_in_smp jiffies_64; 80 86 extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data jiffies; ··· 88 82 #if (BITS_PER_LONG < 64) 89 83 u64 get_jiffies_64(void); 90 84 #else 85 + /** 86 + * get_jiffies_64 - read the 64-bit non-atomic jiffies_64 value 87 + * 88 + * When BITS_PER_LONG < 64, this uses sequence number sampling using 89 + * jiffies_lock to protect the 64-bit read. 90 + * 91 + * Return: current 64-bit jiffies value 92 + */ 91 93 static inline u64 get_jiffies_64(void) 92 94 { 93 95 return (u64)jiffies; ··· 103 89 #endif 104 90 105 91 /* 106 - * These inlines deal with timer wrapping correctly. You are 107 - * strongly encouraged to use them 92 + * These inlines deal with timer wrapping correctly. You are 93 + * strongly encouraged to use them: 108 94 * 1. Because people otherwise forget 109 95 * 2. Because if the timer wrap changes in future you won't have to 110 96 * alter your driver code. 111 - * 112 - * time_after(a,b) returns true if the time a is after time b. 97 + */ 98 + 99 + /** 100 + * time_after - returns true if the time a is after time b. 101 + * @a: first comparable as unsigned long 102 + * @b: second comparable as unsigned long 113 103 * 114 104 * Do this with "<0" and ">=0" to only test the sign of the result. A 115 105 * good compiler would generate better code (and a really good compiler 116 106 * wouldn't care). Gcc is currently neither. 107 + * 108 + * Return: %true is time a is after time b, otherwise %false. 117 109 */ 118 110 #define time_after(a,b) \ 119 111 (typecheck(unsigned long, a) && \ 120 112 typecheck(unsigned long, b) && \ 121 113 ((long)((b) - (a)) < 0)) 114 + /** 115 + * time_before - returns true if the time a is before time b. 116 + * @a: first comparable as unsigned long 117 + * @b: second comparable as unsigned long 118 + * 119 + * Return: %true is time a is before time b, otherwise %false. 120 + */ 122 121 #define time_before(a,b) time_after(b,a) 123 122 123 + /** 124 + * time_after_eq - returns true if the time a is after or the same as time b. 125 + * @a: first comparable as unsigned long 126 + * @b: second comparable as unsigned long 127 + * 128 + * Return: %true is time a is after or the same as time b, otherwise %false. 129 + */ 124 130 #define time_after_eq(a,b) \ 125 131 (typecheck(unsigned long, a) && \ 126 132 typecheck(unsigned long, b) && \ 127 133 ((long)((a) - (b)) >= 0)) 134 + /** 135 + * time_before_eq - returns true if the time a is before or the same as time b. 136 + * @a: first comparable as unsigned long 137 + * @b: second comparable as unsigned long 138 + * 139 + * Return: %true is time a is before or the same as time b, otherwise %false. 140 + */ 128 141 #define time_before_eq(a,b) time_after_eq(b,a) 129 142 130 - /* 131 - * Calculate whether a is in the range of [b, c]. 143 + /** 144 + * time_in_range - Calculate whether a is in the range of [b, c]. 145 + * @a: time to test 146 + * @b: beginning of the range 147 + * @c: end of the range 148 + * 149 + * Return: %true is time a is in the range [b, c], otherwise %false. 132 150 */ 133 151 #define time_in_range(a,b,c) \ 134 152 (time_after_eq(a,b) && \ 135 153 time_before_eq(a,c)) 136 154 137 - /* 138 - * Calculate whether a is in the range of [b, c). 155 + /** 156 + * time_in_range_open - Calculate whether a is in the range of [b, c). 157 + * @a: time to test 158 + * @b: beginning of the range 159 + * @c: end of the range 160 + * 161 + * Return: %true is time a is in the range [b, c), otherwise %false. 139 162 */ 140 163 #define time_in_range_open(a,b,c) \ 141 164 (time_after_eq(a,b) && \ ··· 180 129 181 130 /* Same as above, but does so with platform independent 64bit types. 182 131 * These must be used when utilizing jiffies_64 (i.e. return value of 183 - * get_jiffies_64() */ 132 + * get_jiffies_64()). */ 133 + 134 + /** 135 + * time_after64 - returns true if the time a is after time b. 136 + * @a: first comparable as __u64 137 + * @b: second comparable as __u64 138 + * 139 + * This must be used when utilizing jiffies_64 (i.e. return value of 140 + * get_jiffies_64()). 141 + * 142 + * Return: %true is time a is after time b, otherwise %false. 143 + */ 184 144 #define time_after64(a,b) \ 185 145 (typecheck(__u64, a) && \ 186 146 typecheck(__u64, b) && \ 187 147 ((__s64)((b) - (a)) < 0)) 148 + /** 149 + * time_before64 - returns true if the time a is before time b. 150 + * @a: first comparable as __u64 151 + * @b: second comparable as __u64 152 + * 153 + * This must be used when utilizing jiffies_64 (i.e. return value of 154 + * get_jiffies_64()). 155 + * 156 + * Return: %true is time a is before time b, otherwise %false. 157 + */ 188 158 #define time_before64(a,b) time_after64(b,a) 189 159 160 + /** 161 + * time_after_eq64 - returns true if the time a is after or the same as time b. 162 + * @a: first comparable as __u64 163 + * @b: second comparable as __u64 164 + * 165 + * This must be used when utilizing jiffies_64 (i.e. return value of 166 + * get_jiffies_64()). 167 + * 168 + * Return: %true is time a is after or the same as time b, otherwise %false. 169 + */ 190 170 #define time_after_eq64(a,b) \ 191 171 (typecheck(__u64, a) && \ 192 172 typecheck(__u64, b) && \ 193 173 ((__s64)((a) - (b)) >= 0)) 174 + /** 175 + * time_before_eq64 - returns true if the time a is before or the same as time b. 176 + * @a: first comparable as __u64 177 + * @b: second comparable as __u64 178 + * 179 + * This must be used when utilizing jiffies_64 (i.e. return value of 180 + * get_jiffies_64()). 181 + * 182 + * Return: %true is time a is before or the same as time b, otherwise %false. 183 + */ 194 184 #define time_before_eq64(a,b) time_after_eq64(b,a) 195 185 186 + /** 187 + * time_in_range64 - Calculate whether a is in the range of [b, c]. 188 + * @a: time to test 189 + * @b: beginning of the range 190 + * @c: end of the range 191 + * 192 + * Return: %true is time a is in the range [b, c], otherwise %false. 193 + */ 196 194 #define time_in_range64(a, b, c) \ 197 195 (time_after_eq64(a, b) && \ 198 196 time_before_eq64(a, c)) 199 197 200 198 /* 201 - * These four macros compare jiffies and 'a' for convenience. 199 + * These eight macros compare jiffies[_64] and 'a' for convenience. 202 200 */ 203 201 204 - /* time_is_before_jiffies(a) return true if a is before jiffies */ 202 + /** 203 + * time_is_before_jiffies - return true if a is before jiffies 204 + * @a: time (unsigned long) to compare to jiffies 205 + * 206 + * Return: %true is time a is before jiffies, otherwise %false. 207 + */ 205 208 #define time_is_before_jiffies(a) time_after(jiffies, a) 209 + /** 210 + * time_is_before_jiffies64 - return true if a is before jiffies_64 211 + * @a: time (__u64) to compare to jiffies_64 212 + * 213 + * Return: %true is time a is before jiffies_64, otherwise %false. 214 + */ 206 215 #define time_is_before_jiffies64(a) time_after64(get_jiffies_64(), a) 207 216 208 - /* time_is_after_jiffies(a) return true if a is after jiffies */ 217 + /** 218 + * time_is_after_jiffies - return true if a is after jiffies 219 + * @a: time (unsigned long) to compare to jiffies 220 + * 221 + * Return: %true is time a is after jiffies, otherwise %false. 222 + */ 209 223 #define time_is_after_jiffies(a) time_before(jiffies, a) 224 + /** 225 + * time_is_after_jiffies64 - return true if a is after jiffies_64 226 + * @a: time (__u64) to compare to jiffies_64 227 + * 228 + * Return: %true is time a is after jiffies_64, otherwise %false. 229 + */ 210 230 #define time_is_after_jiffies64(a) time_before64(get_jiffies_64(), a) 211 231 212 - /* time_is_before_eq_jiffies(a) return true if a is before or equal to jiffies*/ 232 + /** 233 + * time_is_before_eq_jiffies - return true if a is before or equal to jiffies 234 + * @a: time (unsigned long) to compare to jiffies 235 + * 236 + * Return: %true is time a is before or the same as jiffies, otherwise %false. 237 + */ 213 238 #define time_is_before_eq_jiffies(a) time_after_eq(jiffies, a) 239 + /** 240 + * time_is_before_eq_jiffies64 - return true if a is before or equal to jiffies_64 241 + * @a: time (__u64) to compare to jiffies_64 242 + * 243 + * Return: %true is time a is before or the same jiffies_64, otherwise %false. 244 + */ 214 245 #define time_is_before_eq_jiffies64(a) time_after_eq64(get_jiffies_64(), a) 215 246 216 - /* time_is_after_eq_jiffies(a) return true if a is after or equal to jiffies*/ 247 + /** 248 + * time_is_after_eq_jiffies - return true if a is after or equal to jiffies 249 + * @a: time (unsigned long) to compare to jiffies 250 + * 251 + * Return: %true is time a is after or the same as jiffies, otherwise %false. 252 + */ 217 253 #define time_is_after_eq_jiffies(a) time_before_eq(jiffies, a) 254 + /** 255 + * time_is_after_eq_jiffies64 - return true if a is after or equal to jiffies_64 256 + * @a: time (__u64) to compare to jiffies_64 257 + * 258 + * Return: %true is time a is after or the same as jiffies_64, otherwise %false. 259 + */ 218 260 #define time_is_after_eq_jiffies64(a) time_before_eq64(get_jiffies_64(), a) 219 261 220 262 /* 221 - * Have the 32 bit jiffies value wrap 5 minutes after boot 263 + * Have the 32-bit jiffies value wrap 5 minutes after boot 222 264 * so jiffies wrap bugs show up earlier. 223 265 */ 224 266 #define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ)) ··· 422 278 #if BITS_PER_LONG < 64 423 279 # define MAX_SEC_IN_JIFFIES \ 424 280 (long)((u64)((u64)MAX_JIFFY_OFFSET * TICK_NSEC) / NSEC_PER_SEC) 425 - #else /* take care of overflow on 64 bits machines */ 281 + #else /* take care of overflow on 64-bit machines */ 426 282 # define MAX_SEC_IN_JIFFIES \ 427 283 (SH_DIV((MAX_JIFFY_OFFSET >> SEC_JIFFIE_SC) * TICK_NSEC, NSEC_PER_SEC, 1) - 1) 428 284 ··· 434 290 extern unsigned int jiffies_to_msecs(const unsigned long j); 435 291 extern unsigned int jiffies_to_usecs(const unsigned long j); 436 292 293 + /** 294 + * jiffies_to_nsecs - Convert jiffies to nanoseconds 295 + * @j: jiffies value 296 + * 297 + * Return: nanoseconds value 298 + */ 437 299 static inline u64 jiffies_to_nsecs(const unsigned long j) 438 300 { 439 301 return (u64)jiffies_to_usecs(j) * NSEC_PER_USEC; ··· 503 353 * 504 354 * msecs_to_jiffies() checks for the passed in value being a constant 505 355 * via __builtin_constant_p() allowing gcc to eliminate most of the 506 - * code, __msecs_to_jiffies() is called if the value passed does not 356 + * code. __msecs_to_jiffies() is called if the value passed does not 507 357 * allow constant folding and the actual conversion must be done at 508 358 * runtime. 509 - * the HZ range specific helpers _msecs_to_jiffies() are called both 359 + * The HZ range specific helpers _msecs_to_jiffies() are called both 510 360 * directly here and from __msecs_to_jiffies() in the case where 511 361 * constant folding is not possible. 362 + * 363 + * Return: jiffies value 512 364 */ 513 365 static __always_inline unsigned long msecs_to_jiffies(const unsigned int m) 514 366 { ··· 552 400 * 553 401 * usecs_to_jiffies() checks for the passed in value being a constant 554 402 * via __builtin_constant_p() allowing gcc to eliminate most of the 555 - * code, __usecs_to_jiffies() is called if the value passed does not 403 + * code. __usecs_to_jiffies() is called if the value passed does not 556 404 * allow constant folding and the actual conversion must be done at 557 405 * runtime. 558 - * the HZ range specific helpers _usecs_to_jiffies() are called both 406 + * The HZ range specific helpers _usecs_to_jiffies() are called both 559 407 * directly here and from __msecs_to_jiffies() in the case where 560 408 * constant folding is not possible. 409 + * 410 + * Return: jiffies value 561 411 */ 562 412 static __always_inline unsigned long usecs_to_jiffies(const unsigned int u) 563 413 { ··· 576 422 extern void jiffies_to_timespec64(const unsigned long jiffies, 577 423 struct timespec64 *value); 578 424 extern clock_t jiffies_to_clock_t(unsigned long x); 425 + 579 426 static inline clock_t jiffies_delta_to_clock_t(long delta) 580 427 { 581 428 return jiffies_to_clock_t(max(0L, delta));

+158 -11

kernel/time/time.c

··· 365 365 } 366 366 #endif 367 367 368 - /* 369 - * Convert jiffies to milliseconds and back. 368 + /** 369 + * jiffies_to_msecs - Convert jiffies to milliseconds 370 + * @j: jiffies value 370 371 * 371 372 * Avoid unnecessary multiplications/divisions in the 372 - * two most common HZ cases: 373 + * two most common HZ cases. 374 + * 375 + * Return: milliseconds value 373 376 */ 374 377 unsigned int jiffies_to_msecs(const unsigned long j) 375 378 { ··· 391 388 } 392 389 EXPORT_SYMBOL(jiffies_to_msecs); 393 390 391 + /** 392 + * jiffies_to_usecs - Convert jiffies to microseconds 393 + * @j: jiffies value 394 + * 395 + * Return: microseconds value 396 + */ 394 397 unsigned int jiffies_to_usecs(const unsigned long j) 395 398 { 396 399 /* ··· 417 408 } 418 409 EXPORT_SYMBOL(jiffies_to_usecs); 419 410 420 - /* 411 + /** 421 412 * mktime64 - Converts date to seconds. 413 + * @year0: year to convert 414 + * @mon0: month to convert 415 + * @day: day to convert 416 + * @hour: hour to convert 417 + * @min: minute to convert 418 + * @sec: second to convert 419 + * 422 420 * Converts Gregorian date to seconds since 1970-01-01 00:00:00. 423 421 * Assumes input in normal date format, i.e. 1980-12-31 23:59:59 424 422 * => year=1980, mon=12, day=31, hour=23, min=59, sec=59. ··· 443 427 * 444 428 * An encoding of midnight at the end of the day as 24:00:00 - ie. midnight 445 429 * tomorrow - (allowable under ISO 8601) is supported. 430 + * 431 + * Return: seconds since the epoch time for the given input date 446 432 */ 447 433 time64_t mktime64(const unsigned int year0, const unsigned int mon0, 448 434 const unsigned int day, const unsigned int hour, ··· 489 471 * Set seconds and nanoseconds field of a timespec variable and 490 472 * normalize to the timespec storage format 491 473 * 492 - * Note: The tv_nsec part is always in the range of 493 - * 0 <= tv_nsec < NSEC_PER_SEC 474 + * Note: The tv_nsec part is always in the range of 0 <= tv_nsec < NSEC_PER_SEC. 494 475 * For negative values only the tv_sec field is negative ! 495 476 */ 496 477 void set_normalized_timespec64(struct timespec64 *ts, time64_t sec, s64 nsec) ··· 518 501 * ns_to_timespec64 - Convert nanoseconds to timespec64 519 502 * @nsec: the nanoseconds value to be converted 520 503 * 521 - * Returns the timespec64 representation of the nsec parameter. 504 + * Return: the timespec64 representation of the nsec parameter. 522 505 */ 523 506 struct timespec64 ns_to_timespec64(s64 nsec) 524 507 { ··· 565 548 * runtime. 566 549 * The _msecs_to_jiffies helpers are the HZ dependent conversion 567 550 * routines found in include/linux/jiffies.h 551 + * 552 + * Return: jiffies value 568 553 */ 569 554 unsigned long __msecs_to_jiffies(const unsigned int m) 570 555 { ··· 579 560 } 580 561 EXPORT_SYMBOL(__msecs_to_jiffies); 581 562 563 + /** 564 + * __usecs_to_jiffies: - convert microseconds to jiffies 565 + * @u: time in milliseconds 566 + * 567 + * Return: jiffies value 568 + */ 582 569 unsigned long __usecs_to_jiffies(const unsigned int u) 583 570 { 584 571 if (u > jiffies_to_usecs(MAX_JIFFY_OFFSET)) ··· 593 568 } 594 569 EXPORT_SYMBOL(__usecs_to_jiffies); 595 570 596 - /* 571 + /** 572 + * timespec64_to_jiffies - convert a timespec64 value to jiffies 573 + * @value: pointer to &struct timespec64 574 + * 597 575 * The TICK_NSEC - 1 rounds up the value to the next resolution. Note 598 576 * that a remainder subtract here would not do the right thing as the 599 577 * resolution values don't fall on second boundaries. I.e. the line: ··· 610 582 * 611 583 * The >> (NSEC_JIFFIE_SC - SEC_JIFFIE_SC) converts the scaled nsec 612 584 * value to a scaled second value. 585 + * 586 + * Return: jiffies value 613 587 */ 614 - 615 588 unsigned long 616 589 timespec64_to_jiffies(const struct timespec64 *value) 617 590 { ··· 630 601 } 631 602 EXPORT_SYMBOL(timespec64_to_jiffies); 632 603 604 + /** 605 + * jiffies_to_timespec64 - convert jiffies value to &struct timespec64 606 + * @jiffies: jiffies value 607 + * @value: pointer to &struct timespec64 608 + */ 633 609 void 634 610 jiffies_to_timespec64(const unsigned long jiffies, struct timespec64 *value) 635 611 { ··· 652 618 /* 653 619 * Convert jiffies/jiffies_64 to clock_t and back. 654 620 */ 621 + 622 + /** 623 + * jiffies_to_clock_t - Convert jiffies to clock_t 624 + * @x: jiffies value 625 + * 626 + * Return: jiffies converted to clock_t (CLOCKS_PER_SEC) 627 + */ 655 628 clock_t jiffies_to_clock_t(unsigned long x) 656 629 { 657 630 #if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0 ··· 673 632 } 674 633 EXPORT_SYMBOL(jiffies_to_clock_t); 675 634 635 + /** 636 + * clock_t_to_jiffies - Convert clock_t to jiffies 637 + * @x: clock_t value 638 + * 639 + * Return: clock_t value converted to jiffies 640 + */ 676 641 unsigned long clock_t_to_jiffies(unsigned long x) 677 642 { 678 643 #if (HZ % USER_HZ)==0 ··· 696 649 } 697 650 EXPORT_SYMBOL(clock_t_to_jiffies); 698 651 652 + /** 653 + * jiffies_64_to_clock_t - Convert jiffies_64 to clock_t 654 + * @x: jiffies_64 value 655 + * 656 + * Return: jiffies_64 value converted to 64-bit "clock_t" (CLOCKS_PER_SEC) 657 + */ 699 658 u64 jiffies_64_to_clock_t(u64 x) 700 659 { 701 660 #if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0 ··· 724 671 } 725 672 EXPORT_SYMBOL(jiffies_64_to_clock_t); 726 673 674 + /** 675 + * nsec_to_clock_t - Convert nsec value to clock_t 676 + * @x: nsec value 677 + * 678 + * Return: nsec value converted to 64-bit "clock_t" (CLOCKS_PER_SEC) 679 + */ 727 680 u64 nsec_to_clock_t(u64 x) 728 681 { 729 682 #if (NSEC_PER_SEC % USER_HZ) == 0 ··· 746 687 #endif 747 688 } 748 689 690 + /** 691 + * jiffies64_to_nsecs - Convert jiffies64 to nanoseconds 692 + * @j: jiffies64 value 693 + * 694 + * Return: nanoseconds value 695 + */ 749 696 u64 jiffies64_to_nsecs(u64 j) 750 697 { 751 698 #if !(NSEC_PER_SEC % HZ) ··· 762 697 } 763 698 EXPORT_SYMBOL(jiffies64_to_nsecs); 764 699 700 + /** 701 + * jiffies64_to_msecs - Convert jiffies64 to milliseconds 702 + * @j: jiffies64 value 703 + * 704 + * Return: milliseconds value 705 + */ 765 706 u64 jiffies64_to_msecs(const u64 j) 766 707 { 767 708 #if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ) ··· 790 719 * note: 791 720 * NSEC_PER_SEC = 10^9 = (5^9 * 2^9) = (1953125 * 512) 792 721 * ULLONG_MAX ns = 18446744073.709551615 secs = about 584 years 722 + * 723 + * Return: nsecs converted to jiffies64 value 793 724 */ 794 725 u64 nsecs_to_jiffies64(u64 n) 795 726 { ··· 823 750 * note: 824 751 * NSEC_PER_SEC = 10^9 = (5^9 * 2^9) = (1953125 * 512) 825 752 * ULLONG_MAX ns = 18446744073.709551615 secs = about 584 years 753 + * 754 + * Return: nsecs converted to jiffies value 826 755 */ 827 756 unsigned long nsecs_to_jiffies(u64 n) 828 757 { ··· 832 757 } 833 758 EXPORT_SYMBOL_GPL(nsecs_to_jiffies); 834 759 835 - /* 836 - * Add two timespec64 values and do a safety check for overflow. 760 + /** 761 + * timespec64_add_safe - Add two timespec64 values and do a safety check 762 + * for overflow. 763 + * @lhs: first (left) timespec64 to add 764 + * @rhs: second (right) timespec64 to add 765 + * 837 766 * It's assumed that both values are valid (>= 0). 838 767 * And, each timespec64 is in normalized form. 768 + * 769 + * Return: sum of @lhs + @rhs 839 770 */ 840 771 struct timespec64 timespec64_add_safe(const struct timespec64 lhs, 841 772 const struct timespec64 rhs) ··· 859 778 return res; 860 779 } 861 780 781 + /** 782 + * get_timespec64 - get user's time value into kernel space 783 + * @ts: destination &struct timespec64 784 + * @uts: user's time value as &struct __kernel_timespec 785 + * 786 + * Handles compat or 32-bit modes. 787 + * 788 + * Return: %0 on success or negative errno on error 789 + */ 862 790 int get_timespec64(struct timespec64 *ts, 863 791 const struct __kernel_timespec __user *uts) 864 792 { ··· 891 801 } 892 802 EXPORT_SYMBOL_GPL(get_timespec64); 893 803 804 + /** 805 + * put_timespec64 - convert timespec64 value to __kernel_timespec format and 806 + * copy the latter to userspace 807 + * @ts: input &struct timespec64 808 + * @uts: user's &struct __kernel_timespec 809 + * 810 + * Return: %0 on success or negative errno on error 811 + */ 894 812 int put_timespec64(const struct timespec64 *ts, 895 813 struct __kernel_timespec __user *uts) 896 814 { ··· 937 839 return copy_to_user(cts, &ts, sizeof(ts)) ? -EFAULT : 0; 938 840 } 939 841 842 + /** 843 + * get_old_timespec32 - get user's old-format time value into kernel space 844 + * @ts: destination &struct timespec64 845 + * @uts: user's old-format time value (&struct old_timespec32) 846 + * 847 + * Handles X86_X32_ABI compatibility conversion. 848 + * 849 + * Return: %0 on success or negative errno on error 850 + */ 940 851 int get_old_timespec32(struct timespec64 *ts, const void __user *uts) 941 852 { 942 853 if (COMPAT_USE_64BIT_TIME) ··· 955 848 } 956 849 EXPORT_SYMBOL_GPL(get_old_timespec32); 957 850 851 + /** 852 + * put_old_timespec32 - convert timespec64 value to &struct old_timespec32 and 853 + * copy the latter to userspace 854 + * @ts: input &struct timespec64 855 + * @uts: user's &struct old_timespec32 856 + * 857 + * Handles X86_X32_ABI compatibility conversion. 858 + * 859 + * Return: %0 on success or negative errno on error 860 + */ 958 861 int put_old_timespec32(const struct timespec64 *ts, void __user *uts) 959 862 { 960 863 if (COMPAT_USE_64BIT_TIME) ··· 974 857 } 975 858 EXPORT_SYMBOL_GPL(put_old_timespec32); 976 859 860 + /** 861 + * get_itimerspec64 - get user's &struct __kernel_itimerspec into kernel space 862 + * @it: destination &struct itimerspec64 863 + * @uit: user's &struct __kernel_itimerspec 864 + * 865 + * Return: %0 on success or negative errno on error 866 + */ 977 867 int get_itimerspec64(struct itimerspec64 *it, 978 868 const struct __kernel_itimerspec __user *uit) 979 869 { ··· 996 872 } 997 873 EXPORT_SYMBOL_GPL(get_itimerspec64); 998 874 875 + /** 876 + * put_itimerspec64 - convert &struct itimerspec64 to __kernel_itimerspec format 877 + * and copy the latter to userspace 878 + * @it: input &struct itimerspec64 879 + * @uit: user's &struct __kernel_itimerspec 880 + * 881 + * Return: %0 on success or negative errno on error 882 + */ 999 883 int put_itimerspec64(const struct itimerspec64 *it, 1000 884 struct __kernel_itimerspec __user *uit) 1001 885 { ··· 1019 887 } 1020 888 EXPORT_SYMBOL_GPL(put_itimerspec64); 1021 889 890 + /** 891 + * get_old_itimerspec32 - get user's &struct old_itimerspec32 into kernel space 892 + * @its: destination &struct itimerspec64 893 + * @uits: user's &struct old_itimerspec32 894 + * 895 + * Return: %0 on success or negative errno on error 896 + */ 1022 897 int get_old_itimerspec32(struct itimerspec64 *its, 1023 898 const struct old_itimerspec32 __user *uits) 1024 899 { ··· 1037 898 } 1038 899 EXPORT_SYMBOL_GPL(get_old_itimerspec32); 1039 900 901 + /** 902 + * put_old_itimerspec32 - convert &struct itimerspec64 to &struct 903 + * old_itimerspec32 and copy the latter to userspace 904 + * @its: input &struct itimerspec64 905 + * @uits: user's &struct old_itimerspec32 906 + * 907 + * Return: %0 on success or negative errno on error 908 + */ 1040 909 int put_old_itimerspec32(const struct itimerspec64 *its, 1041 910 struct old_itimerspec32 __user *uits) 1042 911 {

+9 -6

rust/Makefile

··· 1 1 # SPDX-License-Identifier: GPL-2.0 2 2 3 + # Where to place rustdoc generated documentation 4 + rustdoc_output := $(objtree)/Documentation/output/rust/rustdoc 5 + 3 6 obj-$(CONFIG_RUST) += core.o compiler_builtins.o 4 7 always-$(CONFIG_RUST) += exports_core_generated.h 5 8 ··· 76 73 OBJTREE=$(abspath $(objtree)) \ 77 74 $(RUSTDOC) $(if $(rustdoc_host),$(rust_common_flags),$(rust_flags)) \ 78 75 $(rustc_target_flags) -L$(objtree)/$(obj) \ 79 - --output $(objtree)/$(obj)/doc \ 76 + --output $(rustdoc_output) \ 80 77 --crate-name $(subst rustdoc-,,$@) \ 81 78 @$(objtree)/include/generated/rustc_cfg $< 82 79 ··· 93 90 # and then retouch the generated files. 94 91 rustdoc: rustdoc-core rustdoc-macros rustdoc-compiler_builtins \ 95 92 rustdoc-alloc rustdoc-kernel 96 - $(Q)cp $(srctree)/Documentation/images/logo.svg $(objtree)/$(obj)/doc 97 - $(Q)cp $(srctree)/Documentation/images/COPYING-logo $(objtree)/$(obj)/doc 98 - $(Q)find $(objtree)/$(obj)/doc -name '*.html' -type f -print0 | xargs -0 sed -Ei \ 93 + $(Q)cp $(srctree)/Documentation/images/logo.svg $(rustdoc_output) 94 + $(Q)cp $(srctree)/Documentation/images/COPYING-logo $(rustdoc_output) 95 + $(Q)find $(rustdoc_output) -name '*.html' -type f -print0 | xargs -0 sed -Ei \ 99 96 -e 's:rust-logo\.svg:logo.svg:g' \ 100 97 -e 's:rust-logo\.png:logo.svg:g' \ 101 98 -e 's:favicon\.svg:logo.svg:g' \ 102 99 -e 's:<link rel="alternate icon" type="image/png" href="[./]*favicon-(16x16|32x32)\.png">::g' 103 100 $(Q)echo '.logo-container > img { object-fit: contain; }' \ 104 - >> $(objtree)/$(obj)/doc/rustdoc.css 101 + >> $(rustdoc_output)/rustdoc.css 105 102 106 103 rustdoc-macros: private rustdoc_host = yes 107 104 rustdoc-macros: private rustc_target_flags = --crate-type proc-macro \ ··· 165 162 @$(objtree)/include/generated/rustc_cfg \ 166 163 $(rustc_target_flags) $(rustdoc_test_target_flags) \ 167 164 --sysroot $(objtree)/$(obj)/test/sysroot $(rustdoc_test_quiet) \ 168 - -L$(objtree)/$(obj)/test --output $(objtree)/$(obj)/doc \ 165 + -L$(objtree)/$(obj)/test --output $(rustdoc_output) \ 169 166 --crate-name $(subst rusttest-,,$@) $< 170 167 171 168 quiet_cmd_rustdoc_test_kernel = RUSTDOC TK $<

+5

scripts/kernel-doc

··· 1168 1168 $members =~ s/DECLARE_KFIFO_PTR\s*$$args,\s*$args$/$2 \*$1/gos; 1169 1169 # replace DECLARE_FLEX_ARRAY 1170 1170 $members =~ s/(?:__)?DECLARE_FLEX_ARRAY\s*$$args,\s*$args$/$1 $2\[\]/gos; 1171 + #replace DEFINE_DMA_UNMAP_ADDR 1172 + $members =~ s/DEFINE_DMA_UNMAP_ADDR\s*$$args$/dma_addr_t $1/gos; 1173 + #replace DEFINE_DMA_UNMAP_LEN 1174 + $members =~ s/DEFINE_DMA_UNMAP_LEN\s*$$args$/__u32 $1/gos; 1171 1175 my $declaration = $members; 1172 1176 1173 1177 # Split nested struct/union elements as newer ones ··· 1353 1349 my %_members; 1354 1350 1355 1351 $members =~ s/\s+$//; 1352 + $members =~ s/$[^;]*?[$]//g; 1356 1353 1357 1354 foreach my $arg (split ',', $members) { 1358 1355 $arg =~ s/^\s*(\w+).*/$1/;

Configure Feed

Configure Feed