summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--Documentation/filesystems/sysfs-pci.txt2
-rw-r--r--Documentation/sh/new-machine.txt4
-rw-r--r--arch/powerpc/mm/numa.c2
-rw-r--r--drivers/media/dvb/dvb-core/dvb_frontend.c2
-rw-r--r--drivers/media/dvb/frontends/dib3000mb.c2
-rw-r--r--drivers/pci/pcie/aer/aerdrv.h2
-rw-r--r--drivers/scsi/scsi_transport_fc.c2
-rw-r--r--drivers/scsi/scsi_transport_sas.c4
-rw-r--r--fs/cifs/README2
-rw-r--r--fs/ocfs2/namei.c2
-rw-r--r--include/asm-ia64/pal.h14
11 files changed, 19 insertions, 19 deletions
diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt
index 7ba2baa..5daa2aa 100644
--- a/Documentation/filesystems/sysfs-pci.txt
+++ b/Documentation/filesystems/sysfs-pci.txt
@@ -65,7 +65,7 @@ Accessing legacy resources through sysfs
----------------------------------------
Legacy I/O port and ISA memory resources are also provided in sysfs if the
-underlying platform supports them. They're located in the PCI class heirarchy,
+underlying platform supports them. They're located in the PCI class hierarchy,
e.g.
/sys/class/pci_bus/0000:17/
diff --git a/Documentation/sh/new-machine.txt b/Documentation/sh/new-machine.txt
index 73988e0..5482bf5 100644
--- a/Documentation/sh/new-machine.txt
+++ b/Documentation/sh/new-machine.txt
@@ -17,7 +17,7 @@ of the board-specific code (with the exception of stboards) ended up
in arch/sh/kernel/ directly, with board-specific headers ending up in
include/asm-sh/. For the new kernel, things are broken out by board type,
companion chip type, and CPU type. Looking at a tree view of this directory
-heirarchy looks like the following:
+hierarchy looks like the following:
Board-specific code:
@@ -108,7 +108,7 @@ overloading), and you can feel free to name the directory after the family
member itself.
There are a few things that each board is required to have, both in the
-arch/sh/boards and the include/asm-sh/ heirarchy. In order to better
+arch/sh/boards and the include/asm-sh/ hierarchy. In order to better
explain this, we use some examples for adding an imaginary board. For
setup code, we're required at the very least to provide definitions for
get_system_type() and platform_setup(). For our imaginary board, this
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 2627909..e86c37c 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -154,7 +154,7 @@ EXPORT_SYMBOL_GPL(of_node_to_nid);
* characteristics relative to its multiple connections. We ignore
* this for now. We also assume that all cpu and memory sets have
* their distances represented at a common level. This won't be
- * true for heirarchical NUMA.
+ * true for hierarchical NUMA.
*
* In any case the ibm,associativity-reference-points should give
* the correct depth for a normal NUMA system.
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c
index e859722..7c42d53 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -915,7 +915,7 @@ static int dvb_frontend_ioctl(struct inode *inode, struct file *file,
fetunesettings.parameters.inversion = INVERSION_AUTO;
}
if (fe->ops.info.type == FE_OFDM) {
- /* without hierachical coding code_rate_LP is irrelevant,
+ /* without hierarchical coding code_rate_LP is irrelevant,
* so we tolerate the otherwise invalid FEC_NONE setting */
if (fepriv->parameters.u.ofdm.hierarchy_information == HIERARCHY_NONE &&
fepriv->parameters.u.ofdm.code_rate_LP == FEC_NONE)
diff --git a/drivers/media/dvb/frontends/dib3000mb.c b/drivers/media/dvb/frontends/dib3000mb.c
index adbabfd..b6adea5 100644
--- a/drivers/media/dvb/frontends/dib3000mb.c
+++ b/drivers/media/dvb/frontends/dib3000mb.c
@@ -239,7 +239,7 @@ static int dib3000mb_set_frontend(struct dvb_frontend* fe,
default:
return -EINVAL;
}
- deb_setf("hierachy: ");
+ deb_setf("hierarchy: ");
switch (ofdm->hierarchy_information) {
case HIERARCHY_NONE:
deb_setf("none ");
diff --git a/drivers/pci/pcie/aer/aerdrv.h b/drivers/pci/pcie/aer/aerdrv.h
index 3c0a58f..bf655db 100644
--- a/drivers/pci/pcie/aer/aerdrv.h
+++ b/drivers/pci/pcie/aer/aerdrv.h
@@ -85,7 +85,7 @@ struct aer_rpc {
struct mutex rpc_mutex; /*
* only one thread could do
* recovery on the same
- * root port hierachy
+ * root port hierarchy
*/
wait_queue_head_t wait_release;
};
diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c
index 0d3c10f..58afdb4 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -855,7 +855,7 @@ static FC_CLASS_DEVICE_ATTR(rport, fast_io_fail_tmo, S_IRUGO | S_IWUSR,
/*
* Note: in the target show function we recognize when the remote
- * port is in the heirarchy and do not allow the driver to get
+ * port is in the hierarchy and do not allow the driver to get
* involved in sysfs functions. The driver only gets involved if
* it's the "old" style that doesn't use rports.
*/
diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c
index 6d39150e..b2ef71a 100644
--- a/drivers/scsi/scsi_transport_sas.c
+++ b/drivers/scsi/scsi_transport_sas.c
@@ -500,7 +500,7 @@ struct sas_phy *sas_phy_alloc(struct device *parent, int number)
EXPORT_SYMBOL(sas_phy_alloc);
/**
- * sas_phy_add -- add a SAS PHY to the device hierachy
+ * sas_phy_add -- add a SAS PHY to the device hierarchy
* @phy: The PHY to be added
*
* Publishes a SAS PHY to the rest of the system.
@@ -1265,7 +1265,7 @@ struct sas_rphy *sas_expander_alloc(struct sas_port *parent,
EXPORT_SYMBOL(sas_expander_alloc);
/**
- * sas_rphy_add -- add a SAS remote PHY to the device hierachy
+ * sas_rphy_add -- add a SAS remote PHY to the device hierarchy
* @rphy: The remote PHY to be added
*
* Publishes a SAS remote PHY to the rest of the system.
diff --git a/fs/cifs/README b/fs/cifs/README
index 432e515..080c5eb 100644
--- a/fs/cifs/README
+++ b/fs/cifs/README
@@ -1,5 +1,5 @@
The CIFS VFS support for Linux supports many advanced network filesystem
-features such as heirarchical dfs like namespace, hardlinks, locking and more.
+features such as hierarchical dfs like namespace, hardlinks, locking and more.
It was designed to comply with the SNIA CIFS Technical Reference (which
supersedes the 1992 X/Open SMB Standard) as well as to perform best practice
practical interoperability with Windows 2000, Windows XP, Samba and equivalent
diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c
index f7fa52b..28dd757 100644
--- a/fs/ocfs2/namei.c
+++ b/fs/ocfs2/namei.c
@@ -1098,7 +1098,7 @@ static int ocfs2_rename(struct inode *old_dir,
BUG();
}
- /* Assume a directory heirarchy thusly:
+ /* Assume a directory hierarchy thusly:
* a/b/c
* a/d
* a,b,c, and d are all directories.
diff --git a/include/asm-ia64/pal.h b/include/asm-ia64/pal.h
index bc768153..e43021a 100644
--- a/include/asm-ia64/pal.h
+++ b/include/asm-ia64/pal.h
@@ -32,7 +32,7 @@
#define PAL_CACHE_FLUSH 1 /* flush i/d cache */
#define PAL_CACHE_INFO 2 /* get detailed i/d cache info */
#define PAL_CACHE_INIT 3 /* initialize i/d cache */
-#define PAL_CACHE_SUMMARY 4 /* get summary of cache heirarchy */
+#define PAL_CACHE_SUMMARY 4 /* get summary of cache hierarchy */
#define PAL_MEM_ATTRIB 5 /* list supported memory attributes */
#define PAL_PTCE_INFO 6 /* purge TLB info */
#define PAL_VM_INFO 7 /* return supported virtual memory features */
@@ -113,14 +113,14 @@ typedef s64 pal_status_t;
*/
#define PAL_STATUS_REQUIRES_MEMORY (-9) /* Call requires PAL memory buffer */
-/* Processor cache level in the heirarchy */
+/* Processor cache level in the hierarchy */
typedef u64 pal_cache_level_t;
#define PAL_CACHE_LEVEL_L0 0 /* L0 */
#define PAL_CACHE_LEVEL_L1 1 /* L1 */
#define PAL_CACHE_LEVEL_L2 2 /* L2 */
-/* Processor cache type at a particular level in the heirarchy */
+/* Processor cache type at a particular level in the hierarchy */
typedef u64 pal_cache_type_t;
#define PAL_CACHE_TYPE_INSTRUCTION 1 /* Instruction cache */
@@ -272,14 +272,14 @@ typedef struct pal_cache_protection_info_s {
#define PAL_CACHE_PROT_METHOD_ECC 3 /* ECC protection */
-/* Processor cache line identification in the heirarchy */
+/* Processor cache line identification in the hierarchy */
typedef union pal_cache_line_id_u {
u64 pclid_data;
struct {
u64 cache_type : 8, /* 7-0 cache type */
level : 8, /* 15-8 level of the
* cache in the
- * heirarchy.
+ * hierarchy.
*/
way : 8, /* 23-16 way in the set
*/
@@ -292,7 +292,7 @@ typedef union pal_cache_line_id_u {
u64 cache_type : 8, /* 7-0 cache type */
level : 8, /* 15-8 level of the
* cache in the
- * heirarchy.
+ * hierarchy.
*/
way : 8, /* 23-16 way in the set
*/
@@ -978,7 +978,7 @@ ia64_pal_cache_read (pal_cache_line_id_u_t line_id, u64 physical_addr)
return iprv.status;
}
-/* Return summary information about the heirarchy of caches controlled by the processor */
+/* Return summary information about the hierarchy of caches controlled by the processor */
static inline s64
ia64_pal_cache_summary (u64 *cache_levels, u64 *unique_caches)
{
OpenPOWER on IntegriCloud