fix typos "wich" -> "which"
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>hifive-unleashed-5.1
parent
c690a72253
commit
c30fe7f731
|
@ -121,7 +121,7 @@ Table 1-1: Process specific entries in /proc
|
||||||
..............................................................................
|
..............................................................................
|
||||||
File Content
|
File Content
|
||||||
cmdline Command line arguments
|
cmdline Command line arguments
|
||||||
cpu Current and last cpu in wich it was executed (2.4)(smp)
|
cpu Current and last cpu in which it was executed (2.4)(smp)
|
||||||
cwd Link to the current working directory
|
cwd Link to the current working directory
|
||||||
environ Values of environment variables
|
environ Values of environment variables
|
||||||
exe Link to the executable of this process
|
exe Link to the executable of this process
|
||||||
|
@ -309,13 +309,13 @@ is the same by default:
|
||||||
> cat /proc/irq/0/smp_affinity
|
> cat /proc/irq/0/smp_affinity
|
||||||
ffffffff
|
ffffffff
|
||||||
|
|
||||||
It's a bitmask, in wich you can specify wich CPUs can handle the IRQ, you can
|
It's a bitmask, in which you can specify which CPUs can handle the IRQ, you can
|
||||||
set it by doing:
|
set it by doing:
|
||||||
|
|
||||||
> echo 1 > /proc/irq/prof_cpu_mask
|
> echo 1 > /proc/irq/prof_cpu_mask
|
||||||
|
|
||||||
This means that only the first CPU will handle the IRQ, but you can also echo 5
|
This means that only the first CPU will handle the IRQ, but you can also echo 5
|
||||||
wich means that only the first and fourth CPU can handle the IRQ.
|
which means that only the first and fourth CPU can handle the IRQ.
|
||||||
|
|
||||||
The way IRQs are routed is handled by the IO-APIC, and it's Round Robin
|
The way IRQs are routed is handled by the IO-APIC, and it's Round Robin
|
||||||
between all the CPUs which are allowed to handle it. As usual the kernel has
|
between all the CPUs which are allowed to handle it. As usual the kernel has
|
||||||
|
|
|
@ -40,7 +40,7 @@ network interface card supports some sort of interrupt load mitigation or
|
||||||
+ How to use CONFIG_PACKET_MMAP
|
+ How to use CONFIG_PACKET_MMAP
|
||||||
--------------------------------------------------------------------------------
|
--------------------------------------------------------------------------------
|
||||||
|
|
||||||
From the user standpoint, you should use the higher level libpcap library, wich
|
From the user standpoint, you should use the higher level libpcap library, which
|
||||||
is a de facto standard, portable across nearly all operating systems
|
is a de facto standard, portable across nearly all operating systems
|
||||||
including Win32.
|
including Win32.
|
||||||
|
|
||||||
|
@ -217,8 +217,8 @@ called pg_vec, its size limits the number of blocks that can be allocated.
|
||||||
|
|
||||||
kmalloc allocates any number of bytes of phisically contiguous memory from
|
kmalloc allocates any number of bytes of phisically contiguous memory from
|
||||||
a pool of pre-determined sizes. This pool of memory is mantained by the slab
|
a pool of pre-determined sizes. This pool of memory is mantained by the slab
|
||||||
allocator wich is at the end the responsible for doing the allocation and
|
allocator which is at the end the responsible for doing the allocation and
|
||||||
hence wich imposes the maximum memory that kmalloc can allocate.
|
hence which imposes the maximum memory that kmalloc can allocate.
|
||||||
|
|
||||||
In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The
|
In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The
|
||||||
predetermined sizes that kmalloc uses can be checked in the "size-<bytes>"
|
predetermined sizes that kmalloc uses can be checked in the "size-<bytes>"
|
||||||
|
@ -254,7 +254,7 @@ and, the number of frames be
|
||||||
|
|
||||||
<block number> * <block size> / <frame size>
|
<block number> * <block size> / <frame size>
|
||||||
|
|
||||||
Suposse the following parameters, wich apply for 2.6 kernel and an
|
Suposse the following parameters, which apply for 2.6 kernel and an
|
||||||
i386 architecture:
|
i386 architecture:
|
||||||
|
|
||||||
<size-max> = 131072 bytes
|
<size-max> = 131072 bytes
|
||||||
|
@ -360,7 +360,7 @@ TP_STATUS_LOSING : indicates there were packet drops from last time
|
||||||
statistics where checked with getsockopt() and
|
statistics where checked with getsockopt() and
|
||||||
the PACKET_STATISTICS option.
|
the PACKET_STATISTICS option.
|
||||||
|
|
||||||
TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets wich
|
TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets which
|
||||||
it's checksum will be done in hardware. So while
|
it's checksum will be done in hardware. So while
|
||||||
reading the packet we should not try to check the
|
reading the packet we should not try to check the
|
||||||
checksum.
|
checksum.
|
||||||
|
|
|
@ -256,7 +256,8 @@ config ACPI_CUSTOM_DSDT_FILE
|
||||||
depends on ACPI_CUSTOM_DSDT
|
depends on ACPI_CUSTOM_DSDT
|
||||||
default ""
|
default ""
|
||||||
help
|
help
|
||||||
Enter the full path name to the file wich includes the AmlCode declaration.
|
Enter the full path name to the file which includes the AmlCode
|
||||||
|
declaration.
|
||||||
|
|
||||||
config ACPI_BLACKLIST_YEAR
|
config ACPI_BLACKLIST_YEAR
|
||||||
int "Disable ACPI for systems before Jan 1st this year" if X86_32
|
int "Disable ACPI for systems before Jan 1st this year" if X86_32
|
||||||
|
|
|
@ -7,7 +7,7 @@
|
||||||
*
|
*
|
||||||
* stuff needed to support the Linux X.25 PLP code on top of devices that
|
* stuff needed to support the Linux X.25 PLP code on top of devices that
|
||||||
* can provide a lab_b service using the concap_proto mechanism.
|
* can provide a lab_b service using the concap_proto mechanism.
|
||||||
* This module supports a network interface wich provides lapb_sematics
|
* This module supports a network interface which provides lapb_sematics
|
||||||
* -- as defined in Documentation/networking/x25-iface.txt -- to
|
* -- as defined in Documentation/networking/x25-iface.txt -- to
|
||||||
* the upper layer and assumes that the lower layer provides a reliable
|
* the upper layer and assumes that the lower layer provides a reliable
|
||||||
* data link service by means of the concap_device_ops callbacks.
|
* data link service by means of the concap_device_ops callbacks.
|
||||||
|
|
|
@ -40,7 +40,7 @@
|
||||||
* and so on). So the PSC1 is mapped to /dev/ttyPSC0, PSC2 to /dev/ttyPSC1 and
|
* and so on). So the PSC1 is mapped to /dev/ttyPSC0, PSC2 to /dev/ttyPSC1 and
|
||||||
* so on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly
|
* so on. But be warned, it's an ABSOLUTE REQUIREMENT ! This is needed mainly
|
||||||
* fpr the console code : without this 1:1 mapping, at early boot time, when we
|
* fpr the console code : without this 1:1 mapping, at early boot time, when we
|
||||||
* are parsing the kernel args console=ttyPSC?, we wouldn't know wich PSC it
|
* are parsing the kernel args console=ttyPSC?, we wouldn't know which PSC it
|
||||||
* will be mapped to.
|
* will be mapped to.
|
||||||
*/
|
*/
|
||||||
|
|
||||||
|
|
|
@ -102,7 +102,7 @@ static struct usb_driver option_driver = {
|
||||||
.no_dynamic_id = 1,
|
.no_dynamic_id = 1,
|
||||||
};
|
};
|
||||||
|
|
||||||
/* The card has three separate interfaces, wich the serial driver
|
/* The card has three separate interfaces, which the serial driver
|
||||||
* recognizes separately, thus num_port=1.
|
* recognizes separately, thus num_port=1.
|
||||||
*/
|
*/
|
||||||
static struct usb_serial_driver option_3port_device = {
|
static struct usb_serial_driver option_3port_device = {
|
||||||
|
|
|
@ -32,7 +32,7 @@
|
||||||
|
|
||||||
-TODO: at one time or another test that the mode is acceptable by the monitor
|
-TODO: at one time or another test that the mode is acceptable by the monitor
|
||||||
-ASK: Can I choose different ordering for the color bitfields (rgba argb ...)
|
-ASK: Can I choose different ordering for the color bitfields (rgba argb ...)
|
||||||
wich one should i use ? is there any preferred one ? It seems ARGB is
|
which one should i use ? is there any preferred one ? It seems ARGB is
|
||||||
the one ...
|
the one ...
|
||||||
-TODO: in set_var check the validity of timings (hsync vsync)...
|
-TODO: in set_var check the validity of timings (hsync vsync)...
|
||||||
-TODO: check and recheck the use of sst_wait_idle : we don't flush the fifo via
|
-TODO: check and recheck the use of sst_wait_idle : we don't flush the fifo via
|
||||||
|
|
|
@ -98,7 +98,7 @@ static void matrox_w1_write_ddc_bit(void *, u8);
|
||||||
*
|
*
|
||||||
* Using tristate pins, since i can't find any open-drain pin in whole motherboard.
|
* Using tristate pins, since i can't find any open-drain pin in whole motherboard.
|
||||||
* Unfortunately we can't connect to Intel's 82801xx IO controller
|
* Unfortunately we can't connect to Intel's 82801xx IO controller
|
||||||
* since we don't know motherboard schema, wich has pretty unused(may be not) GPIO.
|
* since we don't know motherboard schema, which has pretty unused(may be not) GPIO.
|
||||||
*
|
*
|
||||||
* I've heard that PIIX also has open drain pin.
|
* I've heard that PIIX also has open drain pin.
|
||||||
*
|
*
|
||||||
|
|
|
@ -118,7 +118,7 @@ befs_fblock2brun(struct super_block *sb, befs_data_stream * data,
|
||||||
* befs_read_lsmylink - read long symlink from datastream.
|
* befs_read_lsmylink - read long symlink from datastream.
|
||||||
* @sb: Filesystem superblock
|
* @sb: Filesystem superblock
|
||||||
* @ds: Datastrem to read from
|
* @ds: Datastrem to read from
|
||||||
* @buf: Buffer in wich to place long symlink data
|
* @buf: Buffer in which to place long symlink data
|
||||||
* @len: Length of the long symlink in bytes
|
* @len: Length of the long symlink in bytes
|
||||||
*
|
*
|
||||||
* Returns the number of bytes read
|
* Returns the number of bytes read
|
||||||
|
|
|
@ -4,7 +4,7 @@
|
||||||
#
|
#
|
||||||
# Stage one of module building created the following:
|
# Stage one of module building created the following:
|
||||||
# a) The individual .o files used for the module
|
# a) The individual .o files used for the module
|
||||||
# b) A <module>.o file wich is the .o files above linked together
|
# b) A <module>.o file which is the .o files above linked together
|
||||||
# c) A <module>.mod file in $(MODVERDIR)/, listing the name of the
|
# c) A <module>.mod file in $(MODVERDIR)/, listing the name of the
|
||||||
# the preliminary <module>.o file, plus all .o files
|
# the preliminary <module>.o file, plus all .o files
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue