Age | Commit message (Collapse) | Author |
|
dealing with a carp interface.
|
|
|
|
from FreeBSD
|
|
From NetBSD
|
|
Do not call mii_pollstat() from within device tick routines; the status
information is updated by mii_tick().
dcphy.c rev 1.13
Work around an Intel 21143 chip bug.
Rev 1.56 of if_dc.c removed calls to mii_pollstat() from the dc_tick()
routine. dc_tick() is called regularly to detect link up and link down
status, especially when autonegotiating.
The expectation was that mii_tick() (which is still called from dc_tick())
would update status information automatically in all cases where it would
be sensible to do so.
Unfortunately, with authentic 21143 chips this is not the case, and
the driver never successfully autonegotiates. This is because (despite
what it says in the 21143 manual) the chip always claims that link is not
present while the autonegotiation enable bit is set. Autonegotation takes
place and succeeds, but the driver tests the link bits before it switches
off the autonegotiation enable bit, and success is not recognised.
The simplest solution is to call dcphy_status() more often for MII_TICK
calls by dropping out of the switch statement instead of exiting when
we are autonegotiating and link appears to not be present. When
autonegotiation succeeds, dcphy_status() will note the speed and fdx/hdx
state and turn off the autonegotiation enable bit. The next call to
dcphy_status() will notice that link is present, and the dc driver code
will be notified.
Macronix chips also use this code, but implement link detection as
described in the manual, and hence don't need this patch. However, tests
on a Macronix 98715AEC-C show that it does not adversely affect them.
From FreeBSD
ok deraadt@
|
|
Add support for BCM5705K
rev 1.74
Add support for the BCM5750/5751. Unfortunately the documentation
I have from Broadcom does not give much information on these devices,
so the Broadcom Linux driver was used for clues to what these chips
support. It turns out they are similar to the 5705 with the 5751
being the PCI-Express version and needing special work-arounds and
settings.
From FreeBSD
|
|
|
|
|
|
|
|
|
|
|
|
|
|
already deals with.
|
|
the BMCR again. The DP83840A manual states that there should be a 500us delay
between asserting software reset and attempting MII serial operations.
From NetBSD
ok mcbride@
|
|
From NetBSD
ok mcbride@
|
|
|
|
From NetBSD
ok mcbride@
|
|
From NetBSD
ok mcbride@
|
|
ok jason@
|
|
|
|
|
|
(apparantly only affects cats GENERIC)
|
|
|
|
From: FreeBSD
|
|
|
|
to try to deduce what the link partner is the hardway. Based on FreeBSD.
|
|
via Jonathan Gray
log message:
Remove advertising clauses from code written by Shingo WATANABE.
He has kindly consented it.
|
|
|
|
ok henning@
|
|
|
|
entry points instead of descrete function pointers, and
extend this to include a "reset" entry point. Make sure
any PHY-specific reset routine is always used.
From NetBSD
ok mcbride@
|
|
|
|
by any of the MII drivers.
From NetBSD
|
|
|
|
gigabit -> Gigabit
|
|
|
|
ok deraadt@
|
|
autonegotiation to take place if IFM_AUTO is selected in mii_media_set.
From NetBSD
|
|
From NetBSD
|
|
from FreeBSD
|
|
|
|
|
|
- If the physical interface goes down or the link goes down,
the carp interface goes down as well.
- We treat this like the preemption holdoff with pfsync.
So if one of the carp interfaces is known to be bad (because the
physical interface it's associated with is bad), all the other carp
interfaces back off: they won't preempt, and their advskew goes to 240.
ok cedric@
|
|
|
|
|
|
|
|
Some bug fixes, support for new hardware like the 5704 and 5705.
Testing by deraadt@, danh@, and drahn@ amoung others.
ok deraadt@.
|
|
addition, leaving only desired Broadcom PHY additions.
|
|
addition, leaving only desired Broadcom PHY additions.
|
|
The Broadcom devices are needed for the bge sync being attempted.
From FreeBSD. As were the pcidevs committed earlier.
|