Largely there are healthy chunks of driver bug fixes and sparse
warning cures here. But, otherwise:
1) TCP splice receive non-block semantic cures from Lennert Buytenhek.
2) GRO enhancements from Herbert Xu.
3) IPV6 routing cache entry creation needs to run a quick
garbage collection when the neighbour table overflows,
otherwise we'll fail unnecessarily and give bogus
-EINVAL errors to sendmsg() calls when sending to multicast
groups.
4) U32 packet classifier locking fix from Jarek Poplawski.
5) Some of the remaining net driver firmware conversions.
Other than these the e100 is the only one pending with
a patch that I am aware of, and Intel folks are testing
that one out before I apply it.
Please pull, thanks a lot!
The following changes since commit fe0bdec68b77020281dc814805edfe594ae89e0f:
Linus Torvalds (1):
Merge branch 'audit.b61' of git://git.kernel.org/.../viro/audit-current
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Baruch Siach (1):
enc28j60: fix RX buffer overflow
Brice Goglin (1):
myri10ge: print MAC and serial number on probe failure
Bruce Allan (1):
e100: cosmetic cleanup
David S. Miller (4):
ipv6: Fix sporadic sendmsg -EINVAL when sending to multicast groups.
tcp: Kill extraneous SPLICE_F_NONBLOCK checks.
Revert "net: Fix for initial link state in 2.6.28"
Frank Blaschka (1):
qeth: do not spin for SETIP ip assist command
Gerrit Renker (4):
tun: Eliminate sparse signedness warning
dccp: Lockless integration of CCID congestion-control plugins
dccp: Clean up ccid.c after integration of CCID plugins
dccp: Integrate the TFRC library with DCCP
Heiko Carstens (2):
qeth: get rid of extra argument after printk to dev_* conversion
iucv: fix cpu hotplug
Hendrik Brueckner (2):
af_iucv: New error return codes for connect()
af_iucv: Free iucv path/socket in path_pending callback
Herbert Xu (2):
gro: Use gso_size to store MSS
gro: Add page frag support
Ilpo J?rvinen (1):
ipv6: IPV6_PKTINFO relied userspace providing correct length
Jarek Poplawski (1):
pkt_sched: cls_u32: Fix locking in u32_change()
Jaswinder Singh (1):
firmware: convert acenic driver to request_firmware()
Jaswinder Singh Rajput (2):
firmware: convert tg3 driver to request_firmware()
starfire: use request_firmware()
Klaus-Dieter Wacker (2):
qeth: HiperSockets mcl string conversion (pre z9 mach)
qeth: No large send using EDDP for HiperSockets.
Lennert Buytenhek (1):
tcp: don't mask EOF and socket errors on nonblocking splice receive
Michael Marineau (1):
net: Fix for initial link state in 2.6.28
Oliver Hartkopp (1):
can: update can-bcm for hrtimer hardirq callbacks
Roel Kluin (2):
isdn: capi: &&/|| typos
DCB: fix kfree(skb)
Ron Mercer (10):
qlge: bugfix: Add missing pci_mapping_err checking.
qlge: bugfix: Add missing pci_unmap_page call in receive path.
qlge: bugfix: Fix shadow register endian issue.
qlge: bugfix: Fix ring length setting for rx ring, large/small
qlge: bugfix: Fix register access error checking.
qlge: Fix sparse warnings for byte swapping in qlge_ethool.c
qlge: Fix sparse endian warning for inbound packet control block flags.
qlge: Fix sparse endian warning in ql_hw_csum_setup().
qlge: Fix sparse warning regarding rx buffer queues.
qlge: Fix sparse warnings for tx ring indexes.
Simon Holm Th?gersen (1):
net/rfkill/rfkill.c: fix unused rfkill_led_trigger() warning
Stephen Rothwell (1):
net/ehea: bitops work on unsigned longs
Ursula Braun (3):
qeth: exploit source MAC address for inbound layer3 packets
qeth: avoid crash in case of layer mismatch for VSWITCH
af_iucv: avoid left over IUCV connections from failing connects
drivers/isdn/capi/capidrv.c | 4 +-
drivers/net/acenic.c | 117 +-
drivers/net/acenic.h | 4 +
drivers/net/e100.c | 268 +-
drivers/net/ehea/ehea.h | 3 +-
drivers/net/ehea/ehea_main.c | 2 +-
drivers/net/enc28j60.c | 4 +-
drivers/net/myri10ge/myri10ge.c | 6 +-
drivers/net/qlge/qlge.h | 57 +-
drivers/net/qlge/qlge_dbg.c | 13 +-
drivers/net/qlge/qlge_ethtool.c | 8 +-
drivers/net/qlge/qlge_main.c | 116 +-
drivers/net/starfire.c | 54 +-
drivers/net/starfire_firmware.h | 346 ---
drivers/net/starfire_firmware.pl | 31 -
drivers/net/tg3.c | 792 +-----
drivers/net/tg3.h | 4 +
drivers/net/tun.c | 2 +-
drivers/s390/net/qeth_core.h | 1 -
drivers/s390/net/qeth_core_main.c | 57 +-
drivers/s390/net/qeth_l2_main.c | 8 +-
drivers/s390/net/qeth_l3_main.c | 26 +-
firmware/Makefile | 11 +
firmware/WHENCE | 49 +
firmware/acenic/tg1.bin.ihex | 4573 +++++++++++++++++++++++++++++++
firmware/acenic/tg2.bin.ihex | 4844 +++++++++++++++++++++++++++++++++
firmware/adaptec/starfire_rx.bin.ihex | 53 +
firmware/adaptec/starfire_tx.bin.ihex | 53 +
firmware/tigon/tg3.bin.ihex | 175 ++
firmware/tigon/tg3_tso.bin.ihex | 446 +++
firmware/tigon/tg3_tso5.bin.ihex | 252 ++
include/linux/netdevice.h | 16 +-
include/net/ndisc.h | 4 +-
net/can/bcm.c | 208 +-
net/core/dev.c | 93 +-
net/core/skbuff.c | 15 +-
net/dcb/dcbnl.c | 14 +-
net/dccp/Kconfig | 4 -
net/dccp/Makefile | 15 +-
net/dccp/ackvec.h | 49 -
net/dccp/ccid.c | 254 +--
net/dccp/ccid.h | 14 +-
net/dccp/ccids/Kconfig | 79 +-
net/dccp/ccids/Makefile | 9 -
net/dccp/ccids/ccid2.c | 22 +-
net/dccp/ccids/ccid3.c | 23 +-
net/dccp/ccids/lib/Makefile | 3 -
net/dccp/ccids/lib/loss_interval.c | 3 -
net/dccp/ccids/lib/packet_history.c | 9 -
net/dccp/ccids/lib/tfrc.c | 19 +-
net/dccp/ccids/lib/tfrc.h | 11 +-
net/dccp/ccids/lib/tfrc_equation.c | 4 -
net/dccp/dccp.h | 2 -
net/dccp/feat.c | 6 +-
net/dccp/input.c | 2 -
net/dccp/proto.c | 7 +
net/ipv4/tcp.c | 9 +-
net/ipv6/ipv6_sockglue.c | 2 +-
net/ipv6/route.c | 52 +-
net/iucv/af_iucv.c | 28 +-
net/iucv/iucv.c | 18 +-
net/rfkill/rfkill.c | 4 +-
net/sched/cls_u32.c | 3 +-
63 files changed, 11470 insertions(+), 1910 deletions(-)
delete mode 100644 drivers/net/starfire_firmware.h
delete mode 100644 drivers/net/starfire_firmware.pl
create mode 100644 firmware/acenic/tg1.bin.ihex
create mode 100644 firmware/acenic/tg2.bin.ihex
create mode 100644 firmware/adaptec/starfire_rx.bin.ihex
create mode 100644 firmware/adaptec/starfire_tx.bin.ihex
create mode 100644 firmware/tigon/tg3.bin.ihex
create mode 100644 firmware/tigon/tg3_tso.bin.ihex
create mode 100644 firmware/tigon/tg3_tso5.bin.ihex
delete mode 100644 net/dccp/ccids/Makefile
delete mode 100644 net/dccp/ccids/lib/Makefile
On Mon, 5 Jan 2009, David Miller wrote:
>
> Jaswinder Singh (1):
> firmware: convert acenic driver to request_firmware()
Grr. But the old acenic_firmware.h file is left around. Which explains
this:
> 63 files changed, 11470 insertions(+), 1910 deletions(-)
Ugh. That looks absolutely horrible.
I pulled, but please take a look at your own diffstats and then ask
yourself if things really look like they should look. Because if you had
done that, you'd have noticed this.
Linus
From: Linus Torvalds <[email protected]>
Date: Mon, 5 Jan 2009 18:42:19 -0800 (PST)
> On Mon, 5 Jan 2009, David Miller wrote:
> >
> > Jaswinder Singh (1):
> > firmware: convert acenic driver to request_firmware()
>
> Grr. But the old acenic_firmware.h file is left around. Which explains
> this:
>
> > 63 files changed, 11470 insertions(+), 1910 deletions(-)
>
> Ugh. That looks absolutely horrible.
>
> I pulled, but please take a look at your own diffstats and then ask
> yourself if things really look like they should look. Because if you had
> done that, you'd have noticed this.
Sorry, I know how this happened even.
As an aside, is there a way to make git-am and other stuff using the
git patch applying engine to take patches liberally like 'patch'
would?
The default is extremely strict, which makes me check things out by
hand. That's good, but as I add the change by hand after verifying
it's sanity I often make mistakes that result in things like the above
missed delete, so if I could ask git to be non-strict it would help me
out a lot.
This doesn't excuse me from looking for bogons at my diffstats of
course :)
David Miller <[email protected]> writes:
>
> The default is extremely strict, which makes me check things out by
> hand. That's good, but as I add the change by hand after verifying
> it's sanity I often make mistakes that result in things like the above
> missed delete, so if I could ask git to be non-strict it would help me
> out a lot.
Sorry for the me too, but I would really love to have such a feature
too.
-Andi
--
[email protected]
On Mon, 5 Jan 2009, David Miller wrote:
>
> As an aside, is there a way to make git-am and other stuff using the
> git patch applying engine to take patches liberally like 'patch'
> would?
Well, "git apply" takes flags like "-C1" to accept fuzzy patches, and
--whitespace=fix etc to apply them despite whitespace differences etc.
And at least more modern versions of "git am" should take them and pass
them on. Although I'd generally not encourage that much. Partly because I
hate how often it has screwed up over the years thanks to GNU patch
accepting any random crud.
So out of that, if I personally have a patch that only applies with fuzz
and I know I still want to apply it, I just go and manually edit away the
parts that no longer match in the patch itself (and fix up the line
counts etc). But that's obviously me, and I'm very comfy editing patches
directly.
But another quite useful approach is to just try to apply the patch to the
version that it was done against - preferably in a separate branch - and
then just merging the end result.
> The default is extremely strict, which makes me check things out by
> hand. That's good, but as I add the change by hand after verifying
> it's sanity I often make mistakes that result in things like the above
> missed delete, so if I could ask git to be non-strict it would help me
> out a lot.
Yeah, I know, "git am" really is very strict, and sometimes annoyingly so.
But it _can_ be overridden. And if the other end uses git to generate the
patch, you can also do a three-way apply, which really tends to work. But
that requires that the patch have the SHA1 ID's of the original blobs (and
that you have those blobs - ie that the patch was really generated against
something you already had)
Linus
From: Linus Torvalds <[email protected]>
Date: Mon, 5 Jan 2009 20:37:58 -0800 (PST)
> > The default is extremely strict, which makes me check things out by
> > hand. That's good, but as I add the change by hand after verifying
> > it's sanity I often make mistakes that result in things like the above
> > missed delete, so if I could ask git to be non-strict it would help me
> > out a lot.
>
> Yeah, I know, "git am" really is very strict, and sometimes annoyingly so.
> But it _can_ be overridden. And if the other end uses git to generate the
> patch, you can also do a three-way apply, which really tends to work. But
> that requires that the patch have the SHA1 ID's of the original blobs (and
> that you have those blobs - ie that the patch was really generated against
> something you already had)
That wouldn't have helped me in this case at all.
I had 4 firmware patches to apply, each one had to add entries
to the same file.
The first patch had to be skipped.
So the second one, which is the first one I added (which is the acenic
bogon with the missed delete), is the one GIT wouldn't take but patch
would.
GIT blobs wouldn't give me any help here, but I suppose the fuzz stuff
might have.
I really just want stupid 'patch' behavior. I'll check the result
carefully, so just apply the thing instead of making me jump through
hoops. :-)
On Tue, Jan 6, 2009 at 10:19 AM, David Miller <[email protected]> wrote:
>
> I had 4 firmware patches to apply, each one had to add entries
> to the same file.
>
> The first patch had to be skipped.
>
In firmware we maintain WHENCE, so every time we add new firmware we
also update WHENCE.
We are facing problems while we prepare patch for firmware as we add
new stuff at the end.
As per David Woodhouse suggestion, I arranged WHENCE to alphabetical
order by driver name to avoid conflicts.
I also send patch on 21 Dec 2008 with ack of David Woodhouse to linus
and waiting from his side.
[PATCH] firmware: Arrange WHENCE in alphabetical order to avoid conflicts
I think this will resolve very soon, once we update WHENCE in
alphabetical order, If you better suggestions, please let me know.
Thanks,
--
JSR
On Tue, Jan 06, 2009 at 10:44:11AM +0530, Jaswinder Singh Rajput wrote:
> On Tue, Jan 6, 2009 at 10:19 AM, David Miller <[email protected]> wrote:
> >
> > I had 4 firmware patches to apply, each one had to add entries
> > to the same file.
> >
> > The first patch had to be skipped.
> >
>
> In firmware we maintain WHENCE, so every time we add new firmware we
> also update WHENCE.
>
> We are facing problems while we prepare patch for firmware as we add
> new stuff at the end.
> As per David Woodhouse suggestion, I arranged WHENCE to alphabetical
> order by driver name to avoid conflicts.
>
> I also send patch on 21 Dec 2008 with ack of David Woodhouse to linus
> and waiting from his side.
>
> [PATCH] firmware: Arrange WHENCE in alphabetical order to avoid conflicts
>
> I think this will resolve very soon, once we update WHENCE in
> alphabetical order, If you better suggestions, please let me know.
We should avoid a central file and push this information
out to the Kconfig files that are at the driver site.
Then we can postprocess autoconf.h to get the filenames etc.
And IMO it is wrong to stroe the firmware files far away
from the driver where they belong.
Sorting WHENCE is a good approach under the current ways
of doing it. But the current ways of doing it looks plain wrong to me.
Sam
From: Sam Ravnborg <[email protected]>
Date: Tue, 6 Jan 2009 06:51:44 +0100
> We should avoid a central file and push this information
> out to the Kconfig files that are at the driver site.
>
> Then we can postprocess autoconf.h to get the filenames etc.
I'll take this opportunity to once again promote my idea wherein build
information (and perhaps other bits like firmware info) for a driver
is encoded into the source of the driver itself, and the build system
just extracts that stuff into Makefiles and whatnot at build time. :-)
Couldn't resist.
David Miller <[email protected]> writes:
> That wouldn't have helped me in this case at all.
>
> I had 4 firmware patches to apply, each one had to add entries
> to the same file.
>
> The first patch had to be skipped.
>
> So the second one, which is the first one I added (which is the acenic
> bogon with the missed delete), is the one GIT wouldn't take but patch
> would.
What I typically do when I see myself in such a situation is to apply all
of four patches to a throw-away branch once, and then discard that branch
right away. Then I can apply only the good three patches, skipping the
first one, and "am -3" would still apply.
On Mon, Jan 05, 2009 at 10:07:42PM -0800, David Miller wrote:
> From: Sam Ravnborg <[email protected]>
> Date: Tue, 6 Jan 2009 06:51:44 +0100
>
> > We should avoid a central file and push this information
> > out to the Kconfig files that are at the driver site.
> >
> > Then we can postprocess autoconf.h to get the filenames etc.
>
> I'll take this opportunity to once again promote my idea wherein build
> information (and perhaps other bits like firmware info) for a driver
> is encoded into the source of the driver itself, and the build system
> just extracts that stuff into Makefiles and whatnot at build time. :-)
One of the pratical issues I have with this is when to read which files.
What we could do is something like:
- during *config scan all "wildcard enabled" directories
and read the Kconfig info from the relevant .C files.
- record which .C files which included Kconfig and do
an automatic "scan + oldconfig" when one of these files
changes
When we add new Kconfig info to a file we would have
to manually do the *config to trigger a scan for the .C files
In the .C file we should restrict us to the first 100 lines or so
to have the Kconfig info to speedd up the 'parse' for this info.
Something like this:
/* Kconfig
config FOO
tristate "A self contained driver"
depends on USB
source mydriver-debug.c if DEBUG
modulename foobar
help
This is a driver for ...
*/
The source file where this info is contained is implicit a source
of this module.
And if we can convince the firmware guys then the firmware info could
be included in the same section.
Sam
From: Sam Ravnborg <[email protected]>
Date: Tue, 6 Jan 2009 09:11:35 +0100
> One of the pratical issues I have with this is when to read which files.
>
> What we could do is something like:
>
> - during *config scan all "wildcard enabled" directories
> and read the Kconfig info from the relevant .C files.
> - record which .C files which included Kconfig and do
> an automatic "scan + oldconfig" when one of these files
> changes
>
> When we add new Kconfig info to a file we would have
> to manually do the *config to trigger a scan for the .C files
Yes, this is the only cheap way to do this.
Note, we are already scanning the full source files using a custom
tool to generate dependencies.... oh nevermind, we used to use a
custom tool, we seem to be just transforming gcc -MD output now.
Anyways, if we were still using that custom optimized parser we could
have put the Kconfig/Makefile info extracter in there.