src/sys/dev/fxp, branch release/9.3.0

MFC r263957:

2014-04-14T04:53:34Z

Increase the number of TX DMA segments from 32 to 35. It turned out 32 is not enough to support a full sized TSO packet. While I'm here fix a long standing bug introduced in r169632 in bce(4) where it didn't include L2 header length of TSO packet in the maximum DMA segment size calculation.

Merge r254263:

2013-08-13T22:05:50Z

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. Candidate for 9.2 Submitted by: jhb Reviewed by: jfv, marius, adrian, achim

MFC r251600:

2013-06-17T04:40:27Z

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).

MFC: r243857 (partial)

2013-03-09T00:39:54Z

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

MFC r242625:

2012-11-12T07:34:05Z

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: r235255

2012-05-14T03:11:07Z

- 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 r233585-233587:

2012-04-11T07:08:41Z

r233585: 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 incore de> Tested by: Andreas Longwitz incore de> r233586: 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. r233587: 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).

MFC r232951,232953,233158:

2012-03-26T05:14:04Z

r232951: 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. r232953: Fix white space nits. r233158: 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 sentex dot net>

MFC r228716:

2012-01-09T19:28:51Z

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.

MFC: r226154, r226165

2011-11-06T17:23:49Z

- Follow the lead of dcphy(4) and pnphy(4) and move the reminder of the PHY drivers that only ever attach to a particular MAC driver, i.e. inphy(4), ruephy(4) and xlphy(4), to the directory where the respective MAC driver lives and only compile it into the kernel when the latter is also there, also removing it from miibus.ko and moving it into the module of the respective MAC driver. - While at it, rename exphy.c, which comes from NetBSD where the MAC driver it corresponds to also is named ex(4) instead of xl(4) but that in FreeBSD actually identifies itself as xlphy(4), and its function names accordingly for consistency. - Additionally while at it, fix some minor style issues like whitespace in the register headers and add multi-inclusion protection to inphyreg.h. Approved by: re (kib)