priorities of the technologies supported by 802.3 Selector Field
value.
1000BASE-T full duplex
1000BASE-T
100BASE-T2 full duplex
100BASE-TX full duplex
100BASE-T2
100BASE-T4
100BASE-TX
10BASE-T full duplex
10BAST-T
However PHY drivers didn't honor the order such that 100BASE-T4 had
higher priority than 100BASE-TX full duplex. Fix that long standing
bugs such that have PHY drivers choose the highest common denominator
ability.
Fix a bug in dcphy which inadvertently aceepts 100BASE-T4.
PR: 92599
Bugfix for the Realtek PHY driver... an RTL8201L standalone PHY
needs different handling than the integrated ones in terms of
speed detection. There was a bogus test based on the parent
device driver name string controlling which speed register to
query. That test began failing when the rl driver was split into
separate rl and re drivers some time ago. Apparently nobody ever
noticed because the buggy code only executes if NWAY negotiation
failed. Since we happen to be testing with an ancient dumb hub
rather than a modern switch, we found it.
To fix it all, have the attach() routine notice whether we're
dealing with an integrated PHY or an RTL8201L and store that info
in a struct accessible to the status() routine that needs to know
which register to query.
I touched up the fixes because they were relative to RELENG_6 and to
bring a few nits into line with style(9).
MFC After: 2 weeks
Submitted by: Ian Lepore
indices when manually adding media. Some of these I've missed while
converting drivers to take advantage of said fuctions recently,
others where longstanding bugs.
mii_phy_match() API and takes care of the PHY device probe based on
the struct mii_phydesc array and the match return value provided.
Convert PHY drivers to take advantage of mii_phy_dev_probe(),
converting drivers to provide a mii_phydesc table in the first
place where necessary.
Reviewed by: yongari
MFC after: 2 weeks
the currently selected media is of type IFM_AUTO as auto-negotiation
doesn't need to be kicked anyway.
- In rlphy_status() just use if_dname instead of determining the name
of the parent NIC via device_get_name(device_get_parent(sc->mii_dev)).
- Use mii_phy_add_media() instead of mii_add_media() so the latter can
be eventually retired.
- Take advantage of mii_phy_setmedia().
- Fix some whitespace nits and remove commented out code that just can't
be used with RealTek PHYs.
MFC after: 2 weeks
rl(4) driver and put it in a new re(4) driver. The re(4) driver shares
the if_rlreg.h file with rl(4) but is a separate module. (Ultimately
I may change this. For now, it's convenient.)
rl(4) has been modified so that it will never attach to an 8139C+
chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to
match the 8169/8169S/8110S gigE chips. if_re.c contains the same
basic code that was originally bolted onto if_rl.c, with the
following updates:
- Added support for jumbo frames. Currently, there seems to be
a limit of approximately 6200 bytes for jumbo frames on transmit.
(This was determined via experimentation.) The 8169S/8110S chips
apparently are limited to 7.5K frames on transmit. This may require
some more work, though the framework to handle jumbo frames on RX
is in place: the re_rxeof() routine will gather up frames than span
multiple 2K clusters into a single mbuf list.
- Fixed bug in re_txeof(): if we reap some of the TX buffers,
but there are still some pending, re-arm the timer before exiting
re_txeof() so that another timeout interrupt will be generated, just
in case re_start() doesn't do it for us.
- Handle the 'link state changed' interrupt
- Fix a detach bug. If re(4) is loaded as a module, and you do
tcpdump -i re0, then you do 'kldunload if_re,' the system will
panic after a few seconds. This happens because ether_ifdetach()
ends up calling the BPF detach code, which notices the interface
is in promiscuous mode and tries to switch promisc mode off while
detaching the BPF listner. This ultimately results in a call
to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init()
to handle the IFF_PROMISC flag change. Unfortunately, calling re_init()
here turns the chip back on and restarts the 1-second timeout loop
that drives re_tick(). By the time the timeout fires, if_re.ko
has been unloaded, which results in a call to invalid code and
blows up the system.
To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(),
which stops the ioctl routine from trying to reset the chip.
- Modified comments in re_rxeof() relating to the difference in
RX descriptor status bit layout between the 8139C+ and the gigE
chips. The layout is different because the frame length field
was expanded from 12 bits to 13, and they got rid of one of the
status bits to make room.
- Add diagnostic code (re_diag()) to test for the case where a user
has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some
NICs have the REQ64# and ACK64# lines connected even though the
board is 32-bit only (in this case, they should be pulled high).
This fools the chip into doing 64-bit DMA transfers even though
there is no 64-bit data path. To detect this, re_diag() puts the
chip into digital loopback mode and sets the receiver to promiscuous
mode, then initiates a single 64-byte packet transmission. The
frame is echoed back to the host, and if the frame contents are
intact, we know DMA is working correctly, otherwise we complain
loudly on the console and abort the device attach. (At the moment,
I don't know of any way to work around the problem other than
physically modifying the board, so until/unless I can think of a
software workaround, this will have do to.)
- Created re(4) man page
- Modified rlphy.c to allow re(4) to attach as well as rl(4).
Note that this code works for the sample 8169/Marvell 88E1000 NIC
that I have, but probably won't work for the 8169S/8110S chips.
RealTek has sent me some sample NICs, but they haven't arrived yet.
I will probably need to add an rlgphy driver to handle the on-board
PHY in the 8169S/8110S (it needs special DSP initialization).
Rename mii_phy_auto_stop() mii_phy_down().
Introduce mii_down(), use it from nge. Do not indirect it to 19 identical
case's in 19 switchstatements like NetBSD did.
doesn't support NWAY, the RealTek PHY (both the integrated ones on 8139
chips and the RTL8201L 10/100 PHY) will not report the link speed via
the ANLPAR or BMSR registers. For the 8201L, we need to look in magic
vendor-specific PHY register 0x19. For the 8139 MAC+PHY combo, we have
to be able to test the RL_MEDIASTAT register.
The changes to rlphy.c are based largely on the patch from PR 30836,
however I tried to eliminate some magic numbers by creating an entry
for the 8201 PHY in miidevs.
Also updated if_rl.c to allow the rlphy driver to read the RL_MEDIASTAT
register via the rl_miibus_readreg() routine.
. Make internal service routines static.
. Use a consistent ordering of checks in MII_TICK. Do the work in the
mii_phy_tick() subroutine if appropriate.
. Call mii_phy_update() to trigger the callbacks.
