rtw_set_access, rtw_set_access1 to match.
Add a subroutine for setting WEP keys. WEP isn't quite finished,
because I have to add the WEP header to Tx packets. Implement the
SIOCS80211NWKEY ioctl for setting WEP keys.
Program the LEDs based on operating state and packet activity.
* On a Revision F RTL8180, blink LED1 at 1Hz to indicate
scan/authenticate/associate states. In the run state, turn LED1
on. In every state, blink LED1 at 5Hz to indicate non-beacon
tx/rx activity. I would like to use two LEDs, but in all my
Rev. F instances, LED0 is not wired to an LED; instead, the
first LED is wired to indicate that the card's power is on.
* On a Revision D RTL8180, program the LEDs so that LED0 indicates
Tx, and LED1 indicates Rx. The Rx LED will blink annoyingly if
there are beacons in the air, but at least the Tx LED is useful.
* Store the hardware revision in the softc to support my futile
attempt at programming LEDs for both Rev. D and Rev. F parts;
I never did get Rev. D LEDs to work right.
* Add a debug flag RTW_DEBUG_LED for the LED transitions.
Add RTW_TPPOLL_ALL, RTW_TPPOLL_SALL to start and stop, respectively,
all of the transmit rings.
In ad hoc mode, allocate a beacon and load it into the beacon ring.
Start the ring. In one trial, the card re-transmitted the beacon
ring's contents several times before stopping. More programming
and testing for ad hoc mode is necessary. I'm not setting the
beacon flag in the transmit descriptor.
Revamp the transmit section to make better use of all the transmit
rings: beacon queue, high-, low-, and medium-priority rings. Put
beacon frames on the beacon ring. All other management frames,
and data frames, go on the medium-priority ring. Power-save data
frames go on the high-priority ring. (Note that powersaving is
not implemented!) This is a work in progress.
Send all 802.11 Management frames at 1Mbps.
After we put a packet on a transmit ring, tickle the right bit in
the TPPOLL to tell RTL8180. Stop all rings on error and in rtw_stop.
Use the RF chip type, not the RTL8180 revision, to choose between
host- and MAC-controlled RF serial I/O. Now the Netgear MA521
works.
Remove bogus definition of bit RTW_TPPOLL_FSWINT.
"oversize frame." Also, some an(4) instances (esp. w/ firmware
version 5+) would not reliably interoperate with some Cisco APs.
Add a sysctl for enabling/disabling debugging.
The problem with Aironet AP interoperability was that the rx frame
'gap' will sometimes be loaded with the 802.2 SNAP header, and
sometimes omitted, when connected to a Cisco AP; an(4) was *always*
discarding the gap. The problem with "oversize frames" was an
off-by-2 error in the frame-length arithmetic.
While we're here, pad some RIDs to the length that new firmware
really expects.
Thanks to Jim Miller for his valuable bug reports and testing, and
to Dheeraj Reddy for RID-length patches. Some clues from various
Linux drivers for Cisco/Aironet cards led to the gap fix.
audio framework
Summary of changes:
* struct audio_params
- remove sw_code, factor, factor_denom, hw_sample_rate,
hw_encoding ,hw_precision, and hw_channels. Conversion information
is conveyed by stream_filter_list_t.
- change the type of sample_rate: u_long -> u_int
- add `validbits,' which represents the valid data size in
precision bits. It is required in order to distinguish 24/32bit
from 24/24bit or 32/32bit.
* audio_hw_if
- add two parameters to set_params()
stream_filter_list_t *pfil, stream_filter_list *rfil
A HW driver should set filter recipes for requested formats
- constify audio_params parameters of trigger_output() and
trigger_input(). They represent audio formats for the hardware.
- make open() and close() optional
- add int (AUMODE_PLAY or AUMODE_RECORD) and audio_params_t parameters
to round_blocksize()
* sw_code is replaced with stream_filter_t.
stream_filer_t converts audio data in an input buffer and writes
into another output buffer unlike sw_code, which converts data in
single buffer.
converters in dev/auconv.c, dev/mulaw.c, dev/aurateconv.c,
dev/tc/bba.c, dev/ic/msm6258.c, and arch/arm/iomd/vidcaudio.c are
reimplemented as stream_filter_t
* MI audio
- audiosetinfo() builds filter pipelines from stream_filter_list_t
filled by audio_hw_if::set_params()
- audiosetinfo() returns with EINVAL if mmapped and set_params()
requests filters
- audio_write(), audio_pint(), and audio_rint() invoke a filter
pipeline.
- ioctl() for FIONREAD, AUDIO_WSEEK, AUDIO_GETIOFFS,
AUDIO_GETOOFFS, and audio_prinfo::{seek,samples} for
AUDIO_GETINFO handle values for a buffer nearest to userland.
* add `struct device *' parameter to ac97_attach()
* all of audio HW drivers follow audio_hw_if and ac97 changes
o add sc_writereg and sc_readreg functions that get passed the hd44780_chip
struct and RS (register-select) signal
o add sc_dev to struct hd44780_chip so upper level read/write routines can get
back to their parent softc
o change TIMEOUT_XXX to HD_TIMEOUT_XXX
o remove sc_rread and sc_rwrite in favor of new sc_writereg and sc_readreg
o add new flag HD_UP to sc_flags that is set once 4bit/8bit mode selection
has been finalized.
o remove sc_irwrite, MD readreg/writereg should check state of HD_UP instead
(mail@janderson.ca): remove ieee80211_ibss_merge's TSFT argument.
Do the TSFT comparison in the drivers (ath, atw). Remove a lot of
extraneous debug statements from ieee80211_ibss_merge.
Set the ieee80211_node's state to IEEE80211_STA_BSS after it's been
copied to the ic_bss, not before.
In struct ieee80211_node, make the ni_tstamp field a union of a
uint64_t and the 8 TSF octets so that it's easier to compare a
neighbor's TSF with the local TSF.
Log IBSS merges (Greg Troxel's suggestion). Also log IBSS creation.
These are rare and important events that deserve to be logged.
Cosmetic: remove two short ladders from rtw_init. Fit the
NIC registers print-out onto one line using the RTW_PRINT_REGS
macro.
sys/dev/ic/rtwvar.h:
Add RTW_PRINT_REGS wrapper macro for rtw_print_regs. It
is a null op unless defined(RTW_DEBUG).
Use clue from rtk(4) and re(4) to fix the rtw(4) packet
filter. Previously, I was using the wrong CRC32 function
to hash multicast addresses; to compensate, I set the
multicast filter to all 1s. Now that I hash the addresses
correctly, I do not any longer set the filter to all 1s.
In rtw_ioctl, avoid gratuitous re-initialization when the
interface flags change. If a !IFF_UP -> IFF_UP transition,
call rtw_init(); otherwise, only reload the packet filter.
In sys/dev/ic/rtwreg.h:
Put useful combinations of Receiver Control Register flags
in RTW_RCR_PKTFILT_MASK, RTW_RCR_MONITOR, and
RTW_RCR_PKTFILT_DEFAULT. (XXX RTW_RCR_MONITOR should be
called RTW_RCR_PKTFILT_MONITOR.)
better than txctl. Change from rtw_txctl/rtw_rxctl to
rtw_txsoft/rtw_rxsoft. Change the descriptor blocks' names to
match: rtw_txctl_blk becomes rtw_txsoft_blk. Change the member-name
prefixes for both software and hardware descriptors.
which is a struct rtw_rxdesc_blk.
Put a copy of the DMA tag and the DMA map into the rx- and tx-ring
blocks so that I don't have to pass them to subroutines all of the
time.
limiting the number of rx buffers an rtw may allocate. Use this
sysctl to test the code that copes with buffer exhaustion.
Allocate at most RTW_RXQLEN rx buffers, stopping at the sysctl
limit. Record in sc_nrxdesc how many were allocated, and put the
end-of-ring indication on sc_rxdesc[sc_nrxdesc - 1]. In rtw_init,
if no rx buffers could be allocated, log a complaint, clear
IFF_RUNNING, and exit with an error.
Many changes to accomodate a short rx ring, mainly of the "add a
rx-ring length argument" variety. XXX I really should consolidate
all of the rx ring variables in one struct and pass that to the
rx-ring subroutines.
Bug fix: after calling MCLGET, use the (m->m_flags & M_EXT) idiom
to check for success, instead of m != NULL.
Bug fix: at the top of rtw_start, if IFF_RUNNING is not set, or
IFF_OACTIVE is, get out.
sc_rxnext.
Add sc_nrxdesc, the number of receive descriptors that we are
actually able to use. sc_nrxdesc will ordinarily equal RTW_RXQLEN.
If buffers are exhausted, sc_nrxdesc < RTW_RXQLEN. My next commit
will change dev/ic/rtw.c to deal with buffer exhaustion.
the first. Otherwise we can overwrite parts of the TX ring that we shouldn't.
Kluge the basic rate setting for now.
Minor simplification to the dequeueing logic.
"power-off NIC" function, by adding a 'disable' argument to ath_stop.
Pass disable=0 to ath_stop() at the top of ath_init, so that we
don't power-off the Cardbus slot before resetting the HAL. Thanks
to Greg Troxel for his analysis of this bug.
empty/unused octets to fill out the data time slot. The value is constrained
by math to 0 for <= 5.5Mb, 0-1 for 11Mb, and 0-2 for 22Mb. It is used to
signal to the MAC that there is residue.
references abound without this fix.
In rtw_intr_rx, skip to the next rx packet earlier if the rx packet
length is too short.
Also in rtw_intr_rx, if a packet is rx'd with unknown rate, printf
a warning, drop the packet, recycle the rx buffer, skip to next rx
packet.
debug flags.
From Linux: handle an RTL8180 bug. Sometimes the NIC skips from
the middle of the ring to the 0th rx descriptor. Now the driver
resynchronizes.
Handle a receive descriptor underrun or Rx FIFO overflow condition
in the way that the Linux driver does. This kind of seems like
overkill, but whatever.
Protect rtw_ioctl with splnet().
Do not load a tx descriptor with a buffer shorter than 4 bytes.
Handle a transmit timeout less disruptively.
bus-independent backend, with PCI and CardBus attachment code.
The committed code has two serious bugs:
1. The driver makes no attempt to recover resources when a (Cardbus)
instance is removed; bus resources are leaked.
2. In testing with a NetGear GA-511, the Cardbus card never responded
to a reset/wakeup if the card is powered down after attachment.
So for now, leave cardbus instances powered up at attachment
(insertion, or at boot if a card is already present).
That aside, it acutally works on my GA-511. Committed as-is despite
the bugs, after repeated requests to make the code available for
further testing. Also requires sys/dev/mii/miidevs rev 1.54 -> 1.55,
and consequent regen of miidevs{,_data}.h.
in an 802.11 unicast data packet is equal to the duration of the
SIFS and Acknowledgement. That is, the amount of time reserved
*after* the packet has finished transmitting.
Change the arguments to ieee80211_compute_duration: pass the entire
packet length, not just the payload length. Add a 'debug' argument
to ieee80211_compute_duration and its helper subroutine,
ieee80211_compute_duration1.
If debug != 0, ieee80211_compute_duration printfs its arguments
and several local variables.
In rtw(4), load the 802.11 Duration field with the result from
ieee80211_compute_duration.
bit in the SROM. It seems as if it is set to 1 when the PHY is
*analog*, not *digital*. Fix my sources.
In rtw_intr_rx, use units of 500kb/s instead of 100kb/s for rate,
to be consistent with net80211's expectations. Polish up some
debugging ugly messages. Dump raw 802.11 packets if IFF_DEBUG|IFF_LINK2
and RTW_DEBUG is defined.
Polish power-state (on/sleep/off) handling. Especially improve
support for RFMD (totally untested) and Maxim. For Philips, take
the Digital PHY property into account.
Call the net80211 watchdog function from rtw_watchdog, so that we
scan again if auth/assoc fails.
Be a little more cautious about writing register[RTW_TPPOLL], since
other drivers are.... Don't frob the high/low-priority queues
right now, since I don't use them.
Add rtw_join_bss which programs the card with the BSSID and other
properties of a BSS. Use it on state transitions. Factor out
rtw_set_nettype.
Make rtw_recv_beacon call ieee80211_recv_mgmt instead of dropping
beacons on the floor! TBD IBSS merges.
Change some rtw_debug=2 printfs to rtw_debug=3 (RTW_DPRINTF3)
printfs so the console doesn't get spammed so badly at rtw_debug=2.
Change some debugging printfs to RTW_DPRINTFs. E.g., print the
"RF programming method" only if debugging is enabled.
descriptor rings, move packets from the transmit queues to the
transmit rings, handle transmission-completed interrupts. My
Linksys WPC11 ver. 4 with Maxim RF, generates interrupts like it
is successfully transmitting packets. Clearly there are bugs: my
G4 Powerbook locks up hard. I will debug tomorrow.
subroutine wi_txcmd_wait from wi_cmd and wi_stop.
This stops wi from griping, "wi0: command timed out, cmd=0x10b,
arg=0x0", when we down/up the interface. Thanks to Pavel Cahyna
for reporting this bug.
Following Charles Hannum's wi(4) optimizations, there could be a
Transmit command outstanding after wi_tx_intr or wi_start returns.
The driver would blithely issue a second command [*] before the
first command was finished, taking the first command's WI_EV_CMD
indication to mean the second command had finished. The driver
would be dreadfully confused when the second command's results did
not meet its expectations (e.g., a RID mismatch error would occur).
The packet transmit section of the code would never read the
WI_EV_CMD it expected, so transmissions would cease.
This patch counts the outstanding transmit commands (there can be
only one) and, if a transmit command is outstanding at the top of
wi_cmd(), wi_cmd waits for the command to complete. If there was
a transmit command outstanding when wi_cmd begins, it calls
wi_cmd_intr() on its way out.
I have tested this on an Orinoco card. Previously, the card would
stop transmitting or the kernel would panic as desynchronization
occurred. Now it works beautifully.
[*] A second command could be issued by wi_ioctl or else by
wi_intr->wi_info_intr->wi_newstate->wi_read_xrid->wi_read_rid.
wi_read_rid(sc, rid, &val, &buflen) == 0 && buflen == sizeof(val),
become wi_read_xrid calls
wi_read_xrid(sc, rid, &val, sizeof(val)) == 0.
If the actual RID length is different from the expected RID length,
wi_read_rid prints to the log.
I added some sysctls to aid debugging:
* hw.rtw.debug -- enable debugging
* hw.rtw.flush_rfio -- Linux voodoo: possibly makes the MAC
"flush" bits down the serial bus to the RF
* hw.rtw.host_rfio: force the host to bang bits to the RF, instead
of the MAC banging bits
* hw.rtw.rfio_delay: after telling the MAC to bang bits to the
RF front-end, delay rfio_delay microseconds.
* hw.rtw.rfprog_fallback: there is this notion of the "RF
programming method." I believe the choice influences the
polarity/timing of the serial bus used to program the RF
front-end. I know the correct choice for Intersil/RFMD/Philips
front-ends, only. For all other front-ends, I "fallback" to
rfprog_fallback.
Make rtw_txdac_enable take an rtw_softc argument. I will probably
revert this change.
Add some Linux voodoo to rtw_continuous_tx_enable. I will probably
revert this change.
Important: add rtw_set_rfprog, which sets the correct RF programming
method. This change and the following change are probably responsible
for making the Philips RF work.
Important: RTW_CONFIG1 is an 8-bit register, treat it that way!
Important: RTW_BRSR is 16-bit, RTW_CRCOUNT, RTW_PHYDELAY, and
RTW_MSR are 8-bit: treat them that way!
Vastly simplify rtw_resume_ticks.
Note to self: set the LED state to match the power state.
Hedge against the possibility that RTW_MSR is protected as
RTW_CONFIG[0123] are, meanwhile reworking that section of rtw_init
a little.
Add sc_anaparm, which isn't used, yet....
with []. Using the driver with my Linksys WPC11 ver. 4, it seems
to be receiving packets for a change. The WPC11 ver. 4 has a Maxim
RF section. My no-name rtw with Philips RF section still does not
receive any packets.
Keep access-level (analog params > config[0123] registers > none)
in sc_access. Add rtw_set_access for changing the access level.
Make rtw_continuous_tx_enable and other subroutines use rtw_set_access
instead of rtw_config0123_enable and rtw_anaparm_enable.
Factor part of the chip-reset code into rtw_chip_reset1.
Change the 'struct foo (*bar)[N]'-style arguments to
'struct foo *bar'-style arguments.
Consolidate software/hardware Tx/Rx ring setup in rtw_hwring_setup,
rtw_swring_setup.
Add a new constant, SA2400_OPMODE_DEFAULTS, for the bits that we
*always* set in the SA2400 OPMODE register.
Factor some code out into rtw_sa2400_calibrate. (Inspired by the
Linux driver.)
[] When the receiver goes into underrun/overflow state, call a new
subroutine, rtw_kick() that stops the Rx/Tx processes, resets
the chip, reinitializes the Tx/Rx rings, and restarts Rx/Tx
processes. (Inspired by the Linux driver.)
[] In rtw_intr_rx, check for too-short packets before calling
ieee80211_find_rxnode. I believe this will prevent a repeat of
the MCHK exception I saw once on macppc.
[] Use seconds-elapased as well as microseconds-elapsed to set the
next "due date" for the timeout interrupt. This keeps the driver
from programming the timeout to expire too early.
[] In rtw_intr, read RTW_ISR at most 10 times, then get out. If
the interface is not enabled (RTW_F_ENABLED), then get out.
[] In rtw_stop, get out if the interface is not enabled (RTW_F_ENABLED).
Block IPL_NET interrupts. Don't read/write any registers if
the interface is invalid (RTW_F_INVALID).
[] Call rtw_stop in rtw_detach.
reviewed by christos@, cube@ and martin@.
While here, remove a printf() in mpu_attach() (ic/mpu.c) to remove
an empty line in some frontends (mpu_isa.c, etc).
as a side-effect. Don't bother handling IFF_PROMISC here, because
ether_ioctl() already calls (*if_init)() to handle flags changes.
When adding/deleting multicast addresses, only whack the address
filter if the interface is marked RUNNING.
Fixes kern/27678.
context. For this introduce 3 new xfer tags:
- C_WAIT, equivalent of AT_WAIT
- C_WAITACT, when there is a thread waiting on this xfer to become the active
one (that is, to be at the head of the queue)
- C_FREE, set by ata_free_xfer() when it can't free the xfer because it's
still in use. The holder should then free the xfer ASAP.
If ata_exec_xfer() is called with (C_POLL | C_WAIT), and there is already
xfers to be processed, assert C_WAITACT and sleep.
atastart() checks for C_WAITACT, and wakeup the thread waiting for this xfer
to become active if set. atastart() won't process this xfer, it's the
responsability of the thread waked up to handle it.
Fix (the right way) kern/27421 by Martin Husemann.
in if_tlp_pci.c... The name code really needs to be fixed so that it does
not have a buffer overflow again:
1. the cardbus and eisa code don't initialize sc_name; it probably should?
2. tlp_attach() seems to print the name and the ethernet address, but
the pci front end seems to do the same.
3. some of the name determination code in the pci front-end does not guarantee
nul terminated strings.
Really, all this name code is just bloat and another place for bugs to hide.
Some devices do not transfer data with proper way on status phase
and it causes bus error in spc_datain_pio() which uses auto xfer
via DREG register on weird x68k hardware.
-convert submatch() style functions (passed to config_search() or
config_found_sm()) to the locator passing variants
-pass interface attributes in some cases
-make submatch() functions look uniformly as far as possible
-avoid macros which just hide cfdata members, and reduce dependencies
on "locators.h"
NCR5380_USE_BUS_SPACE, to make this build again on acorn32, mac68k,
pc532, and sun3. This is done under the assumption that it's
somewhat doubtful that any of those machines will encounter that
chip variant.
The acorn32 and mac68k parent drivers (csa and sbc) are listed in
ncr5380var.h as "easy to convert", but it's evident that noone have
stepped up to that challenge yet. Sun3 and pc532 needs bus.h first,
which they apparently don't have at the moment.
to be allocated anyway). scsipi can deal with resources shortage, but if this
pool goes down to 0 pages we can deadlock with the scsipi_xfer, vnode or
inode pools.
Also update a comment, despite resources accounting we can return
ATAPTER_RESOURCES_SHORTAGE here.
which bustype should be attached with a specific call to config_found()
(from a "mainbus" or a bus bridge).
Do it for isa/eisa/mca and pci/agp for now. These buses all attach to
an mi interface attribute "isabus", "eisabus" etc., and the autoconf
framework now allows to specify an interface attribute on config_found()
and config_search(), which limits the search of matching config data
to these which attach to that specific attribute.
So we basically have to call config_found_ia(..., "foobus", ...) where
such a bus is attached.
As a consequence, where a "mainbus" or alike also attaches other
devices (eg CPUs) which do not attach to a specific attribute yet,
we need at least pass an attribute name (different from "foobus") so
that the foo bus is not found at these places. This made some minor
changes necessary which are not obviously related to the mentioned buses.
- Add an ata_reset_channel() function that performs the common parts
of resetting an ATA channel, which uses the (*ata_reset_channel)()
callback to do the heavy lifting. Adjust callers to use ata_reset_channel()
instead of wdc_reset_channel().
This removes the last wdc-specific code from ata.c!
the ata_bustype for the controller. Fill it in and use it instead
of referencing wdc_ata_bustype directly.
- Add an atac_atapibus_attach member to atac_softc to hold a pointer
to the function that attaches the ATAPI bus for the controller. Fill
it in and use it instead of referencing wdc_atapibus_attach directly.
ata_channel.
- Add and use a CHAN_TO_WDC_REGS() macro to get the wdc_regs from an
ata_channel.
- Add and use a CHAN_TO_PCIIDE() macro to get the pciide_softc from an
ata_channel.
- Add and use a CHAN_TO_PCHAN() macro to get the pciide_channel from an
ata_channel. (This one just hides a cast, and is really just for
consistency with the others.)
* Assert RESET before powering off a socket.
* Turn on the output enable bit earlier so the interface actually drives CEn
and RESET.
* Tighten up the power-on timing a bit.
* Mention the specific timing values named in the spec.
For pccbb, be careful to always power off before zeroing PWRCTL.
wdc_regs structure, and array of which (indexed per channel) is pointed
to by struct wdc_softc.
- Move the resulting wdc_channel structure to atavar.h and rename it to
ata_channel. Rename the corresponding flags.
- Add a "ch_ndrive" member to struct ata_channel, which indicates the
maximum number of drives that can be present on the channel. For now,
this is always 2. Add an ATA_MAXDRIVES constant that places an upper
limit on this value, also currently 2.
wdc_regs structure, and array of which (indexed per channel) is pointed
to by struct wdc_softc.
- Move the resulting wdc_channel structure to atavar.h and rename it to
ata_channel. Rename the corresponding flags.
- Add a "ch_ndrive" member to struct ata_channel, which indicates the
maximum number of drives that can be present on the channel. For now,
this is always 2. Add an ATA_MAXDRIVES constant that places an upper
limit on this value, also currently 2.
* Clean up the socket state earlier in the attach process -- not relying on
the socket attachment to do it.
* Get rid of PCIC_LASTSTATE_HALF. It's pointless.
* In pcic_wait_ready(), also check for the card vanishing, like in pccbb.
* Assert #RESET before powering up the card, not after. (I think it was
actually okay because the value was left as 0 from a previous disable or
the initial socket attach, but...
* If the card fails to come ready, don't bother reinstating windows or
anything -- just power it down.
reading the FIFO status and reading the interrupt status, we could end up
leaving it in the FIFO. Force another round through the loop after reading the
interrupt status until the FIFO reads empty again.
Also, there is no point in having the extra loop to wait for the transfer
command to the controller to be acknowledged, because the transfer loop handles
that just fine -- and getting rid of it fixes another race condition.
instead have a call down from the PCMCIA mid-layer to set it. Use this from
pcmcia_function_enable(). (Currently the policy is the same, but this would
allow for more flexibility in deciding which mode to use.)
Now it is safe to hold the socket enabled during attach, so do that. Only
one enable/disable cycle to attach a card now!
are at the end of the node queue. Change the reference-counting
discipline: ni->ni_refcnt indicates how many times net80211 has
granted ni to the driver. Every node in the table with ni_refcnt=0
is eligible to be garbage-collected. The mere presence of a node
in the table does not any longer indicate its auth/assoc state;
nodes have a ni_state variable, now. A sysctl,
net.link.ieee80211.maxnodecache, controls the maximum LRU cache
size.
While I am here, patch ieee80211_find_node_for_beacon to do a "best
match" by bssid/ssid/channel, not a "perfect match." This keeps
net80211 from caching duplicate nodes in the table.
* If the device returns a length too short to even contain the RID number,
flag it as not supported and return EOPNOTSUPP, rather than returning a
length of -2 and trying to use the value anyway.
* Check the returned lengths to see if we actually got anything.
* If we get no rate list, fail the attach, so we don't just blow up later.
Allow the frontend to pass in a MAC address.
and kill only pending requests for this drive.
Implement a DRIVE_WAITDRAIN flag, which will cause the active command to
be killed once complete.
Other minor fixes.
Now it's possible to detach a ATA or ATAPI device from ioctl even when
a dd on the raw char partition is running.
struct ata_xfer *active_xfer
to ata_queue. Now the active xfer isn't the head of the queue any more,
this makes a few things easier (this will also help for tagged queuing
support).
Remove the WDCF_ACTIVE flag, test active_xfer != NULL instead.
clean up wdc_free_xfer() and kill_xfer().
Clean up wdc_reset_channel(), and make it issue a ATAPI_SOFT_RESET if the
active command is ATAPI.
In wdc_atapi_get_params(), use AT_WAIT | AT_POLL for ATAPI_SOFT_RESET,
so that we'll use tsleep() instead of delay().
In wdc_atapi_start(), call wdc_dmawait() at the right place.
Use this to reset the channel before doing a dump, instead of the hack in
wdc_exec_xfer() based on C_POLL. This hack was causing problems on
controllers with a shared queue, because we now can have C_POLL set during
concurent channels probes (problem found and analysed on sparc64 by
Martin Husemann).
This should even make core dumps marginally more reliable on ATA drives.
the background. The problem was exposed when setting a non-black color
as the background, as the shift did not produce the expected fill value
(for black it worked because 0 is black).
completely. In particular, accept them in monitor mode (where we generally
aren't doing anything unless we're in promiscuous mode anyway) and host-AP
mode (where we want to see neighbor APs).
WSDISPLAY_BORDER_COLOR option, broken by a last-minute change.
Pointed out by xtraeme@.
Also back out the previous change by dogcow@, which was an attempt
to fix kernel builds that didn't define WSDISPLAY_CUSTOM_BORDER;
shouldn't be needed now. (Problem also introduced by the same
last-minute change; sorry).
at the moment.
This includes the addition of two new wsdisplay ioctls, WSDISPLAY_{G,S}BORDER,
one to get the actual color and one to set it, respectively. Possible colors
match those defined by ANSI (and listed in wsdisplayvar.h).
It also adds two accessops to the underlying graphics device, getborder and
setborder, which mach their ioctl counterparts.
Two kernel options are added: WSDISPLAY_CUSTOM_BORDER, which enables the
ioctls described above (to customize the border color from userland after
boot), and WSDISPLAY_BORDER_COLOR, which sets the color at boot time.
The former is enabled by default on the GENERIC kernel, but not on INSTALL
(among others). The later is always commented out, leaving the usual black
border as a default.
wsconsctl is modified to allow accessing this value easily. For example,
'wsconsctl -d -w border=blue'.
Two new ioctls are added to the wsdisplay device, named WSDISPLAY_GMSGATTRS
and WSDISPLAY_SMSGATTRS, used to retrieve the actual values and set them,
respectively (the name, if you are wondering, comes from "message attributes").
A new emulop is added to the underlying display driver (only vga, for now)
which sets the new attribute for the whole screen, without having to clear
it. This is optional, which means that this also works with other drivers
that don't have this new operation.
Five new kernel options have been added, although only documented in
i386 kernels (for now):
- WSDISPLAY_CUSTOM_OUTPUT, which enables the ioctls described above to
change the colors dynamically from userland. This is enabled by default
in the GENERIC kernel (as well as others) but disabled on all INSTALL*
kernels (as this feature is useless there).
- WS_DEFAULT_COLATTR, WS_DEFAULT_MONOATTR, WS_DEFAULT_BG and WS_DEFAULT_FG,
which specify the default colors for the console at boot time. These have
the same meaning as the (already existing) WS_KERNEL_* variables.
wsconsctl is modified to add msg.default.{attrs,bg,fg} and
msg.kernel.{attrs,bg,fg} to the display part, so that colors can be changed
after boot.
Tested on NetBSD/i386 with vga (and vga in mono mode), and on NetBSD/mac68k.
No objections in tech-kern@.
will eventually share it.
In the IBSS merge logic, check conditions in a different order so
that they run faster in the common case---no merge. Fix the
rate-limiting on the debug outputs (enabled by IFF_LINK0).
Begin conditioning device configuration on revision number. Four
revisions are known:
1.1/1.5 -> ADM8211A,
2.0 -> ADM8211B,
3.0 -> ADM8211C.
The B and C parts, which are not supported yet, have AP capability.
start and the number we've started that have not been alloced yet. Currently
sc_txstarted is constained to 0 or 1 because of the way we start the next
packet, but this will change.
* Update sc_txpending[] when a packet is written, even before we issue the TX
command, since it may be active when we issue the TX command for the
following packet.
* Do not lower the rate in ni_txrate or id_rateidx, because these are used to
keep track of sc_txpending[], and could cause us to get "stuck" at the lower
rate.
synthesizer/transceiver/power amplifier. The ADMtek ADM8211C is
sometimes paired with this chip. This the first step toward
supporting the ADMtek ADM8211C-based products.
all the descriptors for a buffer chain. Just synchronize the last
one, which has the interesting stuff.
I still synchronize all the descriptors for the buffer chain if
super-verbose debugging is enabled, since the driver will print
all the descriptors for the chain.
