e1000: Fix the flow control sysctlHEADmain

dev.em.N.fc and dev.igb.N.fc read and wrote a function-static variable
shared by every em(4) and igb(4) device, so a read returned the last
value written to any of them (3 until the first write), not the state of
the device.  The softc value started as 0, which is also the value of
"no flow control", while the hardware was set up for full flow control.
As a result:

- Writing 0 was taken for no change and did nothing, unless another
  value had been written to that device before.
- em_reset() took a softc value of 0 for "not set", so a device set to 0
  went back to full flow control on the next init.
- On igb(4) with more than one receive queue the driver enabled
  per-queue drop (SRRCTL.DROP_EN), which is meant for a MAC that does
  not send pause frames, although the MAC was told to send them.
- Values out of range were accepted and ignored.

A write only forced the MAC's flow control bits.  The pause bits
advertised to the link partner, the pause thresholds and DROP_EN stayed
as the last init had set them, and the next link event resolved flow
control from the stale advertisement again.  On 82577 and 82578 (pchlan)
a write could also turn on transmit flow control, which em_reset() keeps
off there as a workaround.

Start the softc value as full, report it, use it as it is in em_reset(),
reject invalid values, and apply a change by reinitializing the
interface, as the dmac and eee_control sysctls do.  This is the same fix
as 68386f6b551e ("igc: Fix the flow control sysctl"); igc(4) inherited
the handler from this driver.  On pchlan, remove transmit pause from the
requested mode instead of replacing the mode with receive pause, so that
the workaround stays and 0 still turns flow control off.

Reviewed by:		kbowling
MFC after:		2 weeks
Sponsored by:		Rubicon Communications, LLC ("Netgate")
Differential Revision:	https://reviews.freebsd.org/D60376

0 files changed, 0 insertions, 0 deletions