Commit Graph

56 Commits

Author SHA1 Message Date
Domen Puncer
1e7f0bd8c8 drivers/net/: Use the DMA_{64,32}BIT_MASK constants
Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h when calling
pci_set_dma_mask() or pci_set_consistent_dma_mask()

This patch includes dma-mapping.h explicitly because it caused errors
on some architectures otherwise.

See http://marc.theaimsgroup.com/?t=108001993000001&r=1&w=2 for details

Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Domen Puncer <domen@coderock.org>
2005-06-26 18:22:14 -04:00
140fedb5f2 Automatic merge of /spare/repo/netdev-2.6 branch iff-running 2005-06-04 17:11:28 -04:00
James Harper
562faf469f [PATCH] fix PROMISC/bridging in TLAN driver
This has been a problem for me for ages.  When using bridging, the driver
is switched into promiscuous mode before the link init is complete.  The
init complete routine then resets the promisc bit on the card so the kernel
still thinks the card is in promiscuous mode but the card isn't.  doh.

I think this bug only shows up in bridging when the bridge is started at
boot time (or something else that sets promisc at the same time the card
was started).  If promisc is enabled later it works.

Here's a trivial (and hopefully correct) patch that works for me. It
just calls the promisc/multicast setup routine after init.

Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
2005-05-15 22:47:56 -04:00
Stephen Hemminger
15efa9bb2d [PATCH] tlan: restore deleted module parameters.
The module parameter values got lost in the conversion to the new module_param
interface. This should fix it.

Signed-off-by: Stephen Hemminger <shemminger@osdl.org>

Index: tlan/drivers/net/tlan.c
===================================================================
2005-05-15 18:25:23 -04:00
7d17c1d606 [netdrvrs] Use netif_carrier_* instead of IFF_RUNNING 2005-05-12 19:45:25 -04:00
Linus Torvalds
1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00