Documentation: fix common spelling mistakes
This fixes several spelling mistakes in the Documentation/ tree, which are caught by checkpatch.pl's spell checking. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>hifive-unleashed-5.1
Kees Cook
Jonathan Corbet
parent
934275c480
commit
08559657b2
|
|
@ -3,9 +3,10 @@ Date: Mai 2012
|
|||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split into general settings and
|
||||
button settings. buttons holds informations about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons to the mouse. The data has to be 47 bytes long.
|
||||
button settings. The buttons variable holds information about
|
||||
button layout. When written, this file lets one write the
|
||||
respective profile buttons to the mouse. The data has to be
|
||||
47 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
|
|
@ -26,8 +27,8 @@ Date: Mai 2012
|
|||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split into general settings and
|
||||
button settings. profile holds informations like resolution, sensitivity
|
||||
and light effects.
|
||||
button settings. A profile holds information like resolution,
|
||||
sensitivity and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
settings back to the mouse. The data has to be 43 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
|
|||
Description:
|
||||
Provides access to the binary "24x7 catalog" provided by the
|
||||
hypervisor on POWER7 and 8 systems. This catalog lists events
|
||||
avaliable from the powerpc "hv_24x7" pmu. Its format is
|
||||
available from the powerpc "hv_24x7" pmu. Its format is
|
||||
documented here:
|
||||
https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-catalog.h
|
||||
|
||||
|
|
|
|||
|
|
@ -39,5 +39,5 @@ Description: Make it possible to adjust defio refresh rate.
|
|||
Note: As device can barely do 2 complete refreshes a second
|
||||
it only makes sense to adjust this value if only one or two
|
||||
tiles get changed and it's not appropriate to expect the application
|
||||
to flush it's tiny changes explicitely at higher than default rate.
|
||||
to flush its tiny changes explicitly at higher than default rate.
|
||||
|
||||
|
|
|
|||
|
|
@ -169,7 +169,7 @@ Description:
|
|||
to enable/disable/clear ACPI interrupts in user space, which can be
|
||||
used to debug some ACPI interrupt storm issues.
|
||||
|
||||
Note that only writting to VALID GPE/Fixed Event is allowed,
|
||||
Note that only writing to VALID GPE/Fixed Event is allowed,
|
||||
i.e. user can only change the status of runtime GPE and
|
||||
Fixed Event with event handler installed.
|
||||
|
||||
|
|
|
|||
|
|
@ -2841,7 +2841,7 @@ for a GOP and keep it below or equal the set bitrate target. Otherwise the rate
|
|||
overall average bitrate for the stream and keeps it below or equal to the set bitrate. In the first case
|
||||
the average bitrate for the whole stream will be smaller then the set bitrate. This is caused because the
|
||||
average is calculated for smaller number of frames, on the other hand enabling this setting will ensure that
|
||||
the stream will meet tight bandwidth contraints. Applicable to encoders.
|
||||
the stream will meet tight bandwidth constraints. Applicable to encoders.
|
||||
</entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ initialize all fields of the &v4l2-vbi-format;
|
|||
results of <constant>VIDIOC_G_FMT</constant>, and call the
|
||||
&VIDIOC-S-FMT; ioctl with a pointer to this structure. Drivers return
|
||||
an &EINVAL; only when the given parameters are ambiguous, otherwise
|
||||
they modify the parameters according to the hardware capabilites and
|
||||
they modify the parameters according to the hardware capabilities and
|
||||
return the actual parameters. When the driver allocates resources at
|
||||
this point, it may return an &EBUSY; to indicate the returned
|
||||
parameters are valid but the required resources are currently not
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ or the <structfield>flags</structfield> argument is not valid.</para>
|
|||
<term><errorcode>ERANGE</errorcode></term>
|
||||
<listitem>
|
||||
<para>It is not possible to adjust &v4l2-rect; <structfield>
|
||||
r</structfield> rectangle to satisfy all contraints given in the
|
||||
r</structfield> rectangle to satisfy all constraints given in the
|
||||
<structfield>flags</structfield> argument.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
|
|
|||
|
|
@ -176,13 +176,13 @@ a history of how Linux changed RCU more than RCU changed Linux
|
|||
which Mathieu Desnoyers is now maintaining [MathieuDesnoyers2009URCU]
|
||||
[MathieuDesnoyersPhD]. TINY_RCU [PaulEMcKenney2009BloatWatchRCU] made
|
||||
its appearance, as did expedited RCU [PaulEMcKenney2009expeditedRCU].
|
||||
The problem of resizeable RCU-protected hash tables may now be on a path
|
||||
The problem of resizable RCU-protected hash tables may now be on a path
|
||||
to a solution [JoshTriplett2009RPHash]. A few academic researchers are now
|
||||
using RCU to solve their parallel problems [HariKannan2009DynamicAnalysisRCU].
|
||||
|
||||
2010 produced a simpler preemptible-RCU implementation
|
||||
based on TREE_RCU [PaulEMcKenney2010SimpleOptRCU], lockdep-RCU
|
||||
[PaulEMcKenney2010LockdepRCU], another resizeable RCU-protected hash
|
||||
[PaulEMcKenney2010LockdepRCU], another resizable RCU-protected hash
|
||||
table [HerbertXu2010RCUResizeHash] (this one consuming more memory,
|
||||
but allowing arbitrary changes in hash function, as required for DoS
|
||||
avoidance in the networking code), realization of the 2009 RCU-protected
|
||||
|
|
@ -193,7 +193,7 @@ the RCU API [PaulEMcKenney2010RCUAPI].
|
|||
[LinusTorvalds2011Linux2:6:38:rc1:NPigginVFS], an RCU-protected red-black
|
||||
tree using software transactional memory to protect concurrent updates
|
||||
(strange, but true!) [PhilHoward2011RCUTMRBTree], yet another variant of
|
||||
RCU-protected resizeable hash tables [Triplett:2011:RPHash], the 3.0 RCU
|
||||
RCU-protected resizable hash tables [Triplett:2011:RPHash], the 3.0 RCU
|
||||
trainwreck [PaulEMcKenney2011RCU3.0trainwreck], and Neil Brown's "Meet the
|
||||
Lockers" LWN article [NeilBrown2011MeetTheLockers]. Some academic
|
||||
work looked at debugging uses of RCU [Seyster:2011:RFA:2075416.2075425].
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ RedBoot scripting
|
|||
-----------------
|
||||
|
||||
All the commands above aren't so useful if they have to be typed in every
|
||||
time the Assabet is rebooted. Therefore it's possible to automatize the boot
|
||||
time the Assabet is rebooted. Therefore it's possible to automate the boot
|
||||
process using RedBoot's scripting capability.
|
||||
|
||||
For example, I use this to boot Linux with both the kernel and the ramdisk
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
Cirrus Logic/Wolfson Microelectronics Arizona class audio SoCs
|
||||
|
||||
These devices are audio SoCs with extensive digital capabilites and a range
|
||||
These devices are audio SoCs with extensive digital capabilities and a range
|
||||
of analogue I/O.
|
||||
|
||||
Required properties:
|
||||
|
|
|
|||
|
|
@ -272,7 +272,7 @@ A partial list of the supported mount options follows:
|
|||
same domain (e.g. running winbind or nss_ldap) and
|
||||
the server supports the Unix Extensions then the uid
|
||||
and gid can be retrieved from the server (and uid
|
||||
and gid would not have to be specifed on the mount.
|
||||
and gid would not have to be specified on the mount.
|
||||
For servers which do not support the CIFS Unix
|
||||
extensions, the default uid (and gid) returned on lookup
|
||||
of existing files will be the uid (gid) of the person
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ Main features of this FS include:
|
|||
* Read request (data read, directory listing, lookup requests) balancing between multiple servers.
|
||||
* Write requests are replicated to multiple servers and completed only when all of them are acked.
|
||||
* Ability to add and/or remove servers from the working set at run-time.
|
||||
* Strong authentification and possible data encryption in network channel.
|
||||
* Strong authentication and possible data encryption in network channel.
|
||||
* Extended attributes support.
|
||||
|
||||
POHMELFS is based on transactions, which are potentially long-standing objects that live
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ qnx6fs shares many properties with traditional Unix filesystems. It has the
|
|||
concepts of blocks, inodes and directories.
|
||||
On QNX it is possible to create little endian and big endian qnx6 filesystems.
|
||||
This feature makes it possible to create and use a different endianness fs
|
||||
for the target (QNX is used on quite a range of embedded systems) plattform
|
||||
for the target (QNX is used on quite a range of embedded systems) platform
|
||||
running on a different endianness.
|
||||
The Linux driver handles endianness transparently. (LE and BE)
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@
|
|||
|
||||
1), kernel(driver):
|
||||
- calls request_firmware(&fw_entry, $FIRMWARE, device)
|
||||
- kernel searchs the fimware image with name $FIRMWARE directly
|
||||
- kernel searches the firmware image with name $FIRMWARE directly
|
||||
in the below search path of root filesystem:
|
||||
User customized search path by module parameter 'path'[1]
|
||||
"/lib/firmware/updates/" UTS_RELEASE,
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Supported chips:
|
|||
1) For revisions 2 and 3 uGuru's the driver can autodetect the
|
||||
sensortype (Volt or Temp) for bank1 sensors, for revision 1 uGuru's
|
||||
this doesnot always work. For these uGuru's the autodection can
|
||||
be overriden with the bank1_types module param. For all 3 known
|
||||
be overridden with the bank1_types module param. For all 3 known
|
||||
revison 1 motherboards the correct use of this param is:
|
||||
bank1_types=1,1,0,0,0,0,0,2,0,0,0,0,2,0,0,1
|
||||
You may also need to specify the fan_sensors option for these boards
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ Partitions and P_Keys
|
|||
main interface for a subinterface is in "parent."
|
||||
|
||||
Child interface create/delete can also be done using IPoIB's
|
||||
rtnl_link_ops, where childs created using either way behave the same.
|
||||
rtnl_link_ops, where children created using either way behave the same.
|
||||
|
||||
Datagram vs Connected modes
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ This is the driver for the Altera Triple-Speed Ethernet (TSE) controllers
|
|||
using the SGDMA and MSGDMA soft DMA IP components. The driver uses the
|
||||
platform bus to obtain component resources. The designs used to test this
|
||||
driver were built for a Cyclone(R) V SOC FPGA board, a Cyclone(R) V FPGA board,
|
||||
and tested with ARM and NIOS processor hosts seperately. The anticipated use
|
||||
and tested with ARM and NIOS processor hosts separately. The anticipated use
|
||||
cases are simple communications between an embedded system and an external peer
|
||||
for status and simple configuration of the embedded system.
|
||||
|
||||
|
|
|
|||
|
|
@ -1256,7 +1256,7 @@ solution for a couple of reasons:
|
|||
7. SocketCAN resources
|
||||
-----------------------
|
||||
|
||||
The Linux CAN / SocketCAN project ressources (project site / mailing list)
|
||||
The Linux CAN / SocketCAN project resources (project site / mailing list)
|
||||
are referenced in the MAINTAINERS file in the Linux source tree.
|
||||
Search for CAN NETWORK [LAYERS|DRIVERS].
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ be found at:
|
|||
|
||||
http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page
|
||||
|
||||
and then click following respective util pacakge link
|
||||
and then click following respective util package link
|
||||
|
||||
Version Link
|
||||
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ was not really a win, due to the different data structures. Also, the
|
|||
hrtimer functions now have clearer behavior and clearer names - such as
|
||||
hrtimer_try_to_cancel() and hrtimer_cancel() [which are roughly
|
||||
equivalent to del_timer() and del_timer_sync()] - so there's no direct
|
||||
1:1 mapping between them on the algorithmical level, and thus no real
|
||||
1:1 mapping between them on the algorithmic level, and thus no real
|
||||
potential for code sharing either.
|
||||
|
||||
Basic data types: every time value, absolute or relative, is in a
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ the driver. What to do then?
|
|||
cx88-cards.c. If that worked, mail me your changes as unified
|
||||
diff ("diff -u").
|
||||
(3) Or you can mail me the config information. I need at least the
|
||||
following informations to add the card:
|
||||
following information to add the card:
|
||||
|
||||
* the PCI Subsystem ID ("0070:3400" from the line above,
|
||||
"lspci -v" output is fine too).
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ receiver chips. Some boards use the i2c bus instead of the gpio pins
|
|||
to connect the mux chip.
|
||||
|
||||
As mentioned above, there is a array which holds the required
|
||||
informations for each known board. You basically have to create a new
|
||||
information for each known board. You basically have to create a new
|
||||
line for your board. The important fields are these two:
|
||||
|
||||
struct tvcard
|
||||
|
|
|
|||
|
|
@ -220,7 +220,7 @@ resulting effect on persistent huge page allocation is as follows:
|
|||
node list of "all" with numactl --interleave or --membind [-m] to achieve
|
||||
interleaving over all nodes in the system or cpuset.
|
||||
|
||||
4) Any task mempolicy specifed--e.g., using numactl--will be constrained by
|
||||
4) Any task mempolicy specified--e.g., using numactl--will be constrained by
|
||||
the resource limits of any cpuset in which the task runs. Thus, there will
|
||||
be no way for a task with non-default policy running in a cpuset with a
|
||||
subset of the system nodes to allocate huge pages outside the cpuset
|
||||
|
|
|
|||
Loading…
Reference in New Issue