option left but actually consumed by ada(4), so move it to opt_ada.h
and get rid of opt_ata.h.
- Fix stand-alone build of atacore(4) by adding opt_cam.h.
- Use __FBSDID.
- Use DEVMETHOD_END.
- Use NULL instead of 0 for pointers.
- Move ata_timeout() to ata-all.c so we don't need to expose both this
function and ata_cam_end_transaction() but only the former.
- Move ata_cmd2str() from ata-queue.c to ata-all.c so we can get rid of
the former.
- Add some missing prototypes.
MFC after: 3 days
the issues reported regarding camcontrol devlist not showing the rebuild
states of volumes unless an explicit camcontrol rescan was executed.
PR: kern/171650
Reviewed by: scottl@freebsd.org
Obtained from: Yahoo! Inc.
MFC after: 2 weeks
is configured for higher rates (lower than max) but higher TX power
is configured for the lower rates, above the configured cap, to improve
long distance behaviour.
* Add the rest of the missing GPIO output mux types;
* Add in a new debug category;
* And a new MCI btcoex configuration option in ath_hal.ah_config
Obtained from: Qualcomm Atheros
buffers (ie, >4GB on amd64.)
The underlying problem was that PREREAD doesn't sync the mbuf
with the DMA memory (ie, bounce buffer), so the bounce buffer may
have had stale information. Thus it was always considering the
buffer completed and things just went off the rails.
This change does the following:
* Make ath_rx_pkt() always consume the mbuf somehow; it no longer
passes error mbufs (eg CRC errors, crypt errors, etc) back up
to the RX path to recycle. This means that a new mbuf is always
allocated each time, but it's cleaner.
* Push the RX buffer map/unmap to occur in the RX path, not
ath_rx_pkt(). Thus, ath_rx_pkt() now assumes (a) it has to consume
the mbuf somehow, and (b) that it's already been unmapped and
synced.
* For the legacy path, the descriptor isn't mapped, it comes out of
coherent, DMA memory anyway. So leave it there.
* For the EDMA path, the RX descriptor has to be cleared before
its passed to the hardware, so that when we check with
a POSTREAD sync, we actually get either a blank (not finished)
or a filled out descriptor (finished.) Otherwise we get stale
data in the DMA memory.
* .. so, for EDMA RX path, we need PREREAD|PREWRITE to sync the
data -> DMA memory, then POSTREAD|POSTWRITE to finish syncing
the DMA memory -> data.
* Whilst we're here, make sure that in EDMA buffer setup (ie,
bzero'ing the descriptor part) is done before the mbuf is
map/synched.
NOTE: there's been a lot of commits besides this one with regards to
tidying up the busdma handling in ath(4). Please check the recent
commit history.
Discussed with and thanks to: scottl
Tested:
* AR5416 (non-EDMA) on i386, with the DMA tag for the driver
set to 2^^30, not 2^^32, STA
* AR9580 (EDMA) on i386, as above, STA
* User - tested AR9380 on amd64 with 32GB RAM.
PR: kern/177530
most kernels before FreeBSD 9.0. Remove such modules and respective kernel
options: atadisk, ataraid, atapicd, atapifd, atapist, atapicam. Remove the
atacontrol utility and some man pages. Remove useless now options ATA_CAM.
No objections: current@, stable@
MFC after: never
done in ixgbe, thanks to Mike Karels for this fix. When exiting
promiscuous mode MPE bit was being unconditionally cleared, this
should not be done if we are in MAX multicast groups.
different ATA channels, required for acard and pc98 ATA controllers, block
access to second channels of both, hoping that one working channel is better
then none. I have an idea how that support could be implemented, but I have
no hardware to work on that.
MFC after: 1 week
This is required because, in the radeon driver, we can't left-shift in a
central place, like it was done in the i915 driver.
Reviewed by: kib@, kan@, avg@
Tested by: kib@, avg@
before the TX path is being aborted.
Right now it's in the TDMA code and I can live with that; but it really
should get fixed.
I'll do a more thorough audit of this code soon.
* Don't use BUS_DMA_ALLOCNOW for descriptor DMA maps; we never use
bounce buffers for the descriptors themselves.
* Add some XXX's to mark where the ath_buf has its mbuf ripped from
underneath it without actually cleaning up the dmamap. I haven't
audited those particular code paths to see if the DMA map is guaranteed
to be setup there; I'll do that later.
* Print out a warning if the descdma tidyup code is given some descriptors
w/ maps to free. Ideally the owner will free the mbufs and unmap
the descriptors before freeing the descriptor/ath_buf pairs, but
right now that's not guaranteed to be done.
Reviewed by: scottl (BUS_DMA_ALLOCNOW tag)
the buffer is being freed.
* When buffers are cloned, the original mapping isn't copied but it
wasn't freeing the mapping until later. To be safe, free the
mapping when the buffer is cloned.
* ath_freebuf() now no longer calls the busdma sync/unmap routines.
* ath_tx_freebuf() now calls sync/unmap.
* Call sync first, before calling unmap.
Tested:
* AR5416, STA mode
The normal RX path (ath_rx_pkt()) will sync and unmap the
buffer before passing it up the stack. We only need to do this
if we're flushing the FIFO during reset/shutdown.
uart(4) allocates send and receiver buffers in attach() before it calls
the low-level driver's attach routine. Many low-level drivers set the
fifo sizes in their attach routine, which is too late. Other drivers set
them in the probe() routine, so that they're available when uart(4)
allocates buffers. This fixes the ones that were setting the values too
late by moving the code to probe().
to the same thing) by allocating the uart(4) rx buffer based on the
device's rxfifosz rather than using a hard-coded size of 384 bytes.
The historical 384 byte size is 3 times the largest hard-coded fifo
size in the tree, so use that ratio as a guide and allocate the buffer
as three times rxfifosz, but never smaller than the historical size.
includes support for the NIC and TOE features of the 40G, 10G, and
1G/100M cards based on the T5.
The ASIC is mostly backward compatible with the Terminator 4 so cxgbe(4)
has been updated instead of writing a brand new driver. T5 cards will
show up as cxl (short for cxlgb) ports attached to the t5nex bus driver.
Sponsored by: Chelsio
NULL. This simplifies decisions around if/how requests are routed through
busdma. It also paves the way for supporting unmapped bios.
Sponsored by: Intel
the older if_start/non-multiqueue interface from the stack. This
is not the default, but can be turned on in the Makefile now regardless
of the OS level to allow either testing or use of ALTQ.
MFC after: one week
Set promiscuous code was unconditionally turning off multicast when
turning off promiscuous mode, this should only be done when there are
less than MAX groups. Thanks to Mike Karels for this correction.
Second, the overtmp interrupt setup/detection was wrong, correcting it.
MFC after: one week
0x3C: /* Per Intel document 325462-045US 01/2013. */
Add manpage to document all the goodness that is available in this
processor model.
Submitted by: hiren panchasara <hiren.panchasara@gmail.com>
Reviewed by: jimharris, sbruno
Obtained from: Yahoo! Inc.
MFC after: 2 weeks
later found to not be usable because the controller doesn't support the
same number of queues.
This is not the normal case, but does occur with the Chatham prototype
board.
Sponsored by: Intel
unmapped I/O. That one exception is access to INQUIRY VPD request result.
Those requests are never unmapped now, but to be safe add respective check
there and allow unmapped I/O for the SIM by setting PIM_UNMAPPED flag.
This basically restores the spirit of r203535, which was partially reverted
in r205557, while we still map fixed amount to work around transient issues
we experienced with r203535.
Prodded by: avg
Tested by: avg
MFC after: 1 week
which requires OVREF to be set to get proper playback volume, but which has
all zeroes in HDA controller subdevice IDs on PCI.
MFC after: 1 month
Sponsored by:
data buffer for a ccb that is unmapped.
This case is currently not possible, since the SCI framework only
requests these pointers for doing SCSI/ATA translation of non-
READ/WRITE commands. The panic is more to protect against the
unlikely future scenario where additional commands could be unmapped.
Sponsored by: Intel
