Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

0 views
Skip to first unread message

Stephen Rothwell

unread,
Feb 2, 2010, 9:40:02 PM2/2/10
to
Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
drivers/net/ppp_generic.c between commit
fa44a73cc766c7f3bac71a66d564e0049b800325 ("ppp_generic.c severly
whitespace damanged by 9c705260feea6ae329bc6b6d5f6d2ef0227eda0a") from
the net tree and commit 09e1aa00f106a476f5b90d94fc0139544bbded75
("tree-wide: fix 'lenght' typo in comments and code") from the trivial
tree.

I fixed it up (by using the trivial tree version) and can carry the fix
as necessary.
--
Cheers,
Stephen Rothwell s...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Jiri Kosina

unread,
Feb 3, 2010, 5:50:02 AM2/3/10
to
On Wed, 3 Feb 2010, Stephen Rothwell wrote:

> Today's linux-next merge of the trivial tree got a conflict in
> drivers/net/ppp_generic.c between commit
> fa44a73cc766c7f3bac71a66d564e0049b800325 ("ppp_generic.c severly
> whitespace damanged by 9c705260feea6ae329bc6b6d5f6d2ef0227eda0a") from
> the net tree and commit 09e1aa00f106a476f5b90d94fc0139544bbded75
> ("tree-wide: fix 'lenght' typo in comments and code") from the trivial
> tree.
>
> I fixed it up (by using the trivial tree version) and can carry the fix
> as necessary.

Hi,

I think the best thing is me dropping the net/ and drivers/net hunks of
this patch and taking it through Davem's tree ... I have already dropped
those hunks from my tree. Dave, the patch is below, please consider
applying.

From: Daniel Mack <dan...@caiaq.de>
Subject: [PATCH] net: fix 'lenght' typo in comments and code

Some misspelled occurences of 'octet' and some comments were also fixed
as I was on it.

Signed-off-by: Daniel Mack <dan...@caiaq.de>
Cc: Jiri Kosina <tri...@kernel.org>
Cc: Joe Perches <j...@perches.com>
Cc: Junio C Hamano <git...@pobox.com>
Signed-off-by: Jiri Kosina <jko...@suse.cz>

diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
index 2282e72..16cb124 100644
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -1436,17 +1436,16 @@ static int ppp_mp_explode(struct ppp *ppp, struct sk_buff *skb)
}

/*
- *check if we are on the last channel or
- *we exceded the lenght of the data to
- *fragment
+ * check if we are on the last channel or we exceeded the length
+ * of the data to fragment
*/
if ((nfree <= 0) || (flen > len))
flen = len;
/*
- *it is not worth to tx on slow channels:
- *in that case from the resulting flen according to the
- *above formula will be equal or less than zero.
- *Skip the channel in this case
+ * it is not worth to tx on slow channels:
+ * in that case from the resulting flen according to the above
+ * formula will be equal or less than zero.
+ * skip the channel in this case.
*/
if (flen <= 0) {
pch->avail = 2;
@@ -1466,7 +1465,7 @@ static int ppp_mp_explode(struct ppp *ppp, struct sk_buff *skb)
goto noskb;
q = skb_put(frag, flen + hdrlen);

- /* make the MP header */
+ /* make the MP header */
q[0] = PPP_MP >> 8;
q[1] = PPP_MP;
if (ppp->flags & SC_MP_XSHORTSEQ) {
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index f03e2e4..a3f9c3f 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -578,7 +578,7 @@ static int r6040_rx(struct net_device *dev, int limit)
/* RX dribble */
if (err & DSC_RX_ERR_DRI)
dev->stats.rx_frame_errors++;
- /* Buffer lenght exceeded */
+ /* Buffer length exceeded */
if (err & DSC_RX_ERR_BUF)
dev->stats.rx_length_errors++;
/* Packet too long */
diff --git a/drivers/net/sb1000.c b/drivers/net/sb1000.c
index 9f83a11..dab3ac7 100644
--- a/drivers/net/sb1000.c
+++ b/drivers/net/sb1000.c
@@ -65,7 +65,7 @@ static const int sb1000_debug = 1;

static const int SB1000_IO_EXTENT = 8;
/* SB1000 Maximum Receive Unit */
-static const int SB1000_MRU = 1500; /* octects */
+static const int SB1000_MRU = 1500; /* octets */

#define NPIDS 4
struct sb1000_private {
diff --git a/drivers/net/stmmac/common.h b/drivers/net/stmmac/common.h
index e49e518..81e5def 100644
--- a/drivers/net/stmmac/common.h
+++ b/drivers/net/stmmac/common.h
@@ -169,7 +169,7 @@ struct stmmac_extra_stats {
unsigned long rx_toolong;
unsigned long rx_collision;
unsigned long rx_crc;
- unsigned long rx_lenght;
+ unsigned long rx_length;
unsigned long rx_mii;
unsigned long rx_multicast;
unsigned long rx_gmac_overflow;
diff --git a/drivers/net/stmmac/gmac.c b/drivers/net/stmmac/gmac.c
index 52586ee..620b204 100644
--- a/drivers/net/stmmac/gmac.c
+++ b/drivers/net/stmmac/gmac.c
@@ -257,7 +257,7 @@ static int gmac_coe_rdes0(int ipc_err, int type, int payload_err)

/* bits 5 7 0 | Frame status
* ----------------------------------------------------------
- * 0 0 0 | IEEE 802.3 Type frame (lenght < 1536 octects)
+ * 0 0 0 | IEEE 802.3 Type frame (length < 1536 octets)
* 1 0 0 | IPv4/6 No CSUM errorS.
* 1 0 1 | IPv4/6 CSUM PAYLOAD error
* 1 1 0 | IPv4/6 CSUM IP HR error
@@ -358,7 +358,7 @@ static int gmac_get_rx_frame_status(void *data, struct stmmac_extra_stats *x,
}
if (unlikely(p->des01.erx.length_error)) {
DBG(KERN_ERR "GMAC RX: length_error error\n");
- x->rx_lenght++;
+ x->rx_length++;
ret = discard_frame;
}
#ifdef STMMAC_VLAN_TAG_USED
diff --git a/drivers/net/stmmac/mac100.c b/drivers/net/stmmac/mac100.c
index 625171b..1f6b608 100644
--- a/drivers/net/stmmac/mac100.c
+++ b/drivers/net/stmmac/mac100.c
@@ -262,7 +262,7 @@ static int mac100_get_rx_frame_status(void *data, struct stmmac_extra_stats *x,
ret = discard_frame;

if (unlikely(p->des01.rx.length_error)) {
- x->rx_lenght++;
+ x->rx_length++;
ret = discard_frame;
}
if (unlikely(p->des01.rx.mii_error)) {
diff --git a/drivers/net/stmmac/stmmac_ethtool.c b/drivers/net/stmmac/stmmac_ethtool.c
index 694ebe6..9edda5d 100644
--- a/drivers/net/stmmac/stmmac_ethtool.c
+++ b/drivers/net/stmmac/stmmac_ethtool.c
@@ -61,7 +61,7 @@ static const struct stmmac_stats stmmac_gstrings_stats[] = {
STMMAC_STAT(rx_toolong),
STMMAC_STAT(rx_collision),
STMMAC_STAT(rx_crc),
- STMMAC_STAT(rx_lenght),
+ STMMAC_STAT(rx_length),
STMMAC_STAT(rx_mii),
STMMAC_STAT(rx_multicast),
STMMAC_STAT(rx_gmac_overflow),
diff --git a/drivers/net/wimax/i2400m/i2400m-usb.h b/drivers/net/wimax/i2400m/i2400m-usb.h
index 5cc0f27..9c61e5f 100644
--- a/drivers/net/wimax/i2400m/i2400m-usb.h
+++ b/drivers/net/wimax/i2400m/i2400m-usb.h
@@ -105,7 +105,7 @@ static inline void edc_init(struct edc *edc)
*
* @edc: pointer to error density counter.
* @max_err: maximum number of errors we can accept over the timeframe
- * @timeframe: lenght of the timeframe (in jiffies).
+ * @timeframe: length of the timeframe (in jiffies).
*
* Returns: !0 1 if maximum acceptable errors per timeframe has been
* exceeded. 0 otherwise.
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index afd26bf..c4e4121 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -279,7 +279,7 @@ static void p54spi_power_on(struct p54s_priv *priv)
enable_irq(gpio_to_irq(p54spi_gpio_irq));

/*
- * need to wait a while before device can be accessed, the lenght
+ * need to wait a while before device can be accessed, the length
* is just a guess
*/
msleep(10);
diff --git a/drivers/net/wireless/wl12xx/wl1251_cmd.c b/drivers/net/wireless/wl12xx/wl1251_cmd.c
index 770f260..ff446a0 100644
--- a/drivers/net/wireless/wl12xx/wl1251_cmd.c
+++ b/drivers/net/wireless/wl12xx/wl1251_cmd.c
@@ -103,7 +103,7 @@ int wl1251_cmd_test(struct wl1251 *wl, void *buf, size_t buf_len, u8 answer)
* @wl: wl struct
* @id: acx id
* @buf: buffer for the response, including all headers, must work with dma
- * @len: lenght of buf
+ * @len: length of buf
*/
int wl1251_cmd_interrogate(struct wl1251 *wl, u16 id, void *buf, size_t len)
{
diff --git a/drivers/net/wireless/wl12xx/wl1251_rx.c b/drivers/net/wireless/wl12xx/wl1251_rx.c
index f84cc89..0a45528 100644
--- a/drivers/net/wireless/wl12xx/wl1251_rx.c
+++ b/drivers/net/wireless/wl12xx/wl1251_rx.c
@@ -135,7 +135,7 @@ static void wl1251_rx_body(struct wl1251 *wl,
rx_buffer = skb_put(skb, length);
wl1251_mem_read(wl, rx_packet_ring_addr, rx_buffer, length);

- /* The actual lenght doesn't include the target's alignment */
+ /* The actual length doesn't include the target's alignment */
skb->len = desc->length - PLCP_HEADER_LENGTH;

fc = (u16 *)skb->data;
diff --git a/drivers/net/wireless/wl12xx/wl1271_cmd.c b/drivers/net/wireless/wl12xx/wl1271_cmd.c
index c3385b3..1e3d4b0 100644
--- a/drivers/net/wireless/wl12xx/wl1271_cmd.c
+++ b/drivers/net/wireless/wl12xx/wl1271_cmd.c
@@ -437,7 +437,7 @@ int wl1271_cmd_test(struct wl1271 *wl, void *buf, size_t buf_len, u8 answer)
* @wl: wl struct
* @id: acx id
* @buf: buffer for the response, including all headers, must work with dma
- * @len: lenght of buf
+ * @len: length of buf
*/
int wl1271_cmd_interrogate(struct wl1271 *wl, u16 id, void *buf, size_t len)
{
diff --git a/net/dccp/ackvec.h b/net/dccp/ackvec.h
index 7ea557b..fd278d8 100644
--- a/net/dccp/ackvec.h
+++ b/net/dccp/ackvec.h
@@ -73,7 +73,7 @@ struct dccp_ackvec {
* @avr_ack_ackno - sequence number being acknowledged
* @avr_ack_ptr - pointer into av_buf where this record starts
* @avr_ack_nonce - av_ack_nonce at the time this record was sent
- * @avr_sent_len - lenght of the record in av_buf
+ * @avr_sent_len - length of the record in av_buf
*/
struct dccp_ackvec_record {
struct list_head avr_node;
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index eb6d097..cb4c91d 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1206,7 +1206,7 @@ int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
* Let's try using as much space as possible.
* Use MTU if total length of the message fits into the MTU.
* Otherwise, we need to reserve fragment header and
- * fragment alignment (= 8-15 octects, in total).
+ * fragment alignment (= 8-15 octets, in total).
*
* Note that we may need to "move" the data from the tail of
* of the buffer to the new fragment when we split
--
1.6.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

David Miller

unread,
Feb 3, 2010, 11:10:02 PM2/3/10
to
From: Jiri Kosina <jko...@suse.cz>
Date: Wed, 3 Feb 2010 11:39:47 +0100 (CET)

> I think the best thing is me dropping the net/ and drivers/net hunks of
> this patch and taking it through Davem's tree ... I have already dropped
> those hunks from my tree. Dave, the patch is below, please consider
> applying.

...


> From: Daniel Mack <dan...@caiaq.de>
> Subject: [PATCH] net: fix 'lenght' typo in comments and code
>
> Some misspelled occurences of 'octet' and some comments were also fixed
> as I was on it.
>
> Signed-off-by: Daniel Mack <dan...@caiaq.de>
> Cc: Jiri Kosina <tri...@kernel.org>
> Cc: Joe Perches <j...@perches.com>
> Cc: Junio C Hamano <git...@pobox.com>
> Signed-off-by: Jiri Kosina <jko...@suse.cz>

This doesn't apply to net-next-2.6 at all:

error: patch failed: drivers/net/ppp_generic.c:1436
error: drivers/net/ppp_generic.c: patch does not apply
error: drivers/net/stmmac/gmac.c: does not exist in index
error: drivers/net/stmmac/mac100.c: does not exist in index

Jiri Kosina

unread,
Feb 4, 2010, 5:00:02 AM2/4/10
to
On Wed, 3 Feb 2010, David Miller wrote:

> > I think the best thing is me dropping the net/ and drivers/net hunks of
> > this patch and taking it through Davem's tree ... I have already dropped
> > those hunks from my tree. Dave, the patch is below, please consider
> > applying.
> ...
> > From: Daniel Mack <dan...@caiaq.de>
> > Subject: [PATCH] net: fix 'lenght' typo in comments and code
> >
> > Some misspelled occurences of 'octet' and some comments were also fixed
> > as I was on it.
> >
> > Signed-off-by: Daniel Mack <dan...@caiaq.de>
> > Cc: Jiri Kosina <tri...@kernel.org>
> > Cc: Joe Perches <j...@perches.com>
> > Cc: Junio C Hamano <git...@pobox.com>
> > Signed-off-by: Jiri Kosina <jko...@suse.cz>
>
> This doesn't apply to net-next-2.6 at all:
>
> error: patch failed: drivers/net/ppp_generic.c:1436
> error: drivers/net/ppp_generic.c: patch does not apply
> error: drivers/net/stmmac/gmac.c: does not exist in index
> error: drivers/net/stmmac/mac100.c: does not exist in index

Daniel, could you please refresh the drivers/net/ and net/ bits of your
patch and resent it to netdev/Dave?

I have already dropped it from my queue.

Thanks,

--
Jiri Kosina
SUSE Labs, Novell Inc.

Giuseppe CAVALLARO

unread,
Feb 4, 2010, 8:00:02 AM2/4/10
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jiri,

Jiri Kosina wrote:
> On Wed, 3 Feb 2010, David Miller wrote:
>
>>> I think the best thing is me dropping the net/ and drivers/net hunks of
>>> this patch and taking it through Davem's tree ... I have already dropped
>>> those hunks from my tree. Dave, the patch is below, please consider
>>> applying.
>> ...
>>> From: Daniel Mack <dan...@caiaq.de>
>>> Subject: [PATCH] net: fix 'lenght' typo in comments and code
>>>
>>> Some misspelled occurences of 'octet' and some comments were also fixed
>>> as I was on it.
>>>
>>> Signed-off-by: Daniel Mack <dan...@caiaq.de>
>>> Cc: Jiri Kosina <tri...@kernel.org>
>>> Cc: Joe Perches <j...@perches.com>
>>> Cc: Junio C Hamano <git...@pobox.com>
>>> Signed-off-by: Jiri Kosina <jko...@suse.cz>
>> This doesn't apply to net-next-2.6 at all:
>>
>> error: patch failed: drivers/net/ppp_generic.c:1436
>> error: drivers/net/ppp_generic.c: patch does not apply
>> error: drivers/net/stmmac/gmac.c: does not exist in index
>> error: drivers/net/stmmac/mac100.c: does not exist in index

The stmmac driver included in net-next has been restructured: for this
reason both gmac.c and mac100.c files do not exist any more.

Let me know if I can help on this; I mean I'm happy to apply this latest
changes to the stmmac in net-next and send a new patch.

Peppe

> Daniel, could you please refresh the drivers/net/ and net/ bits of your
> patch and resent it to netdev/Dave?
>
> I have already dropped it from my queue.
>
> Thanks,
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktqwo0ACgkQ2Xo3j31MSSLr+QCeM4cA87vv6uQoY1rHf4Wl7Ye8
v1wAnAtI6RWt5wNUFJZRTQ2mEOP4EuE9
=G2hJ
-----END PGP SIGNATURE-----

Giuseppe CAVALLARO

unread,
Feb 4, 2010, 9:00:02 AM2/4/10
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Giuseppe CAVALLARO wrote:
> Hi Jiri,


>
> The stmmac driver included in net-next has been restructured: for this
> reason both gmac.c and mac100.c files do not exist any more.
>
> Let me know if I can help on this; I mean I'm happy to apply this latest
> changes to the stmmac in net-next and send a new patch.

patch attached
I hope it could be useful.

Regards,
Peppe

>
> Peppe
>
>> Daniel, could you please refresh the drivers/net/ and net/ bits of your
>> patch and resent it to netdev/Dave?
>
>> I have already dropped it from my queue.
>
>> Thanks,
>
>

- --
To unsubscribe from this list: send the line "unsubscribe netdev" in


the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

-----BEGIN PGP SIGNATURE-----


Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAktq0R0ACgkQ2Xo3j31MSSKeIgCggHG4aixy7SxkSuaVd/hH3fo/
WZcAoK52FTpJLt/JJqJY2NopN0rFK3G1
=Ur+x
-----END PGP SIGNATURE-----

0001-stmmac-fix-lenght-typo-in-comments-and-code.patch

David Miller

unread,
Feb 4, 2010, 12:40:04 PM2/4/10
to
From: Giuseppe CAVALLARO <peppe.c...@st.com>
Date: Thu, 04 Feb 2010 14:52:29 +0100

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Giuseppe CAVALLARO wrote:
>> Hi Jiri,
>>
>> The stmmac driver included in net-next has been restructured: for this
>> reason both gmac.c and mac100.c files do not exist any more.
>>
>> Let me know if I can help on this; I mean I'm happy to apply this latest
>> changes to the stmmac in net-next and send a new patch.
>
> patch attached
> I hope it could be useful.

Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in


the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Stephen Rothwell

unread,
Feb 4, 2010, 9:40:01 PM2/4/10
to
Hi Jiri,

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.


--
Cheers,
Stephen Rothwell s...@canb.auug.org.au

diff --cc drivers/net/sfc/mcdi_pcol.h
index bd59302,f61e1de..0000000
--- a/drivers/net/sfc/mcdi_pcol.h
+++ b/drivers/net/sfc/mcdi_pcol.h
@@@ -859,14 -852,11 +859,14 @@@
/* MC_CMD_POLL_PHY_BIST: (variadic output)
* Poll for BIST completion
*
- * Returns a single status code, and a binary blob of phy-specific
- * bist output. If the driver can't successfully parse the BIST output,
- * it should still respect the Pass/Fail in OUT.RESULT.
+ * Returns a single status code, and optionally some PHY specific
+ * bist output. The driver should only consume the BIST output
+ * after validating OUTLEN and PHY_CFG.PHY_TYPE.
*
- * If a driver can't succesfully parse the BIST output, it should
- * Locks required: PHY_LOCK if doing a PHY BIST
++ * If a 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
* Return code: 0, EACCES (if PHY_LOCK is not held)
*/
#define MC_CMD_POLL_BIST 0x26

David Miller

unread,
Feb 4, 2010, 11:30:02 PM2/4/10
to
From: Stephen Rothwell <s...@canb.auug.org.au>
Date: Fri, 5 Feb 2010 13:37:47 +1100

> 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.

Thanks.

Jiri Kosina

unread,
Feb 5, 2010, 3:40:01 AM2/5/10
to
On Thu, 4 Feb 2010, David Miller 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.

--
Jiri Kosina
SUSE Labs, Novell Inc.

Jiri Kosina

unread,
Feb 5, 2010, 6:30:03 AM2/5/10
to
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.bu...@gmail.com>
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.bu...@gmail.com>
Signed-off-by: Jiri Kosina <jko...@suse.cz>

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).

David Miller

unread,
Feb 5, 2010, 12:00:03 PM2/5/10
to
From: Jiri Kosina <jko...@suse.cz>
Date: Fri, 5 Feb 2010 12:23:06 +0100 (CET)

> 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

I can't apply it to my tree, that's why we had the conflict
in the first place.

Please submit this to me so that it applies cleanly to net-next-2.6

Thanks.

0 new messages