(currently) only consumer (en).
Add a sysctl node hw.atm where the atm drivers will hook on their hardware
sysctl sub-trees.
Make atm_ifattach call if_attach and remove the corresponding call to if_attach
from en. Create atm_ifdetach and use that in en.
While the last change actually changes the interface this is not a problem in
practice because the only other consumer of this API is an older LANAI driver
on the net, that is not ready for current anyway.
Reviewed by: -atm
ia64 by defining them in terms of newbus. Add a static inline for
fillw(), which doesn't have anything to do with I/O.
It's still ugly, but now the ugliness can be removed from ia64
specific headers.
1) always call fxp_stop in fxp_detach. Since we don't read from
the card, there's no need to carefully look at things with
bus_child_present.
2) Call FXP_UNLOCK() before calling bus_teardown_intr to avoid
a possible deadlock reported by jhb.
3) add gone to the softc. Set it to true in detach.
4) Return immediately if gone is true in fxp_ioctl
5) Return immediately if gone is true in fxp_intr
that one cannot generally hold a lock and call bus_teardown_intr.
This is race free with wi_intr because bus_teardown_intr won't allow
wi_intr to be called after it returns.
# jeff hsu points out that there might be a race between this unlock
# and wi_start. While that may be true also, it won't impact this commit.
Submitted by: jhb
as 64-bit architectures won't like this. Use virtual array indexes
instead. This *should* allow the driver to work on 64-bit platforms,
though it's still not endian clean.
firmware 1.50.12, but 2.20.1 and 3.10.4 work. The 1.50.12 card gets
past doing dhclient, but hangs on transmit a little after the ip
address is set. The 1.50.12 card has always been 'cranky' and Bill
Paul's tearing it apart at FreeBSD '99 hasn't helped.
sc_reset and sc_enable are subtlely different things. sc_reset means
exactly "WI_CMD_INI has happened." sc_enabled means "WI_CMD_ENABLE
has been sent to the card without a WI_CMD_DISABLE following." This
is a little different than what they mean on NetBSD (where both of
these concepts are comingled). NetBSD will try to only enable symbol
cards once, while FreeBSD only sends the WI_CMD_INI once.
Also, only try once to reset the card on a symbol.
This makes the lucent cards no worse than before, but apparently not
much better either. I got fewer hangs in my testing than I have in
the past, but I don't know if it is statistically significant or not.
"Ian gave me this patch" I assume this is iadowse@.
Also, pull in a few devices NetBSD's table. More are there, but I need
to properly move them to pccarddev before including them here.
- Remove getcsrdata().
- Don't print device type, this can be obtained by fwcontrol.
Tested with: Maxtor 5000XT
Tested by: Daniel O'Connor <doconnor@gsoft.com.au>
following changes have been done:
- stylify. The original code was too hard to read.
- get rid of a number of compilation options (Adaptec-only, Eni-only, no-DMA).
- more debugging features.
- locking. This is not correct yet in the absence of interface layer locking,
but is correct enough to not to cause lock order reversals.
- remove RAW mode. There are no users of this in the tree and I doubt that
there are any.
- remove NetBSD compatibility code. There was no way to keep NetBSD non-busdma
and FreeBSD busdma code together.
- if_en now buildable as a module.
This has been actively tested on sparc64 and i386 with ENI server and
client cards and an Adaptec card (thanks to kjc).
Reviewed by: mdodd, arr
- Add fxp_start_body() and change fxp_start() to just acquire locks and
then call fxp_start_body(). Places that would call fxp_start() with
locks held (mutex recursion) now call fxp_start_body() directly.
Remove MTX_RECURSE flag from sc_mtx. [gallatin]
- Change fxp_attach() to work without the softc lock, saving interrupt
hooking until the head of fxp_attach().
- Call ether_ifattach() before overriding ifp parameters. This reverts
part of 1.155.
- Remove multiple error paths in fxp_attach().
- Teardown interrupt in fxp_detach() before unlocking the softc.
- Make sure mutex is not held in fxp_release()
- Delete the miibus instance and/or self in fxp_release(), not in
fxp_detach(). This can happen if attach fails partway through.
- Move ifmedia_removeall to fxp_release() since attach may fail after
media have been allocated.
- Add locking to fxp_suspend, fxp_resume, fxp_start, fxp_intr,
fxp_poll, fxp_tick, fxp_ioctl, fxp_watchdog.
- Pass in ifp to fxp_intr_body since its callers sometimes already use
it.
- Add compatibility define for INTR_MPSAFE for 4.x. [gallatin]
- You don't need to bzero softc.
Ideas from: gallatin, mux
Tested by: >400M packets of dd/ssh, NFS, ping on i386 UP
driver at long last!
Many thanks to vaidas.damosevicius@if.lt for keeping this issue alive
and pursuing Intel for a fix, Intel/ICP for working on the driver, and
Sergey Osokin for bringing the original patches up to 5-CURRENT.
of the infrastructure for the gamma driver which was removed a while back.
The DRM_LINUX option is removed because the handler is now provided by the
linux compat code itself.
(with other names) in the USB driver sources, but I felt that pcireg.h
should have a complete list - at least of classes and interfaces that we
know about and use.
or sched_lock are sufficient to test this flag.
XXX: vinum should really be using a kernel process via kthread_create()
instead of this hack. I'm not even sure PS_INMEM can be clear at this
point anyways.
if attach succeeded. device_is_alive just tells us that probe
succeeded. Since we were using it to do things like detach net
interfaces, this caused problems when there were errors in the attach
routine.
Symptoms of problem reported by: martin blapp
ethernet controller. The driver has been tested with the LinkSys
USB200M adapter. I know for a fact that there are other devices out
there with this chip but don't have all the USB vendor/device IDs.
Note: I'm not sure if this will force the driver to end up in the
install kernel image or not. Special magic needs to be done to exclude
it to keep the boot floppies from bloating again, someone please
advise.
