* Re: [PATCH net-next] llc: Use normal etherdevice.h tests
From: David Miller @ 2013-09-04 2:34 UTC (permalink / raw)
To: joe; +Cc: acme, netdev, linux-kernel
In-Reply-To: <1378066315.1953.23.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Sun, 01 Sep 2013 13:11:55 -0700
> Convert the llc_<foo> static inlines to the
> equivalents from etherdevice.h and remove
> the llc_<foo> static inline functions.
>
> llc_mac_null -> is_zero_ether_addr
> llc_mac_multicast -> is_multicast_ether_addr
> llc_mac_match -> ether_addr_equal
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] tcp: syncookies: reduce mss table to four values
From: David Miller @ 2013-09-04 2:32 UTC (permalink / raw)
To: fw; +Cc: netdev
In-Reply-To: <1378065356-25509-2-git-send-email-fw@strlen.de>
From: Florian Westphal <fw@strlen.de>
Date: Sun, 1 Sep 2013 21:55:56 +0200
> Halve mss table size to make blind cookie guessing more difficult.
> This is sad since the tables were already small, but there
> is little alternative except perhaps adding more precise mss information
> in the tcp timestamp. Timestamps are unfortunately not ubiquitous.
>
> Guessing all possible cookie values still has 8-in 2**32 chance.
>
> Reported-by: Jakob Lell <jakob@jakoblell.com>
> Signed-off-by: Florian Westphal <fw@strlen.de>
> ---
> Changes since v1:
> - add comment explaining mss choices
The ipv6 choices are still a complete mystery.
Why do you put a 9000 entry into the ipv6 table and have nothing
similar in the ipv4 table? Why not mimick the ipv4 values in the ipv6
table, as this is exactly what I would expect to be done here?
You need to add a comment to the ipv6 table explaining things, at the
very least.
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: Convert uses of compare_ether_addr to ether_addr_equal
From: David Miller @ 2013-09-04 2:28 UTC (permalink / raw)
To: joe; +Cc: netdev, e1000-devel, linux-kernel, linux-wireless, users
In-Reply-To: <1378061483.1953.3.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Sun, 01 Sep 2013 11:51:23 -0700
> Use the new bool function ether_addr_equal to add
> some clarity and reduce the likelihood for misuse
> of compare_ether_addr for sorting.
>
> Done via cocci script: (and a little typing)
...
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
^ permalink raw reply
* Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support
From: David Miller @ 2013-09-04 2:27 UTC (permalink / raw)
To: liujunliang_ljl
Cc: horms, joe, romieu, gregkh, netdev, linux-usb, linux-kernel,
sunhecheng
In-Reply-To: <1378035488-8643-1-git-send-email-liujunliang_ljl@163.com>
From: liujunliang_ljl@163.com
Date: Sun, 1 Sep 2013 19:38:08 +0800
> From: Liu Junliang <liujunliang_ljl@163.com>
>
> Signed-off-by: Liu Junliang <liujunliang_ljl@163.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] xen-netback: count number required slots for an skb more carefully
From: annie li @ 2013-09-04 2:25 UTC (permalink / raw)
To: Wei Liu
Cc: David Vrabel, xen-devel, Konrad Rzeszutek Wilk, Boris Ostrovsky,
Ian Campbell, netdev, msw
In-Reply-To: <20130903215328.GA13465@zion.uk.xensource.com>
On 2013-9-4 5:53, Wei Liu wrote:
> On Tue, Sep 03, 2013 at 06:29:50PM +0100, David Vrabel wrote:
>> From: David Vrabel <david.vrabel@citrix.com>
>>
>> When a VM is providing an iSCSI target and the LUN is used by the
>> backend domain, the generated skbs for direct I/O writes to the disk
>> have large, multi-page skb->data but no frags.
>>
>> With some lengths and starting offsets, xen_netbk_count_skb_slots()
>> would be one short because the simple calculation of
>> DIV_ROUND_UP(skb_headlen(), PAGE_SIZE) was not accounting for the
>> decisions made by start_new_rx_buffer() which does not guarantee
>> responses are fully packed.
>>
>> For example, a skb with length < 2 pages but which spans 3 pages would
>> be counted as requiring 2 slots but would actually use 3 slots.
>>
>> skb->data:
>>
>> | 1111|222222222222|3333 |
>>
>> Fully packed, this would need 2 slots:
>>
>> |111122222222|22223333 |
>>
>> But because the 2nd page wholy fits into a slot it is not split across
>> slots and goes into a slot of its own:
>>
>> |1111 |222222222222|3333 |
>>
>> Miscounting the number of slots means netback may push more responses
>> than the number of available requests. This will cause the frontend
>> to get very confused and report "Too many frags/slots". The frontend
>> never recovers and will eventually BUG.
>>
>> Fix this by counting the number of required slots more carefully. In
>> xen_netbk_count_skb_slots(), more closely follow the algorithm used by
>> xen_netbk_gop_skb() by introducing xen_netbk_count_frag_slots() which
>> is the dry-run equivalent of netbk_gop_frag_copy().
>>
> Phew! So this is backend miscounting bug. I thought it was a frontend
> bug so it didn't ring a bell when we had our face-to-face discussion,
> sorry. :-(
>
> This bug was discussed back in July among Annie, Matt, Ian and I. We
> finally agreed to take Matt's solution. Matt agreed to post final
> version within a week but obviously he's too busy to do so. I was away
> so I didn't follow closely. Eventually it fell through the crack. :-(
The fixes can be implemented in two ways, one is fix in
xen_netbk_count_skb_slots to return correct slot count, my
patch(http://lists.xen.org/archives/html/xen-devel/2013-07/msg00785.html) and
David's fall in this way. The other way is fixed in netbk_gop_frag_copy
which is
Matt's(http://lists.xen.org/archives/html/xen-devel/2013-07/msg00760.html).
> Matt, do you fancy sending the final version? IIRC the commit message
> needs to be re-written. I personally still prefer Matt's solution as
> it a) make efficient use of the ring, b) uses ring pointers to
> calculate slots which is most accurate, c) removes the dependence on
> MAX_SKB_FRAGS in guest RX path.
>
> Anyway, we should get this fixed ASAP.
Totally agree. This issue is easy to be reproduced with large MTU. It is
better to upstream the fix soon in case others hit it and waste time to
fix it.
Thanks
Annie
>
> Thanks
> Wei.
>
> REF:
> <1373409659-22383-1-git-send-email-msw@amazon.com>
> <1373350520-19985-1-git-send-email-annie.li@oracle.com>
>
>
>> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
>> ---
>> [Resend to actually Cc netdev, sorry.]
>> ---
>> drivers/net/xen-netback/netback.c | 94 +++++++++++++++++++++++++------------
>> 1 files changed, 64 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
>> index 64828de..f149ce5 100644
>> --- a/drivers/net/xen-netback/netback.c
>> +++ b/drivers/net/xen-netback/netback.c
>> @@ -361,6 +361,49 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
>> return false;
>> }
>>
>> +struct xen_netbk_count_slot_state {
>> + unsigned long copy_off;
>> + bool head;
>> +};
>> +
>> +unsigned int xen_netbk_count_frag_slots(struct xenvif *vif,
>> + unsigned long offset, unsigned long size,
>> + struct xen_netbk_count_slot_state *state)
>> +{
>> + unsigned count = 0;
>> +
>> + offset &= ~PAGE_MASK;
>> +
>> + while (size > 0) {
>> + unsigned long bytes;
>> +
>> + bytes = PAGE_SIZE - offset;
>> +
>> + if (bytes > size)
>> + bytes = size;
>> +
>> + if (start_new_rx_buffer(state->copy_off, bytes, state->head)) {
>> + count++;
>> + state->copy_off = 0;
>> + }
>> +
>> + if (state->copy_off + bytes > MAX_BUFFER_OFFSET)
>> + bytes = MAX_BUFFER_OFFSET - state->copy_off;
>> +
>> + state->copy_off += bytes;
>> +
>> + offset += bytes;
>> + size -= bytes;
>> +
>> + if (offset == PAGE_SIZE)
>> + offset = 0;
>> +
>> + state->head = false;
>> + }
>> +
>> + return count;
>> +}
>> +
>> /*
>> * Figure out how many ring slots we're going to need to send @skb to
>> * the guest. This function is essentially a dry run of
>> @@ -368,48 +411,39 @@ static bool start_new_rx_buffer(int offset, unsigned long size, int head)
>> */
>> unsigned int xen_netbk_count_skb_slots(struct xenvif *vif, struct sk_buff *skb)
>> {
>> + struct xen_netbk_count_slot_state state;
>> unsigned int count;
>> - int i, copy_off;
>> + unsigned char *data;
>> + unsigned i;
>>
>> - count = DIV_ROUND_UP(skb_headlen(skb), PAGE_SIZE);
>> + state.head = true;
>> + state.copy_off = 0;
>>
>> - copy_off = skb_headlen(skb) % PAGE_SIZE;
>> + /* Slot for the first (partial) page of data. */
>> + count = 1;
>>
>> + /* Need a slot for the GSO prefix for GSO extra data? */
>> if (skb_shinfo(skb)->gso_size)
>> count++;
>>
>> - for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
>> - unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
>> - unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
>> - unsigned long bytes;
>> -
>> - offset &= ~PAGE_MASK;
>> -
>> - while (size > 0) {
>> - BUG_ON(offset >= PAGE_SIZE);
>> - BUG_ON(copy_off > MAX_BUFFER_OFFSET);
>> -
>> - bytes = PAGE_SIZE - offset;
>> -
>> - if (bytes > size)
>> - bytes = size;
>> + data = skb->data;
>> + while (data < skb_tail_pointer(skb)) {
>> + unsigned long offset = offset_in_page(data);
>> + unsigned long size = PAGE_SIZE - offset;
>>
>> - if (start_new_rx_buffer(copy_off, bytes, 0)) {
>> - count++;
>> - copy_off = 0;
>> - }
>> + if (data + size > skb_tail_pointer(skb))
>> + size = skb_tail_pointer(skb) - data;
>>
>> - if (copy_off + bytes > MAX_BUFFER_OFFSET)
>> - bytes = MAX_BUFFER_OFFSET - copy_off;
>> + count += xen_netbk_count_frag_slots(vif, offset, size, &state);
>>
>> - copy_off += bytes;
>> + data += size;
>> + }
>>
>> - offset += bytes;
>> - size -= bytes;
>> + for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
>> + unsigned long size = skb_frag_size(&skb_shinfo(skb)->frags[i]);
>> + unsigned long offset = skb_shinfo(skb)->frags[i].page_offset;
>>
>> - if (offset == PAGE_SIZE)
>> - offset = 0;
>> - }
>> + count += xen_netbk_count_frag_slots(vif, offset, size, &state);
>> }
>> return count;
>> }
>> --
>> 1.7.2.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] tg3: Don't turn off led on 5719 serdes port 0
From: David Miller @ 2013-09-04 2:24 UTC (permalink / raw)
To: nsujir; +Cc: netdev, mchan
In-Reply-To: <1377907296-25737-1-git-send-email-nsujir@broadcom.com>
From: "Nithin Nayak Sujir" <nsujir@broadcom.com>
Date: Fri, 30 Aug 2013 17:01:36 -0700
> From: Nithin Sujir <nsujir@broadcom.com>
>
> Turning off led on port 0 of the 5719 serdes causes all other ports to
> lose power and stop functioning. Add tg3_phy_led_bug() function to check
> for this condition. We use a switch() in tg3_phy_led_bug() for
> consistency with the tg3_phy_power_bug() function.
>
> Signed-off-by: Nithin Nayak Sujir <nsujir@broadcom.com>
> Signed-off-by: Michael Chan <mchan@broadcom.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v3 01/11] net: calxedaxgmac: remove NETIF_F_FRAGLIST setting
From: David Miller @ 2013-09-04 2:22 UTC (permalink / raw)
To: robherring2; +Cc: netdev, bhutchings, buytenh, rob.herring
In-Reply-To: <1377899369-23252-1-git-send-email-robherring2@gmail.com>
Series applied, thanks.
In the future, when you send more than one patch at a time, always provide
an initial "[PATCH 00/NN] " posting which gives a top-level overview
description of your patch series and what it achieves.
You can look at what other developers do on this list for examples.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] be2net: set and query VEB/VEPA mode of the PF interface
From: David Miller @ 2013-09-04 2:20 UTC (permalink / raw)
To: ajit.khaparde; +Cc: netdev
In-Reply-To: <20130830200116.GA6311@emulex.com>
From: Ajit Khaparde <ajit.khaparde@emulex.com>
Date: Fri, 30 Aug 2013 15:01:16 -0500
> SkyHawk-R can support VEB or VEPA mode.
> This patch will allow the user to set/query this switch setting.
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: fix comment typo for __skb_alloc_pages()
From: David Miller @ 2013-09-04 2:17 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev
In-Reply-To: <1377873374-11350-1-git-send-email-f.fainelli@gmail.com>
From: "Florian Fainelli" <f.fainelli@gmail.com>
Date: Fri, 30 Aug 2013 15:36:14 +0100
> The name of the function in the comment is __skb_alloc_page() while we
> are actually commenting __skb_alloc_pages(). Fix this typo and make it
> a valid kernel doc comment.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv6: ipv6_create_tempaddr cleanup
From: David Miller @ 2013-09-04 2:17 UTC (permalink / raw)
To: pholasek; +Cc: hannes, netdev, linux-kernel
In-Reply-To: <1377874958-2426-1-git-send-email-pholasek@redhat.com>
From: Petr Holasek <pholasek@redhat.com>
Date: Fri, 30 Aug 2013 17:02:38 +0200
> This two-liner removes max_addresses variable which is now unecessary related
> to patch [ipv6: remove max_addresses check from ipv6_create_tempaddr].
>
> Signed-off-by: Petr Holasek <pholasek@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH][net-next] gianfar: Fix reported number of sent bytes to BQL
From: David Miller @ 2013-09-04 2:14 UTC (permalink / raw)
To: claudiu.manoil; +Cc: netdev, eric.dumazet
In-Reply-To: <1377864075-19491-1-git-send-email-claudiu.manoil@freescale.com>
From: Claudiu Manoil <claudiu.manoil@freescale.com>
Date: Fri, 30 Aug 2013 15:01:15 +0300
> Fix the amount of sent bytes reported to BQL by reporting the
> number of bytes on wire in the xmit routine, and recording that
> value for each skb in order to be correctly confirmed on Tx
> confirmation cleanup.
>
> Reporting skb->len to BQL just before exiting xmit is not correct
> due to possible insertions of TOE block and alignment bytes in the
> skb->data, which are being stripped off by the controller before
> transmission on wire. This led to mismatch of (incorrectly)
> reported bytes to BQL b/w xmit and Tx confirmation, resulting in
> Tx timeout firing, for the h/w tx timestamping acceleration case.
>
> There's no easy way to obtain the number of bytes on wire in the Tx
> confirmation routine, so skb->cb is used to convey that information
> from xmit to Tx confirmation, for now (as proposed by Eric). Revived
> the currently unused GFAR_CB() construct for that purpose.
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Applied.
^ permalink raw reply
* Re: ICMPv6: treat dest unreachable codes 5 and 6 as EACCES, not EPROTO
From: David Miller @ 2013-09-04 2:12 UTC (permalink / raw)
To: jbohac; +Cc: yoshfuji, netdev
In-Reply-To: <20130830091844.GA2706@midget.suse.cz>
From: Jiri Bohac <jbohac@suse.cz>
Date: Fri, 30 Aug 2013 11:18:45 +0200
> RFC 4443 has defined two additional codes for ICMPv6 type 1 (destination
> unreachable) messages:
> 5 - Source address failed ingress/egress policy
> 6 - Reject route to destination
>
> Now they are treated as protocol error and icmpv6_err_convert() converts them
> to EPROTO.
>
> RFC 4443 says:
> "Codes 5 and 6 are more informative subsets of code 1."
>
> Treat codes 5 and 6 as code 1 (EACCES)
>
> Btw, connect() returning -EPROTO confuses firefox, so that fallback to
> other/IPv4 addresses does not work:
> https://bugzilla.mozilla.org/show_bug.cgi?id=910773
>
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] netconsole: avoid a crash with multiple sysfs writers
From: David Miller @ 2013-09-04 2:11 UTC (permalink / raw)
To: alonid; +Cc: linux-kernel, netdev, nhorman
In-Reply-To: <1377860386-8494-1-git-send-email-alonid@postram.com>
From: Dan Aloni <alonid@postram.com>
Date: Fri, 30 Aug 2013 13:59:46 +0300
> When my 'ifup eth' script was fired multiple times and ran concurrent on
> my laptop, for some obscure /etc scripting reason, it was revealed
> that the store_enabled() function in netconsole doesn't handle it nicely,
> as recorded by the Oops below (a syslog paste, but not mangled too much
> to prevent from discerning the traceback).
>
> On Linux 3.10.4, this patch seeks to remedy the problem, and it has been
> running stable on my laptop for a few days.
...
> Signed-off-by: Dan Aloni <alonid@postram.com>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] sh_eth Updates
From: David Miller @ 2013-09-04 2:02 UTC (permalink / raw)
To: horms+renesas
Cc: netdev, linux-sh, magnus.damm, sergei.shtylyov, kouei.abe.cp
In-Reply-To: <1377834068-6978-1-git-send-email-horms+renesas@verge.net.au>
From: Simon Horman <horms+renesas@verge.net.au>
Date: Fri, 30 Aug 2013 12:41:06 +0900
> please consider the following updates to the sh_eth driver
> by Abe-san. They were developed during his testing of the
> driver on the r8a7790/lager board.
>
> Changes between v1 and v2:
Both applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] bonding: clean rlb vlan use
From: David Miller @ 2013-09-04 2:02 UTC (permalink / raw)
To: vfalico; +Cc: netdev, fubar, andy
In-Reply-To: <1377812337-19551-1-git-send-email-vfalico@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Thu, 29 Aug 2013 23:38:55 +0200
> Finish the vlan cleanup, only rlb left.
>
> Remove the bond_vlan_used() function, it's useless anyway, and
> rlb_client_info->tag, cause we can use only ->vlan_id.
>
> CC: Jay Vosburgh <fubar@us.ibm.com>
> CC: Andy Gospodarek <andy@greyhouse.net>
> Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] r8169: add ethtool eeprom change/dump feature
From: David Miller @ 2013-09-04 1:59 UTC (permalink / raw)
To: lekensteyn; +Cc: netdev, romieu, hayeswang, bhutchings
In-Reply-To: <1377787491-2932-1-git-send-email-lekensteyn@gmail.com>
From: Peter Wu <lekensteyn@gmail.com>
Date: Thu, 29 Aug 2013 16:44:51 +0200
> This adds the ability to read and change EEPROM for 93C46/93C56 serial
> EEPROM. Two-Wire serial interface and SPI are not supported. (Do not
> even try this for SPI or other chips, it may break your hardware.)
Please block the operation on configurations, such as the aforementioned
SPI, where it won't work.
^ permalink raw reply
* Re: pull-request: can-next 2013-08-29
From: David Miller @ 2013-09-04 1:56 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <5224E1A2.1010302@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 02 Sep 2013 21:06:10 +0200
> Hello David,
>
> On 08/29/2013 11:13 PM, Marc Kleine-Budde wrote:
>> this is a pull request for net-next. There are two patches from Gerhard
>> Sittig, which improves the clock handling on mpc5121. Oliver Hartkopp
>> provides a patch that adds a per rule limitation of frame hops.
>
> have you forgotten this pull request?
If you actually checked the patchwork queue, you're see that this pull
request was still "under review" and there are people who have been
waiting much longer than you have.
I just pulled this in and will push it out once my build tests complete.
There is no reason for you to ever ask me the above question unless
your pull request doesn't show up in patchwork in an appropriate
state. By default assume I am backlogged and I will get to it
whenever time and my resources allow.
^ permalink raw reply
* Re: [PATCH v2 0/8] Drop support for Renesas H8/300 architecture
From: Chen Gang F T @ 2013-09-04 1:53 UTC (permalink / raw)
To: Guenter Roeck
Cc: Al Viro, linux-kernel, linux-ide, netdev, linux-watchdog,
Wim Van Sebroeck, David S. Miller, Yoshinori Sato,
Geert Uytterhoeven, Eric Paris, Greg Kroah-Hartman, Jiang Liu,
David Howells, Thomas Gleixner, Stephen Rothwell, Linus Torvalds,
Andrew Morton, Rusty Russell, Linus Walleij
In-Reply-To: <20130903205922.GA3372@roeck-us.net>
Thank you for your valuable information: it will let kernel waste mails
less, and also can save my time resources.
On 09/04/2013 04:59 AM, Guenter Roeck wrote:
> On Tue, Sep 03, 2013 at 08:39:38PM +0100, Al Viro wrote:
>> On Tue, Sep 03, 2013 at 11:52:17AM +0800, Chen Gang F T wrote:
>>
>>> extreme sample: let 'kernel code style' and 'gcc code style' in one file, that will make the code very ugly.
>>
>> gcc style will make any code very ugly, no matter what (if anything) else is
>> in the same file...
>>
Hmm... for me, I don't check/judge the 'coding style' of different
products, what I focus on is to follow the original product 'coding
style'.
e.g. Windows, gcc, Linux kernel, their 'coding styles' are quite different with each other.
Originally I worked under Windows, I followed Windows coding style.
Now I worked under Linux kernel, I follow Linux kernel coding style.
I plan to make patch for gcc, I will follow gcc coding style.
(hope this month I can, but I am not sure, I have no experience for gcc development).
And excuse me, I will be silent during 2013-09-05 - 2013-09-20 (but can
response mail). During these days, I will focus on gcc issues (wish can
fix one), and also do some company's internal things.
Thanks.
>> [digs out the ports history table]
>> x86: 0.01 [alive]
>> i386: 0.01..2.6.24-rc1 [folded into x86]
>> x86_64: 2.5.5-pre1..2.6.24-rc1 [folded into x86]
>> x86: 2.6.24-rc1 [alive]
>> alpha: 1.1.67 [alive]
>> sparc: 1.1.77 [alive]
>> sparc64: 2.1.19..2.6.28 [folded into sparc]
>> mips: 1.1.82 [alive]
>> mips64: 2.3.48-pre2..2.6.0-test2 [folded into mips]
>> powerpc: 1.3.45 [alive]
>> ppc: 1.3.45..2.6.26 [folded into powerpc]
>> ppc64: 2.5.5..2.6.15-rc1 [folded into powerpc]
>> powerpc: 2.6.15-rc1 [alive]
>> m68k: 1.3.94 [alive]
>> m68knommu: 2.5.46..2.6.38 [folded into m68k]
>> arm: 2.1.80 [alive]
>> arm26: 2.5.71..2.6.23-rc2 [gone]
>> arm64: 3.7-rc1 [alive][might eventually fold]
>> sh: 2.3.16 [alive]
>> sh64: 2.6.8-rc1..2.6.24 [folded into sh, nearly dead there]
>> ia64: 2.3.43-pre1 [alive]
>> s390: 2.3.99pre8 [alive]
>> s390x: 2.5.0..2.5.67 [folded into s390]
>> parisc: 2.4.0-test12 [alive]
>> cris: 2.5.0 [alive]
>> um: 2.5.35 [alive]
>> v850: 2.5.46..2.6.26 [gone]
>> h8300: 2.5.68 [moderately responsive]
>> m32r: 2.6.9-rc3 [alive]
>> frv: 2.6.11-rc1 [alive]
>> xtensa: 2.6.13-rc1 [alive]
>> avr32: 2.6.19-rc1 [alive]
>> blackfin: 2.6.22-rc1 [alive]
>> mn10300: 2.6.25-rc1 [alive]
>> microblaze: 2.6.30-rc2 [alive]
>> score: 2.6.32-rc1 [abandoned][cloned off mips]
>> tile: 2.6.36-rc1 [alive]
>> unicore32: 2.6.39-rc1 [alive][cloned off arm]
>> openrisc: 3.1-rc1 [alive]
>> hexagon: 3.2-rc1 [alive]
>> c6x: 3.3-rc1 [alive]
>> arc: 3.9-rc1 [alive]
>> metag: 3.9-rc1 [alive]
>>
>> Frankly, I would've expected score and lefotvers of sh64 (aka sh5) to be
>> the first against the wall - h8300 was a bit surprising...
>>
>
> Great summary.
>
> There seemed to be a consensus to remove h8300, at least so far and sufficiently
> enough for me to ask Stephen to add the removal branch to linux-next.
> We'll see if that triggers any further responses.
>
> With score, I am not entirely sure. I got one Ack for the removal, but
> on the other side the score maintainers came back and claimed they would
> still support it. We'll see if anything changes in practice. I am still
> not sure if I should ask for the removal branch to be added to linux-next.
> Frankly I thought I might jump the gun here more than with h8300.
>
> Either case, what to ultimately do with those two architectures will be
> up to the community to decide.
>
> Guenter
>
Thanks again.
--
Chen Gang
^ permalink raw reply
* Re: pull request: wireless-next 2013-08-29
From: David Miller @ 2013-09-04 1:46 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20130829185352.GB2300@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 29 Aug 2013 14:53:53 -0400
> Please accept this batch of updates intended for the 3.12 stream.
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH net-next] net: sctp: probe: allow more advanced ingress filtering by mark
From: David Miller @ 2013-09-04 1:44 UTC (permalink / raw)
To: nhorman; +Cc: dborkman, netdev, linux-sctp
In-Reply-To: <20130830113630.GB1142@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 30 Aug 2013 07:36:30 -0400
> On Thu, Aug 29, 2013 at 06:54:49PM +0200, Daniel Borkmann wrote:
>> This is a follow-up commit for commit b1dcdc68b1f4 ("net: tcp_probe:
>> allow more advanced ingress filtering by mark") that allows for
>> advanced SCTP probe module filtering based on skb mark (for a more
>> detailed description and advantages using mark, refer to b1dcdc68b1f4).
>> The current option to filter by a given port is still being preserved.
>>
>> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2] net: neighbour: Remove CONFIG_ARPD
From: David Miller @ 2013-09-04 1:42 UTC (permalink / raw)
To: tim.gardner
Cc: netdev, linux-kernel, kuznet, jmorris, yoshfuji, kaber, ebiederm,
gaofeng, joe, vfalico
In-Reply-To: <1377779927-28500-1-git-send-email-tim.gardner@canonical.com>
From: Tim Gardner <tim.gardner@canonical.com>
Date: Thu, 29 Aug 2013 06:38:47 -0600
> This config option is superfluous in that it only guards a call
> to neigh_app_ns(). Enabling CONFIG_ARPD by default has no
> change in behavior. There will now be call to __neigh_notify()
> for each ARP resolution, which has no impact unless there is a
> user space daemon waiting to receive the notification, i.e.,
> the case for which CONFIG_ARPD was designed anyways.
>
> Suggested-by: Eric W. Biederman <ebiederm@xmission.com>
...
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/9] set addr_assign_type when inheriting a dev_addr
From: David Miller @ 2013-09-04 1:41 UTC (permalink / raw)
To: bjorn
Cc: devel, jiri, libertas-dev, j, netdev, linux-wireless, linville,
stephen, forest, gregkh, kaber, dan.carpenter
In-Reply-To: <87mwnuqrrx.fsf@nemi.mork.no>
From: Bjørn Mork <bjorn@mork.no>
Date: Tue, 03 Sep 2013 09:38:10 +0200
> But it doesn't look like it ended up in net-next? Or am I missing
> something (again)?
I forgot to push it out from my workstation before going away for the
holiday weekend, this has now been fixed :-)
^ permalink raw reply
* RE: [E1000-devel] [PATCH 0/4] i40e: Neatening and object size reductions
From: Nelson, Shannon @ 2013-09-04 1:38 UTC (permalink / raw)
To: Joe Perches
Cc: Kirsher, Jeffrey T, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1378258258.7347.48.camel@joe-AO722>
> -----Original Message-----
> From: Joe Perches [mailto:joe@perches.com]
> Sent: Tuesday, September 03, 2013 6:31 PM
>
> On Wed, 2013-09-04 at 01:00 +0000, Nelson, Shannon wrote:
>
> Hi Shannon.
>
> > > -----Original Message----- > From: Joe Perches
> > [mailto:joe@perches.com] > Sent: Friday, August 30, 2013 4:06 PM > >
> > Just some potential cleanings...
> >
> > > i40e: Whitespace cleaning
> >
> > Hmmm, we hadn't noticed the new experimental "--fix" option before.
> > There are a lot of good suggestions there, but obviously it needs a
> lot
> > of reading and tweaking before it can be used. There are cases here
> > where function call parameters are adjusted to line up with the
> opening
> > '(' but that pushes the parameter(s) beyond 80 columns - we're trying
> > to stay within the 80 column line and checkpatch clean. Also, there
> > are several where the first continued parameter line indent is changed
> > but the next line or two are not.
> >
> > We'll spend time going through these and try to take care of what
> makes
> > sense.
>
> Swell. All these are your choice to fix as you want.
>
> Exceeding 80 columns doesn't bother me much.
We should perhaps become a little more flexible ourselves, but we've finally got a good process going internally, including this as a check. I don't dare disturb the machine now that it is working :-).
> Keeping alignment appropriate for multi-line statements
> needs work inside checkpatch. I played with it a bit
> but it's unfortunately complicated by intermixed
> insertions and deletions.
Yeah, it all gets a little funky after a while.
>
> > > i40e: Add and use pf_<level>
> >
> > We had considered this kind of macro awhile ago, but nixed it for a
> few
> > different reasons, but primarily because it seems like
> > yet-another-print-macro and not necessarily worth the effort.
> >
> > > i40e: pf_<level> remove "%s: " ... __func__
> >
> > We're beginning to remove many of the __func__ uses, so these prints
> > are no longer all doing the __func__ thing. We originally had them
> > there for early development and debugging and are currently removing
> > them from the normal path messages.
>
> Fine by me. I think __func__ is nearly always pretty
> useless myself.
It was useful for a while, but it is time to be pulling it out.
>
> > > i40e: Convert pf_<level> macros to functions
> >
> > Doesn't this create a problem with polluting the kernel namespace?
> > These don't apply to any other driver. I suppose we could lessen the
> > namespace problem with i40e_ prefix, but I'm still not sold on it. I
> > suspect we can still get much of the text savings replacing the
> > __func__ with __builtin_return_address(0) where needed, and remove
> them
> > where no longer needed. Does that work for you?
>
> I think you could just as soon whatever combinations of the
> other standard logging mechanisms without using pf_<level>
>
> wiphy_<level>
> netif_<level>
> netdev_<level>
> dev_<level>
> pr_<level>
>
> as appropriate. I did that only because there was ~10K
> of what I think of as not too useful function names out
> of a defconfig size of 140k.
Yes, and I think removing much of the __func__ or using __builtin_return_address(0) will help.
>
> > > i40e: Fix 32 bit shift compilation warnings
> >
> > Sure.
>
> I think you should use the kernel.h standard macros
> for lower_32_bits and upper_32_bits instead.
Yep.
>
> cheers, Joe
^ permalink raw reply
* Re: [net-next v3 1/8] i40e: main driver core
From: Joe Perches @ 2013-09-04 1:35 UTC (permalink / raw)
To: Nelson, Shannon
Cc: Kirsher, Jeffrey T, davem@davemloft.net, Brandeburg, Jesse,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
Waskiewicz Jr, Peter P, e1000-devel@lists.sourceforge.net
In-Reply-To: <FC41C24E35F18A40888AACA1A36F3E416C61C0CE@FMSMSX102.amr.corp.intel.com>
On Wed, 2013-09-04 at 00:59 +0000, Nelson, Shannon wrote:
> > -----Original Message-----
> > From: Joe Perches [mailto:joe@perches.com]
[]
> Hi Joe,
Hi again.
> > > +/**
> > > + * i40e_get_netdev_stats_struct - Get statistics for netdev interface
> > > + * @netdev: network interface device structure
> > > + *
> > > + * Returns the address of the device statistics structure.
> > > + * The statistics are actually updated from the service task.
> > > + **/
> > > +static struct rtnl_link_stats64 *i40e_get_netdev_stats_struct(
> > > + struct net_device *netdev,
> > > + struct rtnl_link_stats64 *storage)
> >
> > An alternative bsd declaration style might be
> > more readable for these very long types and names.
> >
> > static struct rtnl_link_stats64 *
> > i40e_get_netdev_stats_struct(struct net_device *netdev,
> > struct rtnl_link_stats64 *storage)
>
> We're trying to stay consistent in kernel function styles, stay within
> standard checkpatch restrictions, and keep the code readable and
> maintainable, which all together make for some difficult choices. No
> matter which way we go on some of these decisions, we run into the
> painfully gray opinion areas of how someone else might have solved the
> problems.
No worries. Whatever you choose to do will be OK.
The BSD declaration style is pretty common in the
kernel tree too though.
Another thing would be to mark various arguments const struct
in the prototypes and declarations instead of just struct.
cheers, Joe
^ permalink raw reply
* Re: [E1000-devel] [PATCH 0/4] i40e: Neatening and object size reductions
From: Joe Perches @ 2013-09-04 1:30 UTC (permalink / raw)
To: Nelson, Shannon
Cc: Kirsher, Jeffrey T, e1000-devel@lists.sourceforge.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <FC41C24E35F18A40888AACA1A36F3E416C61C0E5@FMSMSX102.amr.corp.intel.com>
On Wed, 2013-09-04 at 01:00 +0000, Nelson, Shannon wrote:
Hi Shannon.
> > -----Original Message----- > From: Joe Perches
> [mailto:joe@perches.com] > Sent: Friday, August 30, 2013 4:06 PM > >
> Just some potential cleanings...
>
> > i40e: Whitespace cleaning
>
> Hmmm, we hadn't noticed the new experimental "--fix" option before.
> There are a lot of good suggestions there, but obviously it needs a lot
> of reading and tweaking before it can be used. There are cases here
> where function call parameters are adjusted to line up with the opening
> '(' but that pushes the parameter(s) beyond 80 columns - we're trying
> to stay within the 80 column line and checkpatch clean. Also, there
> are several where the first continued parameter line indent is changed
> but the next line or two are not.
>
> We'll spend time going through these and try to take care of what makes
> sense.
Swell. All these are your choice to fix as you want.
Exceeding 80 columns doesn't bother me much.
Keeping alignment appropriate for multi-line statements
needs work inside checkpatch. I played with it a bit
but it's unfortunately complicated by intermixed
insertions and deletions.
> > i40e: Add and use pf_<level>
>
> We had considered this kind of macro awhile ago, but nixed it for a few
> different reasons, but primarily because it seems like
> yet-another-print-macro and not necessarily worth the effort.
>
> > i40e: pf_<level> remove "%s: " ... __func__
>
> We're beginning to remove many of the __func__ uses, so these prints
> are no longer all doing the __func__ thing. We originally had them
> there for early development and debugging and are currently removing
> them from the normal path messages.
Fine by me. I think __func__ is nearly always pretty
useless myself.
> > i40e: Convert pf_<level> macros to functions
>
> Doesn't this create a problem with polluting the kernel namespace?
> These don't apply to any other driver. I suppose we could lessen the
> namespace problem with i40e_ prefix, but I'm still not sold on it. I
> suspect we can still get much of the text savings replacing the
> __func__ with __builtin_return_address(0) where needed, and remove them
> where no longer needed. Does that work for you?
I think you could just as soon whatever combinations of the
other standard logging mechanisms without using pf_<level>
wiphy_<level>
netif_<level>
netdev_<level>
dev_<level>
pr_<level>
as appropriate. I did that only because there was ~10K
of what I think of as not too useful function names out
of a defconfig size of 140k.
> > i40e: Fix 32 bit shift compilation warnings
>
> Sure.
I think you should use the kernel.h standard macros
for lower_32_bits and upper_32_bits instead.
cheers, Joe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox