case, a "Vortex86" mini PC), the PCI device ID value in the EEPROM (0x8100)
does not agree with the PCI device ID returned by pci_get_device() (0x8139).
This means that while rl_probe() matches the device, rl_attach() doesn't.
Work around this by adding an entry to the rl_devs table for the 8100 with
a device ID of 0x8100.
Also, get rid of extra instance of __FBSDID(). One is enough.
multi-fragment transmission. I'm not sure if this is a bug or a requirement
that I overlooked with going through the documentation, but the sample
8169 NIC that I have seems to require it at least some of the time or
else it botches TCP checksums on segments that span multiple descriptors.
ioctls.
In the particular case of ptrace(), this commit more-or-less reverts
revision 1.53 of sys_process.c, which appears to have been erroneous.
Reviewed by: iedowse, jhb
word between the 8139C+ and the 8169. The 8139C+ has a 'frame alignment
error bit' (bit 27) but the 8169 does not. Rather than simply mark this
bit as reserved, RealTek removed it completely and shifted the remaining
status bits one space to the left. This was causing rl_rxeofcplus()
to misparse the error and checksum bits.
To workaround this, rl_rxeofcplus() now shifts the rxstat word one
bit to the right before testing any of the status bits (but after
the frame length has been extracted).
note the existence of the 8169S and 8110S components. (The 8169
is just a MAC, the 8169S and 8110S contain both a MAC and PHY.)
- Properly handle list and buffer addresses as 64-bit. The RX and
TX DMA list addresses should be bus_addr_t's. Added RL_ADDR_HI()
and RL_ADDR_LO() macros to obtain values for writing into chip
registers.
- Set a slightly different TIMERINT value for 8169 NICs for improved
performance.
- Change left out of previous commit log: added some additional
hardware rev codes for other 10/100 chips and for the 8169S/8110S
'rev C' gigE MACs.
- Fix a bug in rl_dma_map_desc(): set the 'end of ring' bit in the
right descriptor (DESC_CNT - 1, not DESC_CNT). The 8139C+ is limited
to 64 descriptors and automatically wraps at 64 descriptors even
if the EOR bit isn't set, but the 8169 NIC can have up to 1024
descriptors per ring, so we must set the wrap point in the right
place.
- RealTek moved the RL_TIMERINT register from offset 0x54 to 0x58 in
the 8169 -- account for this.
- Added rl_gmii_readreg() and rl_gmii_writereg() routines.
- Fix rl_probe() to deal with the case where the base type is
not RL_8139.
The next step is to add jumbo buffer support.
Tested with the Xterasys XN-152 NIC (hard to beat $29 for a gigE NIC).
mainly to quiet a warning emitted by GCC 3.3 about comparing
a variable to a value which is larger than the former can hold.
The value was checked to make sure the `np->squeue' array is
not accessed behind its boundary.
This worked due to possibly accidental truncation when
(np->squeueput + 1) was larger than or equal to MAX_START (256)
when it was assigned to `qidx'.
`qidx' is used to hold the next position in the start queue
for an insertion. The new type was chosen because some other
code in the function ncr_freeze_devq() also uses plain integers
to hold those indices.
Wrapped the line after the closing parenthesis of an `if'
condition.
sis_ioctl() was called, so one had to use ifconfig each time the cable got
plugged in to be able to use the connection.
Do it a better way now, add a "in_tick" field in the softc structure,
call timeout() in sis_tick() and don't call it in sis_init() if in_tick is
non-zero.
Reported by: Landmark Networks
Pointy hat to: cognet
Some of the calls to bus_dmamap_sync() were syncing the DMA descriptor
ring maps using the mbuf tag, when they should have been using the
descriptor ring tag instead.
series, the 8139C+ has a descriptor-based DMA mechanism, and its
performance is actually pretty respectable. Note: the 8139D chip does
not support C+ mode. Only the 8139C+ and 8169 gigE chips support C+ mode.
Supported features:
- RX and TX checksum offload
- hardware VLAN tag insertion/extraction
- TX interrupt moderation using the 8139's on-board timer
Everything should be properly busdma'ed and endian-independent, so
things should work ok on non-x86 platforms. Unfortunately, my call
for testers on this code was met with deafening silence, and I don't
have access to any non-x86 FreeBSD boxes at the moment, so this is
speculation.
The device detection code has been cleaned up a little as well
(thanks to Michal Mertl) for the patches.
There are also updates to the rl(4) man page (which I accidentally
checked in before when I updated the dc(4) man page. Oops.)
Todo: finish support for the 8169 gigabit ethernet chip. This
mainly requires writing an rlgphy driver to handle the 8169's built-in
PHY. This will have to wait until I actually get my hands on an 8169
card for testing though. (I still can't find a source for one in the
U.S. Suggestions/pointers welcome.)
- MN-110 10/100 USB ethernet (ADMtek Pegasus II, if_aue)
- MN-120 10/100 cardbus (ADMtek Centaur-C, if_dc)
- MN-130 10/100 PCI (ADMtek Centaur-P, if_dc)
Also update dc(4) man page to mention support for MN-120 and MN-130.
register, present only on 3c90xB and later NICs. This meant that you could
not use a 1500 byte MTU with VLANs on original 3c905/3c900 cards (boomerang
chipset). The boomerang chip does support large frames though, just not
in the same way: you can set the 'allow large frames' bit in the MAC
control register to receive frames up to 4K in size.
Changes:
- Set the 'allow large frames' bit for boomerang chips and increase
the packet size register for cyclone and later chips. This allows
us to use IFCAP_VLAN_MTU on all supported xl(4) NICs.
- Actually set the IFCAP_VLAN_MTU flag in the capabilities word
in xl_attach().
- Change the method used to detect older boomerang chips. My 3c575C
cardbus NIC was being incorrectly identified as 3c90x chip instead
of 3c90xB because the capabilities word in its EEPROM reports
a bizzare value. In addition to checking for the supportsNoTxLength
bit, also check for the absence of the supportsLargePackets bit.
Both of these cases denote a 3c90xB chip.
- Make RX and TX checksums configurable via the SIOCSIFCAP ioctl.
- Avoid an unecessary le32toh() in xl_rxeof(): we already have the
received frame size in the lower 16 bits of rxstat, no need to
read it again.
Tested with 3c905-TX, 3c900-TPO, 3c980C and 3c575C NICs.
to have this driver working on sparc64. It still needs to be made
endian-clean before it can work there.
Special thanks to dragonk@evilcode.net for sending me a dc(4) card so
that I was able to do this work.
Many cheers to all the people that tested this change, thanks to them,
this change shouldn't break anything :-).
Tested by: marcel (i386 and ia64), ru (i386), wilko (alpha),
mbr (i386), wpaul (i386) and
Will Saxon <WillS@housing.ufl.edu> (i386)
BUS_DMA_NOWAIT flag, since the code can't handle this.
- Use NULL, NULL for the lockfunc and lockfuncarg parameters of
bus_dma_tag_create() since deferred loads can't happen now.
forced to do slightly bogus power state manipulation. However, this
is one of those features that is preventing further progress, so mark
them as BURN_BIRDGES like I did for the drivers in sys/dev/...
This, like the other change, are a no-op unless you have BURN_BRIDGES
in your kernel.
Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.
sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.
If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.
Reviewed by: tmm, gibbs
bit in the EEPROM mode register on. Also, the address must be written
in two 32-bit register accesses instead of 6 8-bit accesses.
Tested with my 8139B cardbus NIC.
PR: kern/35900
Submitted by: Mark Kettenis <kettenis@chello.nl>
mapped I/O mode, we pause for .1 seconds after issuing the reset command
before trying to poll the 'command busy' bit in the status register.
With my 3c575C cardbus NIC, my Sony Picturebook locks up when it tries
to read the status register immediately after the reset. This appears
to be a problem only with certain NICs on certain hardware, but the
added delay should not hurt cards that already work.
This bug seems to have been brought to light by the fact that the xl
driver now defaults to memory mapped I/O mode instead of programmed
I/O mode like it used to. With PIO mode, the delay isn't needed and
everything works (which is why this NIC worked with 5.0-RELEASE but
not 5.1). I suspect that what's happening is that when the chip is
reset, it takes a little while for the memory-mapped decoding logic
to recover. Trying to access the chip's registers during this period
causes an error condition of some kind that wedges the system.
Devices below may experience a change in geometry.
* Due to a bug, aic(4) never used extended geometry. Changes all drives
>1G to now use extended translation.
* sbp(4) drives exactly 1 GB in size now no longer use extended geometry.
* umass(4) drives exactly 1 GB in size now no longer use extended geometry.
For all other controllers in this commit, this should be a no-op.
Looked over by: scottl
are the same that those of the kernel in the KLD_MODULE case. If
we ever want to detect that kind of problems, this is not the right
place to do this since every network driver would be affected by
such desynchronisation.
toggle several media options (sonet/sdh, for example) with ifconfig and
to see the carrier state in ifconfig's output. It gives also read/write
access (given the right privilegs) to the S/Uni registers to user space
programs.
about the driver version in case of an error report. It conflicts with
some other variable of the same name that has been added to the kernel
just recently and there haven't been any bug reports for quite some
time now, anyway ...
bzero(ptr, sizeof(DC_RXLEN * 5));
which should obviously be:
bzero(ptr, DC_RXLEN * 5);
Looks like this bug may have reduced the effectiveness of the
workaround for the hardware bug in the PNIC chips.
MFC after: 1 week
o Remove register keyword
o ANSIfy prototypes
o Remove "return;" at the end of void functions
o Remove trailing spaces
o Don't align local variables with tabs and reorder them
o Don't use /* FOO */ at the end of a #ifdef FOO block if
it's a small block
- Other non-functional changes :
o 6 -> ETHER_ADDR_LEN
o Don't initialize if_output; ether_ifattach() does it for us
865. The APSIZE register has a variable-sized field of enabled bits.
To figure out how many bits a specific host bridge supports, write the
maximum width and see how many bits are set in the hardware. We then
use this mask for setting and getting the aperture size. Prior to this,
the agp(4) driver would treat an aperture size of 256 MB as 128 MB and
would not allocate enough physical memory for the GART as a result.
MFC after: 3 days
Sponsored by: The Weather Channel
Approved by: re (rwatson)
The submitter of PR 32118 told me that this patch also fixes autoselecting
for znyx 4 port cards (10baseT, 100baseTX did work already).
PR: 32118
Reviewed by: imp
Approved by: rwatson (re)
leads to a panic at unload time, as we own 2 instances of callout and
untimeout() only one.
Will I'm there, remove a call to callout_handler_init(), one is enough.
Reviewed by: wpaul
ILMI daemons. Factor out common softc fields for all ATM interfaces that
need to be externally visible into an ifatm structure and make the midway
driver using this structure and fill the MIB.
(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
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
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
- Unconditionally call *_stop() if device is in the tree. This is to
prevent callouts from happening after the device is gone. Checks for
bus_child_present() should be added in the future to keep from touching
potentially non-existent hardware in *_detach(). Found by iedowse@.
- Always check for and free miibus children, even if the device is not in
the tree since some failure cases could have gotten here.
- Call ether_ifdetach() in the irq setup failure case
- ti(4), xl(4): move ifmedia_init() calls to the beginning of attach so
that ifmedia_removeall() can be unconditionally called on detach. There
is no way to detect whether ifmedia has been initialized without using
a separate variable (as tl(4) does).
- Add comments to indicate assumptions of code path
in dc_detach() instead of only calling it if the hardware is preset.
This is a workaround for page faults in softclock() after a `dc'
device was detached, caused by not disabling a timer before freeing
its memory. The bus_child_present() checks should probably be
re-added later, but only to avoid the hardware accesses and not the
other resource cleanups in dc_stop().
Approved by: njl
network layer (ether).
- Don't abuse module names to facilitate ifconfig module loading;
such abuse isn't really needed. (And if we do need type information
associated with a module then we should make it explicit and not
use hacks.)
unencapsulated packet back into the IFQ. Unfortunately, the only reason
rl_encap would fail was due to m_defrag failing, which should only happen
when we're low on mbufs. Hence, it was possible for us to end up with
an IFQ full of packets which could never clear the queue because they could
never be defragmented because they were themselves taking up all the mbufs.
To solve this, take if_xl's approach to the problem of encapsulation failure:
drop the packet.
MFC after: 3 days
- Don't bother setting OACTIVE when the descriptors are all full
or there's a vr_encap failure, it doesn't help anything.
- Correctly roll back on the descriptor list after a failure
so as not to corrupt the list.
- Add a missing VR_UNLOCK().
Without these changes, vr_encap failure (which is assured during
a low mbuf situation) would result in the card locking until
the watchdog could fire.
MFC after: 1 week
properly (likely due to mbuf exhaustion.) Previously, the driver
got somewhat wedged.
Also, remove the annoying messages printed every time xl_encap
couldn't allocate a mbuf; they served no useful purpose, and just made
an mbuf exhaustion situation more annoying.
MFC after: 1 week
RX part of this driver too. It's better since the code wasn't
dealing with bus_dmamap_load() returning EINPROGRESS, and this
can't happen with bus_dmamap_load_mbuf().
Submitted by: jake
- Remove locking of the softc in the attach method, instead depending on
bus_setup_intr being at the end of attach (delaying interrupt enable until
after ether_ifattach is called)
- Call *_detach directly in the error case of attach, depending on checking
in detach to only free resources that were allocated. This puts all
resource freeing in one place, avoiding thinkos that lead to memory leaks.
- Add bus_child_present check to calls to *_stop in the detach method to
be sure hw is present before touching its registers.
- Remove bzero softc calls since device_t should do this for us.
- dc: move interrupt allocation back where it was before. It was unnecessary
to move it. This reverts part of 1.88
- rl: move irq allocation before ether_ifattach. Problems might have been
caused by allocating the irq after enabling interrupts on the card.
- rl: call rl_stop before ether_ifdetach
- sf: call sf_stop before ether_ifdetach
- sis: add missed free of sis_tag
- sis: check errors from tag creation
- sis: move dmamem_alloc and dmamap_load to happen at same time as tag creation
- sk: remove duplicate initialization of sk_dev
- ste: add missed bus_generic_detach
- ti: call ti_stop before ether_ifdetach
- ti: add missed error setting in ti_rdata alloc failure
- vr: add missed error setting in I/O, memory mapping cases
- xl: add missed error setting in I/O, memory mapping cases
- xl: remove multi-level goto on attach failure
- xl: move dmamem_alloc and dmamap_load to happen at same time as tag creation
- Calls to free(9) are unconditional because it is valid to call free with a
null pointer.
Reviewed by: imp, mdodd
function.
Also, use m_defrag where appropriate to defrag long mbuf chains
in the same fashion as was done in if_sis.c. Before this change,
if_dc would blow up and take down the interface if fed a really long
mbuf chain.
MFC after: 2 weeks
1. The chain passed in is > 31 fragments long
or
2. The chain will not fit in the remaining descriptors without
defragmentation.
This is slightly less clear than other network drivers because the sis
chips share one descriptor list for all packets, it seems.
Before this change, a > 127 fragment chain would get stuck in the IFQUEUE
permanently, bringing all network traffic to a halt.
MFC after: 2 weeks
code messed up on B & C chipsets because it lost the packet header
and therefore the flag indicating the need for hardware checksums.
MFC after: 2 weeks
where physical addresses larger than virtual addresses, such as i386s
with PAE.
- Use this to represent physical addresses in the MI vm system and in the
i386 pmap code. This also changes the paddr parameter to d_mmap_t.
- Fix printf formats to handle physical addresses >4G in the i386 memory
detection code, and due to kvtop returning vm_paddr_t instead of u_long.
Note that this is a name change only; vm_paddr_t is still the same as
vm_offset_t on all currently supported platforms.
Sponsored by: DARPA, Network Associates Laboratories
Discussed with: re, phk (cdevsw change)
driver should use port or memory based IO, determine it dynamically
at runtime, preferring MMIO where possible. This helps us support newer
arches which dislike port based access better.
Tested on i386 & sparc64, with 3c900, 905, 905b, and 905C cards.
(in varying combinations by both jake and myself)
branches:
Initialize struct cdevsw using C99 sparse initializtion and remove
all initializations to default values.
This patch is automatically generated and has been tested by compiling
LINT with all the fields in struct cdevsw in reverse order on alpha,
sparc64 and i386.
Approved by: re(scottl)
- Get rid of the useless atop() / pmap_phys_address() detour. The
device mmap handlers must now give back the physical address
without atop()'ing it.
- Don't borrow the physical address of the mapping in the returned
int. Now we properly pass a vm_offset_t * and expect it to be
filled by the mmap handler when the mapping was successful. The
mmap handler must now return 0 when successful, any other value
is considered as an error. Previously, returning -1 was the only
way to fail. This change thus accidentally fixes some devices
which were bogusly returning errno constants which would have been
considered as addresses by the device pager.
- Garbage collect the poorly named pmap_phys_address() now that it's
no longer used.
- Convert all the d_mmap_t consumers to the new API.
I'm still not sure wheter we need a __FreeBSD_version bump for this,
since and we didn't guarantee API/ABI stability until 5.1-RELEASE.
Discussed with: alc, phk, jake
Reviewed by: peter
Compile-tested on: LINT (i386), GENERIC (alpha and sparc64)
Runtime-tested on: i386
time and there's no indication that it will improve anytime soon.
By removing support for SimOS it is possible to build LINT on
Alpha, which is considered more important at the moment.
Not objected to on: alpha@
as opposed to one after the other. This is faster in both -CURRENT
and -STABLE. Additionally, there is less code duplication for
error-checking.
One thing to note is that this code seems to return(1) when no buffers
are available; perhaps ENOBUFS should be the correct return value?
Partially submitted & tested by: Hiten Pandya <hiten@unixdaemons.com>
MFC after: 1 week
wish the busdma APIs were more consistent accross architectures.
We should probably move all the other DMA map creations in
xl_attach() where we can really handle them failing, since
xl_init() is void and shouldn't fail.
Pointy hat to: mux
Tested by: Anders Andersson <anders@hack.org>
bus_dmamap_load() it.
- Make it so reusing mbufs when we can't allocate (or map) new ones
actually works. We were previously trying to reuse a mbuf which
was already bus_dmamap_unload()'ed.
Reviewed by: silby
for the agp module, and add agp to the list of modules to compile for alpha.
Add an alpha_mb() to agp_flush_cache for alpha -- it's not correct but may
improve the situation, and it's what linux and NetBSD do.
using the Rhine's internal shift registers which are designed
for the job. This reduces the amount of time we wait around shifting
bits, and seems to work better with some chips.
Also, provide a workaround for some newer cards which report fake PHYs
at multiple addresses. (As more cards are ID'd, I'm sure this part
of the code will have to be expanded to cover more cases.)
Submitted by: Thomas Nystrom <thn@saeab.se>
MFC after: 1 week
under load.
This patch has been tested by Thomas and other for more than a month now,
and all (known) hangs seem to be solved.
Thomas's explanation of the patch:
* Fix the problem with the printing of the RX-error.
* Code from if_fet do better deal with the RX-recovery including a
timeout of the RX-turnoff.
* The call to vr_rxeof before vr_rxeoc have been moved to a point
where the RX-part of the chip is turned off. Otherwise there is a
window where new data could have been written to the buffer chain
before the RX-part is turned off. If this happens the chip will see
a busy rx-buffer. I have no evidence that this have occured but
god knows what the chip will do in this case!
* I have added a timeout of the TX-turnoff. I have checked and in
my 900 MHz system the flags for turnoff (both RX & TX) is seen at
the first check in the loop.
* I could see that I got the VR_ISR_DROPPED interrupt sometimes and
started to thinking about this. I then realized that no recovery is
needed for this case and therefore I only count it as an rxerror
(which was not done before).
* Finally I have changed the FIFO RX threshhold to 128 bytes. When I
did this the VR_ISR_DROPPED interrupt went away. Theory: The chip
will receive a complete frame before it tries to write it out to
memory then the RX threshold is set to store'n'forward. IF the frame
is large AND the next rx frame also is large AND the bus is busy
transfering a TX frame to the TX fifo THEN the second received
frame wont fit in the FIFO and is then dropped. By having the RX
threshold set to 128 the RX fifo is emptied faster.
MFC after: 5 days
on 900B and 635(A).
Re-add the enhanced PHY access register method again for older chipsets,
they do not seem to work with all old chips.
Reviewed by: phk
MFC after: 7 days
- Add conversions to/from little endian for fields that the NIC accesses
by DMA as required.
- Add some bus_dmamap_sync() calls, and correct some existing ones.
- Read the receiver information from the EEPROM in an endian-neutral
manner.
- Load all RX and TX descriptors in a single DMA map up front, and
get the bus addresses of individual descriptors by address arithmetic;
this fixes multiple use of the descriptor tags, which would have
undesired effects.
It seems that xl still does not work on e250 boxen, for reasons which
are not clear yet.
Reviewed by: mux
and ether_ifattach() to end. This fixes a "could sleep" case and
simplifies error exit cases as well. Also be sure to set errno
and clean up resources in !mac error case.
Tested by: Ryan Beasley
Allow to read EEPROM from LAN. It is shared
between a 1394 controller and the NIC and each
time we access it, we need to set SIS_EECMD_REQ.
Idea from: linux driver source
Reviewed by: luoqi
Obtained from: linux driver source (idea)
register, and phy has to be directly accessed via mdio.
Patch converted to CURRENT from STABLE.
Submitted by: luoqi
Reviewed by: luoqi (again)
MFC after: 2 weeks
the PCI bus. When this bit is set, the Max DMA Burst Size
for TX/RX DMA should be no larger than 64 bytes.
Reviewed by: luoqi
Obtained from: (idea from linux driver source)
MFC after: 2 weeks
is read one clock edge too late. This bit is driven low by
slave (as any other input data bits from slave) when the clock
is LOW. The current code did read the bit after the clock was
driven high again.
Reviewed by: luoqi
MFC after: 2 weeks
bus_dmamap_load_mbuf() returned EFBIG.
o Fix mbuf leaks in an error (rare) code path.
o Reuse the TX descriptor if xl_encap() failed instead of
just picking the next one.
o Better error messages.
it possible to use this driver under ia64, sparc64 (though
there may be endianness issues with this one) and other archs.
Tested on: i386, alpha (gallatin)
pci_get_ether accesor, which gets it from the CIS for cardbus cards
(and from other pci-like buses via whatever mechanism is used there).
Submitted by: sam
Approved by: re (blanket)
1. Detect the revision of the Rhine chip we're using.
2. Use the force reset command on revisions which support
it whenever the normal reset command fails.
This should solve a wide range of "my vr0 locks up with reset
failed messages" problems. (Although the root causes should
be eventually tracked down.)
Tested by: grenville armitage <garmitage@swin.edu.au>
Obtained from: Via's if_fet driver
MFC after: 3 days
Approved by: re
o use if_input for input packet processing
o don't strip the Ethernet header for input packets
o use BPF_* macros bpf tapping
o call ether_ioctl to handle default ioctl case
o track vlan changes
Reviewed by: many
Approved by: re
OpenBSD who got the code (or the idea) from the NetBSD tlp driver.
This gets some cardbus dc cards working (either completely or nearly
so). It also appears to get additional pci cards working, without
breaking working ones.
# Maybe some additional work is needed here. Also, the cardbus attachment
# might need to match on the CIS rather than on the vendor/device so we have
# a finer level of detail as to what the card is. Technically, the
# vendor/device fields are undefined for CardBus (even though most cards are
# using common silicon with pci models).
According to the MII specification, the delay produced by our
reads alone are sufficient for correct operation.
This reduces the time mii_tick takes from 10ms to ~1ms here. That's
still a lot, but much better than before.
Submitted by: Harti Brandt <brandt@fokus.gmd.de>
MFC after: 3 weeks
RXSTATE to STOPPED, but to WAIT. This should fix hangs which
could only be solved by replugging the cable.
Submitted by: jhb
Reviewed by: phk
MFC after: 2 weeks
The 550 version is location at address 1 but since it works right we
let the code find whatever PHY it can.
Fix a fragment issue on TX. If the number of frags are more then the
driver has allocated then bring all the frags together into one packet
and send it out. Code derived from the fxp driver.
Tested and found by: Francois Tigeot <francois.tigeot@nic.fr>
Hellmuth Michaelis <hm@kts.org>
MFC after: 1 week
