exact model name is not clear yet. All previous RTL8201 10/100 PHYs
used 0x8201 in MII_PHYIDR2 which in turn makes model number 0x20
but this PHY used new model number 0x08.
configuration, which is used to work around issues with certain setups
(see r161237) by default, should not be triggered as it may in turn
cause harm in some edge cases.
- Even after masking the media with IFM_GMASK the result may have bits
besides the duplex ones set so just comparing it with IFM_FDX may lead
to false negatives.
- Announce PAUSE support also for manually selected 1000BASE-T, but for
all manually selected media types only in full-duplex mode. Announce
asymmetric PAUSE support only for manually selected 1000BASE-T.
- Simplify setting the manual configuration bits to only once after we
have figured them all out. This also means we no longer unnecessarily
update the hardware along the road.
- Remove a stale comment.
Reviewed by: yongari (plus additional testing)
MFC after: 3 days
besides the duplex ones set so just comparing it with IFM_FDX may lead
to false negatives.
- Simplify ciphy_service() to only set the manual configuration bits
once after we have figured them all out. This also means we no longer
unnecessarily update the hardware along the road.
MFC after: 1 week
complicates the code.
- Don't let atphy_setmedia() announce PAUSE support for half-duplex when
MIIF_FORCEPAUSE is set.
- Simplify e1000phy_service() and ip1000phy_service() to only set the
manual configuration bits once after we have figured them all out. For
ip1000phy_service() this also means we no longer unnecessarily update
the hardware along the road.
MFC after: 1 week
manual 1000BASE-T modes of DP83865 only work together with other National
Semiconductor PHYs.
- Spell 10BASE-T correctly
- Remove some redundant braces.
controller with Card Read Host Controller. These controllers are
multi-function devices and have the same ethernet core of
JMC250/JMC260. Starting from REVFM 5(chip full mask revision)
controllers have the following features.
o eFuse support
o PCD(Packet Completion Deferring)
o More advanced PHY power saving
Because these controllers started to use eFuse, station address
modified by driver is permanent as if it was written to EEPROM. If
you have to change station address please save your controller
default address to safe place before reprogramming it. There is no
way to restore factory default station address.
Many thanks to JMicron for continuing to support FreeBSD.
HW donated by: JMicron
- Add some DSP init code for BCM5221. The values derived from Apple's GMAC
driver and the same init code also exists in Linux's sungem_phy driver.
- Only read media status bits when they are valid.
Obtained from: NetBSD, OpenBSD
autonegotiation along with manual media selection and also only report flow
control status when BMCR_AUTOEN is set (at least with gentbi(4) determining
the flow control status results in false-positives when not set), use
MIIF_NOMANPAUSE.
autonegotiation along with manual media selection and ukphy_status() also
only reports flow control status when BMCR_AUTOEN is set (at least with
gentbi(4) determining the flow control status results in false-positives
when not set), use MIIF_NOMANPAUSE.
of the MAC driver in order to attach miibus(4) on the first pass instead of
falling through to also calling it on the device_t of miibus(4). The latter
code flow was intended to attach the PHY drivers the same way regardless of
whether it's the first or a repeated pass, modulo the bus_generic_attach()
call in miibus_attach() which shouldn't be there. However, it turned out
that these variants cause miibus(4) to be attached twice under certain
conditions when using MAC drivers as modules.
Submitted by: yongari
MFC after: 3 days
of certain MAC models from brgphy(4) to bge(4) where it belongs. While at it,
update the list of models having that restriction to what OpenBSD uses, which
in turn seems to have obtained that information from the Linux tg3 driver.
annex 31B full duplex flow control as well as the IFM_1000_T master
support committed in r215297. For atphy(4) and jmphy(4) this includes
changing these PHY drivers to no longer unconditionally advertise
support for flow control but only if the selected media has IFM_FLOW
set (or MIIF_FORCEPAUSE is set).
- Rename {atphy,jmphy}_auto() to {atphy,jmphy}_setmedia() as these handle
other media types as well.
Reviewed by: yongari (plus additional testing)
Obtained from: NetBSD (partially), OpenBSD (partially)
MFC after: 2 weeks
support in mii(4):
- Merge generic flow control advertisement (which can be enabled by
passing by MIIF_DOPAUSE to mii_attach(9)) and parsing support from
NetBSD into mii_physubr.c and ukphy_subr.c. Unlike as in NetBSD,
IFM_FLOW isn't implemented as a global option via the "don't care
mask" but instead as a media specific option this. This has the
following advantages:
o allows flow control advertisement with autonegotiation to be
turned on and off via ifconfig(8) with the default typically
being off (though MIIF_FORCEPAUSE has been added causing flow
control to be always advertised, allowing to easily MFC this
changes for drivers that previously used home-grown support for
flow control that behaved that way without breaking POLA)
o allows to deal with PHY drivers where flow control advertisement
with manual selection doesn't work or at least isn't implemented,
like it's the case with brgphy(4), e1000phy(4) and ip1000phy(4),
by setting MIIF_NOMANPAUSE
o the available combinations of media options are readily available
from the `ifconfig -m` output
- Add IFM_FLOW to IFM_SHARED_OPTION_DESCRIPTIONS and IFM_ETH_RXPAUSE
and IFM_ETH_TXPAUSE to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so
these are understood by ifconfig(8).
o Make the master/slave support in mii(4) actually usable:
- Change IFM_ETH_MASTER from being implemented as a global option via
the "don't care mask" to a media specific one as it actually is only
applicable to IFM_1000_T to date.
- Let mii_phy_setmedia() set GTCR_MAN_MS in IFM_1000_T slave mode to
actually configure manually selected slave mode (like we also do in
the PHY specific implementations).
- Add IFM_ETH_MASTER to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS so it
is understood by ifconfig(8).
o Switch bge(4), bce(4), msk(4), nfe(4) and stge(4) along with brgphy(4),
e1000phy(4) and ip1000phy(4) to use the generic flow control support
instead of home-grown solutions via IFM_FLAGs. This includes changing
these PHY drivers and smcphy(4) to no longer unconditionally advertise
support for flow control but only if the selected media has IFM_FLOW
set (or MIIF_FORCEPAUSE is set) and implemented for these media variants,
i.e. typically only for copper.
o Switch brgphy(4), ciphy(4), e1000phy(4) and ip1000phy(4) to report and
set IFM_1000_T master mode via IFM_ETH_MASTER instead of via IFF_LINK0
and some IFM_FLAGn.
o Switch brgphy(4) to add at least the the supported copper media based on
the contents of the BMSR via mii_phy_add_media() instead of hardcoding
them. The latter approach seems to have developed historically, besides
causing unnecessary code duplication it was also undesirable because
brgphy_mii_phy_auto() already based the capability advertisement on the
contents of the BMSR though.
o Let brgphy(4) set IFM_1000_T master mode on all supported PHY and not
just BCM5701. Apparently this was a misinterpretation of a workaround
in the Linux tg3 driver; BCM5701 seem to require RGPHY_1000CTL_MSE and
BRGPHY_1000CTL_MSC to be set when configuring autonegotiation but
this doesn't mean we can't set these as well on other PHYs for manual
media selection.
o Let ukphy_status() report IFM_1000_T master mode via IFM_ETH_MASTER so
IFM_1000_T master mode support now is generally available with all PHY
drivers.
o Don't let e1000phy(4) set master/slave bits for IFM_1000_SX as it's
not applicable there.
Reviewed by: yongari (plus additional testing)
Obtained from: NetBSD (partially), OpenBSD (partially)
MFC after: 2 weeks
about but otherwise ignored. When allowing the master to be set manually via
ifconfig(8) by adding the former to IFM_SUBTYPE_ETHERNET_OPTION_DESCRIPTIONS
(as it should be) it seems to be unfavorable that a machine can be made to
panic with a simple ifconfig(8) invocation.
converted to use the mii_phy_add_media()/mii_phy_setmedia() pair instead
of mii_add_media()/mii_anar() remove the latter.
- Declare mii_media mii_media_table static as it shouldn't be used outside
of mii_physubr.c.
MFC after: never
interface also has such connectors.
- In tl_attach() unify three different ways of obtaining the device and
vendor IDs and remove the now obsolete tl_dinfo from tl_softc.
- Given that tlphy(4) only handles the integrated PHYs of NICs driven by
tl(4) make it only probe on the latter.
- Switch mlphy(4) and tlphy(4) to use mii_phy_add_media()/mii_phy_setmedia().
- Simplify looking for the respective companion PHY in mlphy(4) and tlphy(4)
by ignoring the native one by just comparing the device_t's directly rather
than the device name.
- Use mii_phy_add_media() instead of mii_add_media(). I'm not sure how
this driver actually managed to work before as mii_add_media() is
intended to be used to gether with mii_anar() while mii_phy_add_media()
is intended to be used with mii_phy_setmedia(), however this driver
mii_add_media() along with mii_phy_setmedia().
the NIC drivers as well as the PHY drivers to take advantage of the
mii_attach() introduced in r213878 to get rid of certain hacks. For
the most part these were:
- Artificially limiting miibus_{read,write}reg methods to certain PHY
addresses; we now let mii_attach() only probe the PHY at the desired
address(es) instead.
- PHY drivers setting MIIF_* flags based on the NIC driver they hang
off from, partly even based on grabbing and using the softc of the
parent; we now pass these flags down from the NIC to the PHY drivers
via mii_attach(). This got us rid of all such hacks except those of
brgphy() in combination with bce(4) and bge(4), which is way beyond
what can be expressed with simple flags.
While at it, I took the opportunity to change the NIC drivers to pass
up the error returned by mii_attach() (previously by mii_phy_probe())
and unify the error message used in this case where and as appropriate
as mii_attach() actually can fail for a number of reasons, not just
because of no PHY(s) being present at the expected address(es).
Reviewed by: jhb, yongari
replace mii_phy_probe() altogether. Compared to the latter the advantages
of mii_attach() are:
- intended to be called multiple times in order to attach PHYs in multiple
passes (f.e. in order to only use sub-ranges of the 0 to MII_NPHY - 1
range)
- being able to pass along the capability mask from the NIC to the PHY
drivers
- being able to specify at which address (phyloc) to probe for a PHY
(instead of always probing at all addresses from 0 to MII_NPHY - 1)
- being able to specify which PHY instance (offloc) to attach
- being able to pass along MIIF_* flags from the NIC to the PHY drivers
(f.e. as required to indicated to the PHY drivers that flow control is
supported by the NIC driver, which actually is the motivation for this
change).
While at it, I used the opportunity to get rid of some hacks in mii(4)
like miibus_probe() generally doing work besides sheer probing and the
"EVIL HACK" (which will vanish entirely along with mii_phy_probe()) by
passing the struct ifnet pointer via an argument of mii_attach() as well
as to fix some resource leaks in mii(4) in case something fails.
Commits which will update the PHY drivers to honor the MII flags passed
down from the NIC drivers and take advantage of mii_attach() to get rid
of certain types of hacks in NIC and PHY drivers as well as a conversion
of the remaining uses of mii_phy_probe() will follow shortly.
Reviewed by: jhb, yongari
Obtained from: NetBSD (partially)
different PHY instance being selected and isolation out into the wrappers
around the service methods rather than duplicating them over and over
again (besides, a PHY driver shouldn't need to care about which instance
it actually is).
- Centralize the check for the need to isolate a non-zero PHY instance not
supporting isolation in mii_mediachg() and just ignore it rather than
panicing, which should sufficient given that a) things are likely to
just work anyway if one doesn't plug in more than one port at a time and
b) refusing to attach in this case just leaves us in a unknown but most
likely also not exactly correct configuration (besides several drivers
setting MIIF_NOISOLATE didn't care about these anyway, probably due to
setting this flag for no real reason).
- Minor fixes like removing unnecessary setting of sc->mii_anegticks,
using sc->mii_anegticks instead of hardcoded values etc.
