MFC r342214:
Remove a use of a negative array index from fxp(4).

Revert r330897:

This was intended to be a non-functional change. It wasn't. The commit
message was thus wrong. In addition it broke arm, and merged crypto
related code.

Revert with prejudice.

This revert skips files touched in r316370 since that commit was since
MFCed. This revert also skips files that require $FreeBSD$ property
changes.

Thank you to those who helped me get out of this mess including but not
limited to gonzo, kevans, rgrimes.

Requested by: gjb (re)

Partial merge of the SPDX changes

These changes are incomplete but are making it difficult
to determine what other changes can/should be merged.

No objections from: pfg

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

sys/dev: minor spelling fixes.

Most affect comments, very few have user-visible effects.

These files were getting sys/malloc.h and vm/uma.h with header pollution
via sys/mbuf.h

Add Intel vendor ID to the device table to make it more uniform so
that all the pnp info to match the device is in the fxp_ident_table.

- Remove empty wrappers ether_poll_[de]register_drv(). [1]
- Move polling(9) declarations out of ifq.h back to if_var.h
they are absolutely unrelated to queues.

Submitted by: Mikhail <mp lenta.ru> [1]

- Use if_inc_counter() to increment various counters.
- Do not ever set a counter to a value. For those counters
that we don't increment, but return directly from hardware
create cases in if_get_counter() method.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

It is actually possible to have if_t a typedef to non-void type,
and keep both converted to drvapi and non-converted drivers
compilable.

o Make if_t typedef to struct ifnet *.
o Remove shim functions.

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Convert fxp(4) to use the driver API.

Submitted by: Anuranjan Shukla <anshukla@juniper.net>
Obtained from: Juniper Networks, Inc.

The r48589 promised to remove implicit inclusion of if_var.h soon. Prepare
to this event, adding if_var.h to files that do need it. Also, include
all includes that now are included due to implicit pollution via if_var.h

Sponsored by: Netflix
Sponsored by: Nginx, Inc.

Update PCI drivers to no longer look at the MEMIO-enabled bit in the PCI
command register. The lazy BAR allocation code in FreeBSD sometimes
disables this bit when it detects a range conflict, and will re-enable
it on demand when a driver allocates the BAR. Thus, the bit is no longer
a reliable indication of capability, and should not be checked. This
results in the elimination of a lot of code from drivers, and also gives
the opportunity to simplify a lot of drivers to use a helper API to set
the busmaster enable bit.

This changes fixes some recent reports of disk controllers and their
associated drives/enclosures disappearing during boot.

Submitted by: jhb
Reviewed by: jfv, marius, achadd, achim
MFC after: 1 day

Avoid unnecessary controller reinitialization by checking driver
running state. fxp(4) requires controller reinitialization for the
following cases.
o RX lockup condition on i82557
o promiscuous mode change
o multicast filter change
o WOL configuration
o TSO/VLAN hardware tagging/checksum offloading configuration
o MAC reprogramming after speed/duplex/flow-control resolution
o Any events that result in MAC reprogramming(link UP/DOWN,
remote link partner's restart of auto-negotiation etc)
o Microcode loading/unloading
Apart from above cases which come from hardware limitation, upper
stack also blindly reinitializes controller whenever an IP address
is assigned. After r194573, fxp(4) no longer needs to reinitialize
the controller to program multicast filter after upping the
interface. So keeping track of driver running state should remove
all unnecessary controller reinitializations.

This change will also address endless controller reinitialization
triggered by dhclient(8).

Tested by: hrs, Alban Hertroys <haramrae@gmail.com>

Mechanically substitute flags from historic mbuf allocator with
malloc(9) flags in sys/dev.

Remove duplicate const specifiers in many drivers (I hope I got all of
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

- Change the module order of these MAC drivers to be last so they are
deterministically handled after the corresponding PHY drivers when
loaded as modules. Otherwise, when these MAC/PHY driver pairs are
compiled into a single module probing the PHY driver may fail. This
makes r151438 and r226154 actually work. [1]
Reported and tested by: yongari (fxp(4))
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.

Submitted by: jhb [1]
MFC after: 3 days

Remove unnecessary #if as the software workaround for PCI protocol
violation should be activated unless the system is cold-booted
after updating EEPROM.
The PCI protocol violation happens only when established link is
10Mbps so the workaround should be updated whenever link state
change is detected. Previously the workaround was activated only
when user checks current media status with ifconfig(8).

Load entire EEPROM contents in device attach time and verify
whether the checksum of EEPROM is valid or not. Because driver
heavily relies on EEPROM information when it selectively enables
features/workarounds, it would be helpful to know whether driver
sees valid EEPROM.
While I'm here remove all other EEPROM accesses since the entire
EEPROM is loaded at device attach time.

MFC after: 2 weeks

Partially revert r223608 and selectively allow microcode loading
for 82550C. For 82550 controllers this change restores CPUSaver
microcode loading. Due to silicon bug on 82550 and 82550C with
server extension, these controllers seem to require CPUSaver
microcode to receive fragmented UDP datagrams. However the
microcode shouldn't be used on client featured 82550C as it locks
up the controller. In addition, client featured 82550C does not
have the silicon bug. Also clear temporary memory used for
microcode loading since the same memory area is used for other
commands.
While I'm here use 82550C in probe message instead of generic
82550.

Reported by: Andreas Longwitz <longwitz <> incore de>
Tested by: Andreas Longwitz <longwitz <> incore de>
MFC after: 2 weeks

Do not change current media when driver is already running. If
driver is running driver would have already completed flow control
configuration. This change removes unnecessary media changes in
controller reconfiguration cases such that it does not trigger link
reestablishment for configuration change requests like promiscuous
mode change.

Reported by: Many
Tested by: Mike Tancsa <mike <> sentex dot net>
MFC after: 1 week

Fix white space nits.

fxp(4) does not handle deferred dma map loading. Tell
bus_dmamap_load(9) that it should return immediately with error
when there are insufficient mapping resources.

Minor indenting divot...

TCP header size is represented by number of 32bits words.
Fix the TCP header size calculation such that makes TSO engine
cache all header(ethernet/IP/TCP) bytes to its internal buffer.
While here, remove extra pull up for TCP payload. Unlike some
em(4) controllers, fxp(4) does not require such work around for
TSO.
The two limitations are ethernet/IP/TCP header size should be less
than or equal to the size of controller's internal buffer(80 bytes)
and these header information should be found in the first fragment
of a TSO frame.

Enable CPUSaver D102 E-step microcode loading for 82551 revision
0x10.

Disable microcode loading for 82550 and 82550C controllers. Loading
the microcode caused SCB timeouts. Linux driver does not allow
microcode loading for these controllers and jfv also confirmed that
there is no need to do and it shouldn't.

PR: kern/103332
Additional confirmation from: jfv
MFC after: 1 week

- Remove attempts to implement setting of BMCR_LOOP/MIIF_NOLOOP
(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@

Normally fxp(4) does not receive bad frames but promiscuous mode
makes controller to receive bad frames and i82557 will also receive
bad frames since fxp(4) have to receive VLAN oversized frames. If
fxp(4) encounter DMA overrun error, the received frame size would
be 0 so the actual frame size after checksum field extraction the
length would be negative(-2). Due to signed/unsigned comparison
used in driver, frame length check did not work for DMA overrun
frames. Correct this by casting it to int.
While I'm here explicitly check DMA overrun error and discard the
frame regardless of result of received frame length check.

Reported by: n_hibma
Tested by: n_hibma
MFC after: 1 week

Do a sweep of the tree replacing calls to pci_find_extcap() with calls to
pci_find_cap() instead.

- Allocate the DMA memory shared between the host and the controller as
coherent.
- Update a comment to no longer reference Alpha.

Fix a regression introduced in r215906. The change made in r215906
caused link re-negotiation whenever application joins or leaves a
multicast group. If driver is running, it would have established a
link so there is no need to start re-negotiation. The re-negotiation
broke established link which in turn stopped multicast application
working while re-negotiation is in progress.

PR: kern/154667
MFC after: 1 week

If RX lockup workaround is enabled, fxp(4) will periodically reset
the controller to workaround silicon bug of i82557. Each reset will
re-establish link which in turn triggers MII status change
callback. The callback will try to reconfigure controller if the
controller is not i82557 to enable flow-control. This caused
endless link UP/DOWN when the workaround was enabled on non-i82557
controller.

To fix the issue, apply RX lockup workaround only for i82557.
Previously it blindly checked undocumented EEPROM location such
that it sometimes enabled the workaround for other controllers. At
this time, only i82557 is known to have the silicon bug.
This fixes a regression introduced in r215906 which enabled flow
control support for all controllers except i82557.

Reported by: Karl Denninger (karl <> denninger dot net)
Tested by: Karl Denninger (karl <> denninger dot net)
MFC after: 3 days

Fix and implement missing parts of flow control support. This also removes
the dev.fxp.%d.noflow tunable as the same effect can now be achieved with
ifconfig(8) by setting the flowcontrol media option as desired (besides
the tunable never having a chance to actually enable flow control support
so far).
In joint forces with: yongari

- Sprinkle const on tables.
- Remove an alpha remnant.
- Minor comment and style fixes.

Add TSO support over VLAN for i82550/i82551. Controller requires
VLAN hardware tagging to make TSO work over VLAN. So if VLAN
hardware tagging is disabled explicitly clear TSO over VLAN. While
I'm here allow disabling VLAN TX checksum offloading.

Tested by: Liudas < liudasb <> centras dot lt >
MFC after: 10 days

Convert the PHY drivers to honor the mii_flags passed down and convert
the NIC drivers as well as the PHY drivers to take advantage of the
mii_attach() introduced in r213878 to get rid of certain hacks. For
the most part these were:
- Artificially limiting miibus_{read,write}reg methods to certain PHY
addresses; we now let mii_attach() only probe the PHY at the desired
address(es) instead.
- PHY drivers setting MIIF_* flags based on the NIC driver they hang
off from, partly even based on grabbing and using the softc of the
parent; we now pass these flags down from the NIC to the PHY drivers
via mii_attach(). This got us rid of all such hacks except those of
brgphy() in combination with bce(4) and bge(4), which is way beyond
what can be expressed with simple flags.

While at it, I took the opportunity to change the NIC drivers to pass
up the error returned by mii_attach() (previously by mii_phy_probe())
and unify the error message used in this case where and as appropriate
as mii_attach() actually can fail for a number of reasons, not just
because of no PHY(s) being present at the expected address(es).

Reviewed by: jhb, yongari

Make sure to not use stale ip/tcp header pointers. The ip/tcp
header parser uses m_pullup(9) to get access to mbuf chain.
m_pullup(9) can allocate new mbuf chain and free old one if the
space left in the mbuf chain is not enough to hold requested
contiguous bytes. Previously drivers can use stale ip/tcp header
pointer if m_pullup(9) returned new mbuf chain.

Reported by: Andrew Boyer (aboyer <> averesystems dot com)
MFC after: 10 days

If controller received bad frames make sure to update newly added
RFA. Also drop frames that have either CRC error or alignment
error. Normally bad frames are not received at all. But controllers
running in promiscuous mode will receive bad frames. 82557 will
also receive bad frames to receive VLAN oversized frames.

While I'm here mark RNR condition if driver happen to see RNR in
RFA status and restart RU to receive frames again. Because driver
checks all received frames in RX loop, RNR condition could be set
in the middle of RX processing. Just relying on RNR interrupt was
not enough.

This change fixes "Memory modified after free" issue when fxp(4)
is running as a member of if_bridge(4).

Tested by: Larry Baird <lab <> gta dot com>
MFC after: 5 days

Dont' allow dma map load deferring. fxp(4) is not able to handle
EINPROGRESS.

Controller updates RFA via DMA so driver needs synchronization.
Add missing BUS_DMASYNC_POSTWRITE and BUS_DMASYNC_PREREAD.

Export hardware MAC statistics through sysctl node. Previously
fxp(4) already used to extract most hardware MAC statistics but it
didn't show them. With this change, all MAC statistics counters
are exported. Because there are a couple of new counters for 82558
and 82559, enable extended MAC statistics functionality to get
these counters. Accoring to public data sheet, 82559 MAC statistics
return 24 DWORD counters(3 counters are unknown at this moment) so
increase MAC counter structure to meet the MAC statistics block size.
The completion of MAC counter dump is now checked against
FXP_STATS_DR_COMPLETE status code which is appended at the end of
status block. Previously fxp(4) ignored the status of the
FXP_SCB_COMMAND_CU_DUMPRESET command. fxp(4) does not wait for the
completion of pending command before issuing
FXP_SCB_COMMAND_CU_DUMPRESET. Instead it skips the command and try
it next time. This scheme may show better performance but there is
chance to loose updated counters after stopping controller. So make
sure to update MAC statistics in fxp_stop().
While I'm here move sysctl node creation to fxp_sysctl_node().

Tested by: Larry Baird < lab <> gta dot com >

8255x configure command requires number of bytes of configuration
table. The default size of the configuration table was 22 bytes. To
use extended feature of 82550/82551 the configuration table size
was expanded to 32 bytes. The added configuration for 82550/82551
specifies VLAN hardware tagging and IPSec configuration as well as
TCO.
To make configuration easier fxp(4) used a configuration template
and the template was copied to configuration table. After that,
some parameters of the configuration table was changed depending on
controller type and operation mode. However the size of template
was 22 bytes so some configuration parameters were not properly
initialized on 82550/82551.
Fix this by increasing the template size. For 82557, 82558 and
82559 the size of the configuration is still 22 bytes.

It seems controller has two types of promiscuous control, one for
unicast and the other for multicast. To receive multicast frames
that host didn't join in promiscuous mode, driver have to set
promiscuous mode for multicast frames as well.
The Open Source Software Developer Manual for i8255x was not clear
how to handle promiscuous mode.

PR: kern/145905
MFC after: 5 days

With r206844, CSUM_TCP is also set for CSUM_TSO case. Modify
drivers to take into account for the change. Basically CSUM_TSO
should be checked before checking CSUM_TCP.

It seems some 82559ER controllers do not support Rx checksum
offloading. Datasheet said nothing about the limitation of 82559ER
except WOL. Explicitly disable Rx checksum offloading for
controllers that is known to lack the capability.

PR: kern/138135
Tested by: Gooderum, Mark < mgooderum <> websense dot com >

Revert previous commit and add myself to the list of people who should
know better than to commit with a cat in the area.

Add necessary include.

Use if_maddr_rlock()/if_maddr_runlock() rather than IF_ADDR_LOCK()/
IF_ADDR_UNLOCK() across network device drivers when accessing the
per-interface multicast address list, if_multiaddrs. This will
allow us to change the locking strategy without affecting our driver
programming interface or binary interface.

For two wireless drivers, remove unnecessary locking, since they
don't actually access the multicast address list.

Approved by: re (kib)
MFC after: 6 weeks

For ICH based fxp(4) controllers treat them as 82559 compatibles.
To detect which controller is ICH based one, add a new member
variable ich to struct fxp_ident and move the struct to
if_fxpvar.h. Since I've faked controller revision, don't allow
microcode loading for ICH based controllers.
With this change all ICH based controllers will have WOL and Rx
checksum offload capability.

PR: kern/135451
Tested by: Alexey Shuvaev ( shuvaev <> physik dot uni-wuerzburg dot de ),
pluknet ( pluknet <> gmail dot com ),
Gary Jennejohn ( gary.jennejohn <> freenet dot de )

Overhaul fxp(4) multicast filter programming. fxp(4) hardwares do
not allow multicast filter programming when controller is busy to
send/receive frames. So it used to mark need_mcsetup bit and defer
multicast filter programming until controller becomes idle state.
To detect when the controller is idle fxp(4) relied on Tx
completion interrupt with NOP command and fxp_start_body and
fxp_intr_body had to see whether pending multicast filter
programming was requested. This resulted in very complex logic and
sometimes it did not work as expected.
Since the controller should be in idle state before any multicast
filter modifications I changed it to reinitialize the controller
whenever multicast filter programming is required. This is the same
way what OpenBSD and NetBSD does. Also I added IFF_DRV_RUNNING
check in ioctl handler so controller would be reinitialized only if
it is absolutely needed.
With this change I guess we can remove fxp(4) DELAY hack in ifioctl
for IPv6 case.

Always check fxp(4) is running, see if it can accept frames from
upper stack in fxp_start_body().
fxp(4) drops driver lock in Rx path so check the fxp(4) is still
running after reacquiring driver lock in Rx path. Also don't
invoke fxp_intr_body if fxp(4) is not running. With this change
there is no need to set suspend bit in device attach phase.

Don't blindly enable Rx lock-up workaround. Newer chips do not need
the Rx lock-up workaround.

Obtained from: NetBSD

Due to possible PCI bus lock-up issues fxp(4) didn't perform full
hardware reset in attach phase. Selective reset does not clear
configured parameters so I think full hardware reset is required.
To prevent PCI bus lock-up, do selective reset first which will get
off the controller from PCI bus and request software reset after
selective reset. Software reset will unmask interrupts so disable
it after the reset.

Introduce Rx mbuf dma tag and use it in Rx path. Previously it used
common mbuf dma tag for both Tx and Rx path but Rx buffer should
have single DMA segment and maximum buffer size of the segment
should be less than MCLBYTES.
fxp(4) also have to check Tx completion status which was updated by
DMA so we need BUS_DMASYNC_PREREAD and BUS_DMASYNC_POSTWRITE
synchronization in Tx path. Fix all misuse of bus_dmamap_sync(9) in
fxp(4). I guess this change shall fix occasional driver breakage in
PAE environments.

While I'm here add error messages of dma tag/buffer creation and
correct messages.

Controller will dma SCB command status for a given command and
driver should read updated status back after issuing a SCB command.
To send a command to controller and read updated status back,
driver should synchronize both memory read and write operations
with device. Fix bus_dmamap_sync operation specifier used in
fxp_dma_wait() by adding both memory read and memory write
operations.

When user_frac in the polling subsystem is low it is going to busy the
CPU for too long period than necessary. Additively, interfaces are kept
polled (in the tick) even if no more packets are available.
In order to avoid such situations a new generic mechanism can be
implemented in proactive way, keeping track of the time spent on any
packet and fragmenting the time for any tick, stopping the processing
as soon as possible.

In order to implement such mechanism, the polling handler needs to
change, returning the number of packets processed.
While the intended logic is not part of this patch, the polling KPI is
broken by this commit, adding an int return value and the new flag
IFCAP_POLLING_NOCOUNT (which will signal that the return value is
meaningless for the installed handler and checking should be skipped).

Bump __FreeBSD_version in order to signal such situation.

Reviewed by: emaste
Sponsored by: Sandvine Incorporated

Don't blindly set IP packet length from interface MTU in TSO case.
Remote host can advertise smaller MSS than that of sender so upper
stack might have adjusted the MSS which in turn generates IP
packets that are less size than that of interface MTU.

Reported by: Bjoern Koenig ( bkoenig <> alpha-tierchen dot de )
Tested by: Bjoern Koenig ( bkoenig <> alpha-tierchen dot de )
MFC after: 3 days

remove now-redunant cardbus attachment.

writereg returns an int.

Always check whether dma map is valid before unloading the map.
When fxp(4) intializes Rx buffers for the first time, there is no
loaded dma map so attempting to unload it is an invalid operation.

It seems that we don't need to reserve a TBD to set total TCP
payload length in TSO case. Leaving unused TBD also seem to cause
SCB timeouts under certain conditions when TSO/non-TSO traffics
are active at the same time.

mutex.h is needed here. It got it by namespace pollution.

Pointed out by: bde

Add VLAN hardware tag insertion/stripping support. Tx/Rx checksum
offload for VLAN frames are also supported. The VLAN hardware
assistance is available only on 82550/82551 based controllers.
While I'm here change the confusing name of bit1 in byte 22 of
configuration block to vlan_drop_en. The bit controls whether
hardware strips VLAN tagged frame or not. Special thanks to wpaul
who sent valuable VLAN related information to me.

Tested on: i386, sparc64

Make sure to clear PMDR register by writing back power management
events. Just reading PMDR register was not enough to have fxp(4)
immuninize against received magic packets during system boot.

Tested by: Alexey Shuvaev < shuvaev <> physik DOT uni-wuerzburg DOT de >

Add basic WOL support for 82550/82551/82558 and 82559 based
controllers. ICH based controllers are treated as 82559. 82557,
earlier revision of 82558 and 82559ER have no WOL capability.
o WOL support requires help of a firmware so add check whether
hardware is capable of handling magic frames by reading EEPROM.
o Enable accepting WOL frames only when hardware is about to
suspend or shutdown. Previously fxp(4) used to allow receipt of
magic frame under normal operation mode which could cause
hardware hang if magic frame is received by hardware. Datasheet
clearly states driver should not allow WOL frames under normal
operation mode.
o Disable WOL frame reception in device attach so have fxp(4)
immunize against system hang which can be triggered by magic
packets when the hardware is not in fully initialized state.
o Don't reset all hardware configuration data in fxp_stop()
otherwise important configuration data is lost and this would
reset WOL configuration to default state which in turn cause
hardware hang on receipt of magic frames. To fix the issue,
preserve hardware configuration data by issuing a selective
reset.
o Explicitly disable interrupts after issuing selective reset as
reset may unmask interrupts.

Tested by: Alexey Shuvaev < shuvaev <> physik DOT uni-wuerzburg DOT de >

Implement TSO for 82550/82551 controllers.
o Configure controller to use dynamic TBD as TSO requires that
operation mode.
o Add a dummy TBD to tx_cb_u as TSO can access one more TBD in TSO
operation.
o Increase a DMA segment size to 4096 to hold a full IP segment
with link layer header.
o Unlike other TSO capable controllers, 82550/82551 does not
modify the first IP packet in TSO operation so driver should
create an IP packet with proper header. Subsequent IP packets
are generated from the header information in the first IP packet
header. Likewise pseudo checksum also should be computed by
driver for the first packet.
o TSO requires one more TBD to hold total TCP payload. To make
code simple for TSO/non-TSO case, increase the index of the
first available TBD array.
o Remove KASSERT that checks the size of a DMA segment should be
less than or equal to MCLBYTES as it's no longer valid in TSO.
o Tx threshold and number of TBDs field is used to store MSS in
TSO. So don't set the Tx threshold in TSO case.

Implement Rx checksum offload for 82559 or later controllers.
82559 or later controllers added simple checksum calculation logic
in RU. For backward compatibility the computed checksum is appended
at the end of the data posted to Rx buffer. This type of simple
checksum calculation support had been used on several vendors such
as Sun HME/GEM, SysKonnect GENESIS and Marvell Yukon controllers.
Because this type of checksum offload support requires parsing of
received frame and pseudo checksum calculation with software
routine it still consumes more CPU cycles than that of full-fledged
checksum offload controller. But it's still better than software
checksum calculation.

o Introduce a new function, fxp_new_rfabuf which allocates a new
Rx buffer and loads DMA map. Also add a function
fxp_discard_rfabuf that handles reusing Rx buffer/DMA map. With
this change fxp_add_rfabuf just handles appending a new RFA to
existing chain.
o Initialize mbuf length in fxp_new_rfabuf.
o Don't reset rnr and have fxp(4) handle received frames even if
it couldn't allocate new Rx buffer. This will make fxp(4) reload
updated RFA under rnr case. The rnr would still be reset to 0 if
polling is active and fxp(4) processed number of allowed Rx
events.
o Update if_iqdrops if fxp(4) couldn't allocate Rx buffer.

Previously fxp(4) used to try to reuse Rx buffer when new buffer
allocation is failed. But fxp(4) didn't take into account loaded
DMA map such that the same DMA map was loaded again without
unloading the map. There is no reason to unload the loaded map and
reload the same map again, just reusing the map is enough. I
believe the spare DMA map in softc was introduced to implement this
behaviour. Also fxp(4) used to stop Rx processing if once Rx buffer
allocation or DMA map load fails which in turn resulted in losing
incoming frames under heavy network load. With this change fxp(4)
should survive from resource shortage condition.

Simplify Tx checksum offload configuration. Also clear CSUM_IP if
we've computed IP checksum with software method.

- Allow fxp_encap() enqueue failed transmissions and set
IFF_DRV_OACTIVE to note resource shortage to upper stack.
- Don't count number of mbuf chains. Default 32 DMA segments for a
frame is enough for most cases. If bus_dmamap_mbuf_sg fails use
m_collapse(9) to collapse the mbuf chain instead of relying on
expensive m_defrag(9).
- Move bpf handling to fxp_start_body() which is supposed to be
more appropriate place.
- Always arm watchdog timer whenever a new Tx request is made.
Previously fxp(4) used to arm watchdog timer only when
FXP_CXINT_THRESH-th Tx request is made. Because fxp(4) does not
rely on Tx interrupt to reclaim transmitted mbufs it's better to
arm watchdog timer to detect potential lockups.
- Add more aggresive Tx buffer reclaiming in fxp_start_body to make
room for new Tx requests. Since fxp(4) does not request Tx
completion interrupt for every frames it's necessary to clean
TXCBs in advance to saturate link.
- Make fxp(4) try to start more packets transmitting regardless of
interrupt type in fxp_intr_body.

Move unarming watchdog timer and pending multicast configuration
check to fxp_txeof(). While I'm here unarm watchdog timer only if
there are no pending queued Tx requests.
Previously the watchdog timer was unarmed whenever Tx interrupt is
raised. This could be resulted in hiding root cause of watchdog
timeouts.

Fix Tx/Rx checksum offload ioctl handling and make Rx handler honor
checksum offload configuration. Now checksum offload can be
controlled by ifconfig(8).
While I'm here add an additional check for interface capabilities
before applying user's request.

Make fxp(4) build with FXP_IP_CSUM_WAR.

Sort head files and removed ununsed header file.

Whitespace fix.

Reuse the mbuf that was just retrieved from the receive ring if mbuf
exhaustion is encountered. There was a fix made previously for this
problem but the solution (breaking out of the receive loop) does not
seem to work. mbuf reuse strategy is already adopted by other drivers
such as if_bge. The problem was recreated and the patch is also
verified in the same test environment.

Remove the volatile qualifier to apply to fxp_miibus_readreg().

Add support for the 82562GX chip within if_fxp.

PR: 110251
Submitted by: Vyacheslav Vovk
Approved by: imp (mentor)
MFC After: 3 days

o break newbus api: add a new argument of type driver_filter_t to
bus_setup_intr()

o add an int return code to all fast handlers

o retire INTR_FAST/IH_FAST

For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current

Reviewed by: many
Approved by: re@

Change the remainder of the drivers for DMA'ing devices enabled in the
sparc64 GENERIC and the sound device drivers known working on sparc64
to use bus_get_dma_tag() to obtain the parent DMA tag so we can get rid
of the sparc64_root_dma_tag kludge eventually. Except for ath(4), sk(4),
stge(4) and ti(4) these changes are runtime tested (unless I booted up
the wrong kernels again...).

Grammar nit.

- Instead of if_watchdog/if_timer interface use our own timer
that piggybacks on fxp_tick() callout.

Added yet another extra fxp(4) PCI ID.

PR: kern/104896
Submitted by: Yoshihiko Sarumaru <mistral@imasy.or.jp>
Reviewed by: imp (mentor), jfv
Approved by: imp (mentor)
MFC after: 3 days

Added PCI ID's for:

- 0x1065: Intel 82562ET/EZ/GT/GZ PRO/100 VE Ethernet [1], as found on
Tyan GS14 barebones.
- 0x1094: Intel Pro/100 946GZ (ICH7) Network Connection [2], as found on
Intel 946GZis motherboards.

[1] Submitted by: myself
[2] Submitted by: Mike Tancsa <mike@sentex.net>
Reviewed by: imp (mentor), jfv
Approved by: imp (mentor)
MFC after: 3 days

fix fxp so that it will reset the link when you change the speed... This
will fix a problem where you boot w/ the default of autoselect, but then
set the speed to 100/full, the switch will keep the autoselect/100/full
negotiation... This will continue to work till someone resets the switch
or unplugs the cable resulting in the switch failing to autoneg and falling
back to 100/half, causing a hard to track down duplex mismatch..

Submitted by: nCircle Network Security, Inc.
MFC after: 1 week

Since DELAY() was moved, most <machine/clock.h> #includes have been
unnecessary.

Whitespace fix

Pointed out by: Nate Lawson

Add device ID for Intel Pro/100 VE Network Connection card

PR: kern/95729
Submitted by: Nicky Bulthuis
MFC after: 1 day

Do not touch ifp->if_baudrate in miibus aware drivers.

Check for 10BaseT media correctly. Before we were confusing
ifm_status and ifm_active. IFM_10_T gets set in the ifm_active field,
not in the ifm_status field, as far as I can tell.

Note: this was to enable a workaround that's rarely enabled. I don't know
how to corrupt my eeprom to test it, and would rather not know...

Add the device ID of fxp(4) NICs found in Sony Vaio VGN-TX1XP laptops.

PR: kern/90024
Submitted by: Thomas Hurst <tom@hur.st>
MFC after: 3 days

- Store pointer to the link-level address right in "struct ifnet"
rather than in ifindex_table[]; all (except one) accesses are
through ifp anyway. IF_LLADDR() works faster, and all (except
one) ifaddr_byindex() users were converted to use ifp->if_addr.

- Stop storing a (pointer to) Ethernet address in "struct arpcom",
and drop the IFP2ENADDR() macro; all users have been converted
to use IF_LLADDR() instead.

Catch up with IFP2ENADDR() type change (array -> pointer).

- Don't pollute opt_global.h with DEVICE_POLLING and introduce
opt_device_polling.h
- Include opt_device_polling.h into appropriate files.
- Embrace with HAVE_KERNEL_OPTION_HEADERS the include in the files that
can be compiled as loadable modules.

Reviewed by: bde

Big polling(4) cleanup.

o Axe poll in trap.

o Axe IFF_POLLING flag from if_flags.

o Rework revision 1.21 (Giant removal), in such a way that
poll_mtx is not dropped during call to polling handler.
This fixes problem with idle polling.

o Make registration and deregistration from polling in a
functional way, insted of next tick/interrupt.

o Obsolete kern.polling.enable. Polling is turned on/off
with ifconfig.

Detailed kern_poll.c changes:
- Remove polling handler flags, introduced in 1.21. The are not
needed now.
- Forget and do not check if_flags, if_capenable and if_drv_flags.
- Call all registered polling handlers unconditionally.
- Do not drop poll_mtx, when entering polling handlers.
- In ether_poll() NET_LOCK_GIANT prior to locking poll_mtx.
- In netisr_poll() axe the block, where polling code asks drivers
to unregister.
- In netisr_poll() and ether_poll() do polling always, if any
handlers are present.
- In ether_poll_[de]register() remove a lot of error hiding code. Assert
that arguments are correct, instead.
- In ether_poll_[de]register() use standard return values in case of
error or success.
- Introduce poll_switch() that is a sysctl handler for kern.polling.enable.
poll_switch() goes through interface list and enabled/disables polling.
A message that kern.polling.enable is deprecated is printed.

Detailed driver changes:
- On attach driver announces IFCAP_POLLING in if_capabilities, but
not in if_capenable.
- On detach driver calls ether_poll_deregister() if polling is enabled.
- In polling handler driver obtains its lock and checks IFF_DRV_RUNNING
flag. If there is no, then unlocks and returns.
- In ioctl handler driver checks for IFCAP_POLLING flag requested to
be set or cleared. Driver first calls ether_poll_[de]register(), then
obtains driver lock and [dis/en]ables interrupts.
- In interrupt handler driver checks IFCAP_POLLING flag in if_capenable.
If present, then returns.This is important to protect from spurious
interrupts.

Reviewed by: ru, sam, jhb

Convert fxp(4) to use the new bus_alloc_resources() API, it simplifies
the resource allocation code significantly.

Fix an unaligned I/O memory access in the event that a SCB times out.
The FXP_SCR_FLOWCONTROL registers is at offset 0x19, but 2 bytes wide.
It cannot be read as a word without causing a panic on architectures
that enforce strict alignment.

MFC after: 3 days

Add callout_drain()'s to foo_detach() after calling foo_stop() to make sure
that if softclock is running on another CPU and is blocked on our driver
lock, we will wait until it has acquired the lock, seen that it was
cancelled, dropped the lock, and awakened us so that we can safely destroy
the mutex.

MFC after: 3 days

Propagate rename of IFF_OACTIVE and IFF_RUNNING to IFF_DRV_OACTIVE and
IFF_DRV_RUNNING, as well as the move from ifnet.if_flags to
ifnet.if_drv_flags. Device drivers are now responsible for
synchronizing access to these flags, as they are in if_drv_flags. This
helps prevent races between the network stack and device driver in
maintaining the interface flags field.

Many __FreeBSD__ and __FreeBSD_version checks maintained and continued;
some less so.

Reviewed by: pjd, bz
MFC after: 7 days

- Use callout_init_mtx() to close a small race between callout_stop() and
the timeout routine.
- Fix locking in detach.
- Add locking in shutdown.
- Don't mess with the PCI command register in resume, the PCI bus driver
already does this for us.
- Add locking to the non-serial ifmedia routines.
- Fix locking in ioctl.
- Remove spls and support for 4.x.

MFC after: 1 week

Modify device drivers supporting multicast addresses to lock if_addr_mtx
over iteration of their multicast address lists when synchronizing the
hardware address filter with the network stack-maintained list.

Problem reported by: Ed Maste (emaste at phaedrus dot sandvine dot ca>
MFC after: 1 week

Add a new PCI id for fxp(4) cards found on ICH7-based systems.

This commit is a RELENG_6 candidate.

Submitted by: Martin Nilsson <martin@gneto.com>

Move if_alloc() up in fxp_attach() so there's an ifp before
mii_phy_probe() is called.

Committed via: fxp0

Avoid deadlock in fxp driver when system runs out of mbufs.

MFC after: 1 week
Provided by: Ernie Smallis <esmallis@stbernard.com>

Revert the unnecessicary addition of some braces in fxp_attach(). Don't
explicitly free the ifp in fxp_detach(), the call to fxp_release() takes
care of it.

Stop embedding struct ifnet at the top of driver softcs. Instead the
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.

This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.

Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.

Reviewed by: sobomax, sam

Correct comment

Remove some variables the last commit stopped using so the code compiles.

The PCI bus code saves/restores these config registers now.

Be more conservative when enabling extended features. There are fxp(4)
NICs out there that have an utterly bogus revision ID.

Reported by: Denis Shaposhnikov <dsh@vlink.ru>

Add a microcode to implement receive bundling for 82551 chipsets with
a revision ID of 0x0f (D102 E-step).

MFC after: 2 weeks
Tested by: pav

Enable extended RFDs and TCBs, and thus checksum offloading, for
latest 82550 and 82551 chipsets (revision IDs 0x0e, 0x0f and 0x10).
We were only enabling it for revisions 0x0c and 0x0d, now it's
enabled for any 8255x NIC with a revision ID bigger than 0x0c. It
should be safe, and this is what Intel does in their open source
driver.

MFC after: 2 weeks
Tested by: Pavel Lobach lobach_pavel at mail dot ru

Unload and destroy the TX DMA maps before destroying the DMA tag
they're attached to, not after.

Spotted by: Coverity via sam

- Encapsulate the code responsible for initializing a new TX descriptor
from an mbuf into the fxp_encap() function, as done in other drivers.
- Don't waste time calling bus_dmamap_load_mbuf() if we know the mbuf
chain is too long to fit in a TX descriptor, call m_defrag() first.
- Convert fxp(4) to use bus_dmamap_load_mbuf_sg().

Cleanup: u_intXX_t -> uintX_t conversion.

Use BUS_PROBE_DEFAULT for pci probe return value

Add support for fxp(4) cards found in Sony FS570 laptops.

Submitted by: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk>

Fix the panic recently reported on -current@ occuring when configuring
a vlan interface attached to a fxp(4) card when it has not been
initialized yet. We now set the links from our internel TX descriptor
structure to the TX command blocks at attach time rather than at init
time. While I'm here, slightly improve the style in fxp_attach().

PR: kern/78112
Reported by: Gavin Atkinson <gavin.atkinson@ury.york.ac.uk> and others
Tested by: flz, Gavin Atkinson <gavin.atkinson@ury.york.ac.uk>
MFC after: 1 week

Fix a stupid bogon from myself, sc->revision wasn't initialized when
testing it to know whether we should enable the 82503 serial mode...
Move code to the right location and disallow the use of the 82503
serial mode if the sc->revision field is 0 again. This makes fxp(4)
work correctly with ATMEL 350 93C46 cards (3 port 82559 based with a
82555 PHY), as well as with the older ATMEL 220 93C46 (same flavour)
and with the even older 10Mbps-only 82557 cards with the 82503 serial
interface.

Tested by: Andre Albsmeier <andrer@albsmeier.net>, krion
MFC after: 2 weeks

Remove an outdated comment about ifnet not being locked.

OK'ed by: njl, rwatson, sam

Disable ethernet flow control in if_fxp by default, in order to prevent
unexpected surprises when a system panics or is left in the debugger.

Requested by: kris
MFC after: 3 days

Allow fxp(4) cards with a revision id of 0 to use the 82503 serial
interface as well. This is not an expected revision id per the
datasheet, but unfortunately there are such cards out there with
a 82557 chipset, and they want to use the 82503.

PR: kern/75739
Reported by: Andre Albsmeier <andre.albsmeier@siemens.com>

Only try to use the 82503 serial interface for the 82557 chipsets. The
datasheet says it is only valid for such chipsets and shouldn't be used
with others. This fixes some 82559 based cards which otherwise only
work at 10Mbit.

MFC after: 5 days
Tested by: krion

Make interrupt coalescing work on big endian systems.
Also change struct ucode.length to be in number of elements (u_int32_t)
to help endian handling.

MFC after: 2 weeks

Add support for the fxp(4) based card in ICH6 (i915) chipsets.

This is a RELENG_5 candidate.

Submitted by: Mike Tancsa <mike@sentex.net>

Deorbit the fxp tuning hint (hint.fxp.UNIT_NUMBER.ipcbxmit_disable)
introduced in if_fxp.c revision 1.180. The bug fix committed in
revision 1.180 fixed the packet truncation problem.

Bring in the first chunk of altq driver modifications. This covers the
following drivers: bfe(4), em(4), fxp(4), lnc(4), tun(4), de(4) rl(4),
sis(4) and xl(4)

More patches are pending on: http://peoples.freebsd.org/~mlaier/ Please take
a look and tell me if "your" driver is missing, so I can fix this.

Tested-by: many
No-objection: -current, -net

Remove the setting of the pci config variables on power state changes.
The bus does this now.

Abstract the locking in fxp(4) a bit more by using macros for
mtx_assert() and mtx_owned(), as it is done in other places,
for instance proc locking.

Use the device sysctl tree instead of rolling our own. Some of the
sysctls were global (hw.fxp_rnr and hw.fxp_noflow), all of them are
now per-device. Sample output of "sysctl dev.fxp0" with this patch,
with the standard %foo nodes removed :

dev.fxp0.int_delay: 1000
dev.fxp0.bundle_max: 6
dev.fxp0.rnr: 0
dev.fxp0.noflow: 0

Add missing <sys/module.h> includes

POLA dictates that VLAN_MTU be enabled by default.
In particular, disabling it was likely to break configurations
involving ng_vlan(4) since the latter couldn't control
the parent's VLAN_MTU in the way vlan(4) did.

Pointed out by: ru

Those sysctls shouldn't be writtable from inside a jail.

Teach fxp(4) to control VLAN_MTU in the hardware.
Now reception of extended frames can be toggled
through ioctl(SIOCSIFCAP).

The card will also receive extended frames when
in promiscuous mode.

Change a if (...) panic() to a KASSERT().

A handler for ioctl(SIOCSIFCAP) should not alter a bit in
if_capenable unless the interface driver is actually able
to toggle the respective capability on and off.

Reviewed by: ru

We don't need to initialize if_output, ether_ifattach() does it
for us.

Cosmetic:
Set capability bits in a consistent way.
Add a comment on why the VLAN_MTU stuff comes after ether_ifattach().

The driver fxp(4) has reception of large frames enabled hardcodedly,
so let VLAN_MTU be marked in if_capenable from the beginning.

Implemented per-interface polling(4) control.

Add new ID for Intel 82562ET (ICH5/ICH5R) Pro/100 VE Ethernet.

Submitted by: Stefan Bethke
PR: 61320

Convert callers to the new bus_alloc_resource_any(9) API.

Submitted by: Mark Santcroos <marks@ripe.net>
Reviewed by: imp, dfr, bde

Adjust $FreeBSD$'s.

Announce ethernet MAC addresss in ether_ifattach().

Sometimes cardbus attachments don't attach, so while we track down
this problem put these lines back in. While they should be
unnecessary, they appear to be sometimes necessary.

Reviewed in concept: dfr
Approved by: re (scottl@)

Remove explicit cardbus attachments from drivers where this is identical
to the pci attachment. Cardbus is a derived class of pci so all pci
drivers are automatically available for matching against cardbus devices.

Reviewed by: imp

Replace the if_name and if_unit members of struct ifnet with new members
if_xname, if_dname, and if_dunit. if_xname is the name of the interface
and if_dname/unit are the driver name and instance.

This change paves the way for interface renaming and enhanced pseudo
device creation and configuration symantics.

Approved By: re (in principle)
Reviewed By: njl, imp
Tested On: i386, amd64, sparc64
Obtained From: NetBSD (if_xname)

mark interrupt handlers MPSAFE

change timeout to be MPSAFE

Sponsored by: FreeBSD Foundation

Use PCIR_BAR(x) instead of PCIR_MAPS.

Glanced over by: imp, gibbs
Tested by: i386 LINT

Use __FBSDID().
Also some minor style cleanups.

Prefer new location of pci include files (which have only been in the
tree for two or more years now), except in a few places where there's
code to be compatible with older versions of FreeBSD.

Use the revision ID from PCI configuration space to identify Intel
8255x chips more precisely. The information was obtained from Intel's
Open Source Software Developer Manual for the 8255x.

MFC after: 1 day

Use the BUS_DMA_ZERO flag.

De-inline some functions. It doesn't gain us anything and bloats
code size by 3616 bytes. Furthemore, it was previously ignored by GCC.

While I'm at it, fix some bogus comments.

Unlock the fxp driver lock before calling fxp_poll() to avoid recursing on
the lock when using DEVICE_POLLING.

Tested by: Robin P. Blanchard <Robin.Blanchard@gactr.uga.edu>
Reviewed by: njl

All current uses of pci_set_powerstate are bogus, at least in theory.
However, they are presently necessary due to bigger bogusness in the
pci bus layer not doing the right thing on suspend/resume or on
initial device probe. This is exactly the sort of thing that the
BURN_BRIDGES option was invented for. Mark all of them as
BURN_BRIDGES. As soon as I have the powerstate stuff properly
integrated into the pci bus code, I intend to remove all these
workarounds.

Mega busdma API commit.

Add two new arguments to bus_dma_tag_create(): lockfunc and lockfuncarg.
Lockfunc allows a driver to provide a function for managing its locking
semantics while using busdma. At the moment, this is used for the
asynchronous busdma_swi and callback mechanism. Two lockfunc implementations
are provided: busdma_lock_mutex() performs standard mutex operations on the
mutex that is specified from lockfuncarg. dftl_lock() is a panic
implementation and is defaulted to when NULL, NULL are passed to
bus_dma_tag_create(). The only time that NULL, NULL should ever be used is
when the driver ensures that bus_dmamap_load() will not be deferred.
Drivers that do not provide their own locking can pass
busdma_lock_mutex,&Giant args in order to preserve the former behaviour.

sparc64 and powerpc do not provide real busdma_swi functions, so this is
largely a noop on those platforms. The busdma_swi on is64 is not properly
locked yet, so warnings will be emitted on this platform when busdma
callback deferrals happen.

If anyone gets panics or warnings from dflt_lock() being called, please
let me know right away.

Reviewed by: tmm, gibbs

Drop locks before calling if_input() since it may re-enter fxp_start()
in the netisr case. This would result in a lock reversal. This
fixes the net.isr.enable=1 case. Better performance might be
obtained by chaining all packets received, dropping the lock, and
then calling if_input() on each one.

Reported by: hmp

Forced commit to note that the last commit fixed those
problem reports.

PR: kern/53038, kern/53228
Requested by: nork

Add a new device ID.

Submitted by: Tom Alsberg <alsbergt@cs.huji.ac.il>

Replace if_fxp's handrolled defrag function with m_defrag.

No actual bug with the existing code, just tidying things up.

Submitted by: hmp

Always set the hardware parse bit in the IPCB structure when this
structure, which is new to the 82550 and 82551, is used to transmit
a packet. This appears to fix the packet truncation problem that was
observed when using 82550-based fxp cards to transmit ICMP or fragmented
UDP packets of certain lengths which only had one to three bytes in the
second and final mbuf of the packet. This matches a note in the "Intel
8255x 10/100 Mbps Ethernet Controller Family Open Source Software Developer
Manual", which says that the hardware parse bit should be set when sending
these types of packets.

There have also been unconfirmed reports of similar problems when
transmitting TCP packets, which should not be affected by the above
mentioned change because the hardware parse bit was already being set
if the stack requested hardware checksumming of the packet. If the
problem remains, the use of the IPCB structure can be disabled to
cause the driver to fall back to using the older 82559 interface with
82550-based cards by setting
hint.fxp.UNIT_NUMBER.ipcbxmit_disable
to a non-zero value at boot time, or using kenv to set this variable
before using kldload to load the fxp driver.

Approved by: re (jhb)

Add a tunable/sysctl "hw.fxp_noflow" which disables flow control support
on if_fxp cards. When flow control is enabled, if the operating system
doesn't acknowledge the packet buffer filling, the card will begin to
generate ethernet quench packets, but appears to get into a feedback
loop of some sort, hosing local switches. This is a temporary workaround
for 5.1: the ability to configure flow control should probably be
exposed by some or another management interface on ethernet link layer
devices.

Approved by: re (bmah)
Reviewed by: mux

Fix tpyo in last commit.

Noticed by: kuriyama-san

Get rid of the redundant 'gone' field, and overload suspend instead.
Check for suspend before the device polling, rather than after it.
Check to see if the current thread owns the lock in ioctl and return
EBUSY if it does.

This advances the locking to the point that I can eject my fxp card 10
times in a row, but I agree with Jeff Hsu that we need to get the
network layer locking finished before chasing more of the races here
(actually, he doesn't think this set is worth it even). There's a
number of races between FXP_LOCK in detach and all other users of
FXP_LOCK, and this gets back to the 'device with sleepers being
forcibly detached' problem as well...

(5) from last commit was omitted by mistake:

(5) Return immediately from fxp_intr() if gone is set.

Fix 5 bugs:
1) always call fxp_stop in fxp_detach. Since we don't read from
the card, there's no need to carefully look at things with
bus_child_present.
2) Call FXP_UNLOCK() before calling bus_teardown_intr to avoid
a possible deadlock reported by jhb.
3) add gone to the softc. Set it to true in detach.
4) Return immediately if gone is true in fxp_ioctl
5) Return immediately if gone is true in fxp_intr

Make fxp(4) INTR_MPSAFE (but do not enable MPSAFE just yet):
- Add fxp_start_body() and change fxp_start() to just acquire locks and
then call fxp_start_body(). Places that would call fxp_start() with
locks held (mutex recursion) now call fxp_start_body() directly.
Remove MTX_RECURSE flag from sc_mtx. [gallatin]
- Change fxp_attach() to work without the softc lock, saving interrupt
hooking until the head of fxp_attach().
- Call ether_ifattach() before overriding ifp parameters. This reverts
part of 1.155.
- Remove multiple error paths in fxp_attach().
- Teardown interrupt in fxp_detach() before unlocking the softc.
- Make sure mutex is not held in fxp_release()
- Delete the miibus instance and/or self in fxp_release(), not in
fxp_detach(). This can happen if attach fails partway through.
- Move ifmedia_removeall to fxp_release() since attach may fail after
media have been allocated.
- Add locking to fxp_suspend, fxp_resume, fxp_start, fxp_intr,
fxp_poll, fxp_tick, fxp_ioctl, fxp_watchdog.
- Pass in ifp to fxp_intr_body since its callers sometimes already use
it.
- Add compatibility define for INTR_MPSAFE for 4.x. [gallatin]
- You don't need to bzero softc.

Ideas from: gallatin, mux
Tested by: >400M packets of dd/ssh, NFS, ping on i386 UP

Update comment to match reality.

- Don't call pci_enable_io() in drivers (unless needed for resume).
- Don't test memory/port status and emit an error message; the PCI
bus code will do this now.

- Express hard dependencies on bus (pci, isa, pccard) and
network layer (ether).
- Don't abuse module names to facilitate ifconfig module loading;
such abuse isn't really needed. (And if we do need type information
associated with a module then we should make it explicit and not
use hacks.)

Use pci_enable_{busmaster|io}() instead of directly writing into
PCI configuration register.

Submitted by: mdodd

Before attaching device set PCIM_CMD_PORTEN in addition to
PCIM_CMD_MEMEN and PCIM_CMD_BUSMASTEREN, becaise some braindead
BIOSes (such as one found in my vprmatrix notebook) forget
to initialize it properly resulting in attachment failure.

- Call ether_ifdetach() before shutting down the hardware.
- Remove a useless device_is_alive() check.
- Disable interrupts if bus_child_present() so that this
check is more useful.

This fixes the hangs I was seeing when unloading the fxp driver.

Suggestions from: hsu, njl

- Clean up the fxp_release() and fxp_detach() functions.
- Be sure to teardown the interrupt first so that "kldunload if_fxp"
doesn't panic the box. It's now deadlocking rather than crashing,
which isn't really better, but I'm unsure this is fxp(4)'s fault.
- Change a bus_dmamap_sync() call to also do a BUS_DMASYNC_PREREAD
now that we can pass several operations.

- Pass a busdma tag and a busdma map to fxp_dma_wait() so that
it can do the necessary bus_dmamap_sync() calls.
- While I'm here, reorder arguments to match other functions.

Add an XXX comment for the atomic operation in the __alpha__
case so that it doesn't confuse more people. Use the more
correct atomic_clear_16() instead of atomic_clear_short().

- Endian fixes.
- 6 -> ETHER_ADDR_LEN.

Fix the hangs people have been seeing. For some reason, the
atomic operation change caused this, so backout it until I
can figure out what's wrong with it.

Correct the maxsize and maxsegsz parameters for the
bus_dma_tag_create() calls. Without this, fxp(4) + PAE
would consume insane amounts of bounce pages.

Remove an erroneous htole16(). The byte_count field in the
struct fxp_cb_config is a 6-bit field, not a 16-bit integer
as in struct fxp_cb_tx.

Move a bus_dmamap_sync() to the correct place.

Because alpha can't access memory in 16-bit granularity,
we're using an atomic operation to clear the suspend flag
in fxp_start(). Since other architectures may need the
same thing, we want to do it all the time and not only
in the __alpha__ case. However, we don't want to use
atomic operations on 16-bit integers, because those may
not be available on any architecture. We're thus faking
a 32-bit atomic operation here. This patch also deals
with endianness here.

Use __FBSDID.

- Instead of rolling our own alignment-safe function, use le32enc()
which deals with both endianness and alignment issues.
- Collect low-hanging fruits for endianness safety.
- Use 0xffffffff instead of -1 where appropriate.

- Change a FXP_NRFABUFS which would have been a FXP_NTXCB.
- Correct some bus_dmamap_sync() calls.

Submitted by: jake

Setup our interrupt only at the end of fxp_attach(), when all
other allocations/initializations have been successful. I kinda
doubt it will fix the recent breakage that some people are seeing,
but this could have caused problems for sure.

Remove useless initialization.

Remove all the bogus volatile qualifiers from the structs definitions
and associated evil casts to discard them.

Convert the fxp(4) driver to the busdma API.

This patch is rather big because I had to significantly redesign
the driver to make the busdma conversion possible. Most notably,
hardware and software structures were carefully splitted to get
rid of all the structs overlapping evilness.

Special thanks to phk and Richard Puga <puga@mauibuilt.com> for
providing me with fxp(4) hardware to do this work.

Thanks to marcel for testing this on ia64, and to Fred Clift
<fclift@verio.net> for testing this on alpha.

Tested on: i386, ia64, alpha

Correct names for fxp devices. Sort data by devid in
fxp_ident_table.

PR: kern/48699
Submitted by: Sergey A. Osokin <osa@FreeBSD.org.ru>
Obtained from: NetBSD (the device strings, that is)
MFC after: 4 weeks

Finish driving a stake through the heart of netns and the associated
ifdefs scattered around the place - its dead Jim!

The SMB stuff had stolen AF_NS, make it official.

Remember to set if_capenable when setting up checksum offload in fxp_attach().

Pointed out by: jlemon

As previously threatened, add TCP/IP checksum offload support to
the fxp driver. This is enabled only for the 82550/82551 chips
(PCI revision code 12 or 13). RX and TX checksum offload are
both supported. Transmit offload is limited to TCP and UDP only
right now: there seems to be a problem with IP header checksumming
on transmit in some cases.

This chip has hardware VLAN support as well. I hope to enable
support for this eventually.

Back out M_* changes, per decision of the TRB.

Approved by: trb

Add PCI id for fxp(Intel Pro/100 M Mobile Connection).

PR: i386/41915
Submitted by: Ross A. Lippert <ripper@eskimo.com>
MFC after: 1 week

Remove M_TRYWAIT/M_WAITOK/M_WAIT. Callers should use 0.
Merge M_NOWAIT/M_DONTWAIT into a single flag M_NOWAIT.

network interface driver changes:

o don't strip the Ethernet header from inbound packets; pass packets
up the stack intact (required significant changes to some drivers)
o reference common definitions in net/ethernet.h (e.g. ETHER_ALIGN)
o track ether_ifattach/ether_ifdetach API changes
o track bpf changes (use BPF_TAP and BPF_MTAP)
o track vlan changes (ifnet capabilities, revised processing scheme, etc.)
o use if_input to pass packets "up"
o call ether_ioctl for default handling of ioctls

Reviewed by: many
Approved by: re

Properly fix the occassional random crash issue that revision 1.142
just limited to the DEVICE_POLLING case. This removes the FXP_RFA_RNRMARK
hack, and replaces it with a softc flag that is used to record when
the handling of a no-resource condition was deferred due to running
out of DEVICE_POLLING cycles. This was tested on -stable, but the
code is essentially the same as in -current. It should only affect
the case where DEVICE_POLLING is defined.

The details of the mechanism behind the crashes are still uncertain
but the most likely cause seems to be some kind of hardware confusion
when the no-resource recovery code is accidentally invoked while
the receiver is still active. This could have happened if the
hardware left the 0x4000 bit of the RFA status word set. The comments
in the commit log for revision 1.142 stating that the driver could
clash with the hardware writing to this status word were not correct.

Tested by: Guy Helmer <ghelmer@palisadesys.com>

Revision 1.136 introduced two features that may cause undefined
behaviour of the hardware: a possibly reserved bit of the receive
descriptor (RFA) `status' field is borrowed to record no-resource
(RNR) events, and the same status field is read and written to at
a time that may clash with the hardware updating this field.

There is no hardware documentation available to determine if these
things are safe to do; the second issue almost certainly isn't, and
the first is only safe if there is documentation saying that this
bit is free to be used by the driver. The PR referenced below
provides extremely convincing evidence that the changes cause random
crashes on some (unusual) hardware.

Since these features are only required by the DEVICE_POLLING case,
this commit makes their use conditional on that option. It does not
change the DEVICE_POLLING case, but at least people with the rare
hardware on which this code causes problems can now avoid the crashes
by not enabling DEVICE_POLLING.

PR: kern/42260
Reviewed by: luigi
Problem revision found by: Pawel Malachowski <pawmal@unia.3lo.lublin.pl>
Tested by: Pawel Malachowski <pawmal@unia.3lo.lublin.pl>
MFC after: 1 week

'&' is not needed to pointerize functions.

Spotted by: FlexeLint

Add some PCI id's for fxp. I've only tested 0x103B, but the Intel
Linux driver defines 0x103[B-E] so add those as well.

Obtained from: Intel Linux e100 driver
MFC: Immediately if re@ allows it, otherwise after 4.7-RELEASE

Increase size of ifnet.if_flags from 16 bits (short) to 32 bits (int). To avoid
breaking application ABI use unused ifreq.ifru_flags[1] for upper 16 bits in
SIOCSIFFLAGS and SIOCGIFFLAGS ioctl's.

Reviewed by: -hackers, -net

use the new interface to ether_input(), with eh = NULL and
the MAC header in the mbuf.

MFC after: 3 days

Use m_getcl() to allocate buffers for the receive ring.

MFC after: 3 days

Fix handling of Receiver Not Ready errors when doing polling.
Also take this chance to cleanup the code in fxp_intr_body.

Add a missing block of code to disable interrupts when
reinitializing the interface while doing polling (the RELENG_4
version was correct).

MFC after: 3 days

Forced commit.

Rev 1.134 actually reverts rev 1.132, NOT rev 1.131.

Revert rev 1.131.

1.131 is slightly broken, and I would commit the fix to that here, but it
has been reported that any deviation from the original code is causing
problems with some 82557 chips, causing them to lock hard.

Until those issues have been figured out, going back to the original
code is the best plan.

Frustrated: Silby

whitespace commit: fix indentation in fxp_intr_body.
This is also done in preparation of a subsequent fix
for the handling of RNR conditions in polling mode.

Fix if_timer logic so that there is always a timeout pending if there
are packets queued for transmission.

This driver is strange -- it never sets IFF_OACTIVE, so all
transmissions always cause a call to fxp_start. However, if the
link gets stuck, there was nothing to reset it, so there was still
a possibility of lockups.

MFC after: 3 days

Add another Intel chipset (i82562).

PR: 39974
Submitted by: Morten Aaboe Jensen <morten@codemonkey.dk>
MFC after: 1 day

Add device id. for fxp chip on Intel D845EPT2L boards. This seems to
make the onboard NIC work.

Sponsored by: Vernier Networks
MFC after: 1 day

Change callers of mtx_init() to pass in an appropriate lock type name. In
most cases NULL is passed, but in some cases such as network driver locks
(which use the MTX_NETWORK_LOCK macro) and UMA zone locks, a name is used.

Tested on: i386, alpha, sparc64

Remove mbuf exhaustion warning messages; these are handled by the
mbuf system in a rate-limited fashion now.

Reviewed by: luigi
MFC after: 1 week

Initialize the sysctl_ctx list early, which avoids a panic in case other
allocatiosn fail and fxp_release() is called.

Explicitly reload the multicast filters when the hardware is reinitialized
instead of relying on the previous filters to be present.

Back out r1.125, as a reset is needed to unload any existing microcode,
(which clears the multicast addresses), as it is superceded by this change.

Possibly typo fix (s/FXP_PORT_SOFTWARE_RESET/FXP_PORT_SELECTIVE_RESET/)
in fxp_stop().

Reference: http://www.freebsd.org/cgi/mid.cgi?id=7md718f0qo.wl@waterblue.imgsrc.co.jp
Submitted by: Keiichi SHIMA <keiichi@iij.ad.jp>

Fix (again) some blatent style bugs in DEVICE_POLLING code.

Device Polling code for -current.

Non-SMP, i386-only, no polling in the idle loop at the moment.

To use this code you must compile a kernel with

options DEVICE_POLLING

and at runtime enable polling with

sysctl kern.polling.enable=1

The percentage of CPU reserved to userland can be set with

sysctl kern.polling.user_frac=NN (default is 50)

while the remainder is used by polling device drivers and netisr's.
These are the only two variables that you should need to touch. There
are a few more parameters in kern.polling but the default values
are adequate for all purposes. See the code in kern_poll.c for
more details on them.

Polling in the idle loop will be implemented shortly by introducing
a kernel thread which does the job. Until then, the amount of CPU
dedicated to polling will never exceed (100-user_frac).
The equivalent (actually, better) code for -stable is at

http://info.iet.unipi.it/~luigi/polling/

and also supports polling in the idle loop.

NOTE to Alpha developers:
There is really nothing in this code that is i386-specific.
If you move the 2 lines supporting the new option from
sys/conf/{files,options}.i386 to sys/conf/{files,options} I am
pretty sure that this should work on the Alpha as well, just that
I do not have a suitable test box to try it. If someone feels like
trying it, I would appreciate it.

NOTE to other developers:
sure some things could be done better, and as always I am open to
constructive criticism, which a few of you have already given and
I greatly appreciated.
However, before proposing radical architectural changes, please
take some time to possibly try out this code, or at the very least
read the comments in kern_poll.c, especially re. the reason why I
am using a soft netisr and cannot (I believe) replace it with a
simple timeout.

Quick description of files touched by this commit:

sys/conf/files.i386
new file kern/kern_poll.c
sys/conf/options.i386
new option
sys/i386/i386/trap.c
poll in trap (disabled by default)
sys/kern/kern_clock.c
initialization and hardclock hooks.
sys/kern/kern_intr.c
minor swi_net changes
sys/kern/kern_poll.c
the bulk of the code.
sys/net/if.h
new flag
sys/net/if_var.h
declaration for functions used in device drivers.
sys/net/netisr.h
NETISR_POLL
sys/dev/fxp/if_fxp.c
sys/dev/fxp/if_fxpvar.h
sys/pci/if_dc.c
sys/pci/if_dcreg.h
sys/pci/if_sis.c
sys/pci/if_sisreg.h
device driver modifications

Tone down and remove some obnoxious warnings that are slightly overkill.

Emit a warning if the mbuf or mbuf cluster allocation failed.

Requested by: Mike Barcroft

Aargh. I really shouldn't do late night commits. Remove a floating point
multiply, and replace it with a close equivalent. 1.488 =~ 1.5

Add support for loadable microcode which implements interrupt coalescing
and packet bundling. Make the microcode settings controllable via sysctl
and loader tunables.

Submitted by: Marko Zec <zec@tel.fer.hr>
(with some munging and dynamic sysctl support by me)

Also extend the workaround for Dynamic Standby mode to later '559 chips,
not just the ICH2 variants.

Deconditionalize vlan support.

Systems based on the ICH2/ICH2-M chip from Intel have a defect where
the chip can cause a PCI protocol violation in under certain scenarios.
The workaround is to rewrite the EEPROM to disable Dynamic Standby Mode.

Once the EEPROM is rewritten, the system needs to be rebooted in order
to pick up the new settings.

This has been tested on several ICH2/ICH2-M systems, found in 815E based
boards, and usually identified by the presence of the 82562 ET/EM PHY.

Thanks to: Mike Tansca, Paul Saab for samples of the problematic boards.

Reset the device's powerstate to d0 when resuming from a suspend
operation, not just when we initally attach to the device.

Submitted by: warner

Only turn on MWI if the PCI configuration word indicates that it
is supported, in addition to checking for a valid cacheline size.
Add a missing splx() in fxp_tick that got dropped.

Found by: peter
MFC in: 3 days

While in the interrupt loop, check for a bogus interrupt value of 0xff.
This may be returned if the underlying hardware is a pc-card which has
been ejected.

Reviewed by: warner

Add workaround for embedded NICs, in particular, the 815E boards.
There appears to be a bug where the chip will lock up when running
in 10Mb/s mode.

Use " |= " to enable special media handling for fxp with no MII, instead
of " &= ". Also change the MII PHY device mask to check the correct bits.

Cookie to: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
Pointy hat to: me

Remove safety belt that checks for miibus in the config file. This
was only intended for -stable, not -current.

Add few cosmetic style fixes, and some debug information for SCB timeouts.
Add VLAN support, obtained from Pedro J. Lobo (through Mike Tancsa).

Add some performance features to the fxp driver. If the chip is not
a 82557 (e.g.: a newer chip) then:

+ enable MWI, if the PCI configuration indicates the system supports it
+ enable usage of extended TxCB, for better performance
+ enable hardware flow control. FC frames will be passed up to the
host only if promiscuous mode is enabled.

Fix a whitespace bogon.

Pointed out by: ps

Convert the fxp driver to miibus, which involves ripping out the PHY
logic and media bits. Support for Intel PHYs can now be found in
dev/mii/inphy.c.

Clean up the driver, and add various 82558 and 82559 specific bits.

A better mousetrap: use device hints, as in:

hint.fxp.0.prefer_iomap="1"

to set IO vs. Memory space mapping.

Convert if_multiaddrs from LIST to TAILQ so that it can be traversed
backwards in the three drivers which want to do that.

Reviewed by: mikeh

Use LIST_FOREACH() to traverse ifp->if_multiaddrs list, instead of
<sys/queue.h> implementation details.

Created with: /usr/sbin/sed
Reviewed with: /sbin/md5

Allow fxp to configure in I/O space if the user wants it and specifies
an override as a loader settable variable (fxp_iomap). fxp_iomap is
a bitmap of fxp units that should be configured to use PCI I/O space
in stead of PCI Memory space.

Reviewed by: Kees Jan Koster <dutchman@tccn.cs.kun.nl>, dg@freebsd.org

Implement MTX_RECURSE flag for mtx_init().
All calls to mtx_init() for mutexes that recurse must now include
the MTX_RECURSE bit in the flag argument variable. This change is in
preparation for an upcoming (further) mutex API cleanup.
The witness code will call panic() if a lock is found to recurse but
the MTX_RECURSE bit was not set during the lock's initialization.

The old MTX_RECURSE "state" bit (in mtx_lock) has been renamed to
MTX_RECURSED, which is more appropriate given its meaning.

The following locks have been made "recursive," thus far:
eventhandler, Giant, callout, sched_lock, possibly some others declared
in the architecture-specific code, all of the network card driver locks
in pci/, as well as some other locks in dev/ stuff that I've found to
be recursive.

Reviewed by: jhb

Add power state manipulation to the fxp driver. Some people have
claimed that their Intel NIC is comatose after a warm boot from Windoze.
This is most likely due to the card getting put in the D3 state. This
should bring it back to life.

Convert more malloc+bzero to malloc+M_ZERO.

Submitted by: josh@zipperup.org
Submitted by: Robert Drehmel <robd@gmx.net>

Make usual 1-line cardbus support modification.

I'm committing this over an Intel PRO-100 CardBus II card.

Catch up to moving headers:
- machine/ipl.h -> sys/ipl.h
- machine/mutex.h -> sys/mutex.h

Remove unneeded #include <machine/clock.h>

Make mutex name reflect device driver name.
Destroy mutex when detaching the device.
Submitted by: John Baldwin <jhb@FreeBSD.ORG>

Don't #include <sys/proc.h>, since machine/mutex.h does it now.

Add the PCI device ID for the on-board ethernet controllers on the
Intel 815E motherboard, which I believe is an i82562. Seems to work
just fine with the fxp driver.

Removed NetBSD support, which bit-rotted long ago.
Changed new SMP locking macros given the new situation.

Added a couple more missing FXP_SPLVAR()'s.

As a minor optimization, do suspended checking more like it was originally
in the PR - before the while loop.

Added missing FXP_SPLVAR() to fxp_intr().

Attempt to replicate the new fxp SMP locking in the changes committed
in the previous (APM suspend/resume) commit.

Added support for APM suspend/resume.

PR: 18756
Submitted by: mike ryan <msr@elision.org>, with modifications by me.

Add include of proc.h to make compile without SMP defined. This
change is likely interm, the include happens automagically
when SMP is defined.

Obtained from: Jason Evans.

Add locking to make able to run without the Giant lock being held. This
is enabling as all entries are still called with Giant being held.
Maintaining compatability with NetBSD makes what should be very simple
kinda ugly.

Reviewed by: Jason Evans

Fix a bug brought to light by the people working on SMPng. I don't quite
understand exactly what it is about SMPng that tickles this bug. What I
do know is that the foo_init() routine in most drivers is often called
twice when an interface is brought up. One time is due to the ifconfig(8)
command calling the SIOCSIFFLAGS ioctl to set the IFF_UP flag, and another
is probably due to the kernel calling ifp->if_init at some point. In any
case, the SMPng changes seem to affect the timing of these two events in
such a way that there is a significant delay before any packets are sent
onto the wire after the interface is first brought up. This manifested
itself locally as an SMPng test machine which failed to obtain an address
via DHCP when booting up.

It looks like the second call to fxp_init() is happening faster now than
it did before, and I think it catches the chip while it's in the process
of dealing with the configuration command from the first call. Whatever
the case, a FXP_CSR_SCB_CNA interrupt event is now generated shortly after
the second fxp_init() call. (This interrupt is apparently never generated
by a non-SMPng kernel, so nobody noticed.)

There are two problems with this: first, fxp_intr() does not handle the
FXP_CSR_SCB_CNA interrupt event (it never tests for it or does anything
to deal with it), and second, the meaning of FXP_CSR_SCB_CNA is not
documented in the driver. (Apparently it means "command unit not active.")
Bad coder. No biscuit.

The fix is to have the FXP_CSR_SCB_CNA interrupt handled just like the
FXP_SCB_STATACK_CXTNO interrupt. This prevents the state machine for
the configuration/RX filter programming stuff from getting wedged for
several seconds and preventing packet transmission.

Noticed by: jhb

"Fix" cast qualifier warnings using the uintptr_t intermediate trick.

Fix an alpha-only race which causes the transmit side of the chip to
lock up under moderate to heavy load.

The status & command fields share a 32-bit longword. The programming
API of the eepro apparently requires that you update the command field
of a transmit slot that you've already given to the card. This means
the card could be updating the status field of the same longword at
the same time. Since alphas can only operate on 32-bit chunks of
memory, both the status & command fields are loaded from memory &
operated on in registers when the following line of C is executed:

sc->cbl_last->cb_command &= ~FXP_CB_COMMAND_S;

The race is caused by the card DMA'ing up the status at just the wrong
time -- after it has been loaded into a register & before it has been
written back. The old value of the status is written back, clobbering
the status the card just DMA'ed up. The fact that the card has sent
this frame is missed & the transmit engine appears to hang.

Luckily, as numerous people on the freebsd-alpha list pointed out, the
load-locked/store-conditional instructions used by the atomic
functions work with respect changes in memory due to I/O devices. We
now use them to safely update the command field.

Tested by: Bernd Walter <ticso@mail.cicely.de>

Make all Ethernet drivers attach using ether_ifattach() and detach using
ether_ifdetach().

The former consolidates the operations of if_attach(), ng_ether_attach(),
and bpfattach(). The latter consolidates the corresponding detach operations.

Reviewed by: julian, freebsd-net

Implemented some optimizations which result in 14 fewer instructions in the
receive path.

Added support for the i82559ER (10/100Mbps NIC for embedded applications).

Product device ID provided by: Les Biffle <les@ns3.safety.net>

Move code to handle BPF and bridging for incoming Ethernet packets out
of the individual drivers and into the common routine ether_input().
Also, remove the (incomplete) hack for matching ethernet headers
in the ip_fw code.

The good news: net result of 1016 lines removed, and this should make
bridging now work with *all* Ethernet drivers.

The bad news: it's nearly impossible to test every driver, especially
for bridging, and I was unable to get much testing help on the mailing
lists.

Reviewed by: freebsd-net

Added support for cards and on-motherboard NICs that use an SEEPROM
address size that is different than the standard 6bits. This fixes
support for the Compaq NC3121 card, certain newer Intel Pro/100+
cards, and should also fix integrated NICs on SuperMicro and Compaq
motherboards.
The auto-sizing algorithm was taken from NetBSD (thanks!), which I
think got it from Linux originally.
Thanks also to Andrew Sparrow <spadger@best.com> and Joe Moore
<jomor@ahpcns.com> for supplying me with unworking Compaq and Intel
cards to develop and test the fixes with.

Make the fxp driver work on alpha, rather than panic the machine on boot
and/or when using the card.

o Convert the driver to using bus_space. This allows alphas with
fxp's to boot, rather than panic'ing because rman_get_virtual()
doesn't really return a virtual address on alphas.

o Fix an alpha unaligned access error caused by some misfeature of
gcc/egcs: if link_addr & rbd_addr in the fxp_rfa struct are 32 bit
quantities, egcs will assume they are naturally aligned. So it will do
a ldl & some shifty/masky to twiddle 16 bit values in fxp_lwcopy().
However, if they are 16-bit aligned, the ldl will actually be done on
a 16-bit aligned value & we will panic with an unaligned access
error... Changing their definition to an array of chars seems to fix
this. I obtained this from NetBSD.

I've tested this on both i386 & alpha.

Remove NBPF conditionality of bpf calls in most of our network drivers.

This means that we will not have to have a bpf and a non-bpf version
of our driver modules.

This does not open any security hole, because the bpf core isn't loadable

The drivers left unchanged are the "cross platform" drivers where the respective
maintainers are urged to DTRT, whatever that may be.

Add a couple of missing FreeBSD tags.

Tweak these for what I hope is the last time: change the DRIVER_MODULE()
declaration for the interface driver from "foo" to "if_foo" but leave the
declaration for the miibus attached to the interface driver alone. This
lets the internal module name be "if_foo" while still allowing the miibus
instances to attach to "foo."

This should allow ifconfig to autoload driver modules again without
breaking the miibus attach.

Un-do the changes to the DRIVER_MODULE() declarations in these drivers.
This whole idea isn't going to work until somebody makes the bus/kld
code smarter. The idea here is to change the module's internal name
from "foo" to "if_foo" so that ifconfig can tell a network driver from
a non-network one. However doing this doesn't work correctly no matter
how you slice it. For everything to work, you have to change the name
in both the driver_t struct and the DRIVER_MODULE() declaration. The
problems are:

- If you change the name in both places, then the kernel thinks that
the device's name is now "if_foo", so you get things like:

if_foo0: <FOO ethernet> irq foo at device foo on pcifoo
if_foo0: Ethernet address: foo:foo:foo:foo:foo:foo

This is bogus. Now the device name doesn't agree with the logical
interface name. There's no reason for this, and it violates the
principle of least astonishment.

- If you leave the name in the driver_t struct as "foo" and only
change the names in the DRIVER_MODULE() declaration to "if_foo" then
attaching drivers to child devices doesn't work because the names don't
agree. This breaks miibus: drivers that need to have miibuses and PHY
drivers attached never get them.

In other words: damned if you do, damned if you don't.

This needs to be thought through some more. Since the drivers that
use miibus are broken, I have to change these all back in order to
make them work again. Yes this will stop ifconfig from being able
to demand load driver modules. On the whole, I'd rather have that
than having the drivers not work at all.

Change the name we register with DRIVER_MODULE() to include the leading
"if_".

Reviewed by: msmith, wpaul

Recognise the new 82559 chip id as used on the InBusiness 10/100 adapter.
I have an 82559 card with the same id as the other 8255[78] chips, but
that was made with a date code of 0699 (June 99). The submitter shows
this working with the probe etc, but doesn't actually say it works as
on the ethernet. :-) Assuming it does, this is a RELENG_3 merge candidate.
Submitted by: Steven E Lumos <slumos@sam.ISRI.UNLV.EDU>

$Id$ -> $FreeBSD$

Rename bpfilter to bpf.

Fix two warnings.

Move the declaration of the interrupt type from the driver structure
to the BUS_SETUP_INTR call.

Bring the 'new-bus' to the i386. This extensively changes the way the
i386 platform boots, it is no longer ISA-centric, and is fully dynamic.
Most old drivers compile and run without modification via 'compatability
shims' to enable a smoother transition. eisa, isapnp and pccard* are
not yet using the new resource manager. Once fully converted, all drivers
will be loadable, including PCI and ISA.

(Some other changes appear to have snuck in, including a port of Soren's
ATA driver to the Alpha. Soren, back this out if you need to.)

This is a checkpoint of work-in-progress, but is quite functional.

The bulk of the work was done over the last few years by Doug Rabson and
Garrett Wollman.

Approved by: core

Turn on PCI bus mastering in driver attach routine
to avoid hanging the system if the BIOS has not
initialized the interface.

PR: 10150
Reviewed by: dg

MF22... add bridging support to the device drivers. Without this
bridging cannot work on -current/releng3!

Improved reporting of autodetected speed and duplex.
Now should be able to report speed for cards using NatSemi PHY.
(if you have one please let me know if it works as I
only have the Intel version)

Reviewed by: David Greenman <dg@root.com>

Define more registers in the PHY unit and use them to report back
the result of the media auto negotiation.

Reviewed by: David Greenman <dg@freebsd.org>

Fix warnings related to -Wall -Wcast-qual

Fix warnings in preparation for adding -Wall -Wcast-qual to the
kernel compile

Fix warnings in preparation for adding -Wall -Wcast-qual to the
kernel compile.

This commit includes significant work to proper handle const arguments
for the DDB symbol routines.

pci_device pd_probe function changed from returning char * to returning
const char *. Originally I was going to add casts from const char * to
char * in some of the pci device drivers, but the reality is that the
pci device probes return constant quoted strings.

Defer rundown (m_freem) of completed transmit buffers for no longer
than 1 second.

Clear out transmit descriptor memory in fxp_attach when it's malloced.
fxp_stop is called as the first thing in fxp_init, and if the tx desc
list has junk in it, the system may panic. This bug showed up as a side
effect of the changes in rev 1.56, but has been in the code since the
beginning.

Fixed mbuf leak in fxp_stop().

Implemented a more sophisticated mechanism for handling transmitter
interrupts which now defers them until the transmit queue if filled
up with completed buffers. This has two advantages: first, it reduces
the number of transmitter interrupts to just 1/120th of the rate
that they occured previously, and two, running down many buffers
at once has much improved cache effects.

Added 82555B support for media status.

Killed unused variable/assignment.

Seventy-odd "its" / "it's" typos in comments fixed as per kern/6108.

Support compiling with `gcc -ansi'.

Added support for the 82553 and 'B' 82555 PHY.

Removed unused #includes.

Staticize.

Make INET a proper option.

This will not make any of object files that LINT create change; there
might be differences with INET disabled, but hardly anything compiled
before without INET anyway. Now the 'obvious' things will give a
proper error if compiled without inet - ipx_ip, ipfw, tcp_debug. The
only thing that _should_ work (but can't be made to compile reasonably
easily) is sppp :-(

This commit move struct arpcom from <netinet/if_ether.h> to
<net/if_arp.h>.

Removed unused #includes.

Rewrote fxp_start() for better clarity and efficiency.

Fixed a bug where input packets were counted twice - messing up the
stats.

Killed a gratuitous assignment in a NetBSD case.

Two changes which should make the system less suseptible to receiver
overruns (not that it was a problem, but it could be):

1) Doubled the number of receive buffers in the DMA chain to 64.
2) Do packet receive processing before transmit in the interrupt routine.

Work around a bug in the 82557 NIC where the receiver will lock up
if it is in 10Mbps mode and gets certain types of garbage prior to
the packet header. The work-around involves reprogramming the
multicast filter if nothing is received in some number of seconds
(currently set at 15). As a side effect, implemented complete support
for multicasting rather than the previous 'receive all multicasts'
hack, since we now have the ability to program the filter table.
Fixed a serious bug which crept in with the timeout() changes;
the cookie was only saved on the first timeout() call in fxp_init()
and wasn't updated in the most common place in fxp_stats_update()
when the timeout was rescheduled. This bug would have resulted in
an eventual panic if fxp_stop() was called (which happens when any
interface flags are changed, for example).
Fixed a bug in Alpha support that would have caused the TxCB
descriptor chain to span a page boundry, causing serious problems
if the pages didn't happen to be contiguous.
Removed some gratuitous bit masking that was left over from an
older implementation.
Fixed a bug where too much was copied from the configuration
template, spilling over into memory that followed it.
Fixed handling of if_timer...it was cleared too early in some cases.

Update for new callout interface.

Changes to support NetBSD and the new ifmedia extensions.
Submitted by: Jason Thorpe <thorpej@netbsd.org>

Removed unused #includes.

Added support for the Seeq 80c24 PHY; does nothing except disable the
unsupported warning message for it.

Minor optimization in fxp_intr.

Added support for the Intel 82555 PHY chip which is being used on newer
Pro/100B cards. Full duplex should work now, although it hasn't been
tested.

Check that the received packet length indicated by the card is at least
large enough to contain the ethernet header. There appears to be a
condition where the card can return "0" in some failure cases, and this
causes bad things to happen (a panic).

Made a couple of minor optimizations that improve performance of the
common case of the interrupt routine by about 20%.

Don't include <sys/ioctl.h> in the kernel. Stage 2: include
<sys/sockio.h> instead of <sys/ioctl.h> in network files.

Added support for newer cards that have the DP83840A PHY chip.
Fixed a bug in fxp_mdi_write - a hex number was missing a preceding 0x
and this was causing the routine to not wait for a PHY write to complete.
Added support for link0, link1, and link2 flags to toggle auto-
negotiation, 10/100, and half/full duplex:

link0 disable auto-negotiation

When set, these flags then have meaning:

-link1 10Mbps
link1 100Mbps
-link2 half duplex
link2 full duplex

...needs a manual page.

Fixed two deficiencies in the driver that have existed since it was
written:

1) Full duplex mode is now supported (and works!)
2) The 10Mbps-only PCI Pro/10 should now work (untested, however)

Thanks to Justin Gibbs for providing a PCI bus analyzer trace while the
Intel Windows driver was configuring the board...this made it possible
to figure out the mystery bit that I wasn't setting in the PHY for full
duplex to work.

Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are not
ready for it yet.

Changed several configuration options:

Disabled the DMA byte counters - I had it this way originally and this is
the recommended setting.
Set crscdt to CRS only (0) since this is what it should be for an MII PHY.
Also fixed some comments.

Do "selective" reset rather than full reset...the manual specifically
says not to do the full reset because it can lock up the PCI bus if the
chip is active. Added various PORT command definitions to facilitate
this.

Don't include the short-frames counter in with the input errors. This
counter is incremented on all short frames, including those that are
the result of collisions.

Make the long-awaited change from $Id$ to $FreeBSD$

This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.

Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.

Use the new if_multiaddrs list for multicast addresses rather than the
previous hackery involving struct in_ifaddr and arpcom. Get rid of the
abominable multi_kludge. Update all network interfaces to use the
new machanism. Distressingly few Ethernet drivers program the multicast
filter properly (assuming the hardware has one, which it usually does).

1) Implement SIOCSIFMTU in ether_ioctl(), and change ether_ioctl's return
type to be int so that errors can be returned.
2) Use the new SIOCSIFMTU ether_ioctl support in the few drivers that are
using ether_ioctl().
3) In if_fxp.c: treat if_bpf as a token, not as a pointer. Don't bother
testing for FXP_NTXSEG being reached in fxp_start()...just check for
non-NULL 'm'. Change fxp_ioctl() to use ether_ioctl().

Fixed obsolete comment.

Removed nested include if <sys/socket.h> from <net/if.h> and
<net/if_arp.h> and fixed the things that depended on it. The nested
include just allowed unportable programs to compile and made my
simple #include checking program report that networking code doesn't
need to include <sys/socket.h>.

Backed out one of my "performance optimizations" as it results in sometimes
not resuming the NIC as required for transmit. Thanks to Alan Cox
<alc@cs.rice.edu> for noticing this.
Added another performance optimization to compensate. :-)

Changed crscdt to 1...strange, but this seems to be needed for some reason
despite what the manual says.

Fixed a bug with the management of the pointer to the first TxCB in the
ring that caused wrong things to happen sometimes.
Doubled the number of transmit descriptors to 128 so that the internal
FIFO in the NIC can be fully filled when dealing with small packets.
Several minor performance improvements.

Fixed a bug in the receive buffer allocation code that resulted in a
panic if an mbuf cluster couldn't be allocated. This was caused by a
failure to re-initialize m_data when the old mbuf/mbcluster was recycled.

When the devconf stuff was ripped out of the kernel, the ripper neglected
to deal with the fact that we relied on devconf to do the shutdown
callouts in various drivers. The changes in this commit are to add support
for device shutdown in this driver via the new at_shutdown() mechanism.
Similar changes need to be made to all of the other drivers that need
a shutdown routine called (if_de.c comes to mind immediately).

Implemented a better, dynamic, mechanism for adjusting the transmit
threshold.

Increased transmit threshold to 1024 bytes to fix a problem with underruns
on machines with poor PCI performance.

Remove devconf, it never grew up to be of any use.

Set ifnet.baudrate for ethernet / FDDI interfaces too. Makes
SNMP slightly more informative

Reviewed by: Garrett Wollman

Removed sections 3 and 4 from my copyright.

Clean up Ethernet drivers:
- fill in and use ifp->if_softc
- use if_bpf rather than private cookie variables
- change bpf interface to take advantage of this
- call ether_ifattach() directly from Ethernet drivers
- delete kludge in if_attach() that did this indirectly

The last part of the ether_sprint -> %6D change.
Sorry for the delay.
(%D is for hexdumping.)

Make PCI interrupt handlers return void like everybody else does.

Reviewed by: davidg

This driver really is for the Pro/100B and not for the Pro/100 (and in fact
doesn't even work with a Pro/100)...updated to reflect this.

Reworked the stop/reset code to properly run-down allocated buffers and
made the code detect and handle wedged cards.

Added prototype for fxp_scb_wait() and fixed a bug where the wrong pointer
was passed in one case.

Untangled the vm.h include file spaghetti.

Increased the number of Tx segments from 13 to 29 to reduce the need to
recopy to near zero. Wrote the necessary code to recopy the mbuf chain
into another buffer if there are too many mbufs in the chain.

all:
Removed ifnet.if_init and ifnet.if_reset as they are generally unused.
Change the parameter passed to if_watchdog to be a ifnet * rather than
a unit number. All of this is an attempt to move toward not needing an
array of softc pointers (which is usually static in size) to point to
the driver softc.

if_ed.c:
Changed some of the argument passing to some functions to make a little
more sense.

if_ep.c, if_vx.c:
Killed completely bogus use of if_timer. It was being set in such a way
that the interface was being reset once per second (blech!).

Fix minor bug that would cause the packet statistics updates to stop
working under extremely rare circumstances. Also added some additional
comments..

Device driver for Intel Pro/100 PCI Fast Ethernet controller.