+1 -1

Documentation/ABI/testing/pstore

reviewed

··· 26 26 27 27 Once the information in a file has been read, removing 28 28 the file will signal to the underlying persistent storage 29 29 - device that it can reclaim the space for later re-use:: 29 29 + device that it can reclaim the space for later reuse:: 30 30 31 31 $ rm /sys/fs/pstore/dmesg-erst-1 32 32

+1 -1

Documentation/admin-guide/initrd.rst

reviewed

··· 297 297 8) now the system is bootable and additional installation tasks can be 298 298 performed 299 299 300 300 - The key role of initrd here is to re-use the configuration data during 300 300 + The key role of initrd here is to reuse the configuration data during 301 301 normal system operation without requiring the use of a bloated "generic" 302 302 kernel or re-compiling or re-linking the kernel. 303 303

+1 -1

Documentation/admin-guide/kdump/kdump.rst

reviewed

··· 591 591 cat /sys/kernel/config/crash_dm_crypt_keys/count 592 592 2 593 593 594 594 - # To support CPU/memory hot-plugging, re-use keys already saved to reserved 594 594 + # To support CPU/memory hot-plugging, reuse keys already saved to reserved 595 595 # memory 596 596 echo true > /sys/kernel/config/crash_dm_crypt_key/reuse 597 597

+1 -1

Documentation/admin-guide/mm/nommu-mmap.rst

reviewed

··· 38 38 39 39 In the no-MMU case: 40 40 41 41 - - If one exists, the kernel will re-use an existing mapping to the 41 41 + - If one exists, the kernel will reuse an existing mapping to the 42 42 same segment of the same file if that has compatible permissions, 43 43 even if this was created by another process. 44 44

+2 -2

Documentation/arch/arm64/arm-acpi.rst

reviewed

··· 306 306 then retrieve the value of the property by evaluating the KEY0 object. 307 307 However, using Name() this way has multiple problems: (1) ACPI limits 308 308 names ("KEY0") to four characters unlike DT; (2) there is no industry 309 309 - wide registry that maintains a list of names, minimizing re-use; (3) 309 309 + wide registry that maintains a list of names, minimizing reuse; (3) 310 310 there is also no registry for the definition of property values ("value0"), 311 311 - again making re-use difficult; and (4) how does one maintain backward 311 311 + again making reuse difficult; and (4) how does one maintain backward 312 312 compatibility as new hardware comes out? The _DSD method was created 313 313 to solve precisely these sorts of problems; Linux drivers should ALWAYS 314 314 use the _DSD method for device properties and nothing else.

+1 -1

Documentation/arch/s390/driver-model.rst

reviewed

··· 279 279 - Can be 'online' or 'offline'. 280 280 Piping 'on' or 'off' sets the chpid logically online/offline. 281 281 Piping 'on' to an online chpid triggers path reprobing for all devices 282 282 - the chpid connects to. This can be used to force the kernel to re-use 282 282 + the chpid connects to. This can be used to force the kernel to reuse 283 283 a channel path the user knows to be online, but the machine hasn't 284 284 created a machine check for. 285 285

+1 -1

Documentation/arch/x86/shstk.rst

reviewed

··· 165 165 When a task forks a child, its shadow stack PTEs are copied and both the 166 166 parent's and the child's shadow stack PTEs are cleared of the dirty bit. 167 167 Upon the next shadow stack access, the resulting shadow stack page fault 168 168 - is handled by page copy/re-use. 168 168 + is handled by page copy/reuse. 169 169 170 170 When a pthread child is created, the kernel allocates a new shadow stack 171 171 for the new thread. New shadow stack creation behaves like mmap() with respect

+1 -1

Documentation/driver-api/phy/phy.rst

reviewed

··· 19 19 SATA etc. 20 20 21 21 The intention of creating this framework is to bring the PHY drivers spread 22 22 - all over the Linux kernel to drivers/phy to increase code re-use and for 22 22 + all over the Linux kernel to drivers/phy to increase code reuse and for 23 23 better code maintainability. 24 24 25 25 This framework will be of use only to devices that use external PHY (PHY

+1 -1

Documentation/driver-api/tty/tty_ldisc.rst

reviewed

··· 18 18 Line disciplines are registered with tty_register_ldisc() passing the ldisc 19 19 structure. At the point of registration the discipline must be ready to use and 20 20 it is possible it will get used before the call returns success. If the call 21 21 - returns an error then it won’t get called. Do not re-use ldisc numbers as they 21 21 + returns an error then it won’t get called. Do not reuse ldisc numbers as they 22 22 are part of the userspace ABI and writing over an existing ldisc will cause 23 23 demons to eat your computer. You must not re-register over the top of the line 24 24 discipline even with the same data or your computer again will be eaten by

+1 -1

Documentation/driver-api/usb/gadget.rst

reviewed

··· 459 459 ``gadget`` framework. To do that, the system software relies on small 460 460 additions to those programming interfaces, and on a new internal 461 461 component (here called an "OTG Controller") affecting which driver stack 462 462 - connects to the OTG port. In each role, the system can re-use the 462 462 + connects to the OTG port. In each role, the system can reuse the 463 463 existing pool of hardware-neutral drivers, layered on top of the 464 464 controller driver interfaces (:c:type:`usb_bus` or :c:type:`usb_gadget`). 465 465 Such drivers need at most minor changes, and most of the calls added to

+1 -1

Documentation/filesystems/relay.rst

reviewed

··· 452 452 Misc 453 453 ---- 454 454 455 455 - Some applications may want to keep a channel around and re-use it 455 455 + Some applications may want to keep a channel around and reuse it 456 456 rather than open and close a new channel for each use. relay_reset() 457 457 can be used for this purpose - it resets a channel to its initial 458 458 state without reallocating channel buffer memory or destroying

+1 -1

Documentation/filesystems/resctrl.rst

reviewed

··· 482 482 "max_threshold_occupancy": 483 483 Read/write file provides the largest value (in 484 484 bytes) at which a previously used LLC_occupancy 485 485 - counter can be considered for re-use. 485 485 + counter can be considered for reuse. 486 486 487 487 Finally, in the top level of the "info" directory there is a file 488 488 named "last_cmd_status". This is reset with every "command" issued

+1 -1

Documentation/firmware-guide/acpi/DSD-properties-rules.rst

reviewed

··· 89 89 account in the first place and returning invalid property sets from _DSD must be 90 90 avoided. For this reason, it may not be possible to make _DSD return a property 91 91 set following the given DT binding literally and completely. Still, for the 92 92 - sake of code re-use, it may make sense to provide as much of the configuration 92 92 + sake of code reuse, it may make sense to provide as much of the configuration 93 93 data as possible in the form of device properties and complement that with an 94 94 ACPI-specific mechanism suitable for the use case at hand. 95 95

+1 -1

Documentation/firmware-guide/acpi/enumeration.rst

reviewed

··· 12 12 SoC/Chipset to appear only in ACPI namespace. These are typically devices 13 13 that are accessed through memory-mapped registers. 14 14 15 15 - In order to support this and re-use the existing drivers as much as 15 15 + In order to support this and reuse the existing drivers as much as 16 16 possible we decided to do following: 17 17 18 18 - Devices that have no bus connector resource are represented as

+1 -1

Documentation/input/gamepad.rst

reviewed

··· 79 79 All new gamepads are supposed to comply with this mapping. Please report any 80 80 bugs, if they don't. 81 81 82 82 - There are a lot of less-featured/less-powerful devices out there, which re-use 82 82 + There are a lot of less-featured/less-powerful devices out there, which reuse 83 83 the buttons from this protocol. However, they try to do this in a compatible 84 84 fashion. For example, the "Nintendo Wii Nunchuk" provides two trigger buttons 85 85 and one analog stick. It reports them as if it were a gamepad with only one

+2 -2

Documentation/process/adding-syscalls.rst

reviewed

··· 117 117 the timing window between ``xyzzy()`` and calling 118 118 ``fcntl(fd, F_SETFD, FD_CLOEXEC)``, where an unexpected ``fork()`` and 119 119 ``execve()`` in another thread could leak a descriptor to 120 120 - the exec'ed program. (However, resist the temptation to re-use the actual value 120 120 + the exec'ed program. (However, resist the temptation to reuse the actual value 121 121 of the ``O_CLOEXEC`` constant, as it is architecture-specific and is part of a 122 122 numbering space of ``O_*`` flags that is fairly full.) 123 123 ··· 459 459 ... 460 460 555 x32 xyzzy __x32_compat_sys_xyzzy 461 461 462 462 - If no pointers are involved, then it is preferable to re-use the 64-bit system 462 462 + If no pointers are involved, then it is preferable to reuse the 64-bit system 463 463 call for the x32 ABI (and consequently the entry in 464 464 arch/x86/entry/syscalls/syscall_64.tbl is unchanged). 465 465

+1 -1

Documentation/sound/hd-audio/notes.rst

reviewed

··· 191 191 configuration of that preset with the correct pin setup, etc. 192 192 Thus, if you have a newer machine with a slightly different PCI SSID 193 193 (or codec SSID) from the existing one, you may have a good chance to 194 194 - re-use the same model. You can pass the ``model`` option to specify the 194 194 + reuse the same model. You can pass the ``model`` option to specify the 195 195 preset model instead of PCI (and codec-) SSID look-up. 196 196 197 197 What ``model`` option values are available depends on the codec chip.