not support TSO over VLAN if VLAN hardware tagging is disabled so
there is no need to check VLAN here.
While I'm here make sure to pullup IP/TCP headers in the first
buffer.
GEM_MIF_CONFIG_MDI0 cannot be trusted when the firmware has powered
down the chip so the internal transceiver has to be hardcoded. This
is also in line with the AppleGMACEthernet driver, which just doesn't
distinguish between internal/external transceiver and MDIO/MDI1
respectively in the first place. Tested by: Andreas Tobler
MFC after: 1 week
frame, make sure to update VLAN capabilities whenever jumbo frame
is configured.
While I'm here rearrange interface capabilities configuration. The
controller requires VLAN hardware tagging to make TSO work on VLANs
so explicitly check this requirement.
Tx DMA burst size 2048, I beleive PCIe maximum read request size
also should match to the value of Tx DMA burst size. With this
change I can get more than 800Mbps for TCP bulk transfers.
Previously I was not able to get more than 700Mbps. If I enable TSO
it now shows 927Mbps.
to make TSO work on VLAN. So if VLAN hardware tagging is disabled
explicitly clear TSO on VLAN. While I'm here remove duplicated
VLAN_CAPABILITIES call.
o uses v4 firmware instead of v3. A port will be committed to create
the bwn firmware module.
o supports B/G and LP(low power) PHYs.
o supports 32 / 64 bits DMA operations.
o tested on big / little endian machines so should work on all
architectures.
It'd not connected to the build until the firmware port is committed.
With FBS enabled, we have no idea what command caused timeout.
Implement same logic as in siis(4) - wait for other commands
complete or timeout and then give some more time.
- introduce drbr_needs_enqueue that returns whether the interface/br needs
an enqueue operation: returns true if altq is enabled or there are
already packets in the ring (as we need to maintain packet order)
- update all drbr consumers
- fix drbr_flush
- avoid using the driver queue (IFQ_DRV_*) in the altq case as the
multiqueue consumer does not provide enough protection, serialize altq
interaction with the main queue lock
- make drbr_dequeue_cond work with altq
Discussed with: kmacy, yongari, jfv
MFC after: 4 weeks
It is belived that that pass s not needed anymore.
Specifically it is not required now for the reasons that were given
in the removed comment.
Discussed with: jhb
MFC after: 4 weeks
Some current systems dynamically load SSDT(s) when _PDC/_OSC method
of Processor is evaluated. Other devices in ACPI namespace may access
objects defined in the dynamic SSDT. Drivers for such devices might
have to have a rather high priority, because of other dependencies.
Good example is acpi_ec driver for EC.
Thus we attach to Processors as early as possible to load the SSDTs
before any other drivers may try to evaluate control methods.
It also seems to be a natural order for a processor in a device
hierarchy.
On the other hand, some child devices on acpi cpu bus need to access
other system resources like PCI configuration space of chipset devices,
so they need to be probed and attached rather late.
For this reason we probe and attach the cpu bus at
SI_SUB_CONFIGURE:SI_ORDER_MIDDLE SYSINIT level.
In the future this could be done more elegantly via multipass.
Please note that acpi drivers that might access ACPI namespace from
device_identify will do that before _PDC/_OSC of Processors are evaluated.
Legacy cpu driver is not affected by this change.
PR: kern/142561 (in part)
Reviewed by: jhb
Silence from: acpi@
MFC after: 5 weeks
The softc obtained in device probe wouldn't be the same one used in
device attach. Drivers should not assume any values stored in softc
structure in probe routine will be available for its attach routine.
