summaryrefslogtreecommitdiffstats
path: root/Documentation/powerpc
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/powerpc')
-rw-r--r--Documentation/powerpc/booting-without-of.txt8
-rw-r--r--Documentation/powerpc/eeh-pci-error-recovery.txt2
2 files changed, 5 insertions, 5 deletions
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index ee272035f78..8ca9a563e22 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -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.
diff --git a/Documentation/powerpc/eeh-pci-error-recovery.txt b/Documentation/powerpc/eeh-pci-error-recovery.txt
index be8867d03db..4530d1bf028 100644
--- a/Documentation/powerpc/eeh-pci-error-recovery.txt
+++ b/Documentation/powerpc/eeh-pci-error-recovery.txt
@@ -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