06 Sep, 2005
1 commit
-
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
Signed-off-by: Jeff Garzik
31 Aug, 2005
2 commits
-
BZ# 4475.
-
Noted in BZ# 2960.
20 Aug, 2005
1 commit
-
- s/DEVICE/net_device/
- improve formatting
- remove dead code
- check return value, in several areas
12 Aug, 2005
1 commit
-
It has a separate driver now, 'uli526x'.
30 Jul, 2005
1 commit
-
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
Signed-off-by: Jeff Garzik
29 Jun, 2005
1 commit
-
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
Acked-by: Jeff Garzik
27 Jun, 2005
5 commits
-
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
Signed-off-by: Adam Belay
Signed-off-by: Andrew Morton -
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 typeThis is basically a guess:
Cc: Jeff Garzik
Signed-off-by: Andrew Morton
24 May, 2005
1 commit
-
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
16 May, 2005
1 commit
-
This patch fixes a typo in tulip driver in 2.6.12-rc3.
13 May, 2005
3 commits
-
This patch removes a NULL check that was useles because it happened
after the first dereference of the variable.Signed-off-by: Adrian Bunk
Signed-off-by: Jeff Garzik -
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
Signed-off-by: Jeff Garzik -
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
Signed-off-by: Jeff Garzik
17 Apr, 2005
2 commits
-
This fixes remaining u32s in drivers/ net.
Signed-off-by: Pavel Machek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
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!
