mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-30 11:41:38 -04:00
Merge git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial
* git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial: (21 commits) BUG_ON() Conversion in drivers/video/ BUG_ON() Conversion in drivers/parisc/ BUG_ON() Conversion in drivers/block/ BUG_ON() Conversion in sound/sparc/cs4231.c BUG_ON() Conversion in drivers/s390/block/dasd.c BUG_ON() Conversion in lib/swiotlb.c BUG_ON() Conversion in kernel/cpu.c BUG_ON() Conversion in ipc/msg.c BUG_ON() Conversion in block/elevator.c BUG_ON() Conversion in fs/coda/ BUG_ON() Conversion in fs/binfmt_elf_fdpic.c BUG_ON() Conversion in input/serio/hil_mlc.c BUG_ON() Conversion in md/dm-hw-handler.c BUG_ON() Conversion in md/bitmap.c The comment describing how MS_ASYNC works in msync.c is confusing rcu: undeclared variable used in documentation fix typos "wich" -> "which" typo patch for fs/ufs/super.c Fix simple typos tabify drivers/char/Makefile ...
This commit is contained in:
commit
1e8c573933
39 changed files with 116 additions and 142 deletions
|
|
@ -360,7 +360,7 @@ uses of RCU may be found in listRCU.txt, arrayRCU.txt, and NMI-RCU.txt.
|
|||
struct foo *new_fp;
|
||||
struct foo *old_fp;
|
||||
|
||||
new_fp = kmalloc(sizeof(*fp), GFP_KERNEL);
|
||||
new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
|
||||
spin_lock(&foo_mutex);
|
||||
old_fp = gbl_foo;
|
||||
*new_fp = *old_fp;
|
||||
|
|
@ -461,7 +461,7 @@ The foo_update_a() function might then be written as follows:
|
|||
struct foo *new_fp;
|
||||
struct foo *old_fp;
|
||||
|
||||
new_fp = kmalloc(sizeof(*fp), GFP_KERNEL);
|
||||
new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
|
||||
spin_lock(&foo_mutex);
|
||||
old_fp = gbl_foo;
|
||||
*new_fp = *old_fp;
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ to store page tables. The recommended placement is 32KiB into RAM.
|
|||
|
||||
In either case, the following conditions must be met:
|
||||
|
||||
- Quiesce all DMA capable devicess so that memory does not get
|
||||
- Quiesce all DMA capable devices so that memory does not get
|
||||
corrupted by bogus network packets or disk data. This will save
|
||||
you many hours of debug.
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ Modules
|
|||
Although modularisation is supported (and required for the FP emulator),
|
||||
each module on an ARM2/ARM250/ARM3 machine when is loaded will take
|
||||
memory up to the next 32k boundary due to the size of the pages.
|
||||
Therefore, modularisation on these machines really worth it?
|
||||
Therefore, is modularisation on these machines really worth it?
|
||||
|
||||
However, ARM6 and up machines allow modules to take multiples of 4k, and
|
||||
as such Acorn RiscPCs and other architectures using these processors can
|
||||
|
|
|
|||
|
|
@ -58,7 +58,7 @@ below:
|
|||
video_y
|
||||
|
||||
This describes the character position of cursor on VGA console, and
|
||||
is otherwise unused. (should not used for other console types, and
|
||||
is otherwise unused. (should not be used for other console types, and
|
||||
should not be used for other purposes).
|
||||
|
||||
memc_control_reg
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ Table 1-1: Process specific entries in /proc
|
|||
..............................................................................
|
||||
File Content
|
||||
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
|
||||
environ Values of environment variables
|
||||
exe Link to the executable of this process
|
||||
|
|
@ -309,13 +309,13 @@ is the same by default:
|
|||
> cat /proc/irq/0/smp_affinity
|
||||
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:
|
||||
|
||||
> echo 1 > /proc/irq/prof_cpu_mask
|
||||
|
||||
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
|
||||
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
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
hence wich imposes the maximum memory that kmalloc can allocate.
|
||||
allocator which is at the end the responsible for doing the allocation and
|
||||
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
|
||||
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>
|
||||
|
||||
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:
|
||||
|
||||
<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
|
||||
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
|
||||
reading the packet we should not try to check the
|
||||
checksum.
|
||||
|
|
|
|||
Loading…
Reference in a new issue