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
not provide any MAC configuration interface for resolved flow
control parameters. There is even no register that configures water
mark which will control generation of pause frames.
However enabling flow control surely enhanced performance a lot.
such that nfe(4) does not work with MSI-X. When MSI-X support was
introduced, I remember MCP55 controller worked without problems so
the issue could be either PCI bridge or BIOS issue. But I also
noticed snd_hda(4) disabled MSI on all MCP55 chipset so I'm still
not sure this is generic issue of MCP55 chipset. If this was PCI
bridge issue we would have added it to a system wide black-list
table but it's not clear to me at this moment whether it was caused
by either broken BIOS or silicon bug of MCP55 chipset.
To workaround the issue, maintain a MSI/MSI-X black-list table in
driver and lookup base board manufacturer and product name from the
table before attempting to use MSI-X. If driver find an matching
entry, nfe(4) will not use MSI/MSI-X and fall back on traditional
INTx mode. This approach should be the last resort since it relies
on smbios and if another instance of MSI/MSI-X breakage is reported
with different maker/product, we may have to get the PCI bridge
black-listed instead of adding an new entry.
PR: kern/152150
K3765 datacard. After ejecting this device, it reappears using
the normal K3765 ID. It does not switch automatically
Reviewed by: n_hibma
Obtained from: OpenBSD
MFC after: 2 weeks
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
case to previous panic behavior.
I have a real fix that changes the sg dma tag allocation
to be limited to the under 4GB address space but would
prefer to have review before committing.
Bug fixes:
* Fixed "inquiry data fails comparion at DV1 step"
* Fixed bad range input in bus_alloc_resource for ADAPTER_TYPE_B
* Fixed arcmsr driver prevent arcsas support for Areca SAS HBA ARC13x0
Many thanks to Areca for continuing to support FreeBSD.
This commit is intended for MFC before 8.2-RELEASE.
Submitted by: Ching-Lung Huang <ching2048 areca com tw>
The external gpio pins are connected to a PLD on the i2c bus, unfortunatley
this device does not conform by failing to send an ack after each byte written.
The iicbb driver will abort the transfer when the address is not ack'd and it
would introduce a lot of churn to be able to pass a flag down to
iicbb_start/iicbb_write. Instead we do bad things by grabbing the iicbus but
then doing our own bit banging.
controller does not perform automatic switching from 1000Mbps link
to 10/100Mbps link when WOL is activated. Implement establishing
10/100Mps link with auto-negotiation in driver. Link status change
handler was modified to remove taskqueue based approach since driver
now needs synchronous handling for link establishment.
Submitted by: Yamagi Burmeister (lists <> yamagi.org ) (initial version)
Tested by: Yamagi Burmeister (lists <> yamagi.org )
MFC after: 1 week
and updated comments in the usb_quirk.h header file.
The main purpose of this is to expose the quirks for ejecting 3G
modules. usb_modeswitch in Linux does a great job of collecting
information on these, and with the quirks module people can try out the
modeswitch config file entries on FreeBSD, hence the SCSI strings in the
man page.
MFC after: 2 weeks
does-not-exist error when no client interface module is installed instead
of dereferencing NULL pointers. This eases implementation of platforms
that may or may not have Open Firmware.
It seems RTL8169/RTL8168/RTL810xE has a kind of interrupt
moderation mechanism but it is not documented at all. The magic
value dramatically reduced number of interrupts without noticeable
performance drops so apply it to all RTL8169/RTL8169 controllers.
Vendor's FreeBSD driver also applies it to RTL810xE controllers but
their Linux driver explicitly cleared the register, so do not
enable interrupt moderation for RTL810xE controllers.
While I'm here sort 8169 specific registers.
Obtained from: RealTek FreeBSD driver
There were a couple of attempts in the past to reduce it since it
took more than 1ms. Because mii_tick() periodically polls link
status, waiting more than 1ms for each GMII register access was
overkill. Unfortunately all previous attempts were failed with
various ways on different controllers.
This time, add additional 20us dealy at the end of GMII register
access which seems to requirement of all RealTek controllers to
issue next GMII register access request. This is the same way what
Linux does.
controllers. sk(4) never reprogrammed station address for Yukon
controllers so overriding station address with ifconfig(8) was not
possible.
Fix the bug by reprogramming all registers that control station
address, flow-control and virtual station address. Virtual station
address has no use at this moment since driver does not make use of
fail over feature.
Tested by: "Mikhail T." <mi+thun <> aldan.algebra.com>
MFC after: 1 week
the IEEE80211_C_RATECTL flag set, default to NONE for all drivers. Only if
a driver calls ieee80211_ratectl_init() check if the NONE algo is still
selected and try to use AMRR in that case. Drivers are still free to use
any other algo by calling ieee80211_ratectl_set() prior to the
ieee80211_ratectl_init() call.
After this change it is now safe to assume that a ratectl algo is always
available and selected, which renders the IEEE80211_C_RATECTL flag pretty
much useless. Therefore revert r211314 and 211546.
Reviewed by: rpaulo
MFC after: 2 weeks
based devices (QUALCOMMINC 0x2000). He made it use SCSI eject instead of
ZTE STOR eject. This prevented my ZTE MF626 dongle from switching.
- Apply both eject methods for ZTE STOR based devices. Works on my as
well as mav's device.
- Remove the duplicate.
- Sort the usbdevs entries for Qualcomm so this won't happen again.
- Add bootverbose message displaying the fact that we are ejecting (and
how).
Reviewed by: mav
MFC after: 2 weeks
copied as a template for _SRS, a string pointer for descriptor name is also
copied and it becomes stale as soon as it gets de-allocated[2]. Now _CRS is
used as a template for _SRS as ACPI specification suggests if it is usable.
The template from _PRS is still utilized but only when _CRS is not available
or broken. To avoid use-after-free the problem in this case, however, only
mandatory fields are copied, optional data is removed, and structure length
is adjusted accordingly.
Reported by: hps[1]
Analyzed by: avg[2]
Tested by: hps
useful counters like rl_missed_pkts is 16 bits quantity which is
too small to hold meaningful information happened in a second. This
means driver should frequently read these counters in order not to
lose accuracy and that approach is too inefficient in driver's
view. Moreover it seems there is no way to trigger an interrupt to
detect counter near-full or wraparound event as well as lacking
clearing the MAC counters. Another limitation of reading the
counters from RealTek controllers is lack of interrupt firing at
the end of DMA cycle of MAC counter read request such that driver
have to poll the end of the DMA which is a time consuming process
as well as inefficient. The more severe issue of the MAC counter
read request is it takes too long to complete the DMA. All these
limitation made maintaining MAC counters in driver impractical. For
now, just provide simple sysctl interface to trigger reading the
MAC counters. These counters could be used to track down driver
issues. Users can read MAC counters maintained in controller with
the following command.
#sysctl dev.re.0.stats=1
While I'm here add check for validity of dma map and allocated
memory before unloading/freeing them.
Tested by: rmacklem
information through devd. My E220 now produces the notification (1 line):
+u3g0 at bus=1 hubaddr=1 port=0 devaddr=2 interface=0 \
vendor=0x12d1 product=0x1003 devclass=0x00 devsubclass=0x00 \
sernum="" release=0x0000 intclass=0xff intsubclass=0xff \
ttyname=U0 ttyports=2 on uhub0
Note: serial/ufoma and net/uhso still provide port number and tty name
(uhso only) information through sysctls, which should now be removed.
Reviewed by: hpselasky
