sys: Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

miidevs2h: Ignore the first line

The first line hasn't contained version information in years. Ignore it
entirely.

Sponsored by: Netflix

spdx: The BSD-2-Clause-NetBSD identifier is obsolete, drop -NetBSD

The SPDX folks have obsoleted the BSD-2-Clause-NetBSD identifier. Catch
up to that fact and revert to their recommended match of BS

spdx: The BSD-2-Clause-NetBSD identifier is obsolete, drop -NetBSD

The SPDX folks have obsoleted the BSD-2-Clause-NetBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

sys: general adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
pro

sys: general adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

No functional change intended.

show more ...

MFC @ r266724

An SVM update will follow this.

Merge head

IFC @264767

Merge head up to r263906.

Update NetBSD Foundation copyrights to 2-clause BSD

The NetBSD Foundation states "Third parties are encouraged to change the
license on any files which have a 4-clause license contributed to the
Net

Update NetBSD Foundation copyrights to 2-clause BSD

The NetBSD Foundation states "Third parties are encouraged to change the
license on any files which have a 4-clause license contributed to the
NetBSD Foundation to a 2-clause license."

This change removes clauses 3 and 4 from copyright / license blocks that
list The NetBSD Foundation as the only copyright holder.

Sponsored by: The FreeBSD Foundation

show more ...

/* -> /*- for license, minor formatting changes

Remove miidevs.h and generate it from miidevs at compile time.
The devlist2h.awk tool to do this has been repocopied to sys/tools/.

$Id$ -> $FreeBSD$ (some mangled and/or hidden ones)

$Id$ -> $FreeBSD$

This commit adds support for the NetBSD MII abstraction layer and
MII-compliant PHY drivers. Many 10/100 ethernet NICs available today
either use an MII transceiver or have built-in transceivers that

This commit adds support for the NetBSD MII abstraction layer and
MII-compliant PHY drivers. Many 10/100 ethernet NICs available today
either use an MII transceiver or have built-in transceivers that can
be programmed using an MII interface. It makes sense then to separate
this support out into common code instead of duplicating it in all
of the NIC drivers. The mii code also handles all of the media
detection, selection and reporting via the ifmedia interface.

This is basically the same code from NetBSD's /sys/dev/mii, except
it's been adapted to FreeBSD's bus architecture. The advantage to this
is that it automatically allows everything to be turned into a
loadable module. There are some common functions for use in drivers
once an miibus has been attached (mii_mediachg(), mii_pollstat(),
mii_tick()) as well as individual PHY drivers. There is also a
generic driver for all PHYs that aren't handled by a specific driver.
It's possible to do this because all 10/100 PHYs implement the same
general register set in addition to their vendor-specific register
sets, so for the most part you can use one driver for pretty much
any PHY. There are a couple of oddball exceptions though, hence
the need to have specific drivers.

There are two layers: the generic "miibus" layer and the PHY driver
layer. The drivers are child devices of "miibus" and the "miibus" is
a child of a given NIC driver. The "miibus" code and the PHY drivers
can actually be compiled and kldoaded as completely separate modules
or compiled together into one module. For the moment I'm using the
latter approach since the code is relatively small.

Currently there are only three PHY drivers here: the generic driver,
the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding
others later as I convert various NIC drivers to use this code.

I realize that I'm cvs adding this stuff instead of importing it
onto a separate vendor branch, but in my opinion the import approach
doesn't really offer any significant advantage: I'm going to be
maintaining this stuff and writing my own PHY drivers one way or
the other.

show more ...

/* -> /*- for license, minor formatting changes

Remove miidevs.h and generate it from miidevs at compile time.
The devlist2h.awk tool to do this has been repocopied to sys/tools/.

$Id$ -> $FreeBSD$ (some mangled and/or hidden ones)

$Id$ -> $FreeBSD$

This commit adds support for the NetBSD MII abstraction layer and
MII-compliant PHY drivers. Many 10/100 ethernet NICs available today
either use an MII transceiver or have built-in transceivers that

This commit adds support for the NetBSD MII abstraction layer and
MII-compliant PHY drivers. Many 10/100 ethernet NICs available today
either use an MII transceiver or have built-in transceivers that can
be programmed using an MII interface. It makes sense then to separate
this support out into common code instead of duplicating it in all
of the NIC drivers. The mii code also handles all of the media
detection, selection and reporting via the ifmedia interface.

This is basically the same code from NetBSD's /sys/dev/mii, except
it's been adapted to FreeBSD's bus architecture. The advantage to this
is that it automatically allows everything to be turned into a
loadable module. There are some common functions for use in drivers
once an miibus has been attached (mii_mediachg(), mii_pollstat(),
mii_tick()) as well as individual PHY drivers. There is also a
generic driver for all PHYs that aren't handled by a specific driver.
It's possible to do this because all 10/100 PHYs implement the same
general register set in addition to their vendor-specific register
sets, so for the most part you can use one driver for pretty much
any PHY. There are a couple of oddball exceptions though, hence
the need to have specific drivers.

There are two layers: the generic "miibus" layer and the PHY driver
layer. The drivers are child devices of "miibus" and the "miibus" is
a child of a given NIC driver. The "miibus" code and the PHY drivers
can actually be compiled and kldoaded as completely separate modules
or compiled together into one module. For the moment I'm using the
latter approach since the code is relatively small.

Currently there are only three PHY drivers here: the generic driver,
the built-in 3Com XL driver and the NS DP83840 driver. I'll be adding
others later as I convert various NIC drivers to use this code.

I realize that I'm cvs adding this stuff instead of importing it
onto a separate vendor branch, but in my opinion the import approach
doesn't really offer any significant advantage: I'm going to be
maintaining this stuff and writing my own PHY drivers one way or
the other.

show more ...