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

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

Documentation/filesystems/sysfs-pci.txt

+1 −1
Original line number Diff line number Diff line
@@ -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/

Documentation/sh/new-machine.txt

+2 −2
Original line number Diff line number Diff line
@@ -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

arch/powerpc/mm/numa.c

+1 −1
Original line number Diff line number Diff line
@@ -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.

drivers/media/dvb/dvb-core/dvb_frontend.c

+1 −1
Original line number Diff line number Diff line
@@ -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)

drivers/media/dvb/frontends/dib3000mb.c

+1 −1
Original line number Diff line number Diff line
@@ -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 ");