mirror of
https://github.com/torvalds/linux.git
synced 2024-12-25 12:21:37 +00:00
Documentation: Fix multiple typo in Documentation
Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This commit is contained in:
Masanari Iida
Jiri Kosina
parent
4e70daaf05
commit
40e47125e6
@ -7,7 +7,7 @@ Date: 09-Jul-2007
|
||||
KernelVersion v2.6.22
|
||||
Contact: linux-wireless@vger.kernel.org
|
||||
Description: Current state of the transmitter.
|
||||
This file is deprecated and sheduled to be removed in 2014,
|
||||
This file is deprecated and scheduled to be removed in 2014,
|
||||
because its not possible to express the 'soft and hard block'
|
||||
state of the rfkill driver.
|
||||
Values: A numeric value.
|
||||
|
||||
@ -6,7 +6,7 @@ Description:
|
||||
The name of the module that is in the kernel. This
|
||||
module name will show up either if the module is built
|
||||
directly into the kernel, or if it is loaded as a
|
||||
dyanmic module.
|
||||
dynamic module.
|
||||
|
||||
/sys/module/MODULENAME/parameters
|
||||
This directory contains individual files that are each
|
||||
|
||||
@ -945,7 +945,7 @@ and other resources, etc.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
!BSY && ERR after CDB tranfer starts but before the
|
||||
!BSY && ERR after CDB transfer starts but before the
|
||||
last byte of CDB is transferred. ATA/ATAPI standard states
|
||||
that "The device shall not terminate the PACKET command
|
||||
with an error before the last byte of the command packet has
|
||||
@ -1050,7 +1050,7 @@ and other resources, etc.
|
||||
to complete a command. Combined with the fact that MWDMA
|
||||
and PIO transfer errors aren't allowed to use ICRC bit up to
|
||||
ATA/ATAPI-7, it seems to imply that ABRT bit alone could
|
||||
indicate tranfer errors.
|
||||
indicate transfer errors.
|
||||
</para>
|
||||
<para>
|
||||
However, ATA/ATAPI-8 draft revision 1f removes the part
|
||||
|
||||
@ -444,7 +444,7 @@ linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR24</constant></link></para></entr
|
||||
<entry><para><link
|
||||
linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR32</constant></link><footnote>
|
||||
<para>Presumably all V4L RGB formats are
|
||||
little-endian, although some drivers might interpret them according to machine endianess. V4L2 defines little-endian, big-endian and red/blue
|
||||
little-endian, although some drivers might interpret them according to machine endianness. V4L2 defines little-endian, big-endian and red/blue
|
||||
swapped variants. For details see <xref linkend="pixfmt-rgb" />.</para>
|
||||
</footnote></para></entry>
|
||||
</row>
|
||||
@ -823,7 +823,7 @@ standard); 35468950 Hz PAL and SECAM (625-line standards)</entry>
|
||||
<row>
|
||||
<entry>sample_format</entry>
|
||||
<entry>V4L2_PIX_FMT_GREY. The last four bytes (a
|
||||
machine endianess integer) contain a frame counter.</entry>
|
||||
machine endianness integer) contain a frame counter.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start[]</entry>
|
||||
|
||||
@ -25,7 +25,7 @@ inline (either in the code emitted directly by the compiler, or part of
|
||||
the implementation of a library call) when optimizing for a recent enough
|
||||
processor that has the necessary native support, but only if resulting
|
||||
binaries are already to be incompatible with earlier ARM processors due to
|
||||
useage of similar native instructions for other things. In other words
|
||||
usage of similar native instructions for other things. In other words
|
||||
don't make binaries unable to run on earlier processors just for the sake
|
||||
of not using these kernel helpers if your compiled code is not going to
|
||||
use new instructions for other purpose.
|
||||
|
||||
@ -94,11 +94,11 @@ Throttling/Upper Limit policy
|
||||
|
||||
Hierarchical Cgroups
|
||||
====================
|
||||
- Currently none of the IO control policy supports hierarhical groups. But
|
||||
cgroup interface does allow creation of hierarhical cgroups and internally
|
||||
- Currently none of the IO control policy supports hierarchical groups. But
|
||||
cgroup interface does allow creation of hierarchical cgroups and internally
|
||||
IO policies treat them as flat hierarchy.
|
||||
|
||||
So this patch will allow creation of cgroup hierarhcy but at the backend
|
||||
So this patch will allow creation of cgroup hierarchcy but at the backend
|
||||
everything will be treated as flat. So if somebody created a hierarchy like
|
||||
as follows.
|
||||
|
||||
@ -266,7 +266,7 @@ Proportional weight policy files
|
||||
- blkio.idle_time
|
||||
- Debugging aid only enabled if CONFIG_DEBUG_BLK_CGROUP=y.
|
||||
This is the amount of time spent by the IO scheduler idling for a
|
||||
given cgroup in anticipation of a better request than the exising ones
|
||||
given cgroup in anticipation of a better request than the existing ones
|
||||
from other queues/cgroups. This is in nanoseconds. If this is read
|
||||
when the cgroup is in an idling state, the stat will only report the
|
||||
idle_time accumulated till the last idle period and will not include
|
||||
@ -283,34 +283,34 @@ Throttling/Upper limit policy files
|
||||
-----------------------------------
|
||||
- blkio.throttle.read_bps_device
|
||||
- Specifies upper limit on READ rate from the device. IO rate is
|
||||
specified in bytes per second. Rules are per deivce. Following is
|
||||
specified in bytes per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.read_bps_device
|
||||
|
||||
- blkio.throttle.write_bps_device
|
||||
- Specifies upper limit on WRITE rate to the device. IO rate is
|
||||
specified in bytes per second. Rules are per deivce. Following is
|
||||
specified in bytes per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.write_bps_device
|
||||
|
||||
- blkio.throttle.read_iops_device
|
||||
- Specifies upper limit on READ rate from the device. IO rate is
|
||||
specified in IO per second. Rules are per deivce. Following is
|
||||
specified in IO per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.read_iops_device
|
||||
|
||||
- blkio.throttle.write_iops_device
|
||||
- Specifies upper limit on WRITE rate to the device. IO rate is
|
||||
specified in io per second. Rules are per deivce. Following is
|
||||
specified in io per second. Rules are per device. Following is
|
||||
the format.
|
||||
|
||||
echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.write_iops_device
|
||||
|
||||
Note: If both BW and IOPS rules are specified for a device, then IO is
|
||||
subjectd to both the constraints.
|
||||
subjected to both the constraints.
|
||||
|
||||
- blkio.throttle.io_serviced
|
||||
- Number of IOs (bio) completed to/from the disk by the group (as
|
||||
|
||||
@ -28,7 +28,7 @@ The target is named "raid" and it accepts the following parameters:
|
||||
raid6_nc RAID6 N continue
|
||||
- rotating parity N (right-to-left) with data continuation
|
||||
|
||||
Refererence: Chapter 4 of
|
||||
Reference: Chapter 4 of
|
||||
http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
|
||||
|
||||
<#raid_params>: The number of parameters that follow.
|
||||
|
||||
@ -3,7 +3,7 @@ Introduction
|
||||
|
||||
The more-sophisticated device-mapper targets require complex metadata
|
||||
that is managed in kernel. In late 2010 we were seeing that various
|
||||
different targets were rolling their own data strutures, for example:
|
||||
different targets were rolling their own data structures, for example:
|
||||
|
||||
- Mikulas Patocka's multisnap implementation
|
||||
- Heinz Mauelshagen's thin provisioning target
|
||||
|
||||
@ -5,7 +5,7 @@ IPs present in the SoC.
|
||||
On top of that an omap_device is created to extend the platform_device
|
||||
capabilities and to allow binding with one or several hwmods.
|
||||
The hwmods will contain all the information to build the device:
|
||||
adresse range, irq lines, dma lines, interconnect, PRCM register,
|
||||
address range, irq lines, dma lines, interconnect, PRCM register,
|
||||
clock domain, input clocks.
|
||||
For the moment just point to the existing hwmod, the next step will be
|
||||
to move data from hwmod to device-tree representation.
|
||||
|
||||
@ -1,3 +1,3 @@
|
||||
prima2 "cb" evalutation board
|
||||
prima2 "cb" evaluation board
|
||||
Required root node properties:
|
||||
- compatible = "sirf,prima2-cb", "sirf,prima2";
|
||||
|
||||
@ -169,7 +169,7 @@ it with special cases.
|
||||
|
||||
b) Entry with a flattened device-tree block. Firmware loads the
|
||||
physical address of the flattened device tree block (dtb) into r2,
|
||||
r1 is not used, but it is considered good practise to use a valid
|
||||
r1 is not used, but it is considered good practice to use a valid
|
||||
machine number as described in Documentation/arm/Booting.
|
||||
|
||||
r0 : 0
|
||||
|
||||
@ -63,7 +63,7 @@ The slave DMA usage consists of following steps:
|
||||
struct dma_slave_config *config)
|
||||
|
||||
Please see the dma_slave_config structure definition in dmaengine.h
|
||||
for a detailed explaination of the struct members. Please note
|
||||
for a detailed explanation of the struct members. Please note
|
||||
that the 'direction' member will be going away as it duplicates the
|
||||
direction given in the prepare call.
|
||||
|
||||
|
||||
@ -177,8 +177,8 @@ sgram - tells to driver that you have Gxx0 with SGRAM memory. It has no
|
||||
effect without `init'.
|
||||
sdram - tells to driver that you have Gxx0 with SDRAM memory.
|
||||
It is a default.
|
||||
inv24 - change timings parameters for 24bpp modes on Millenium and
|
||||
Millenium II. Specify this if you see strange color shadows around
|
||||
inv24 - change timings parameters for 24bpp modes on Millennium and
|
||||
Millennium II. Specify this if you see strange color shadows around
|
||||
characters.
|
||||
noinv24 - use standard timings. It is the default.
|
||||
inverse - invert colors on screen (for LCD displays)
|
||||
@ -204,9 +204,9 @@ grayscale - enable grayscale summing. It works in PSEUDOCOLOR modes (text,
|
||||
can paint colors.
|
||||
nograyscale - disable grayscale summing. It is default.
|
||||
cross4MB - enables that pixel line can cross 4MB boundary. It is default for
|
||||
non-Millenium.
|
||||
non-Millennium.
|
||||
nocross4MB - pixel line must not cross 4MB boundary. It is default for
|
||||
Millenium I or II, because of these devices have hardware
|
||||
Millennium I or II, because of these devices have hardware
|
||||
limitations which do not allow this. But this option is
|
||||
incompatible with some (if not all yet released) versions of
|
||||
XF86_FBDev.
|
||||
|
||||
@ -308,7 +308,7 @@ min_batch_time=usec This parameter sets the commit time (as
|
||||
fast disks, at the cost of increasing latency.
|
||||
|
||||
journal_ioprio=prio The I/O priority (from 0 to 7, where 0 is the
|
||||
highest priorty) which should be used for I/O
|
||||
highest priority) which should be used for I/O
|
||||
operations submitted by kjournald2 during a
|
||||
commit operation. This defaults to 3, which is
|
||||
a slightly higher priority than the default I/O
|
||||
@ -343,7 +343,7 @@ noinit_itable Do not initialize any uninitialized inode table
|
||||
init_itable=n The lazy itable init code will wait n times the
|
||||
number of milliseconds it took to zero out the
|
||||
previous block group's inode table. This
|
||||
minimizes the impact on the systme performance
|
||||
minimizes the impact on the system performance
|
||||
while file system's inode table is being initialized.
|
||||
|
||||
discard Controls whether ext4 should issue discard/TRIM
|
||||
|
||||
@ -62,7 +62,7 @@ be fixed.
|
||||
|
||||
The REMOVE uevent is generated at the end of an unsuccessful mount
|
||||
or at the end of a umount of the filesystem. All REMOVE uevents will
|
||||
have been preceded by at least an ADD uevent for the same fileystem,
|
||||
have been preceded by at least an ADD uevent for the same filesystem,
|
||||
and unlike the other uevents is generated automatically by the kernel's
|
||||
kobject subsystem.
|
||||
|
||||
|
||||
@ -20,7 +20,7 @@ Commands can be embedded into transaction command (which in turn has own command
|
||||
so one can extend protocol as needed without breaking backward compatibility as long
|
||||
as old commands are supported. All string lengths include tail 0 byte.
|
||||
|
||||
All commands are transferred over the network in big-endian. CPU endianess is used at the end peers.
|
||||
All commands are transferred over the network in big-endian. CPU endianness is used at the end peers.
|
||||
|
||||
@cmd - command number, which specifies command to be processed. Following
|
||||
commands are used currently:
|
||||
|
||||
@ -993,7 +993,7 @@ struct dentry_operations {
|
||||
|
||||
If the 'rcu_walk' parameter is true, then the caller is doing a
|
||||
pathwalk in RCU-walk mode. Sleeping is not permitted in this mode,
|
||||
and the caller can be asked to leave it and call again by returing
|
||||
and the caller can be asked to leave it and call again by returning
|
||||
-ECHILD.
|
||||
|
||||
This function is only used if DCACHE_MANAGE_TRANSIT is set on the
|
||||
|
||||
@ -53,7 +53,7 @@ attributes are write-only, all other attributes are read-only.
|
||||
in1_label "vin1" or "vout1" depending on chip variant and
|
||||
configuration.
|
||||
in1_input Measured voltage.
|
||||
in1_min Minumum Voltage.
|
||||
in1_min Minimum Voltage.
|
||||
in1_max Maximum voltage.
|
||||
in1_min_alarm Voltage low alarm.
|
||||
in1_max_alarm Voltage high alarm.
|
||||
|
||||
@ -42,9 +42,9 @@ attributes are read-only.
|
||||
|
||||
in[1-4]_label "vout[1-4]"
|
||||
in[1-4]_input Measured voltage. From READ_VOUT register.
|
||||
in[1-4]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-4]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-4]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[1-4]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-4]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-4]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[1-4]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[1-4]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
|
||||
@ -48,9 +48,9 @@ attributes are read-only.
|
||||
|
||||
in[1-6]_label "vout[1-6]".
|
||||
in[1-6]_input Measured voltage. From READ_VOUT register.
|
||||
in[1-6]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-6]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-6]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[1-6]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-6]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-6]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[1-6]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[1-6]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
|
||||
@ -42,9 +42,9 @@ attributes are read-only.
|
||||
|
||||
in1_label "vout1"
|
||||
in1_input Measured voltage. From READ_VOUT register.
|
||||
in1_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in1_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in1_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in1_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in1_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in1_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in1_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in1_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
|
||||
@ -70,9 +70,9 @@ attributes are read-only.
|
||||
|
||||
in[1-12]_label "vout[1-12]".
|
||||
in[1-12]_input Measured voltage. From READ_VOUT register.
|
||||
in[1-12]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-12]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-12]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[1-12]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-12]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-12]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[1-12]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[1-12]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
@ -82,7 +82,7 @@ in[1-12]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
|
||||
curr[1-12]_label "iout[1-12]".
|
||||
curr[1-12]_input Measured current. From READ_IOUT register.
|
||||
curr[1-12]_max Maximum current. From IOUT_OC_WARN_LIMIT register.
|
||||
curr[1-12]_lcrit Critical minumum output current. From IOUT_UC_FAULT_LIMIT
|
||||
curr[1-12]_lcrit Critical minimum output current. From IOUT_UC_FAULT_LIMIT
|
||||
register.
|
||||
curr[1-12]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
|
||||
curr[1-12]_max_alarm Current high alarm. From IOUT_OC_WARNING status.
|
||||
|
||||
@ -54,9 +54,9 @@ attributes are read-only.
|
||||
|
||||
in1_label "vin".
|
||||
in1_input Measured voltage. From READ_VIN register.
|
||||
in1_min Minumum Voltage. From VIN_UV_WARN_LIMIT register.
|
||||
in1_min Minimum Voltage. From VIN_UV_WARN_LIMIT register.
|
||||
in1_max Maximum voltage. From VIN_OV_WARN_LIMIT register.
|
||||
in1_lcrit Critical minumum Voltage. VIN_UV_FAULT_LIMIT register.
|
||||
in1_lcrit Critical minimum Voltage. VIN_UV_FAULT_LIMIT register.
|
||||
in1_crit Critical maximum voltage. From VIN_OV_FAULT_LIMIT register.
|
||||
in1_min_alarm Voltage low alarm. From VIN_UV_WARNING status.
|
||||
in1_max_alarm Voltage high alarm. From VIN_OV_WARNING status.
|
||||
@ -65,9 +65,9 @@ in1_crit_alarm Voltage critical high alarm. From VIN_OV_FAULT status.
|
||||
|
||||
in[2-5]_label "vout[1-4]".
|
||||
in[2-5]_input Measured voltage. From READ_VOUT register.
|
||||
in[2-5]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[2-5]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[2-5]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[2-5]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[2-5]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[2-5]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[2-5]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[2-5]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
@ -80,7 +80,7 @@ curr1_input Measured current. From READ_IIN register.
|
||||
curr[2-5]_label "iout[1-4]".
|
||||
curr[2-5]_input Measured current. From READ_IOUT register.
|
||||
curr[2-5]_max Maximum current. From IOUT_OC_WARN_LIMIT register.
|
||||
curr[2-5]_lcrit Critical minumum output current. From IOUT_UC_FAULT_LIMIT
|
||||
curr[2-5]_lcrit Critical minimum output current. From IOUT_UC_FAULT_LIMIT
|
||||
register.
|
||||
curr[2-5]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
|
||||
curr[2-5]_max_alarm Current high alarm. From IOUT_OC_WARNING status.
|
||||
|
||||
@ -108,7 +108,7 @@ in1_label "vin"
|
||||
in1_input Measured input voltage.
|
||||
in1_min Minimum input voltage.
|
||||
in1_max Maximum input voltage.
|
||||
in1_lcrit Critical minumum input voltage.
|
||||
in1_lcrit Critical minimum input voltage.
|
||||
in1_crit Critical maximum input voltage.
|
||||
in1_min_alarm Input voltage low alarm.
|
||||
in1_max_alarm Input voltage high alarm.
|
||||
@ -117,7 +117,7 @@ in1_crit_alarm Input voltage critical high alarm.
|
||||
|
||||
in2_label "vout1"
|
||||
in2_input Measured output voltage.
|
||||
in2_lcrit Critical minumum output Voltage.
|
||||
in2_lcrit Critical minimum output Voltage.
|
||||
in2_crit Critical maximum output voltage.
|
||||
in2_lcrit_alarm Critical output voltage critical low alarm.
|
||||
in2_crit_alarm Critical output voltage critical high alarm.
|
||||
|
||||
@ -138,7 +138,7 @@ VI. Setting Parameters
|
||||
|
||||
The return value is the size in bytes of the data written into
|
||||
ops->resbuf if no errors occur. If an error occurs, -1 is returned
|
||||
and errno is set appropriatly:
|
||||
and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
@ -222,7 +222,7 @@ VIII. Downloading Software
|
||||
RETURNS
|
||||
|
||||
This function returns 0 no errors occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
@ -264,7 +264,7 @@ IX. Uploading Software
|
||||
RETURNS
|
||||
|
||||
This function returns 0 if no errors occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
@ -301,7 +301,7 @@ X. Removing Software
|
||||
RETURNS
|
||||
|
||||
This function returns 0 if no errors occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
@ -325,7 +325,7 @@ X. Validating Configuration
|
||||
RETURNS
|
||||
|
||||
This function returns 0 if no erro occur. If an error occurs, -1 is
|
||||
returned and errno is set appropriatly:
|
||||
returned and errno is set appropriately:
|
||||
|
||||
ETIMEDOUT Timeout waiting for reply message
|
||||
ENXIO Invalid IOP number
|
||||
@ -360,7 +360,7 @@ XI. Configuration Dialog
|
||||
RETURNS
|
||||
|
||||
This function returns 0 if no error occur. If an error occurs, -1
|
||||
is returned and errno is set appropriatly:
|
||||
is returned and errno is set appropriately:
|
||||
|
||||
EFAULT Invalid user space pointer was passed
|
||||
ENXIO Invalid IOP number
|
||||
|
||||
@ -175,7 +175,7 @@
|
||||
* since the .pdf version doesn't seem to work...
|
||||
* -- Updated the TODO list to something more current.
|
||||
*
|
||||
* 4.15 Aug 25, 1998 -- Updated ide-cd.h to respect mechine endianess,
|
||||
* 4.15 Aug 25, 1998 -- Updated ide-cd.h to respect machine endianness,
|
||||
* patch thanks to "Eddie C. Dost" <ecd@skynet.be>
|
||||
*
|
||||
* 4.50 Oct 19, 1998 -- New maintainers!
|
||||
|
||||
@ -131,8 +131,8 @@ number of contacts (f1 and f0 in the table below).
|
||||
byte 5: 0 1 ? ? ? ? f1 f0
|
||||
|
||||
This packet only appears after a position packet with the mt bit set, and
|
||||
ususally only appears when there are two or more contacts (although
|
||||
ocassionally it's seen with only a single contact).
|
||||
usually only appears when there are two or more contacts (although
|
||||
occassionally it's seen with only a single contact).
|
||||
|
||||
The final v3 packet type is the trackstick packet.
|
||||
|
||||
|
||||
@ -330,7 +330,7 @@ the USB documentation for how to setup an USB mouse.
|
||||
The TM DirectConnect (BSP) protocol is supported by the tmdc.c
|
||||
module. This includes, but is not limited to:
|
||||
|
||||
* ThrustMaster Millenium 3D Inceptor
|
||||
* ThrustMaster Millennium 3D Interceptor
|
||||
* ThrustMaster 3D Rage Pad
|
||||
* ThrustMaster Fusion Digital Game Pad
|
||||
|
||||
|
||||
@ -596,7 +596,7 @@ HDIO_DRIVE_TASKFILE execute raw taskfile
|
||||
if CHS/LBA28
|
||||
|
||||
The association between in_flags.all and each enable
|
||||
bitfield flips depending on endianess; fortunately, TASKFILE
|
||||
bitfield flips depending on endianness; fortunately, TASKFILE
|
||||
only uses inflags.b.data bit and ignores all other bits.
|
||||
The end result is that, on any endian machines, it has no
|
||||
effect other than modifying in_flags on completion.
|
||||
@ -720,7 +720,7 @@ HDIO_DRIVE_TASKFILE execute raw taskfile
|
||||
|
||||
[6] Do not access {in|out}_flags->all except for resetting
|
||||
all the bits. Always access individual bit fields. ->all
|
||||
value will flip depending on endianess. For the same
|
||||
value will flip depending on endianness. For the same
|
||||
reason, do not use IDE_{TASKFILE|HOB}_STD_{OUT|IN}_FLAGS
|
||||
constants defined in hdreg.h.
|
||||
|
||||
|
||||
@ -117,7 +117,7 @@ applicable everywhere (see syntax).
|
||||
This attribute is only applicable to menu blocks, if the condition is
|
||||
false, the menu block is not displayed to the user (the symbols
|
||||
contained there can still be selected by other symbols, though). It is
|
||||
similar to a conditional "prompt" attribude for individual menu
|
||||
similar to a conditional "prompt" attribute for individual menu
|
||||
entries. Default value of "visible" is true.
|
||||
|
||||
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
|
||||
|
||||
@ -44,7 +44,7 @@ the 'software updates' pages. The firmware binaries are part of
|
||||
the various ForeThought software distributions.
|
||||
|
||||
Notice that different versions of the PCA-200E firmware exist, depending
|
||||
on the endianess of the host architecture. The driver is shipped with
|
||||
on the endianness of the host architecture. The driver is shipped with
|
||||
both little and big endian PCA firmware images.
|
||||
|
||||
Name and location of the new firmware images can be set at kernel
|
||||
|
||||
@ -1718,7 +1718,7 @@ Changes from 20040319 to 20040326
|
||||
* lpfc_els_timeout_handler() now uses system timer.
|
||||
* Further cleanup of #ifdef powerpc
|
||||
* lpfc_scsi_timeout_handler() now uses system timer.
|
||||
* Replace common driver's own defines for endianess w/ Linux's
|
||||
* Replace common driver's own defines for endianness w/ Linux's
|
||||
__BIG_ENDIAN etc.
|
||||
* Added #ifdef IPFC for all IPFC specific code.
|
||||
* lpfc_disc_retry_rptlun() now uses system timer.
|
||||
|
||||
@ -510,7 +510,7 @@ i. Support for 1078 type (ppc IOP) controller, device id : 0x60 added.
|
||||
3 Older Version : 00.00.02.02
|
||||
i. Register 16 byte CDB capability with scsi midlayer
|
||||
|
||||
"Ths patch properly registers the 16 byte command length capability of the
|
||||
"This patch properly registers the 16 byte command length capability of the
|
||||
megaraid_sas controlled hardware with the scsi midlayer. All megaraid_sas
|
||||
hardware supports 16 byte CDB's."
|
||||
|
||||
|
||||
@ -102,7 +102,7 @@ So take at least the following measures:
|
||||
ftp://student.physik.uni-dortmund.de/pub/linux/kernel/bootdisk.gz
|
||||
|
||||
One more warning: I used to overclock my PCI bus to 41.67 MHz. My Tekram
|
||||
DC390F (Sym53c875) accepted this as well as my Millenium. But the Am53C974
|
||||
DC390F (Sym53c875) accepted this as well as my Millennium. But the Am53C974
|
||||
produced errors and started to corrupt my disks. So don't do that! A 37.50
|
||||
MHz PCI bus works for me, though, but I don't recommend using higher clocks
|
||||
than the 33.33 MHz being in the PCI spec.
|
||||
|
||||
@ -536,6 +536,6 @@ writing a single character to the /smack/logging file :
|
||||
3 : log denied & accepted
|
||||
|
||||
Events are logged as 'key=value' pairs, for each event you at least will get
|
||||
the subjet, the object, the rights requested, the action, the kernel function
|
||||
the subject, the object, the rights requested, the action, the kernel function
|
||||
that triggered the event, plus other pairs depending on the type of event
|
||||
audited.
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Trusted and Encrypted Keys
|
||||
|
||||
Trusted and Encrypted Keys are two new key types added to the existing kernel
|
||||
key ring service. Both of these new types are variable length symmetic keys,
|
||||
key ring service. Both of these new types are variable length symmetric keys,
|
||||
and in both cases all keys are created in the kernel, and user space sees,
|
||||
stores, and loads only encrypted blobs. Trusted Keys require the availability
|
||||
of a Trusted Platform Module (TPM) chip for greater security, while Encrypted
|
||||
|
||||
@ -668,7 +668,7 @@ The keyctl syscall functions are:
|
||||
|
||||
If the kernel calls back to userspace to complete the instantiation of a
|
||||
key, userspace should use this call mark the key as negative before the
|
||||
invoked process returns if it is unable to fulfil the request.
|
||||
invoked process returns if it is unable to fulfill the request.
|
||||
|
||||
The process must have write access on the key to be able to instantiate
|
||||
it, and the key must be uninstantiated.
|
||||
|
||||
@ -1588,7 +1588,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
||||
|
||||
Module supports autoprobe a chip.
|
||||
|
||||
Note: the driver may have problems regarding endianess.
|
||||
Note: the driver may have problems regarding endianness.
|
||||
|
||||
The power-management is supported.
|
||||
|
||||
|
||||
@ -116,7 +116,7 @@ Description:
|
||||
A UVC control can be mapped to several V4L2 controls. For instance,
|
||||
a UVC pan/tilt control could be mapped to separate pan and tilt V4L2
|
||||
controls. The UVC control is divided into non overlapping fields using
|
||||
the 'size' and 'offset' fields and are then independantly mapped to
|
||||
the 'size' and 'offset' fields and are then independently mapped to
|
||||
V4L2 control.
|
||||
|
||||
For signed integer V4L2 controls the data_type field should be set to
|
||||
|
||||
@ -347,7 +347,7 @@ To instantiate a large spte, four constraints must be satisfied:
|
||||
|
||||
- the spte must point to a large host page
|
||||
- the guest pte must be a large pte of at least equivalent size (if tdp is
|
||||
enabled, there is no guest pte and this condition is satisified)
|
||||
enabled, there is no guest pte and this condition is satisfied)
|
||||
- if the spte will be writeable, the large page frame may not overlap any
|
||||
write-protected pages
|
||||
- the guest page must be wholly contained by a single memory slot
|
||||
@ -356,7 +356,7 @@ To check the last two conditions, the mmu maintains a ->write_count set of
|
||||
arrays for each memory slot and large page size. Every write protected page
|
||||
causes its write_count to be incremented, thus preventing instantiation of
|
||||
a large spte. The frames at the end of an unaligned memory slot have
|
||||
artificically inflated ->write_counts so they can never be instantiated.
|
||||
artificially inflated ->write_counts so they can never be instantiated.
|
||||
|
||||
Further reading
|
||||
===============
|
||||
|
||||
@ -1403,7 +1403,7 @@ segmentation, if both guests are amenable.
|
||||
|
||||
Packets are transmitted by placing them in the transmitq, and
|
||||
buffers for incoming packets are placed in the receiveq. In each
|
||||
case, the packet itself is preceeded by a header:
|
||||
case, the packet itself is preceded by a header:
|
||||
|
||||
struct virtio_net_hdr {
|
||||
|
||||
@ -1642,7 +1642,7 @@ struct virtio_net_ctrl_mac {
|
||||
|
||||
The device can filter incoming packets by any number of
|
||||
destination MAC addresses.[footnote:
|
||||
Since there are no guarentees, it can use a hash filter
|
||||
Since there are no guarantees, it can use a hash filter
|
||||
orsilently switch to allmulti or promiscuous mode if it is given
|
||||
too many addresses.
|
||||
] This table is set using the class VIRTIO_NET_CTRL_MAC and the
|
||||
@ -1805,7 +1805,7 @@ the FLUSH and FLUSH_OUT types are equivalent, the device does not
|
||||
distinguish between them
|
||||
]). If the device has VIRTIO_BLK_F_BARRIER feature the high bit
|
||||
(VIRTIO_BLK_T_BARRIER) indicates that this request acts as a
|
||||
barrier and that all preceeding requests must be complete before
|
||||
barrier and that all preceding requests must be complete before
|
||||
this one, and all following requests must not be started until
|
||||
this is complete. Note that a barrier does not flush caches in
|
||||
the underlying backend device in host, and thus does not serve as
|
||||
@ -2118,7 +2118,7 @@ This is historical, and independent of the guest page size
|
||||
|
||||
Otherwise, the guest may begin to re-use pages previously given
|
||||
to the balloon before the device has acknowledged their
|
||||
withdrawl. [footnote:
|
||||
withdrawal. [footnote:
|
||||
In this case, deflation advice is merely a courtesy
|
||||
]
|
||||
|
||||
|
||||
@ -619,7 +619,7 @@ all PTEs from the page. For this purpose, the unevictable/mlock infrastructure
|
||||
introduced a variant of try_to_unmap() called try_to_munlock().
|
||||
|
||||
try_to_munlock() calls the same functions as try_to_unmap() for anonymous and
|
||||
mapped file pages with an additional argument specifing unlock versus unmap
|
||||
mapped file pages with an additional argument specifying unlock versus unmap
|
||||
processing. Again, these functions walk the respective reverse maps looking
|
||||
for VM_LOCKED VMAs. When such a VMA is found for anonymous pages and file
|
||||
pages mapped in linear VMAs, as in the try_to_unmap() case, the functions
|
||||
|
||||
Loading…
Reference in New Issue
Block a user