History log of /openbsd/sys/dev/mii/amphy.c (Results 1 – 22 of 22)
Revision Date Author Comments
# 471aeecf 06-Apr-2022 naddy <naddy@openbsd.org>

constify struct cfattach


# 21dab745 14-Mar-2015 jsg <jsg@openbsd.org>

Remove some includes include-what-you-use claims don't
have any direct symbols used. Tested for indirect use by compiling
amd64/i386/sparc64 kernels.

ok tedu@ deraadt@


# 0deb6685 05-Dec-2014 mpi <mpi@openbsd.org>

Explicitly include <net/if_var.h> instead of pulling it in <net/if.h>.

ok mikeb@, krw@, bluhm@, tedu@


# fa9fb3ed 28-Dec-2013 deraadt <deraadt@openbsd.org>

mii drivers no longer need activate functions. Repair of the PHY
configuration setting is done at resume time because all networks
drivers which were previously up, do an IFF_UP operation which
hits

mii drivers no longer need activate functions. Repair of the PHY
configuration setting is done at resume time because all networks
drivers which were previously up, do an IFF_UP operation which
hits PHY_RESET.
This was in snapshots for about 2 weeks.

show more ...


# f4e5fafb 08-Sep-2008 brad <brad@openbsd.org>

IEEE 802.3 Annex 28B.3 explicitly specifies the following relative
priorities of the technologies supported by 802.3 Selector Field
value.

1000BASE-T full duplex
1000BASE-T
100BASE-T2 full duplex
10

IEEE 802.3 Annex 28B.3 explicitly specifies the following relative
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 did not honor the order such that 100BASE-T4 had
higher priority than 100BASE-TX full duplex. Fix a long standing bug
such that PHY drivers choose the highest common denominator ability.

This bug is exposed by a Cisco 3550 switch which inadvertently
announces 100BASE-T4 capability even though it is not capable of
100BASE-T4 operation, it is a 100BASE-TX switch.

From FreeBSD

Tested with dc(4), fxp(4), rl(4), sis(4).

show more ...


# b207a830 12-Mar-2008 brad <brad@openbsd.org>

Fix comment typo, of -> if.

ok sthen@


# 147b4765 02-Mar-2008 brad <brad@openbsd.org>

Correct a status flag which could cause half duplex to be reported for
a 10 Mbps full duplex connection but only when not using autoneg.

ok kettenis@


# 98be1dc0 31-Dec-2006 krw <krw@openbsd.org>

Bring last few phys into line by calling their XXX_status() functions
through mii_phy_status() rather than directly. No functional change.

from brad@ ok mglocker@


# bc654221 27-Dec-2006 kettenis <kettenis@openbsd.org>

Always explicitly set IFM_HDX for half-duplex.

From brad@


# e9a12bcb 27-May-2005 brad <brad@openbsd.org>

some cleanup


# 0df3c7cf 05-Feb-2005 brad <brad@openbsd.org>

better


# 896019e7 05-Feb-2005 brad <brad@openbsd.org>

use mii_phy_match()


# d240c9bf 28-Jan-2005 brad <brad@openbsd.org>

Get flags passed down to PHY drivers correctly. This was done on
an adhoc basis in a couple of PHY drivers, this fixes it more generally.

From NetBSD

Fixes panics with aue(4) NICs.


# 446e95de 04-Oct-2004 deraadt <deraadt@openbsd.org>

davicom DM9601 contains another amiphy clone


# c43900ff 27-Sep-2004 brad <brad@openbsd.org>

ANSI protos and some minor cleanup

ok henning@


# 78a92591 26-Sep-2004 brad <brad@openbsd.org>

Restructure the PHY entry points to use a structure of
entry points instead of descrete function pointers, and
extend this to include a "reset" entry point. Make sure
any PHY-specific reset routine i

Restructure the PHY entry points to use a structure of
entry points instead of descrete function pointers, and
extend this to include a "reset" entry point. Make sure
any PHY-specific reset routine is always used.

From NetBSD

ok mcbride@

show more ...


# dd9058e3 20-Sep-2004 brad <brad@openbsd.org>

don't include sys/malloc.h, no memory management functions are used
by any of the MII drivers.

From NetBSD


# 1402a805 06-Aug-2004 pefo <pefo@openbsd.org>

Add support for Am79C875 quad phy.
ok deraadt@


# dde42f34 17-Apr-2002 jason <jason@openbsd.org>

dm9102 appears to be register compatible with dm9101 which is also an amphy-alike.


# c4071fd1 14-Mar-2002 millert <millert@openbsd.org>

First round of __P removal in sys


# b5fef8cf 20-Nov-2000 jason <jason@openbsd.org>

amphy was a bit too liberal in attaching; Gregory Steuck <greg@nest.cx>


# 5512b887 17-Oct-2000 jason <jason@openbsd.org>

driver for amphy from freebsd; aaron ok