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

MFC r263957:

2014-04-14T04:51:59Z

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.

Update PCI drivers to no longer look at the MEMIO-enabled bit in the PCI

2013-08-12T23:30:01Z

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

2013-06-10T07:31:49Z

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

Mechanically substitute flags from historic mbuf allocator with

2012-12-04T09:32:43Z

malloc(9) flags in sys/dev.

Remove duplicate const specifiers in many drivers (I hope I got all of

2012-11-05T19:16:27Z

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

2012-05-11T02:40:40Z

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

2012-03-28T01:52:38Z

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

2012-03-28T01:27:27Z

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

2012-03-28T01:08:55Z

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> MFC after: 2 weeks

Do not change current media when driver is already running. If

2012-03-19T02:10:40Z

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 after: 1 week