Commit Graph

19 Commits

Author SHA1 Message Date
Bill Paul
e51e55880d Call sk_start() at the end of sk_intr() if there's packets in the
interface send queue that need to be processed.
1999-09-25 04:50:27 +00:00
Bill Paul
98a229f65e As suggested by phk, unconditionalize BPF support in these drivers. Since
there are stubs compiled into the kernel if BPF support is not enabled,
there aren't any problems with unresolved symbols. The modules in /modules
are compiled with BPF support enabled anyway, so the most this will do is
bloat GENERIC a little.
1999-09-23 03:32:57 +00:00
Bill Paul
9e4c647c74 Tweak these for what I hope is the last time: change the DRIVER_MODULE()
declaration for the interface driver from "foo" to "if_foo" but leave the
declaration for the miibus attached to the interface driver alone. This
lets the internal module name be "if_foo" while still allowing the miibus
instances to attach to "foo."

This should allow ifconfig to autoload driver modules again without
breaking the miibus attach.
1999-09-22 06:08:11 +00:00
Bill Paul
0355003f26 Un-do the changes to the DRIVER_MODULE() declarations in these drivers.
This whole idea isn't going to work until somebody makes the bus/kld
code smarter. The idea here is to change the module's internal name
from "foo" to "if_foo" so that ifconfig can tell a network driver from
a non-network one. However doing this doesn't work correctly no matter
how you slice it. For everything to work, you have to change the name
in both the driver_t struct and the DRIVER_MODULE() declaration. The
problems are:

- If you change the name in both places, then the kernel thinks that
  the device's name is now "if_foo", so you get things like:

if_foo0: <FOO ethernet> irq foo at device foo on pcifoo
if_foo0: Ethernet address: foo:foo:foo:foo:foo:foo

  This is bogus. Now the device name doesn't agree with the logical
  interface name. There's no reason for this, and it violates the
  principle of least astonishment.

- If you leave the name in the driver_t struct as "foo" and only
  change the names in the DRIVER_MODULE() declaration to "if_foo" then
  attaching drivers to child devices doesn't work because the names don't
  agree. This breaks miibus: drivers that need to have miibuses and PHY
  drivers attached never get them.

In other words: damned if you do, damned if you don't.

This needs to be thought through some more. Since the drivers that
use miibus are broken, I have to change these all back in order to
make them work again. Yes this will stop ifconfig from being able
to demand load driver modules. On the whole, I'd rather have that
than having the drivers not work at all.
1999-09-20 19:06:45 +00:00
Bill Paul
fac1f39b19 Grrr. Okay, changing the devnames was a bad idea. Put them back the way
they were.
1999-09-20 08:47:11 +00:00
Bill Paul
b95a9362a0 Fix the strings in the driver_t structs so that they match the new names
in the DRIVER_MODULES() declarations. *sigh*
1999-09-20 08:14:39 +00:00
David E. O'Brien
bd8a15ce8a Change the name we register with DRIVER_MODULE() to include the leading
"if_".

Reviewed by:	msmith, wpaul
1999-09-20 06:50:52 +00:00
Bill Paul
2c0431ecf6 Fix the mechanism used to choose the unit numbers for the IP interfaces
attached by the SysKonnect driver. Use ifunit() to scan for existing
skN interfaces and pick the first unused one.
1999-09-18 04:01:31 +00:00
Bruce Evans
3de9d6fbe4 Don't restrict our requests for contiguous memory to addresses >= 1MB.
This fixes, at least, panics in ncr_attach() on i386's with about 5MB
of memory.  The restriction was a hack to leave some low memory for ISA
DMA, but on i386's we now allocate pages from the top down, so all the
restriction did was cause our allocations to fail when there is no free
memory above 1MB.
1999-08-29 09:03:58 +00:00
Peter Wemm
c3aac50f28 $Id$ -> $FreeBSD$ 1999-08-28 01:08:13 +00:00
Bill Paul
c9ce464cb7 Remember to clear the IFF_RUNNING and IFF_OACTIVE flags in sf_stop() and
sk_stop().
1999-07-25 05:16:05 +00:00
Bill Paul
09590dc4c1 One last tweak before I turn in for the evening: the driver name in
the driver_t declaration should be "skc" not "sk". Technically, "skc"
is the parent PCI device (the SysKonnect GEnesis controller) and "sk0"
and "sk1" are the network interfaces that get attached to it.
1999-07-23 05:50:35 +00:00
Bill Paul
5c9e5de3e3 Some more small newbus cleanups. Remember to free all resources in case
of failures in foo_attach(), simplify iospace/memspace things a little.
1999-07-23 02:06:57 +00:00
Bill Paul
75156903c8 Fix a small mind-o: one instance of SYS_RES_IOPORT should have been
SYS_RES_MEMOTY in sk_detatch().
1999-07-22 14:58:54 +00:00
Bill Paul
e11a2e3d81 Convert the SysKonnect gigabit ethernet driver to newbus. 1999-07-22 04:04:12 +00:00
Bill Paul
ab03d8e65f Make a few other cleanups while I'm in the area. Typo in comment, unused
structure members, etc. No functional changes.
1999-07-14 21:53:11 +00:00
Bill Paul
b31b2566e0 Revert some changes I had made to try and cut down on the number of TX EOF
interrupts that were scheduled. Testing shows it didn't really do very much
and it makes the code a little more complicated (which is never a good thing).

Also fix the rambuffer offset initialization for the 512K/64K SRAM case
(512K total using 64K chips). It should be 0. The only case with a
non-standard rambuffer offset address is 1024K/64K according to the
SysKonnect manual. (My card has the 1024/64 configuration and I don't know
which card uses the 512/64 configuration, if any, so I'm not sure that
this was really a problem for anyone.)
1999-07-14 18:57:32 +00:00
Bill Paul
05919c5b73 if_sk.c: use pci_port_t instead of u_short
if_skreg.h: use alpha_XXX_dmamap() instead of pmap_kextract hackery on
alpha platform
1999-07-09 17:36:23 +00:00
Bill Paul
3ebb090530 This commit adds driver support for the SysKonnect SK-984x series
gigabit ethernet adapters. This includes two single port cards
(single mode and multimode fiber) and two dual port cards (also single
mode and multimode fiber). SysKonnect is currently the only
vendor with a dual port gigabit ethernet NIC.

The ports on dual port adapters are treated as separate network
interfaces. Thus, if you have an SK-9844 dual port SX card, you
should have both sk0 and sk1 interfaces attached. Dual port cards
are implemented using two XMAC II chips connected to a single
SysKonnect GEnesis controller. Hence, dual port cards are really
one PCI device, as opposed to two separate PCI devices connected
through a PCI to PCI bridge. Note that SysKonnect's drivers use
the two ports for failover purposes rather that as two separate
interfaces, plus they don't support jumbo frames. This applies to
their Linux driver too. :)

Support is provided for hardware multicast filtering, BPF and
jumbo frames. The SysKonnect cards support TCP checksum offload
however this feature is not currently enabled (hopefully it will
be once we get checksum offload support).

There are still a few things that need to be implemeted, like
the ability to communicate with the on-board LM80 voltage/temperature
monitor, but I wanted to get the driver under CVS control and into
-current so people could bang on it.

A big thanks for SysKonnect for making all their programming info
for these cards (and for their FDDI and token ring cards) available
without NDA (see www.syskonnect.com).
1999-07-09 04:30:09 +00:00