dev.igc.N.fc read and wrote a function-static variable shared by every
igc 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.
- igc_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.
- 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: a port set to 0 came back
honoring pause frames, for example.
Start the softc value as full, report it, use it as it is in
igc_reset(), reject invalid values, and apply a change by
reinitializing the interface, as the dmac and eee_control sysctls do.
Fixes: 517904de5cca ("igc(4): Introduce new driver for the Intel I225 Ethernet controller.")
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")