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>
This commit is contained in:
Родитель
85d1fe095c
Коммит
1b3c3714cb
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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)
|
||||
{
|
||||
|
|
Загрузка…
Ссылка в новой задаче