+2 -2

Documentation/PCI/endpoint/pci-endpoint-cfs.rst

reviewed

··· 86 86 be created by the user to represent the virtual functions that are bound to 87 87 the physical function. In the above directory structure <EPF Device 11> is a 88 88 physical function and <EPF Device 31> is a virtual function. An EPF device once 89 89 - it's linked to another EPF device, cannot be linked to a EPC device. 89 89 + it's linked to another EPF device, cannot be linked to an EPC device. 90 90 91 91 EPC Device 92 92 ========== ··· 108 108 The <EPC Device> directory will have a list of symbolic links to 109 109 <EPF Device>. These symbolic links should be created by the user to 110 110 represent the functions present in the endpoint device. Only <EPF Device> 111 111 - that represents a physical function can be linked to a EPC device. 111 111 + that represents a physical function can be linked to an EPC device. 112 112 113 113 The <EPC Device> directory will also have a *start* field. Once 114 114 "1" is written to this field, the endpoint device will be ready to

+3 -3

Documentation/PCI/endpoint/pci-endpoint.rst

reviewed

··· 197 197 * pci_epf_register_driver() 198 198 199 199 The PCI Endpoint Function driver should implement the following ops: 200 200 - * bind: ops to perform when a EPC device has been bound to EPF device 201 201 - * unbind: ops to perform when a binding has been lost between a EPC 200 200 + * bind: ops to perform when an EPC device has been bound to EPF device 201 201 + * unbind: ops to perform when a binding has been lost between an EPC 202 202 device and EPF device 203 203 * add_cfs: optional ops to create function specific configfs 204 204 attributes ··· 251 251 * pci_epf_bind() 252 252 253 253 pci_epf_bind() should be invoked when the EPF device has been bound to 254 254 - a EPC device. 254 254 + an EPC device. 255 255 256 256 * pci_epf_unbind() 257 257

+1 -1

Documentation/RCU/lockdep.rst

reviewed

··· 106 106 Like rcu_dereference(), when lockdep is enabled, RCU list and hlist 107 107 traversal primitives check for being called from within an RCU read-side 108 108 critical section. However, a lockdep expression can be passed to them 109 109 - as a additional optional argument. With this lockdep expression, these 109 109 + as an additional optional argument. With this lockdep expression, these 110 110 traversal primitives will complain only if the lockdep expression is 111 111 false and they are called from outside any RCU read-side critical section. 112 112

+1 -1

Documentation/RCU/stallwarn.rst

reviewed

··· 119 119 uncommon in large datacenter. In one memorable case some decades 120 120 back, a CPU failed in a running system, becoming unresponsive, 121 121 but not causing an immediate crash. This resulted in a series 122 122 - of RCU CPU stall warnings, eventually leading the realization 122 122 + of RCU CPU stall warnings, eventually leading to the realization 123 123 that the CPU had failed. 124 124 125 125 The RCU, RCU-sched, RCU-tasks, and RCU-tasks-trace implementations have

+1 -1

Documentation/admin-guide/LSM/SafeSetID.rst

reviewed

··· 41 41 services without having to give out CAP_SETUID all over the place just so that 42 42 non-root programs can drop to even-lesser-privileged uids. This is especially 43 43 relevant when one non-root daemon on the system should be allowed to spawn other 44 44 - processes as different uids, but its undesirable to give the daemon a 44 44 + processes as different uids, but it's undesirable to give the daemon a 45 45 basically-root-equivalent CAP_SETUID. 46 46 47 47

+1 -1

Documentation/admin-guide/RAS/main.rst

reviewed

··· 253 253 Some architectures have ECC detectors for L1, L2 and L3 caches, 254 254 along with DMA engines, fabric switches, main data path switches, 255 255 interconnections, and various other hardware data paths. If the hardware 256 256 - reports it, then a edac_device device probably can be constructed to 256 256 + reports it, then an edac_device device probably can be constructed to 257 257 harvest and present that to userspace. 258 258 259 259

+1 -1

Documentation/admin-guide/blockdev/paride.rst

reviewed

··· 118 118 ================ ============ ======== 119 119 120 120 All parports and all protocol drivers are probed automatically unless probe=0 121 121 - parameter is used. So just "modprobe epat" is enough for a Imation SuperDisk 121 121 + parameter is used. So just "modprobe epat" is enough for an Imation SuperDisk 122 122 drive to work. 123 123 124 124 Manual device creation::

+1 -1

Documentation/admin-guide/device-mapper/vdo-design.rst

reviewed

··· 600 600 All storage within vdo is managed as 4KB blocks, but it can accept writes 601 601 as small as 512 bytes. Processing a write that is smaller than 4K requires 602 602 a read-modify-write operation that reads the relevant 4K block, copies the 603 603 - new data over the approriate sectors of the block, and then launches a 603 603 + new data over the appropriate sectors of the block, and then launches a 604 604 write operation for the modified data block. The read and write stages of 605 605 this operation are nearly identical to the normal read and write 606 606 operations, and a single data_vio is used throughout this operation.

+1 -1

Documentation/admin-guide/hw-vuln/mds.rst

reviewed

··· 214 214 command line with the 'ring3mwait=disable' command line option. 215 215 216 216 XEON PHI is not affected by the other MDS variants and MSBDS is mitigated 217 217 - before the CPU enters a idle state. As XEON PHI is not affected by L1TF 217 217 + before the CPU enters an idle state. As XEON PHI is not affected by L1TF 218 218 either disabling SMT is not required for full protection. 219 219 220 220 .. _mds_smt_control:

+1 -1

Documentation/admin-guide/kdump/kdump.rst

reviewed

··· 471 471 performance degradation. To enable multi-cpu support, you should bring up an 472 472 SMP dump-capture kernel and specify maxcpus/nr_cpus options while loading it. 473 473 474 474 - * For s390x there are two kdump modes: If a ELF header is specified with 474 474 + * For s390x there are two kdump modes: If an ELF header is specified with 475 475 the elfcorehdr= kernel parameter, it is used by the kdump kernel as it 476 476 is done on all other architectures. If no elfcorehdr= kernel parameter is 477 477 specified, the s390x kdump kernel dynamically creates the header. The

+5 -5

Documentation/admin-guide/kernel-parameters.txt

reviewed

··· 3700 3700 looking for corruption. Enabling this will 3701 3701 both detect corruption and prevent the kernel 3702 3702 from using the memory being corrupted. 3703 3703 - However, its intended as a diagnostic tool; if 3703 3703 + However, it's intended as a diagnostic tool; if 3704 3704 repeatable BIOS-originated corruption always 3705 3705 affects the same memory, you can use memmap= 3706 3706 to prevent the kernel from using that memory. ··· 7382 7382 (converted into nanoseconds). Fast, but 7383 7383 depending on the architecture, may not be 7384 7384 in sync between CPUs. 7385 7385 - global - Event time stamps are synchronize across 7385 7385 + global - Event time stamps are synchronized across 7386 7386 CPUs. May be slower than the local clock, 7387 7387 but better for some race conditions. 7388 7388 counter - Simple counting of events (1, 2, ..) ··· 7502 7502 section. 7503 7503 7504 7504 trace_trigger=[trigger-list] 7505 7505 - [FTRACE] Add a event trigger on specific events. 7505 7505 + [FTRACE] Add an event trigger on specific events. 7506 7506 Set a trigger on top of a specific event, with an optional 7507 7507 filter. 7508 7508 7509 7509 The format is "trace_trigger=<event>.<trigger>[ if <filter>],..." 7510 7510 - Where more than one trigger may be specified that are comma deliminated. 7510 7510 + Where more than one trigger may be specified that are comma delimited. 7511 7511 7512 7512 For example: 7513 7513 ··· 7515 7515 7516 7516 The above will enable the "stacktrace" trigger on the "sched_switch" 7517 7517 event but only trigger it if the "prev_state" of the "sched_switch" 7518 7518 - event is "2" (TASK_UNINTERUPTIBLE). 7518 7518 + event is "2" (TASK_UNINTERRUPTIBLE). 7519 7519 7520 7520 See also "Event triggers" in Documentation/trace/events.rst 7521 7521

+1 -1

Documentation/admin-guide/laptops/sonypi.rst

reviewed

··· 25 25 (when available) 26 26 27 27 Those events (see linux/sonypi.h) can be polled using the character device node 28 28 - /dev/sonypi (major 10, minor auto allocated or specified as a option). 28 28 + /dev/sonypi (major 10, minor auto allocated or specified as an option). 29 29 A simple daemon which translates the jogdial movements into mouse wheel events 30 30 can be downloaded at: <http://popies.net/sonypi/> 31 31

+1 -1

Documentation/admin-guide/media/imx.rst

reviewed

··· 96 96 motion compensation modes: low, medium, and high motion. Pipelines are 97 97 defined that allow sending frames to the VDIC subdev directly from the 98 98 CSI. There is also support in the future for sending frames to the 99 99 - VDIC from memory buffers via a output/mem2mem devices. 99 99 + VDIC from memory buffers via output/mem2mem devices. 100 100 101 101 - Includes a Frame Interval Monitor (FIM) that can correct vertical sync 102 102 problems with the ADV718x video decoders.

+3 -3

Documentation/admin-guide/media/si4713.rst

reviewed

··· 13 13 Information about the Device 14 14 ---------------------------- 15 15 16 16 - This chip is a Silicon Labs product. It is a I2C device, currently on 0x63 address. 16 16 + This chip is a Silicon Labs product. It is an I2C device, currently on 0x63 address. 17 17 Basically, it has transmission and signal noise level measurement features. 18 18 19 19 The Si4713 integrates transmit functions for FM broadcast stereo transmission. ··· 28 28 Device driver description 29 29 ------------------------- 30 30 31 31 - There are two modules to handle this device. One is a I2C device driver 31 31 + There are two modules to handle this device. One is an I2C device driver 32 32 and the other is a platform driver. 33 33 34 34 The I2C device driver exports a v4l2-subdev interface to the kernel. ··· 113 113 - acomp_attack_time - Sets the attack time for audio dynamic range control. 114 114 - acomp_release_time - Sets the release time for audio dynamic range control. 115 115 116 116 - * Limiter setups audio deviation limiter feature. Once a over deviation occurs, 116 116 + * Limiter sets up the audio deviation limiter feature. Once an over deviation occurs, 117 117 it is possible to adjust the front-end gain of the audio input and always 118 118 prevent over deviation. 119 119

+1 -1

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

reviewed

··· 357 357 DAMON-based operation scheme. 358 358 359 359 Under ``quotas`` directory, four files (``ms``, ``bytes``, 360 360 - ``reset_interval_ms``, ``effective_bytes``) and two directores (``weights`` and 360 360 + ``reset_interval_ms``, ``effective_bytes``) and two directories (``weights`` and 361 361 ``goals``) exist. 362 362 363 363 You can set the ``time quota`` in milliseconds, ``size quota`` in bytes, and

+2 -2

Documentation/admin-guide/perf/hisi-pmu.rst

reviewed

··· 109 109 - 2'b11: count the events which sent to the uring_ext (MATA) channel; 110 110 - 2'b01: is the same as 2'b11; 111 111 - 2'b10: count the events which sent to the uring (non-MATA) channel; 112 112 - - 2'b00: default value, count the events which sent to the both uring and 113 113 - uring_ext channel; 112 112 + - 2'b00: default value, count the events which sent to both uring and 113 113 + uring_ext channels; 114 114 115 115 Users could configure IDs to count data come from specific CCL/ICL, by setting 116 116 srcid_cmd & srcid_msk, and data desitined for specific CCL/ICL by setting

+2 -2

Documentation/admin-guide/quickly-build-trimmed-linux.rst

reviewed

··· 273 273 does nothing at all; in that case you have to manually install your kernel, 274 274 as outlined in the reference section. 275 275 276 276 - If you are running a immutable Linux distribution, check its documentation 276 276 + If you are running an immutable Linux distribution, check its documentation 277 277 and the web to find out how to install your own kernel there. 278 278 279 279 [:ref:`details<install>`] ··· 884 884 setup that often can be fixed quickly; other times though the problem lies in 885 885 the code and can only be fixed by a developer. A close examination of the 886 886 failure messages coupled with some research on the internet will often tell you 887 887 - which of the two it is. To perform such a investigation, restart the build 887 887 + which of the two it is. To perform such an investigation, restart the build 888 888 process like this:: 889 889 890 890 make V=1

+2 -2

Documentation/admin-guide/reporting-issues.rst

reviewed

··· 611 611 612 612 How to read the MAINTAINERS file 613 613 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 614 614 - To illustrate how to use the :ref:`MAINTAINERS <maintainers>` file, lets assume 614 614 + To illustrate how to use the :ref:`MAINTAINERS <maintainers>` file, let's assume 615 615 the WiFi in your Laptop suddenly misbehaves after updating the kernel. In that 616 616 case it's likely an issue in the WiFi driver. Obviously it could also be some 617 617 code it builds upon, but unless you suspect something like that stick to the ··· 1543 1543 1544 1544 And note, it helps developers a great deal if you can specify the exact version 1545 1545 that introduced the problem. Hence if possible within a reasonable time frame, 1546 1546 - try to find that version using vanilla kernels. Lets assume something broke when 1546 1546 + try to find that version using vanilla kernels. Let's assume something broke when 1547 1547 your distributor released a update from Linux kernel 5.10.5 to 5.10.8. Then as 1548 1548 instructed above go and check the latest kernel from that version line, say 1549 1549 5.10.9. If it shows the problem, try a vanilla 5.10.5 to ensure that no patches

+1 -1

Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst

reviewed

··· 1757 1757 to your bootloader's configuration. 1758 1758 1759 1759 You have to take care of some or all of the tasks yourself, if your 1760 1760 - distribution lacks a installkernel script or does only handle part of them. 1760 1760 + distribution lacks an installkernel script or does only handle part of them. 1761 1761 Consult the distribution's documentation for details. If in doubt, install the 1762 1762 kernel manually:: 1763 1763

+3 -3

Documentation/core-api/irq/irq-affinity.rst

reviewed

··· 9 9 10 10 /proc/irq/IRQ#/smp_affinity and /proc/irq/IRQ#/smp_affinity_list specify 11 11 which target CPUs are permitted for a given IRQ source. It's a bitmask 12 12 - (smp_affinity) or cpu list (smp_affinity_list) of allowed CPUs. It's not 12 12 + (smp_affinity) or CPU list (smp_affinity_list) of allowed CPUs. It's not 13 13 allowed to turn off all CPUs, and if an IRQ controller does not support 14 14 - IRQ affinity then the value will not change from the default of all cpus. 14 14 + IRQ affinity then the value will not change from the default of all CPUs. 15 15 16 16 /proc/irq/default_smp_affinity specifies default affinity mask that applies 17 17 to all non-active IRQs. Once IRQ is allocated/activated its affinity bitmask ··· 60 60 This time around IRQ44 was delivered only to the last four processors. 61 61 i.e counters for the CPU0-3 did not change. 62 62 63 63 - Here is an example of limiting that same irq (44) to cpus 1024 to 1031:: 63 63 + Here is an example of limiting that same IRQ (44) to CPUs 1024 to 1031:: 64 64 65 65 [root@moon 44]# echo 1024-1031 > smp_affinity_list 66 66 [root@moon 44]# cat smp_affinity_list

+19 -19

Documentation/core-api/irq/irq-domain.rst

reviewed

··· 18 18 So in the past, IRQ numbers could be chosen so that they match the 19 19 hardware IRQ line into the root interrupt controller (i.e. the 20 20 component actually firing the interrupt line to the CPU). Nowadays, 21 21 - this number is just a number and the number loose all kind of 22 22 - correspondence to hardware interrupt numbers. 21 21 + this number is just a number and the number has no 22 22 + relationship to hardware interrupt numbers. 23 23 24 24 For this reason, we need a mechanism to separate controller-local 25 25 interrupt numbers, called hardware IRQs, from Linux IRQ numbers. ··· 77 77 variety of methods: 78 78 79 79 - irq_resolve_mapping() returns a pointer to the irq_desc structure 80 80 - for a given domain and hwirq number, and NULL if there was no 80 80 + for a given domain and hwirq number, or NULL if there was no 81 81 mapping. 82 82 - irq_find_mapping() returns a Linux IRQ number for a given domain and 83 83 - hwirq number, and 0 if there was no mapping 83 83 + hwirq number, or 0 if there was no mapping 84 84 - generic_handle_domain_irq() handles an interrupt described by a 85 85 domain and a hwirq number 86 86 87 87 - Note that irq domain lookups must happen in contexts that are 88 88 - compatible with a RCU read-side critical section. 87 87 + Note that irq_domain lookups must happen in contexts that are 88 88 + compatible with an RCU read-side critical section. 89 89 90 90 The irq_create_mapping() function must be called *at least once* 91 91 before any call to irq_find_mapping(), lest the descriptor will not ··· 100 100 ============================ 101 101 102 102 There are several mechanisms available for reverse mapping from hwirq 103 103 - to Linux irq, and each mechanism uses a different allocation function. 103 103 + to Linux IRQ, and each mechanism uses a different allocation function. 104 104 Which reverse map type should be used depends on the use case. Each 105 105 of the reverse map types are described below: 106 106 ··· 111 111 112 112 irq_domain_create_linear() 113 113 114 114 - The linear reverse map maintains a fixed size table indexed by the 114 114 + The linear reverse map maintains a fixed-size table indexed by the 115 115 hwirq number. When a hwirq is mapped, an irq_desc is allocated for 116 116 the hwirq, and the IRQ number is stored in the table. 117 117 118 118 The Linear map is a good choice when the maximum number of hwirqs is 119 119 fixed and a relatively small number (~ < 256). The advantages of this 120 120 - map are fixed time lookup for IRQ numbers, and irq_descs are only 120 120 + map are fixed-time lookup for IRQ numbers, and irq_descs are only 121 121 allocated for in-use IRQs. The disadvantage is that the table must be 122 122 as large as the largest possible hwirq number. 123 123 ··· 134 134 IRQs. When an hwirq is mapped, an irq_desc is allocated and the 135 135 hwirq is used as the lookup key for the radix tree. 136 136 137 137 - The tree map is a good choice if the hwirq number can be very large 137 137 + The Tree map is a good choice if the hwirq number can be very large 138 138 since it doesn't need to allocate a table as large as the largest 139 139 hwirq number. The disadvantage is that hwirq to IRQ number lookup is 140 140 dependent on how many entries are in the table. ··· 169 169 170 170 The Legacy mapping is a special case for drivers that already have a 171 171 range of irq_descs allocated for the hwirqs. It is used when the 172 172 - driver cannot be immediately converted to use the linear mapping. For 172 172 + driver cannot be immediately converted to use the Linear mapping. For 173 173 example, many embedded system board support files use a set of #defines 174 174 for IRQ numbers that are passed to struct device registrations. In that 175 175 - case the Linux IRQ numbers cannot be dynamically assigned and the legacy 175 175 + case the Linux IRQ numbers cannot be dynamically assigned and the Legacy 176 176 mapping should be used. 177 177 178 178 As the name implies, the \*_legacy() functions are deprecated and only ··· 180 180 added. Same goes for the \*_simple() functions when their use results 181 181 in the legacy behaviour. 182 182 183 183 - The legacy map assumes a contiguous range of IRQ numbers has already 183 183 + The Legacy map assumes a contiguous range of IRQ numbers has already 184 184 been allocated for the controller and that the IRQ number can be 185 185 calculated by adding a fixed offset to the hwirq number, and 186 186 visa-versa. The disadvantage is that it requires the interrupt 187 187 controller to manage IRQ allocations and it requires an irq_desc to be 188 188 allocated for every hwirq, even if it is unused. 189 189 190 190 - The legacy map should only be used if fixed IRQ mappings must be 191 191 - supported. For example, ISA controllers would use the legacy map for 190 190 + The Legacy map should only be used if fixed IRQ mappings must be 191 191 + supported. For example, ISA controllers would use the Legacy map for 192 192 mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ 193 193 numbers. 194 194 ··· 197 197 system and will otherwise use a linear domain mapping. The semantics of 198 198 this call are such that if an IRQ range is specified then descriptors 199 199 will be allocated on-the-fly for it, and if no range is specified it 200 200 - will fall through to irq_domain_create_linear() which means *no* irq 200 200 + will fall through to irq_domain_create_linear() which means *no* IRQ 201 201 descriptors will be allocated. 202 202 203 203 A typical use case for simple domains is where an irqchip provider ··· 214 214 215 215 On some architectures, there may be multiple interrupt controllers 216 216 involved in delivering an interrupt from the device to the target CPU. 217 217 - Let's look at a typical interrupt delivering path on x86 platforms:: 217 217 + Let's look at a typical interrupt delivery path on x86 platforms:: 218 218 219 219 Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU 220 220 ··· 227 227 To support such a hardware topology and make software architecture match 228 228 hardware architecture, an irq_domain data structure is built for each 229 229 interrupt controller and those irq_domains are organized into hierarchy. 230 230 - When building irq_domain hierarchy, the irq_domain near to the device is 231 231 - child and the irq_domain near to CPU is parent. So a hierarchy structure 230 230 + When building irq_domain hierarchy, the irq_domain nearest the device is 231 231 + child and the irq_domain nearest the CPU is parent. So a hierarchy structure 232 232 as below will be built for the example above:: 233 233 234 234 CPU Vector irq_domain (root irq_domain to manage CPU vectors)

+1 -1

Documentation/filesystems/erofs.rst

reviewed

··· 116 116 cluster for further reading. It still does 117 117 in-place I/O decompression for the rest 118 118 compressed physical clusters; 119 119 - readaround Cache the both ends of incomplete compressed 119 119 + readaround Cache both ends of incomplete compressed 120 120 physical clusters for further reading. 121 121 It still does in-place I/O decompression 122 122 for the rest compressed physical clusters.

+1 -1

Documentation/filesystems/gfs2-glocks.rst

reviewed

··· 105 105 Operations must not drop either the bit lock or the spinlock 106 106 if its held on entry. go_dump and do_demote_ok must never block. 107 107 Note that go_dump will only be called if the glock's state 108 108 - indicates that it is caching uptodate data. 108 108 + indicates that it is caching up-to-date data. 109 109 110 110 Glock locking order within GFS2: 111 111

+1 -1

Documentation/filesystems/hpfs.rst

reviewed

··· 65 65 'cat FOO', 'cat Foo', 'cat foo' or 'cat F*' but not 'cat f*'. Note, that you 66 66 also won't be able to compile linux kernel (and maybe other things) on HPFS 67 67 because kernel creates different files with names like bootsect.S and 68 68 - bootsect.s. When searching for file thats name has characters >= 128, codepages 68 68 + bootsect.s. When searching for file whose name has characters >= 128, codepages 69 69 are used - see below. 70 70 OS/2 ignores dots and spaces at the end of file name, so this driver does as 71 71 well. If you create 'a. ...', the file 'a' will be created, but you can still

+1 -1

Documentation/filesystems/resctrl.rst

reviewed

··· 563 563 depending on # of threads: 564 564 565 565 For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4 566 566 - thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although 566 566 + thread, with 10% bandwidth' can consume up to 10GBps and 40GBps although 567 567 they have same percentage bandwidth of 10%. This is simply because as 568 568 threads start using more cores in an rdtgroup, the actual bandwidth may 569 569 increase or vary although user specified bandwidth percentage is same.

+2 -2

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

reviewed

··· 454 454 information. 455 455 Once the scan is done, the owning object is re-locked, the live data is used to 456 456 write a new ondisk structure, and the repairs are committed atomically. 457 457 - The hooks are disabled and the staging staging area is freed. 457 457 + The hooks are disabled and the staging area is freed. 458 458 Finally, the storage from the old data structure are carefully reaped. 459 459 460 460 Introducing concurrency helps online repair avoid various locking problems, but ··· 2185 2185 checking and repairing of secondary metadata commonly requires coordination 2186 2186 between a live metadata scan of the filesystem and writer threads that are 2187 2187 updating that metadata. 2188 2188 - Keeping the scan data up to date requires requires the ability to propagate 2188 2188 + Keeping the scan data up to date requires the ability to propagate 2189 2189 metadata updates from the filesystem into the data being collected by the scan. 2190 2190 This *can* be done by appending concurrent updates into a separate log file and 2191 2191 applying them before writing the new metadata to disk, but this leads to

+1 -1

Documentation/networking/can.rst

reviewed

··· 539 539 The CAN filters are processed in per-device filter lists at CAN frame 540 540 reception time. To reduce the number of checks that need to be performed 541 541 while walking through the filter lists the CAN core provides an optimized 542 542 - filter handling when the filter subscription focusses on a single CAN ID. 542 542 + filter handling when the filter subscription focuses on a single CAN ID. 543 543 544 544 For the possible 2048 SFF CAN identifiers the identifier is used as an index 545 545 to access the corresponding subscription list without any further checks.

+1 -1

Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst

reviewed

··· 42 42 overwriting of bridge configuration as CPSW switch driver completely reloads its 43 43 configuration when first port changes its state to UP. 44 44 45 45 - When the both interfaces joined the bridge - CPSW switch driver will enable 45 45 + When both interfaces have joined the bridge - CPSW switch driver will enable 46 46 marking packets with offload_fwd_mark flag. 47 47 48 48 All configuration is implemented via switchdev API.

+1 -1

Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst

reviewed

··· 92 92 overwriting of bridge configuration as CPSW switch driver copletly reloads its 93 93 configuration when first Port changes its state to UP. 94 94 95 95 - When the both interfaces joined the bridge - CPSW switch driver will enable 95 95 + When both interfaces have joined the bridge - CPSW switch driver will enable 96 96 marking packets with offload_fwd_mark flag unless "ale_bypass=0" 97 97 98 98 All configuration is implemented via switchdev API.

+1 -1

Documentation/networking/rds.rst

reviewed

··· 339 339 rds_sendmsg() 340 340 - struct rds_message built from incoming data 341 341 - CMSGs parsed (e.g. RDMA ops) 342 342 - - transport connection alloced and connected if not already 342 342 + - transport connection allocated and connected if not already 343 343 - rds_message placed on send queue 344 344 - send worker awoken 345 345

+2 -2

Documentation/power/pci.rst

reviewed

··· 472 472 The pci_pm_suspend_noirq() routine is executed after suspend_device_irqs() has 473 473 been called, which means that the device driver's interrupt handler won't be 474 474 invoked while this routine is running. It first checks if the device's driver 475 475 - implements legacy PCI suspends routines (Section 3), in which case the legacy 475 475 + implements legacy PCI suspend routines (Section 3), in which case the legacy 476 476 late suspend routine is called and its result is returned (the standard 477 477 configuration registers of the device are saved if the driver's callback hasn't 478 478 done that). Second, if the device driver's struct dev_pm_ops object is not ··· 544 544 The resume phase is carried out asynchronously for PCI devices, like the 545 545 suspend phase described above, which means that if two PCI devices don't depend 546 546 on each other in a known way, the pci_pm_resume() routine may be executed for 547 547 - the both of them in parallel. 547 547 + both of them in parallel. 548 548 549 549 The pci_pm_complete() routine only executes the device driver's pm->complete() 550 550 callback, if defined.

+1 -1

Documentation/power/suspend-and-cpuhotplug.rst

reviewed

··· 13 13 14 14 Well, a picture is worth a thousand words... So ASCII art follows :-) 15 15 16 16 - [This depicts the current design in the kernel, and focusses only on the 16 16 + [This depicts the current design in the kernel, and focuses only on the 17 17 interactions involving the freezer and CPU hotplug and also tries to explain 18 18 the locking involved. It outlines the notifications involved as well. 19 19 But please note that here, only the call paths are illustrated, with the aim

+1 -1

Documentation/trace/fprobe.rst

reviewed

··· 81 81 after the register_fprobe() is called and before it returns. See 82 82 :file:`Documentation/trace/ftrace.rst`. 83 83 84 84 - Also, the unregister_fprobe() will guarantee that the both enter and exit 84 84 + Also, the unregister_fprobe() will guarantee that both enter and exit 85 85 handlers are no longer being called by functions after unregister_fprobe() 86 86 returns as same as unregister_ftrace_function(). 87 87

+1 -1

Documentation/trace/ftrace-uses.rst

reviewed

··· 193 193 Note, if this flag is set, then the callback will always be called 194 194 with preemption disabled. If it is not set, then it is possible 195 195 (but not guaranteed) that the callback will be called in 196 196 - preemptable context. 196 196 + preemptible context. 197 197 198 198 FTRACE_OPS_FL_IPMODIFY 199 199 Requires FTRACE_OPS_FL_SAVE_REGS set. If the callback is to "hijack"

+7 -7

Documentation/trace/ftrace.rst

reviewed

··· 30 30 a task is woken to the task is actually scheduled in. 31 31 32 32 One of the most common uses of ftrace is the event tracing. 33 33 - Throughout the kernel is hundreds of static event points that 33 33 + Throughout the kernel are hundreds of static event points that 34 34 can be enabled via the tracefs file system to see what is 35 35 going on in certain parts of the kernel. 36 36 ··· 383 383 not be listed in this count. 384 384 385 385 If the callback registered to be traced by a function with 386 386 - the "save regs" attribute (thus even more overhead), a 'R' 386 386 + the "save regs" attribute (thus even more overhead), an 'R' 387 387 will be displayed on the same line as the function that 388 388 is returning registers. 389 389 ··· 392 392 an 'I' will be displayed on the same line as the function that 393 393 can be overridden. 394 394 395 395 - If a non ftrace trampoline is attached (BPF) a 'D' will be displayed. 395 395 + If a non-ftrace trampoline is attached (BPF) a 'D' will be displayed. 396 396 Note, normal ftrace trampolines can also be attached, but only one 397 397 "direct" trampoline can be attached to a given function at a time. 398 398 ··· 402 402 403 403 If a function had either the "ip modify" or a "direct" call attached to 404 404 it in the past, a 'M' will be shown. This flag is never cleared. It is 405 405 - used to know if a function was every modified by the ftrace infrastructure, 405 405 + used to know if a function was ever modified by the ftrace infrastructure, 406 406 and can be used for debugging. 407 407 408 408 If the architecture supports it, it will also show what callback ··· 418 418 419 419 This file contains all the functions that ever had a function callback 420 420 to it via the ftrace infrastructure. It has the same format as 421 421 - enabled_functions but shows all functions that have every been 421 421 + enabled_functions but shows all functions that have ever been 422 422 traced. 423 423 424 424 To see any function that has every been modified by "ip modify" or a ··· 517 517 Whenever an event is recorded into the ring buffer, a 518 518 "timestamp" is added. This stamp comes from a specified 519 519 clock. By default, ftrace uses the "local" clock. This 520 520 - clock is very fast and strictly per cpu, but on some 520 520 + clock is very fast and strictly per CPU, but on some 521 521 systems it may not be monotonic with respect to other 522 522 CPUs. In other words, the local clocks may not be in sync 523 523 with local clocks on other CPUs. ··· 868 868 869 869 "mmiotrace" 870 870 871 871 - A special tracer that is used to trace binary module. 871 871 + A special tracer that is used to trace binary modules. 872 872 It will trace all the calls that a module makes to the 873 873 hardware. Everything it writes and reads from the I/O 874 874 as well.

+1 -1

Documentation/trace/histogram.rst

reviewed

··· 840 840 841 841 The compound key examples used a key and a sum value (hitcount) to 842 842 sort the output, but we can just as easily use two keys instead. 843 843 - Here's an example where we use a compound key composed of the the 843 843 + Here's an example where we use a compound key composed of the 844 844 common_pid and size event fields. Sorting with pid as the primary 845 845 key and 'size' as the secondary key allows us to display an 846 846 ordered summary of the recvfrom sizes, with counts, received by