auto-correction. This change makes re(4) establish a link with
a system using non-crossover UTP cable.
Tested by: Michael BlackHeart < amdmiek <> gmail dot com >
Unfortunately 5720S uses 5709S PHY id so add a hack to detect 5720S
PHY by checking parent device name. 5720S PHY does not support 2500SX.
Tested by: Geans Pin < geanspin <> broadcom dot com >
them, please let me know if not). Most of these are of the form:
static const struct bzzt_type {
[...list of members...]
} const bzzt_devs[] = {
[...list of initializers...]
};
The second const is unnecessary, as arrays cannot be modified anyway,
and if the elements are const, the whole thing is const automatically
(e.g. it is placed in .rodata).
I have verified this does not change the binary output of a full kernel
build (except for build timestamps embedded in the object files).
Reviewed by: yongari, marius
MFC after: 1 week
handling(jumbo, wire speed etc) in brgphy_reset(). Touching
BRGPHY_MII_AUXCTL register seems to confuse APE firmware such that
it couldn't establish a link.
extract a link status of PHY when parent driver is re(4).
RGEPHY_MII_SSR register does not seem to report correct PHY status
on some integrated PHYs used with re(4).
Unfortunately, RealTek PHYs have no additional information to
differentiate integrated PHYs from external ones so relying on PHY
model number is not enough to know that. However, it seems
RGEPHY_MII_SSR register exists for external RealTek PHYs so
checking parent driver would be good indication to know which PHY
was used. In other words, for non-re(4) controllers, the PHY is
external one and its revision number is greater than or equal to 2.
This change fixes intermittent link UP/DOWN messages reported on
RTL8169 controller.
Also, mii_attach(9) is tried after setting interface name since
rgephy(4) have to know parent driver name.
PR: kern/165509
found on Adaptec AIC-6915 Starfire ethernet controller.
While here, use status register to know resolved speed/duplex.
With this change, sf(4) correctly reports speed/duplex of
established link.
Reviewed by: marius
- In case the parent is bge(4), don't set the Jumbo frame settings unless
the MAC actually is Jumbo capable as otherwise the PHY might not have the
corresponding registers implemented. This is also in line with what the
Linux tg3 driver does.
PR: 165032
Submitted by: Alexander Milanov
Obtained from: OpenBSD
MFC after: 3 days
before calling bus_enumerate_hinted_children(9) (which is the minimum for
this to work) instead of fully probing it so later on we can just call
bus_generic_attach(9) on the parent of the miibus(4) instance. The latter
is necessary in order to work around what seems to be a bzzarre race in
newbus affecting a few machines since r227687, causing no driver being
probed for the newly added miibus(4) instance. Presumably this is the
same race that was the motivation for the work around done in r215348.
Reported and tested by: yongari
- Revert the removal of a static in r221913 in order to help compilers to
produce more optimal code.
issues probably needing workarounds in bge(4) when brgphy(4) handles this
PHY. Letting ukphy(4) handle it instead results in a working configuration,
although likely with performance penalties.
one. Interestingly, these are actually the default for quite some time
(bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9)
since r52045) but even recently added device drivers do this unnecessarily.
Discussed with: jhb, marcel
- While at it, use DEVMETHOD_END.
Discussed with: jhb
- Also while at it, use __FBSDID.
bit should not affect link establishment process of auto-negotiation
if manual configuration is not used, which is true in auto-negotiation.
However it seems setting this bit interfere with IP1001 PHY's
down-shifting feature such that establishing a 10/100Mbps link failed
when 1000baseT link is not available during auto-negotiation process.
Tested by: Andrey Smagin <samspeed <> mail dot ru >
addresses from being probed and attaching something including ukphy(4)
to it. This is mainly necessarily for PHY switches that create duplicate
or fake PHYs on the bus that can corrupt the PHY state when accessed or
simply cause problems when ukphy(4) isolates the additional instances.
- Change miibus(4) to be a hinted bus, allowing to add child devices via
hints and to set their attach arguments (including for automatically
probed PHYs). This is mainly needed for PHY switches that violate IEEE
802.3 and don't even implement the basic register set so we can't probe
them automatically. However, the ability to alter the attach arguments
for automatically probed PHYs is also useful as for example it allows
to test (or tell a user to test) new variant of a PHY with a specific
driver by letting an existing driver attach to it via manipulating the
IDs without the need to touch the source code or to limit a Gigabit
Ethernet PHY to only announce up to Fast Ethernet in order to save
energy by limiting the capability mask. Generally, a driver has to
be hinted via hint.phydrv.X.at="miibusY" and hint.phydrv.X.phyno="Z"
(which already is sufficient to add phydrvX at miibusY at PHY address
Z). Then optionally the following attach arguments additionally can
be configured:
hint.phydrv.X.id1
hint.phydrv.X.id2
hint.phydrv.X.capmask
- Some minor cleanup.
Reviewed by: adrian, ray
take advantage of it instead of duplicating it. This reduces the size of
the i386 GENERIC kernel by about 4k. The only potential in-tree user left
unconverted is xe(4), which generally should be changed to use miibus(4)
instead of implementing PHY handling on its own, as otherwise it makes not
much sense to add a dependency on miibus(4)/mii_bitbang(4) to xe(4) just
for the MII bitbang'ing code. The common MII bitbang'ing code also is
useful in the embedded space for using GPIO pins to implement MII access.
- Based on lessons learnt with dc(4) (see r185750), add bus barriers to the
MII bitbang read and write functions of the other drivers converted in
order to ensure the intended ordering. Given that register access via an
index register as well as register bank/window switching is subject to the
same problem, also add bus barriers to the respective functions of smc(4),
tl(4) and xl(4).
- Sprinkle some const.
Thanks to the following testers:
Andrew Bliznak (nge(4)), nwhitehorn@ (bm(4)), yongari@ (sis(4) and ste(4))
Thanks to Hans-Joerg Sirtl for supplying hardware to test stge(4).
Reviewed by: yongari (subset of drivers)
Obtained from: NetBSD (partially)
drivers that only ever attach to a particular MAC driver, i.e. inphy(4),
ruephy(4) and xlphy(4), to the directory where the respective MAC driver
lives and only compile it into the kernel when the latter is also there,
also removing it from miibus.ko and moving it into the module of the
respective MAC driver.
- While at it, rename exphy.c, which comes from NetBSD where the MAC driver
it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD
actually identifies itself as xlphy(4), and its function names accordingly
for consistency.
- Additionally while at it, fix some minor style issues like whitespace
in the register headers and add multi-inclusion protection to inphyreg.h.
isolated but also powered down after a reset and while they just work fine
[sic] when both is the case they don't if they are only deisolate but still
powered down. So in order to put PHYs in an overall normal operation mode
for the common case, ensure in mii_phy_reset() that they are not powered
down after a reset. Unfortunately, this only helps in case of BCM5421,
while BCM5709S apparently only work when they remain isolated and powered
down after a reset. So don't call mii_phy_reset() in brgphy_reset() and
implement the reset locally leaving the problematic bits alone. Effectively
this bypasses r221812 for brgphy(4).
Thanks to Justin Hibbits for doing a binary search in order to identify
the problematic commit.
PR: 157405, 158156
Reviewed by: yongari (mii_phy_reset() part)
Approved by: re (kib)
MFC after: 3 days
AR8132 FastEthernet controller. The PHY has no ability to
establish a gigabit link. Previously only link parters which
support down-shifting was able to establish link.
This change should fix a long standing link establishment issue of
AR8132.
PR: kern/156935
MFC after: 1 week
(reporting IFM_LOOP based on BMCR_LOOP is left in place though as
it might provide useful for debugging). For most mii(4) drivers it
was unclear whether the PHYs driven by them actually support
loopback or not. Moreover, typically loopback mode also needs to
be activated on the MAC, which none of the Ethernet drivers using
mii(4) implements. Given that loopback media has no real use (and
obviously hardly had a chance to actually work) besides for driver
development (which just loopback mode should be sufficient for
though, i.e one doesn't necessary need support for loopback media)
support for it is just dropped as both NetBSD and OpenBSD already
did quite some time ago.
- Let mii_phy_add_media() also announce the support of IFM_NONE.
- Restructure the PHY entry points to use a structure of entry points
instead of discrete function pointers, and extend this to include
a "reset" entry point. Make sure any PHY-specific reset routine is
always used, and provide one for lxtphy(4) which disables MII
interrupts (as is done for a few other PHYs we have drivers for).
This includes changing NIC drivers which previously just called the
generic mii_phy_reset() to now actually call the PHY-specific reset
routine, which might be crucial in some cases. While at it, the
redundant checks in these NIC drivers for mii->mii_instance not being
zero before calling the reset routines were removed because as soon
as one PHY driver attaches mii->mii_instance is incremented and we
hardly can end up in their media change callbacks etc if no PHY driver
has attached as mii_attach() would have failed in that case and not
attach a miibus(4) instance.
Consequently, NIC drivers now no longer should call mii_phy_reset()
directly, so it was removed from EXPORT_SYMS.
- Add a mii_phy_dev_attach() as a companion helper to mii_phy_dev_probe().
The purpose of that function is to perform the common steps to attach
a PHY driver instance and to hook it up to the miibus(4) instance and to
optionally also handle the probing, addition and initialization of the
supported media. So all a PHY driver without any special requirements
has to do in its bus attach method is to call mii_phy_dev_attach()
along with PHY-specific MIIF_* flags, a pointer to its PHY functions
and the add_media set to one. All PHY drivers were updated to take
advantage of mii_phy_dev_attach() as appropriate. Along with these
changes the capability mask was added to the mii_softc structure so
PHY drivers taking advantage of mii_phy_dev_attach() but still
handling media on their own do not need to fiddle with the MII attach
arguments anyway.
- Keep track of the PHY offset in the mii_softc structure. This is done
for compatibility with NetBSD/OpenBSD.
- Keep track of the PHY's OUI, model and revision in the mii_softc
structure. Several PHY drivers require this information also after
attaching and previously had to wrap their own softc around mii_softc.
NetBSD/OpenBSD also keep track of the model and revision on their
mii_softc structure. All PHY drivers were updated to take advantage
as appropriate.
- Convert the mebers of the MII data structure to unsigned where
appropriate. This is partly inspired by NetBSD/OpenBSD.
- According to IEEE 802.3-2002 the bits actually have to be reversed
when mapping an OUI to the MII ID registers. All PHY drivers and
miidevs where changed as necessary. Actually this now again allows to
largely share miidevs with NetBSD, which fixed this problem already
9 years ago. Consequently miidevs was synced as far as possible.
- Add MIIF_NOMANPAUSE and mii_phy_flowstatus() calls to drivers that
weren't explicitly converted to support flow control before. It's
unclear whether flow control actually works with these but typically
it should and their net behavior should be more correct with these
changes in place than without if the MAC driver sets MIIF_DOPAUSE.
Obtained from: NetBSD (partially)
Reviewed by: yongari (earlier version), silence on arch@ and net@
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
