linux-dev - Linux kernel development work

Age	Commit message (Collapse)	Author	Files	Lines
2007-10-10	[NET]: Introduce and use print_mac() and DECLARE_MAC_BUF()	Joe Perches	1	-3/+5
	This is nicer than the MAC_FMT stuff. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-10-10	[NET]: Nuke SET_MODULE_OWNER macro.	Ralf Baechle	1	-1/+0
	It's been a useless no-op for long enough in 2.6 so I figured it's time to remove it. The number of people that could object because they're maintaining unified 2.4 and 2.6 drivers is probably rather small. [ Handled drivers added by netdev tree and some missed IRDA cases... -DaveM ] Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-02-09	[PATCH] kill eth_io_copy_and_sum()	Al Viro	1	-2/+1
	On all targets that sucker boils down to memcpy_fromio(sbk->data, from, len). The function name is highly misguiding (it _never_ does any checksums), the last argument is just a noise and simply expanding the call to memcpy_fromio() gives shorter and more readable source. For a lot of reasons it has almost no remaining users, so it's better to just outright kill it. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2006-09-13	drivers/net: Trim trailing whitespace	Jeff Garzik	1	-5/+5
	Signed-off-by: Jeff Garzik <jeff@garzik.org>
2005-05-12	[PATCH] drivers/net/smc-mca.c: cleanups	Adrian Bunk	1	-2/+58
	This patch contains the following cleanups: - make a needlessly global function static - make three needlessly global structs static const Since after moving the now-static stucts to smc-mca.c the file smc-mca.h was empty except for two #define's, I've also killed the rest of smc-mca.h . Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-04-16	Linux-2.6.12-rc2	Linus Torvalds	1	-0/+508
	Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!