it exists in order to allow arch-specific overrides. This fixes the
binutils (and world) build on powerpc64 after recent TBEMD merges.
Reviewed by: imp
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
BIOS does not support ACPI. The other options in the menu retain their
existing numbers, option 2 is simply blanked out (and '2' is ignored).
MFC after: 1 month
unsupported futex operation
- for those futex operations which are known to be not supported,
print out which futex operation it is
- shortcut the error return of the unsupported FUTEX_CLOCK_REALTIME in
some cases:
FUTEX_CLOCK_REALTIME can be used to tell linux to use
CLOCK_REALTIME instead of CLOCK_MONOTONIC. FUTEX_CLOCK_REALTIME
however must only be set, if either FUTEX_WAIT_BITSET or
FUTEX_WAIT_REQUEUE_PI are set too. If that's not the case
we can die with ENOSYS right at the beginning.
Submitted by: arundel
Reviewed by: rdivacky (earlier iteration of the patch)
MFC after: 1 week
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
The ports/Mk/bsd.port.mk uses sys/param.h to fetch osrel, and cannot
grok several constants with the prefix.
Reported and tested by: swell.k gmail com
MFC after: 1 week
The unmapped page separates the tip of the stack and possible adjanced
segment, making some uses of stack overflow harder. The stack growing
code refuses to expand the segment to the last page of the reseved
region when sysctl security.bsd.stack_guard_page is set to 1. The
default value for sysctl and accompanying tunable is 0.
Please note that mmap(MAP_FIXED) still can place a mapping right up to
the stack, making continuous region.
Reviewed by: alc
MFC after: 1 week
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.
during boot.
Change the last argument of gets() to indicate a visibility flag and add
definitions for the numerical constants. Except for the value 2, gets()
will behave exactly the same, so existing consumers shouldn't break. We
only use it in two places, though.
Submitted by: lme (older version)
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
probe method return BUS_PROBE_NOWILDCARD so it doesn't get attached to real
devices hanging off of nexus(4) with no specific devclass set. Actually, the
more desirable fix for this would be to get rid of the newbus interface of
cryptosoft(4) altogether but apparently crypto(9) was written with support
for cryptographic hardware in mind so that approach would require some KPI
breaking changes which don't seem worth it.
MFC after: 1 week
