the FIFO.
I still see some corner cases where no RX occurs when it should be
occuring. It's quite possible that there's a subtle race condition
somewhere; or maybe I'm not programming the RX queues right.
There's also no locking here yet, so any reset/configuration path
state change (ie, enabling/disabling receive from the ioctl, net80211
taskqueue, etc) could quite possibly confuse things.
* For now, kickpcu should hopefully just do nothing - the PCU doesn't need
'kicking' for Osprey and later NICs. The PCU will just restart once
the next FIFO entry is pushed in.
* Teach "proc" about "dosched", so it can be used to just flush the
FIFO contents without adding new FIFO entries.
* .. and now, implement the RX "flush" routine.
* Re-initialise the FIFO contents if the FIFO is empty (the DP is NULL.)
When PCU RX is disabled (ie, writing RX_D to the RX configuration
register) then the FIFO will be completely emptied. If the software FIFO
is full, then no further descriptors are pushed into the FIFO and
things stall.
This all requires much, much more thorough stress testing.
This is inspired by ath9k and the reference driver, but it's a new
implementation of the RX FIFO handling.
This has some issues - notably the FIFO needs to be reprogrammed when
the chip is reset.
* Add a couple of RX errors;
* Add the spectral scan PHY error code;
* extend the RX flags to be a 16 bit field, rather than an 8 bit field;
* Add a new RX flag.
Obtained from: Qualcomm Atheros
The AR93xx and later chips support two RX FIFO queues - a high and low
priority queue.
For legacy chips, just assume the queues are high priority.
This is inspired by the reference driver but is a reimplementation of
the API and code.
AR93xx receive descriptors.
This isn't entirely complete - the AR93xx and later descriptors
don't have a link/buffer pointer; the descriptor contents just
start.
setting in the igb and em driver. This was necessitated by
a shared code change that I was given late in the game, a data
type changed from bool to int, in the last update I dealt with
it by a cast, but it was pointed out (thanks jhb) that there
was a potential problem with this. John suggested this safer
approach, and it is fine with me...
MFC after:2 days (to catch the 9.1 update)
although by default only C1 is enabled (cx_lowest=0) and enabling deeper
states goes through acpi_cpu_set_cx_lowest which re-evaluates cpu_non_c3
MFC after: 2 weeks
cpu_non_c3 is already evaluated in acpi_cpu_cx_cst and in
acpi_cpu_set_cx_lowest.
Besides acpi_cpu_cx_list is not protected by any locking.
As a result also move setting of cpu_can_deep_sleep to more appropriate
places.
MFC after: 2 weeks
Don't use Maxmem when the amount of memory is meant. Use realmem instead.
Maxmem is not only a MD variable, it represents the highest physical memory
address in use. On systems where memory is sparsely layed-out the highest
memory address and the amount of memory are not interchangeable. Scaling the
AGP aperture based on the actual amount of memory (= realmem) rather than
the available memory (= physmem) makes sure there's consistent behaviour
across architectures.
agp_i810.c:
While arguably the use of Maxmem can be considered correct, replace its use
with realmem anyway. agp_i810.c is specific to amd64, i386 & pc98, which
have a dense physical memory layout. Avoiding Maxmem here is done with an
eye on copy-n-paste behaviour in general and to avoid confusion caused by
using realmem in agp.c and Maxmem in agp_i810.c.
In both cases, remove the inclusion of md_var.h
"Reserved by Microsoft" in the standard PNP ID table, but has been seen
in the wild on at least one laptop.
PR: kern/169571
Submitted by: Matthias Apitz guru unixarea de
MFC after: 3 days
- Add a couple of new devices
- Flow control changes in shared and core code
- Bug fix to Flow Director for 82598
- Shared code sync to internal with required core change
Thanks to those helping in the testing and improvements to this driver!
MFC after:5 days
shared code update and small changes in core required
Add support for new i210/i211 devices
Improve queue calculation based on mac type
MFC after:5 days
The new driver changed the size of the mfi_dcmd_frame structure in such a
way that a MFI_IOC_PASSTHRU ioctl from an old amd64 binary is treated as an
MFI_IOC_PASSTHRU32 ioctl in the new driver. As a result, the user pointer
is treated as the buffer length. mfi_user_command() doesn't have a bounds
check on the buffer length, so it passes a really big value to malloc()
which panics when it tries to exhaust the kmem_map. Fix this two ways:
- Only honor MFI_IOC_PASSTHRU32 if the binary has the SV_ILP32 flag set,
otherwise treat it as an unknown ioctl.
- Add a bounds check on the buffer length passed by the user. For now
it fails any user attempts to use a buffer larger than 1MB.
While here, fix a few other nits:
- Remove an unnecessary check for a NULL return from malloc(M_WAITOK).
- Use the ENOTTY errno for invalid ioctl commands instead of ENOENT.
MFC after: 3 days
The RX EDMA support requires a modified approach to the RX descriptor
handling.
Specifically:
* There's now two RX queues - high and low priority;
* The RX queues are implemented as FIFOs; they're now an array of pointers
to buffers;
* .. and the RX buffer and descriptor are in the same "buffer", rather than
being separate.
So to that end, this commit abstracts out most of the RX related functions
from the bulk of the driver. Notably, the RX DMA/buffer allocation isn't
updated, primarily because I haven't yet fleshed out what it should look
like.
Whilst I'm here, create a set of matching but mostly unimplemented EDMA
stubs.
Tested:
* AR9280, station mode
TODO:
* Thorough AP and other mode testing for non-EDMA chips;
* Figure out how to allocate RX buffers suitable for RX EDMA, including
correctly setting the mbuf length to compensate for the RX descriptor
and completion status area.
This driver does not yet handle multiple chip selects properly.
Note that the NAND infrastructure does not perform full page
reads or writes, which means that this driver cannot make use
of the hardware ECC that is otherwise present.
of interrupts of direct children. Have the bus_config_intr and
bus_teardown_intr methods implemented by bus_generic_config_intr and
bus_generic_teardown_intr (resp) as we don't need to do anything
special outselves.
This removes all the ``#ifdef $arch'' code that was there because powerpc
didn't have a proper nexus and people tend to copy and paste stuff.
names to shorten them. PulseAudio reported to have problems with names
longer then 63 chars and at least in XMMS long names are inconvinient.
Reported by: hselasky
MFC after: 3 days
Adjust power_profile script to handle the new world order as well.
Some vendors are opting out of a C2 state and only defining C1 & C3. This
leads the acpi_cpu display to indicate that the machine supports C1 & C2
which is caused by the (mis)use of the index of the cx_state array as the
ACPI_STATE_CX value.
e.g. the code was pretending that cx_state[i] would
always convert to i by subtracting 1.
cx_state[2] == ACPI_STATE_C3
cx_state[1] == ACPI_STATE_C2
cx_state[0] == ACPI_STATE_C1
however, on certain machines this would lead to
cx_state[1] == ACPI_STATE_C3
cx_state[0] == ACPI_STATE_C1
This didn't break anything but led to a display of:
* dev.cpu.0.cx_supported: C1/1 C2/96
Instead of
* dev.cpu.0.cx_supported: C1/1 C3/96
MFC after: 2 weeks
