mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-11-16 22:54:39 +08:00
Documentation: fix minor typos/spelling
Fix some minor typos: * informations => information * there own => their own * these => this Signed-off-by: Sylvestre Ledru <sylvestre.ledru@scilab.org> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
parent
44a4dcf75c
commit
f65e51d740
@ -40,7 +40,7 @@ What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-
|
||||
Date: March 2010
|
||||
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 holds informations like button
|
||||
press of a button. A profile holds information like button
|
||||
mappings, sensitivity, the colors of the 5 leds and light
|
||||
effects.
|
||||
When read, these files return the respective profile. The
|
||||
|
@ -33,7 +33,7 @@ Date: August 2010
|
||||
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 in settings and buttons.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons back to the mouse. The data has to be 77 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
@ -47,7 +47,7 @@ Date: August 2010
|
||||
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 in settings and buttons.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When read, these files return the respective profile buttons.
|
||||
The returned data is 77 bytes in size.
|
||||
This file is readonly.
|
||||
@ -58,7 +58,7 @@ Date: October 2010
|
||||
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 in settings and buttons.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings 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.
|
||||
@ -73,7 +73,7 @@ Date: August 2010
|
||||
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 in settings and buttons.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When read, these files return the respective profile settings.
|
||||
The returned data is 43 bytes in size.
|
||||
|
@ -52,7 +52,7 @@ Date: January 2011
|
||||
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 in settings and buttons.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons back to the mouse. The data has to be 23 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
@ -66,7 +66,7 @@ Date: January 2011
|
||||
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 in settings and buttons.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When read, these files return the respective profile buttons.
|
||||
The returned data is 23 bytes in size.
|
||||
This file is readonly.
|
||||
@ -77,7 +77,7 @@ Date: January 2011
|
||||
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 in settings and buttons.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings 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 16 bytes long.
|
||||
@ -92,7 +92,7 @@ Date: January 2011
|
||||
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 in settings and buttons.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When read, these files return the respective profile settings.
|
||||
The returned data is 16 bytes in size.
|
||||
|
@ -39,7 +39,7 @@ Date: August 2010
|
||||
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 in settings and buttons.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings 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 13 bytes long.
|
||||
@ -54,7 +54,7 @@ Date: August 2010
|
||||
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 in settings and buttons.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When read, these files return the respective profile settings.
|
||||
The returned data is 13 bytes in size.
|
||||
@ -66,7 +66,7 @@ Date: August 2010
|
||||
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 in settings and buttons.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons back to the mouse. The data has to be 19 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
@ -80,7 +80,7 @@ Date: August 2010
|
||||
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 in settings and buttons.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When read, these files return the respective profile buttons.
|
||||
The returned data is 19 bytes in size.
|
||||
This file is readonly.
|
||||
|
@ -27,7 +27,7 @@ KernelVersion: 2.6.20
|
||||
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||
Description:
|
||||
Some models like the W1N have a LED display that can be
|
||||
used to display several informations.
|
||||
used to display several items of information.
|
||||
To control the LED display, use the following :
|
||||
echo 0x0T000DDD > /sys/devices/platform/asus_laptop/
|
||||
where T control the 3 letters display, and DDD the 3 digits display.
|
||||
|
@ -138,7 +138,7 @@ and properties to be present. This will be described in detail in
|
||||
section III, but, for example, the kernel does not require you to
|
||||
create a node for every PCI device in the system. It is a requirement
|
||||
to have a node for PCI host bridges in order to provide interrupt
|
||||
routing informations and memory/IO ranges, among others. It is also
|
||||
routing information and memory/IO ranges, among others. It is also
|
||||
recommended to define nodes for on chip devices and other buses that
|
||||
don't specifically fit in an existing OF specification. This creates a
|
||||
great flexibility in the way the kernel can then probe those and match
|
||||
@ -385,7 +385,7 @@ struct boot_param_header {
|
||||
among others, by kexec. If you are on an SMP system, this value
|
||||
should match the content of the "reg" property of the CPU node in
|
||||
the device-tree corresponding to the CPU calling the kernel entry
|
||||
point (see further chapters for more informations on the required
|
||||
point (see further chapters for more information on the required
|
||||
device-tree contents)
|
||||
|
||||
- size_dt_strings
|
||||
@ -553,7 +553,7 @@ looks like in practice.
|
||||
|
||||
This tree is almost a minimal tree. It pretty much contains the
|
||||
minimal set of required nodes and properties to boot a linux kernel;
|
||||
that is, some basic model informations at the root, the CPUs, and the
|
||||
that is, some basic model information at the root, the CPUs, and the
|
||||
physical memory layout. It also includes misc information passed
|
||||
through /chosen, like in this example, the platform type (mandatory)
|
||||
and the kernel command line arguments (optional).
|
||||
|
@ -1,7 +1,7 @@
|
||||
The DVB subsystem currently registers to the sysfs subsystem using the
|
||||
"class_simple" interface.
|
||||
|
||||
This means that only the basic informations like module loading parameters
|
||||
This means that only the basic information like module loading parameters
|
||||
are presented through sysfs. Other things that might be interesting are
|
||||
currently *not* available.
|
||||
|
||||
|
@ -311,7 +311,7 @@ Total Correctable Errors count attribute file:
|
||||
'ce_noinfo_count'
|
||||
|
||||
This attribute file displays the number of CEs that
|
||||
have occurred wherewith no informations as to which DIMM slot
|
||||
have occurred wherewith no information as to which DIMM slot
|
||||
is having errors. Memory is handicapped, but operational,
|
||||
yet no information is available to indicate which slot
|
||||
the failing memory is in. This count field should be also
|
||||
|
@ -2478,8 +2478,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
topology= [S390]
|
||||
Format: {off | on}
|
||||
Specify if the kernel should make use of the cpu
|
||||
topology informations if the hardware supports these.
|
||||
The scheduler will make use of these informations and
|
||||
topology information if the hardware supports this.
|
||||
The scheduler will make use of this information and
|
||||
e.g. base its process migration decisions on it.
|
||||
Default is on.
|
||||
|
||||
|
@ -61,7 +61,7 @@ Usage
|
||||
Hotkeys are also reported as input keys (like keyboards) you can check
|
||||
which key are supported using "xev" under X11.
|
||||
|
||||
You can get informations on the version of your DSDT table by reading the
|
||||
You can get information on the version of your DSDT table by reading the
|
||||
/sys/devices/platform/asus-laptop/infos entry. If you have a question or a
|
||||
bug report to do, please include the output of this entry.
|
||||
|
||||
@ -178,7 +178,7 @@ LED display
|
||||
-----------
|
||||
|
||||
Some models like the W1N have a LED display that can be used to display
|
||||
several informations.
|
||||
several items of information.
|
||||
|
||||
LED display works for the following models:
|
||||
W1000N
|
||||
|
@ -72,7 +72,7 @@ folder:
|
||||
# fragmentation gw_sel_class vis_mode
|
||||
|
||||
|
||||
There is a special folder for debugging informations:
|
||||
There is a special folder for debugging information:
|
||||
|
||||
# ls /sys/kernel/debug/batman_adv/bat0/
|
||||
# gateways socket transtable_global vis_data
|
||||
|
@ -2273,7 +2273,7 @@ IP forwarding is on.
|
||||
There is a lot of useful info in here best found by going in & having a look around,
|
||||
so I'll take you through some entries I consider important.
|
||||
|
||||
All the processes running on the machine have there own entry defined by
|
||||
All the processes running on the machine have their own entry defined by
|
||||
/proc/<pid>
|
||||
So lets have a look at the init process
|
||||
cd /proc/1
|
||||
|
@ -285,7 +285,7 @@ from the driver.
|
||||
|
||||
7. Profiling information
|
||||
|
||||
This driver does not provide profiling informations as did its predecessors.
|
||||
This driver does not provide profiling information as did its predecessors.
|
||||
This feature was not this useful and added complexity to the code.
|
||||
As the driver code got more complex, I have decided to remove everything
|
||||
that didn't seem actually useful.
|
||||
|
@ -2229,7 +2229,7 @@ Proc interfaces (/proc/asound)
|
||||
|
||||
/proc/asound/card#/pcm#[cp]/oss
|
||||
-------------------------------
|
||||
String "erase" - erase all additional informations about OSS applications
|
||||
String "erase" - erase all additional information about OSS applications
|
||||
String "<app_name> <fragments> <fragment_size> [<options>]"
|
||||
|
||||
<app_name> - name of application with (higher priority) or without path
|
||||
|
@ -1,10 +1,10 @@
|
||||
Driver
|
||||
------
|
||||
|
||||
Informations about Audio Excel DSP 16 driver can be found in the source
|
||||
Information about Audio Excel DSP 16 driver can be found in the source
|
||||
file aedsp16.c
|
||||
Please, read the head of the source before using it. It contain useful
|
||||
informations.
|
||||
information.
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
@ -68,7 +68,7 @@ Sound cards supported
|
||||
This driver supports the SC-6000 and SC-6600 based Gallant's sound card.
|
||||
It don't support the Audio Excel DSP 16 III (try the SC-6600 code).
|
||||
I'm working on the III version of the card: if someone have useful
|
||||
informations about it, please let me know.
|
||||
information about it, please let me know.
|
||||
For all the non-supported audio cards, you have to boot MS-DOS (or WIN95)
|
||||
activating the audio card with the MS-DOS device driver, then you have to
|
||||
<ctrl>-<alt>-<del> and boot Linux.
|
||||
|
@ -5,7 +5,7 @@ FIRST OF ALL
|
||||
============
|
||||
|
||||
This code references YAMAHA's sample codes and data sheets.
|
||||
I respect and thank for all people they made open the informations
|
||||
I respect and thank for all people they made open the information
|
||||
about YMF7xx cards.
|
||||
|
||||
And this codes heavily based on Jeff Garzik <jgarzik@pobox.com>'s
|
||||
|
@ -1,5 +1,5 @@
|
||||
|
||||
Note: "modinfo <module>" prints various informations about a kernel
|
||||
Note: "modinfo <module>" prints various information about a kernel
|
||||
module, among them a complete and up-to-date list of insmod options.
|
||||
This list tends to be outdated because it is updated manually ...
|
||||
|
||||
|
@ -8,7 +8,7 @@ completely by the bt8xx chip, which is common on all boards. But
|
||||
sound is handled in slightly different ways on each board.
|
||||
|
||||
To handle the grabber boards correctly, there is a array tvcards[] in
|
||||
bttv-cards.c, which holds the informations required for each board.
|
||||
bttv-cards.c, which holds the information required for each board.
|
||||
Sound will work only, if the correct entry is used (for video it often
|
||||
makes no difference). The bttv driver prints a line to the kernel
|
||||
log, telling which card type is used. Like this one:
|
||||
|
@ -191,10 +191,10 @@ Syntax: <n>
|
||||
Description: Debugging information level, from 0 to 3:
|
||||
0 = none (use carefully)
|
||||
1 = critical errors
|
||||
2 = significant informations
|
||||
2 = significant information
|
||||
3 = more verbose messages
|
||||
Level 3 is useful for testing only, when only one device
|
||||
is used at the same time. It also shows some more informations
|
||||
is used at the same time. It also shows some more information
|
||||
about the hardware being detected. This module parameter can be
|
||||
changed at runtime thanks to the /sys filesystem interface.
|
||||
Default: 2
|
||||
|
@ -214,10 +214,10 @@ Syntax: <n>
|
||||
Description: Debugging information level, from 0 to 3:
|
||||
0 = none (use carefully)
|
||||
1 = critical errors
|
||||
2 = significant informations
|
||||
2 = significant information
|
||||
3 = more verbose messages
|
||||
Level 3 is useful for testing only. It also shows some more
|
||||
informations about the hardware being detected.
|
||||
information about the hardware being detected.
|
||||
This parameter can be changed at runtime thanks to the /sys
|
||||
filesystem interface.
|
||||
Default: 2
|
||||
|
@ -413,7 +413,7 @@ Syntax: <n>
|
||||
Description: Debugging information level, from 0 to 6:
|
||||
0 = none (use carefully)
|
||||
1 = critical errors
|
||||
2 = significant informations
|
||||
2 = significant information
|
||||
3 = configuration or general messages
|
||||
4 = warnings
|
||||
5 = called functions
|
||||
|
@ -181,10 +181,10 @@ Syntax: <n>
|
||||
Description: Debugging information level, from 0 to 3:
|
||||
0 = none (use carefully)
|
||||
1 = critical errors
|
||||
2 = significant informations
|
||||
2 = significant information
|
||||
3 = more verbose messages
|
||||
Level 3 is useful for testing only, when only one device
|
||||
is used at the same time. It also shows some more informations
|
||||
is used at the same time. It also shows some information
|
||||
about the hardware being detected. This module parameter can be
|
||||
changed at runtime thanks to the /sys filesystem interface.
|
||||
Default: 2
|
||||
@ -261,7 +261,7 @@ the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'.
|
||||
|
||||
11. Credits
|
||||
===========
|
||||
- Informations about the chip internals needed to enable the I2C protocol have
|
||||
- Information about the chip internals needed to enable the I2C protocol have
|
||||
been taken from the documentation of the ZC030x Video4Linux1 driver written
|
||||
by Andrew Birkett <andy@nobugs.org>;
|
||||
- The initialization values of the ZC0301 controller connected to the PAS202BCB
|
||||
|
@ -431,7 +431,7 @@ virt_page_table_tlb_miss_fault:
|
||||
* The thing is, we know that in normal circumstances, this is
|
||||
* always called as a second level tlb miss for SW load or as a first
|
||||
* level TLB miss for HW load, so we should be able to peek at the
|
||||
* relevant informations in the first exception frame in the PACA.
|
||||
* relevant information in the first exception frame in the PACA.
|
||||
*
|
||||
* However, we do need to double check that, because we may just hit
|
||||
* a stray kernel pointer or a userland attack trying to hit those
|
||||
|
@ -46,7 +46,7 @@ config PPC_OF_BOOT_TRAMPOLINE
|
||||
help
|
||||
Support from booting from Open Firmware or yaboot using an
|
||||
Open Firmware client interface. This enables the kernel to
|
||||
communicate with open firmware to retrieve system informations
|
||||
communicate with open firmware to retrieve system information
|
||||
such as the device tree.
|
||||
|
||||
In case of doubt, say Y
|
||||
|
Loading…
Reference in New Issue
Block a user