Commit 1b3c3714 authored by Uwe Kleine-König's avatar Uwe Kleine-König Committed by Adrian Bunk

Fix typos concerning hierarchy

        heirarchical, hierachical -> hierarchical
        heirarchy, hierachy -> hierarchy
Signed-off-by: default avatarUwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
parent 85d1fe09
......@@ -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/
......
......@@ -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
......
......@@ -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.
......
......@@ -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)
......
......@@ -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 ");
......
......@@ -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;
};
......
......@@ -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.
*/
......
......@@ -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.
......
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
......
......@@ -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.
......
......@@ -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)
{
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment