mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-28 10:41:38 -04:00
Fix typos in Documentation/: 'Q'-'R'
This patch fixes typos in various Documentation txts. The patch addresses some words starting with the letters 'Q'-'R'. Signed-off-by: Matt LaPlante <[email protected]> Acked-by: Randy Dunlap <[email protected]> Signed-off-by: Adrian Bunk <[email protected]>
This commit is contained in:
parent
84eb8d0608
commit
d6bc8ac9e1
26 changed files with 40 additions and 40 deletions
|
|
@ -245,7 +245,7 @@ the block to RAM before passing it to the kernel.
|
|||
---------
|
||||
|
||||
The kernel is entered with r3 pointing to an area of memory that is
|
||||
roughtly described in include/asm-powerpc/prom.h by the structure
|
||||
roughly described in include/asm-powerpc/prom.h by the structure
|
||||
boot_param_header:
|
||||
|
||||
struct boot_param_header {
|
||||
|
|
@ -1068,13 +1068,13 @@ while all this has been defined and implemented.
|
|||
around. It contains no internal offsets or pointers for this
|
||||
purpose.
|
||||
|
||||
- An example of code for iterating nodes & retreiving properties
|
||||
- An example of code for iterating nodes & retrieving properties
|
||||
directly from the flattened tree format can be found in the kernel
|
||||
file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function,
|
||||
it's usage in early_init_devtree(), and the corresponding various
|
||||
its usage in early_init_devtree(), and the corresponding various
|
||||
early_init_dt_scan_*() callbacks. That code can be re-used in a
|
||||
GPL bootloader, and as the author of that code, I would be happy
|
||||
do discuss possible free licencing to any vendor who wishes to
|
||||
to discuss possible free licencing to any vendor who wishes to
|
||||
integrate all or part of this code into a non-GPL bootloader.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ EEH-isolated, there is a firmware call it can make to determine if
|
|||
this is the case. If so, then the device driver should put itself
|
||||
into a consistent state (given that it won't be able to complete any
|
||||
pending work) and start recovery of the card. Recovery normally
|
||||
would consist of reseting the PCI device (holding the PCI #RST
|
||||
would consist of resetting the PCI device (holding the PCI #RST
|
||||
line high for two seconds), followed by setting up the device
|
||||
config space (the base address registers (BAR's), latency timer,
|
||||
cache line size, interrupt line, and so on). This is followed by a
|
||||
|
|
|
|||
Loading…
Reference in a new issue