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