summaryrefslogtreecommitdiffstats
path: root/drivers/net/wan
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2011-05-02 14:16:37 +0200
committerTejun Heo <tj@kernel.org>2011-05-02 14:16:47 +0200
commitba67cf5cf2ce10ad86a212b70f8c7c75d93a5016 (patch)
tree70242f5927c6d6454bd352ff78f956cfc5238f59 /drivers/net/wan
parentaff364860aa105b2deacc6f21ec8ef524460e3fc (diff)
parent2be19102b71c1a45d37fec50303791daa1a06869 (diff)
downloadblackbird-op-linux-ba67cf5cf2ce10ad86a212b70f8c7c75d93a5016.tar.gz
blackbird-op-linux-ba67cf5cf2ce10ad86a212b70f8c7c75d93a5016.zip
Merge branch 'x86/urgent' into x86-mm
Merge reason: Pick up the following two fix commits. 2be19102b7: x86, NUMA: Fix empty memblk detection in numa_cleanup_meminfo() 765af22da8: x86-32, NUMA: Fix ACPI NUMA init broken by recent x86-64 change Scheduled NUMA init 32/64bit unification changes depend on these. Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'drivers/net/wan')
-rw-r--r--drivers/net/wan/cosa.c2
-rw-r--r--drivers/net/wan/dscc4.c8
-rw-r--r--drivers/net/wan/hostess_sv11.c2
-rw-r--r--drivers/net/wan/ixp4xx_hss.c4
-rw-r--r--drivers/net/wan/lmc/lmc_main.c2
-rw-r--r--drivers/net/wan/lmc/lmc_var.h6
-rw-r--r--drivers/net/wan/z85230.c8
7 files changed, 16 insertions, 16 deletions
diff --git a/drivers/net/wan/cosa.c b/drivers/net/wan/cosa.c
index 10bafd59f9c3..6fb6f8e667d0 100644
--- a/drivers/net/wan/cosa.c
+++ b/drivers/net/wan/cosa.c
@@ -329,7 +329,7 @@ static int startmicrocode(struct cosa_data *cosa, int address);
static int readmem(struct cosa_data *cosa, char __user *data, int addr, int len);
static int cosa_reset_and_read_id(struct cosa_data *cosa, char *id);
-/* Auxilliary functions */
+/* Auxiliary functions */
static int get_wait_data(struct cosa_data *cosa);
static int put_wait_data(struct cosa_data *cosa, int data);
static int puthexnumber(struct cosa_data *cosa, int number);
diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c
index 4578e5b4b411..acb9ea830628 100644
--- a/drivers/net/wan/dscc4.c
+++ b/drivers/net/wan/dscc4.c
@@ -56,7 +56,7 @@
* IV. Notes
* The current error (XDU, RFO) recovery code is untested.
* So far, RDO takes his RX channel down and the right sequence to enable it
- * again is still a mistery. If RDO happens, plan a reboot. More details
+ * again is still a mystery. If RDO happens, plan a reboot. More details
* in the code (NB: as this happens, TX still works).
* Don't mess the cables during operation, especially on DTE ports. I don't
* suggest it for DCE either but at least one can get some messages instead
@@ -1065,7 +1065,7 @@ static int dscc4_open(struct net_device *dev)
/*
* Due to various bugs, there is no way to reliably reset a
- * specific port (manufacturer's dependant special PCI #RST wiring
+ * specific port (manufacturer's dependent special PCI #RST wiring
* apart: it affects all ports). Thus the device goes in the best
* silent mode possible at dscc4_close() time and simply claims to
* be up if it's opened again. It still isn't possible to change
@@ -1230,9 +1230,9 @@ static inline int dscc4_check_clock_ability(int port)
* scaling. Of course some rounding may take place.
* - no high speed mode (40Mb/s). May be trivial to do but I don't have an
* appropriate external clocking device for testing.
- * - no time-slot/clock mode 5: shameless lazyness.
+ * - no time-slot/clock mode 5: shameless laziness.
*
- * The clock signals wiring can be (is ?) manufacturer dependant. Good luck.
+ * The clock signals wiring can be (is ?) manufacturer dependent. Good luck.
*
* BIG FAT WARNING: if the device isn't provided enough clocking signal, it
* won't pass the init sequence. For example, straight back-to-back DTE without
diff --git a/drivers/net/wan/hostess_sv11.c b/drivers/net/wan/hostess_sv11.c
index 48edc5f4dac8..e817583e6ec5 100644
--- a/drivers/net/wan/hostess_sv11.c
+++ b/drivers/net/wan/hostess_sv11.c
@@ -15,7 +15,7 @@
* The hardware does the bus handling to avoid the need for delays between
* touching control registers.
*
- * Port B isnt wired (why - beats me)
+ * Port B isn't wired (why - beats me)
*
* Generic HDLC port Copyright (C) 2008 Krzysztof Halasa <khc@pm.waw.pl>
*/
diff --git a/drivers/net/wan/ixp4xx_hss.c b/drivers/net/wan/ixp4xx_hss.c
index 6c571e198835..f1e1643dc3eb 100644
--- a/drivers/net/wan/ixp4xx_hss.c
+++ b/drivers/net/wan/ixp4xx_hss.c
@@ -178,7 +178,7 @@
*
* The resulting average clock frequency (assuming 33.333 MHz oscillator) is:
* freq = 66.666 MHz / (A + (B + 1) / (C + 1))
- * minumum freq = 66.666 MHz / (A + 1)
+ * minimum freq = 66.666 MHz / (A + 1)
* maximum freq = 66.666 MHz / A
*
* Example: A = 2, B = 2, C = 7, CLOCK_CR register = 2 << 22 | 2 << 12 | 7
@@ -230,7 +230,7 @@
#define PKT_PIPE_MODE_WRITE 0x57
/* HDLC packet status values - desc->status */
-#define ERR_SHUTDOWN 1 /* stop or shutdown occurrance */
+#define ERR_SHUTDOWN 1 /* stop or shutdown occurrence */
#define ERR_HDLC_ALIGN 2 /* HDLC alignment error */
#define ERR_HDLC_FCS 3 /* HDLC Frame Check Sum error */
#define ERR_RXFREE_Q_EMPTY 4 /* RX-free queue became empty while receiving
diff --git a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c
index 70feb84df670..b7f2358d23be 100644
--- a/drivers/net/wan/lmc/lmc_main.c
+++ b/drivers/net/wan/lmc/lmc_main.c
@@ -24,7 +24,7 @@
*
* Linux driver notes:
* Linux uses the device struct lmc_private to pass private information
- * arround.
+ * around.
*
* The initialization portion of this driver (the lmc_reset() and the
* lmc_dec_reset() functions, as well as the led controls and the
diff --git a/drivers/net/wan/lmc/lmc_var.h b/drivers/net/wan/lmc/lmc_var.h
index 65d01978e784..01ad45218d19 100644
--- a/drivers/net/wan/lmc/lmc_var.h
+++ b/drivers/net/wan/lmc/lmc_var.h
@@ -180,7 +180,7 @@ struct lmc___ctl {
/*
- * Carefull, look at the data sheet, there's more to this
+ * Careful, look at the data sheet, there's more to this
* structure than meets the eye. It should probably be:
*
* struct tulip_desc_t {
@@ -380,7 +380,7 @@ struct lmc___softc {
/* CSR6 settings */
#define OPERATION_MODE 0x00000200 /* Full Duplex */
#define PROMISC_MODE 0x00000040 /* Promiscuous Mode */
-#define RECIEVE_ALL 0x40000000 /* Recieve All */
+#define RECIEVE_ALL 0x40000000 /* Receive All */
#define PASS_BAD_FRAMES 0x00000008 /* Pass Bad Frames */
/* Dec control registers CSR6 as well */
@@ -398,7 +398,7 @@ struct lmc___softc {
#define TULIP_CMD_RECEIVEALL 0x40000000L /* (RW) Receivel all frames? */
#define TULIP_CMD_MUSTBEONE 0x02000000L /* (RW) Must Be One (21140) */
#define TULIP_CMD_TXTHRSHLDCTL 0x00400000L /* (RW) Transmit Threshold Mode (21140) */
-#define TULIP_CMD_STOREFWD 0x00200000L /* (RW) Store and Foward (21140) */
+#define TULIP_CMD_STOREFWD 0x00200000L /* (RW) Store and Forward (21140) */
#define TULIP_CMD_NOHEARTBEAT 0x00080000L /* (RW) No Heartbeat (21140) */
#define TULIP_CMD_PORTSELECT 0x00040000L /* (RW) Post Select (100Mb) (21140) */
#define TULIP_CMD_FULLDUPLEX 0x00000200L /* (RW) Full Duplex Mode */
diff --git a/drivers/net/wan/z85230.c b/drivers/net/wan/z85230.c
index 93956861ea21..0806232e0f8f 100644
--- a/drivers/net/wan/z85230.c
+++ b/drivers/net/wan/z85230.c
@@ -542,7 +542,7 @@ static void z8530_dma_tx(struct z8530_channel *chan)
z8530_tx(chan);
return;
}
- /* This shouldnt occur in DMA mode */
+ /* This shouldn't occur in DMA mode */
printk(KERN_ERR "DMA tx - bogus event!\n");
z8530_tx(chan);
}
@@ -1219,7 +1219,7 @@ static const char *z8530_type_name[]={
* @io: the port value in question
*
* Describe a Z8530 in a standard format. We must pass the I/O as
- * the port offset isnt predictable. The main reason for this function
+ * the port offset isn't predictable. The main reason for this function
* is to try and get a common format of report.
*/
@@ -1588,7 +1588,7 @@ static void z8530_rx_done(struct z8530_channel *c)
unsigned long flags;
/*
- * Complete this DMA. Neccessary to find the length
+ * Complete this DMA. Necessary to find the length
*/
flags=claim_dma_lock();
@@ -1657,7 +1657,7 @@ static void z8530_rx_done(struct z8530_channel *c)
* fifo length for this. Thus we want to flip to the new
* buffer and then mess around copying and allocating
* things. For the current case it doesn't matter but
- * if you build a system where the sync irq isnt blocked
+ * if you build a system where the sync irq isn't blocked
* by the kernel IRQ disable then you need only block the
* sync IRQ for the RT_LOCK area.
*
OpenPOWER on IntegriCloud