| Age | Commit message (Collapse) | Author |
|---|
|
drivers/net/tulip/uli526x.c: In function `__check_mode':
drivers/net/tulip/uli526x.c:1693: warning: return from incompatible pointer type
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
|
Replace the MODULE_PARM usage in uli526x.c with module_param.
Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
|
A BIOS bug affecting some multiport tulip NICs requires an irq fixup
in tulip_core.c. This has only been enabled for i686, but it is
needed for x86_64 as well.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
|
|
|
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
drivers/net/tulip/de2104x.c | 5 +++++
1 files changed, 5 insertions(+)
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
|
The patch below is necessary to allow my Digital DS21143 Tulip rev 48
ethernet interface to work in a 10Mbit Half Duplex network. Without
it, the driver keeps retrying other modes in an endless loop. It seems
like someone already had the same problem with a rev 65 board :)
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
|
xircom_cb.c does #if CONFIG_NET_POLL_CONTROLLER instead of #ifdef,
resulting in drivers/net/tulip/xircom_cb.c:120:5: warning:
"CONFIG_NET_POLL_CONTROLLER" is not defined.
Signed-off-by: Keith Owens <kaos@sgi.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
|
s/for/list_for_each/
Signed-off-by: Maximilian Attems <janitor@sternwelten.at>
Signed-off-by: Domen Puncer <domen@coderock.org>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
added missing include of dma-mapping.h, removed bogus ptrace.h (what the
hell was it doing there, in the first place?)
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
|
BZ# 4475.
|
|
Noted in BZ# 2960.
|
|
- s/DEVICE/net_device/
- improve formatting
- remove dead code
- check return value, in several areas
|
|
It has a separate driver now, 'uli526x'.
|
|
We want to extract our LAN card driver from tulip core driver and
make a new file uli526x.c at tulip folder, because we have added
some ethtool interface support and non-eprom support in our driver
and may be other change in the futher.
If our controllers support are still contained in the tulip core
driver, I think it'll increase the complexity of maintenance, you
know, tulip core driver include several files and support so many
other controllers. Furthermore, I tested the newest kernel 2.6.12
and I found the tulip driver can not work on our lan controller, and
I no time to debug it, so I aspired want to make a single uli526x.c
file just for our controllers. Could you help us remove the ULi
m5261/m5263 lan controller support from tulip core driver and add
the new single uli526x.c file for us?
Signed-off-by: Peer Chen <Peer.Chen@uli.com.tw>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
|
Many drivers use skb->tail unnecessarily.
In these situations, the code roughly looks like:
dev = dev_alloc_skb(...);
[optional] skb_reserve(skb, ...);
... skb->tail ...
But even if the skb_reserve() happens, skb->data equals
skb->tail. So it doesn't make any sense to use anything
other than skb->data in these cases.
Another case was the s2io.c driver directly mucking with
the skb->data and skb->tail pointers. It really just wanted
to do an skb_reserve(), so that's what the code was changed
to do instead.
Another reason I'm making this change as it allows some SKB
cleanups I have planned simpler to merge. In those cleanups,
skb->head, skb->tail, and skb->end pointers are removed, and
replaced with skb->head_room and skb->tail_room integers.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Jeff Garzik <jgarzik@pobox.com>
|
|
This patch allows the tulip driver to suspend and resume properly. It was
originally written by Karsten Keil and then modified by Adam Belay.
Signed-off-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: Adam Belay <abelay@novell.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
|
|
|
|
drivers/net/tulip/dmfe.c: In function `dmfe_parse_srom':
drivers/net/tulip/dmfe.c:1805: warning: passing arg 1 of `__le16_to_cpup' from incompatible pointer type
drivers/net/tulip/dmfe.c:1817: warning: passing arg 1 of `__le32_to_cpup' from incompatible pointer type
drivers/net/tulip/dmfe.c:1817: warning: passing arg 1 of `__le32_to_cpup' from incompatible pointer type
This is basically a guess:
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
|
|
|
|
|
|
The 'if' clause for ULI526X in tulip_mdio_write allows for
spin_unlock_irqrestore to be called twice for tp->mii_lock. I believe
this is caused by the unintentional omission of a return at the end
of that clause. This patch adds that return.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch fixes a typo in tulip driver in 2.6.12-rc3.
|
|
This patch removes a NULL check that was useles because it happened
after the first dereference of the variable.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
|
The previous patch did not compile cleanly on all architectures so
here's a fixed one.
Use the DMA_32BIT_MASK constant from dma-mapping.h when calling
pci_set_dma_mask() or pci_set_consistent_dma_mask()
Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
|
The previous patch did not compile cleanly on all architectures so
here's a fixed one.
Use the DMA_32BIT_MASK constant from dma-mapping.h when calling
pci_set_dma_mask() or pci_set_consistent_dma_mask()
Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
|
This fixes remaining u32s in drivers/ net.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
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!
|
