Commit 1b3c3714cb4767d00f507cc6854d3339d82c5b9d

Authored by Uwe Kleine-König
Committed by Adrian Bunk
1 parent 85d1fe095c

Fix typos concerning hierarchy

heirarchical, hierachical -> hierarchical
        heirarchy, hierachy -> hierarchy

Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>

Showing 11 changed files with 19 additions and 19 deletions Side-by-side Diff

Documentation/filesystems/sysfs-pci.txt
... ... @@ -65,7 +65,7 @@
65 65 ----------------------------------------
66 66  
67 67 Legacy I/O port and ISA memory resources are also provided in sysfs if the
68   -underlying platform supports them. They're located in the PCI class heirarchy,
  68 +underlying platform supports them. They're located in the PCI class hierarchy,
69 69 e.g.
70 70  
71 71 /sys/class/pci_bus/0000:17/
Documentation/sh/new-machine.txt
... ... @@ -17,7 +17,7 @@
17 17 in arch/sh/kernel/ directly, with board-specific headers ending up in
18 18 include/asm-sh/. For the new kernel, things are broken out by board type,
19 19 companion chip type, and CPU type. Looking at a tree view of this directory
20   -heirarchy looks like the following:
  20 +hierarchy looks like the following:
21 21  
22 22 Board-specific code:
23 23  
... ... @@ -108,7 +108,7 @@
108 108 member itself.
109 109  
110 110 There are a few things that each board is required to have, both in the
111   -arch/sh/boards and the include/asm-sh/ heirarchy. In order to better
  111 +arch/sh/boards and the include/asm-sh/ hierarchy. In order to better
112 112 explain this, we use some examples for adding an imaginary board. For
113 113 setup code, we're required at the very least to provide definitions for
114 114 get_system_type() and platform_setup(). For our imaginary board, this
arch/powerpc/mm/numa.c
... ... @@ -154,7 +154,7 @@
154 154 * characteristics relative to its multiple connections. We ignore
155 155 * this for now. We also assume that all cpu and memory sets have
156 156 * their distances represented at a common level. This won't be
157   - * true for heirarchical NUMA.
  157 + * true for hierarchical NUMA.
158 158 *
159 159 * In any case the ibm,associativity-reference-points should give
160 160 * the correct depth for a normal NUMA system.
drivers/media/dvb/dvb-core/dvb_frontend.c
... ... @@ -915,7 +915,7 @@
915 915 fetunesettings.parameters.inversion = INVERSION_AUTO;
916 916 }
917 917 if (fe->ops.info.type == FE_OFDM) {
918   - /* without hierachical coding code_rate_LP is irrelevant,
  918 + /* without hierarchical coding code_rate_LP is irrelevant,
919 919 * so we tolerate the otherwise invalid FEC_NONE setting */
920 920 if (fepriv->parameters.u.ofdm.hierarchy_information == HIERARCHY_NONE &&
921 921 fepriv->parameters.u.ofdm.code_rate_LP == FEC_NONE)
drivers/media/dvb/frontends/dib3000mb.c
... ... @@ -239,7 +239,7 @@
239 239 default:
240 240 return -EINVAL;
241 241 }
242   - deb_setf("hierachy: ");
  242 + deb_setf("hierarchy: ");
243 243 switch (ofdm->hierarchy_information) {
244 244 case HIERARCHY_NONE:
245 245 deb_setf("none ");
drivers/pci/pcie/aer/aerdrv.h
... ... @@ -85,7 +85,7 @@
85 85 struct mutex rpc_mutex; /*
86 86 * only one thread could do
87 87 * recovery on the same
88   - * root port hierachy
  88 + * root port hierarchy
89 89 */
90 90 wait_queue_head_t wait_release;
91 91 };
drivers/scsi/scsi_transport_fc.c
... ... @@ -855,7 +855,7 @@
855 855  
856 856 /*
857 857 * Note: in the target show function we recognize when the remote
858   - * port is in the heirarchy and do not allow the driver to get
  858 + * port is in the hierarchy and do not allow the driver to get
859 859 * involved in sysfs functions. The driver only gets involved if
860 860 * it's the "old" style that doesn't use rports.
861 861 */
drivers/scsi/scsi_transport_sas.c
... ... @@ -500,7 +500,7 @@
500 500 EXPORT_SYMBOL(sas_phy_alloc);
501 501  
502 502 /**
503   - * sas_phy_add -- add a SAS PHY to the device hierachy
  503 + * sas_phy_add -- add a SAS PHY to the device hierarchy
504 504 * @phy: The PHY to be added
505 505 *
506 506 * Publishes a SAS PHY to the rest of the system.
... ... @@ -1265,7 +1265,7 @@
1265 1265 EXPORT_SYMBOL(sas_expander_alloc);
1266 1266  
1267 1267 /**
1268   - * sas_rphy_add -- add a SAS remote PHY to the device hierachy
  1268 + * sas_rphy_add -- add a SAS remote PHY to the device hierarchy
1269 1269 * @rphy: The remote PHY to be added
1270 1270 *
1271 1271 * Publishes a SAS remote PHY to the rest of the system.
1 1 The CIFS VFS support for Linux supports many advanced network filesystem
2   -features such as heirarchical dfs like namespace, hardlinks, locking and more.
  2 +features such as hierarchical dfs like namespace, hardlinks, locking and more.
3 3 It was designed to comply with the SNIA CIFS Technical Reference (which
4 4 supersedes the 1992 X/Open SMB Standard) as well as to perform best practice
5 5 practical interoperability with Windows 2000, Windows XP, Samba and equivalent
... ... @@ -1098,7 +1098,7 @@
1098 1098 BUG();
1099 1099 }
1100 1100  
1101   - /* Assume a directory heirarchy thusly:
  1101 + /* Assume a directory hierarchy thusly:
1102 1102 * a/b/c
1103 1103 * a/d
1104 1104 * a,b,c, and d are all directories.
include/asm-ia64/pal.h
... ... @@ -32,7 +32,7 @@
32 32 #define PAL_CACHE_FLUSH 1 /* flush i/d cache */
33 33 #define PAL_CACHE_INFO 2 /* get detailed i/d cache info */
34 34 #define PAL_CACHE_INIT 3 /* initialize i/d cache */
35   -#define PAL_CACHE_SUMMARY 4 /* get summary of cache heirarchy */
  35 +#define PAL_CACHE_SUMMARY 4 /* get summary of cache hierarchy */
36 36 #define PAL_MEM_ATTRIB 5 /* list supported memory attributes */
37 37 #define PAL_PTCE_INFO 6 /* purge TLB info */
38 38 #define PAL_VM_INFO 7 /* return supported virtual memory features */
39 39  
... ... @@ -113,14 +113,14 @@
113 113 */
114 114 #define PAL_STATUS_REQUIRES_MEMORY (-9) /* Call requires PAL memory buffer */
115 115  
116   -/* Processor cache level in the heirarchy */
  116 +/* Processor cache level in the hierarchy */
117 117 typedef u64 pal_cache_level_t;
118 118 #define PAL_CACHE_LEVEL_L0 0 /* L0 */
119 119 #define PAL_CACHE_LEVEL_L1 1 /* L1 */
120 120 #define PAL_CACHE_LEVEL_L2 2 /* L2 */
121 121  
122 122  
123   -/* Processor cache type at a particular level in the heirarchy */
  123 +/* Processor cache type at a particular level in the hierarchy */
124 124  
125 125 typedef u64 pal_cache_type_t;
126 126 #define PAL_CACHE_TYPE_INSTRUCTION 1 /* Instruction cache */
127 127  
... ... @@ -272,14 +272,14 @@
272 272 #define PAL_CACHE_PROT_METHOD_ECC 3 /* ECC protection */
273 273  
274 274  
275   -/* Processor cache line identification in the heirarchy */
  275 +/* Processor cache line identification in the hierarchy */
276 276 typedef union pal_cache_line_id_u {
277 277 u64 pclid_data;
278 278 struct {
279 279 u64 cache_type : 8, /* 7-0 cache type */
280 280 level : 8, /* 15-8 level of the
281 281 * cache in the
282   - * heirarchy.
  282 + * hierarchy.
283 283 */
284 284 way : 8, /* 23-16 way in the set
285 285 */
... ... @@ -292,7 +292,7 @@
292 292 u64 cache_type : 8, /* 7-0 cache type */
293 293 level : 8, /* 15-8 level of the
294 294 * cache in the
295   - * heirarchy.
  295 + * hierarchy.
296 296 */
297 297 way : 8, /* 23-16 way in the set
298 298 */
... ... @@ -978,7 +978,7 @@
978 978 return iprv.status;
979 979 }
980 980  
981   -/* Return summary information about the heirarchy of caches controlled by the processor */
  981 +/* Return summary information about the hierarchy of caches controlled by the processor */
982 982 static inline s64
983 983 ia64_pal_cache_summary (u64 *cache_levels, u64 *unique_caches)
984 984 {