Re: linux-next: manual merge of the trivial tree with the net tree

[Jiri Kosina]

On Fri, 5 Feb 2010, Jiri Kosina wrote:

> > > Today's linux-next merge of the trivial tree got a conflict in 
> > > drivers/net/sfc/mcdi_pcol.h between commit 
> > > 5297a98d5dd6de86fe1e2ffc9ea60cdf59b71443 ("sfc: Update MCDI protocol 
> > > definitions") from the net tree and commit 
> > > 4887b438e6880c73c4b44d868211e70c1f3deaec ("Fix misspelling of 
> > > "successful" and variants in comments") from the trivial tree.
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary.
> > 
> > Ugh, this is the second spelling fix that's hit a conflict
> > in the same exact tree.
> > 
> > Please, submit these things to the subsystem maintainers instead
> > of keeping them together in a totally seperate tree.  That way
> > we won't have to keep fighting these things.
> 
> Well, no problem with that. 
> 
> Some maintainers just don't want to be buggered with such patches though, 
> and I always take care of sending this queue to Linus only when all the 
> trees which had conflict in linux-next are already in (and I do the 
> conflict resolution myself), so this should be exactly zero additional 
> work for subsystem maintainers.
> 
> But if you don't like this, I'll just start refusing all the trivial 
> patches touching net/ and drivers/net/ and will redirect them your way.


Ayway, below is the hunk that I have already dropped from my tree (so that 
conflict in linux-next is gone), please feel free to apply it to your 
tree, and let me known whether you want me to reject all furutre patches 
touching net/ and driver/net/ to be refused on my side and redirected your 
way, or if you are fine with me handling the conflict resolution before I 
push them to Linus.

Thanks.



From: Adam Buchbinder <adam.buchbinder@xxxxxxxxx>
Subject: NET: Fix misspelling of "successful" and variants in comments.

Some comments misspell "successful" or variants of the word; this
fixes them. No code changes.

Signed-off-by: Adam Buchbinder <adam.buchbinder@xxxxxxxxx>
Signed-off-by: Jiri Kosina <jkosina@xxxxxxx>

diff --git a/drivers/net/sfc/mcdi_pcol.h b/drivers/net/sfc/mcdi_pcol.h
index 2a85360..f61e1de 100644
--- a/drivers/net/sfc/mcdi_pcol.h
+++ b/drivers/net/sfc/mcdi_pcol.h
@@ -853,7 +853,7 @@
  * Poll for BIST completion
  *
  * Returns a single status code, and a binary blob of phy-specific
- * bist output. If the driver can't succesfully parse the BIST output,
+ * bist output. If the driver can't successfully parse the BIST output,
  * it should still respect the Pass/Fail in OUT.RESULT.
  *
  * Locks required: PHY_LOCK  if doing a  PHY BIST
diff --git a/drivers/net/wimax/i2400m/fw.c b/drivers/net/wimax/i2400m/fw.c
index 64cdfeb..40ee5f6 100644
--- a/drivers/net/wimax/i2400m/fw.c
+++ b/drivers/net/wimax/i2400m/fw.c
@@ -1595,7 +1595,7 @@ int i2400m_dev_bootstrap(struct i2400m *i2400m, enum i2400m_bri flags)
 		i2400m->fw_name = fw_name;
 		ret = i2400m_fw_bootstrap(i2400m, fw, flags);
 		release_firmware(fw);
-		if (ret >= 0)	/* firmware loaded succesfully */
+		if (ret >= 0)	/* firmware loaded successfully */
 			break;
 		i2400m->fw_name = NULL;
 	}
diff --git a/drivers/net/wireless/rt2x00/rt2x00link.c b/drivers/net/wireless/rt2x00/rt2x00link.c
index 0efbf5a..ffee9f8 100644
--- a/drivers/net/wireless/rt2x00/rt2x00link.c
+++ b/drivers/net/wireless/rt2x00/rt2x00link.c
@@ -240,7 +240,7 @@ void rt2x00link_update_stats(struct rt2x00_dev *rt2x00dev,
 	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
 
 	/*
-	 * Frame was received successfully since non-succesfull
+	 * Frame was received successfully since non-successful
 	 * frames would have been dropped by the hardware.
 	 */
 	qual->rx_success++;
diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c b/drivers/net/wireless/rt2x00/rt2x00usb.c
index 0a751e7..8b8c500 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
@@ -200,7 +200,7 @@ static void rt2x00usb_interrupt_txdone(struct urb *urb)
 	 * Obtain the status about this packet.
 	 * Note that when the status is 0 it does not mean the
 	 * frame was send out correctly. It only means the frame
-	 * was succesfully pushed to the hardware, we have no
+	 * was successfully pushed to the hardware, we have no
 	 * way to determine the transmission status right now.
 	 * (Only indirectly by looking at the failed TX counters
 	 * in the register).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/