"While I'm here..."
All that grotesque code allegedly for the 88190 and 88790 is actually just
mapping the CCR and writing to it. So, enable the device normally and use
pcmcia_ccr_{read,write}() rather than doing this crap ourselves.
force it to 0 when a card is detached, possibly disabling the socket in the
process.
Add several new functions:
* pcmcia_config_alloc(pf, cfe)
Tries to allocate all the I/O and memory spaces in a config entry.
* pcmcia_config_free(pf)
Frees all the I/O and memory spaces for the active configuration.
* pcmcia_config_map(pf)
Maps all the allocated I/O and memory spaces for the active configuration.
* pcmcia_config_unmap(pf)
Unmaps all the allocated I/O and memory spaces for the active configuration.
And two higher-level functions:
* pcmcia_function_configure(pf, validator)
Tries to find a CIS config entry that it can allocate the spaces for. Each
entry is verified by calling the "validator" function -- which can also do
card- and driver-specific fixups. If successful, the regions are all mapped.
* pcmcia_function_unconfigure(pf)
Equivalent to calling both pcmcia_config_unmap() and pcmcia_config_free().
Most drivers are expected to use the latter two functions, which will greatly
reduce the amount of crufty code.
* Kill off device nodes *before* we clear out the queue, to help prevent any
new I/O being queued.
* More useful error reporting in wd_setcache() and wd_flushcache().
* Add a wd_standby() (tested but not used yet).
And the most important:
* In wddetach(), if the device was open, call adapt_delref() so that we
propagate the disable up to our PCMCIA socket.
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.
underlying implementation DTRT. This has the side effect of causing us to
ignore the INTR and INTRACK bits in the CCR -- but this seems for the best
anyway, since they are not reliably implemented. (I note that Linux doesn't
bother either.)
with the function enabled. If this happens, issue a warning. (This is only
really important for multifunction cards.)
This allows me to get rid of a bunch of extra code.
* Don't call handlers for functions that are not enabled.
* Always call the handler if the function doesn't support the STATUS register.
While I'm here, divide the CCR numbers by 2.
case (ne@pcmcia) where we were using these to create a subregion, it is better
handled by calling bus_space_subregion().
Now there is a 1:1 mapping between I/O spaces in the config table and windows
mapped in the function. Rework the multifunction mapping code to take
advantage of this by using both I/O base addresses if necessary.
* Don't splnet() in xi_init() -- the callers do that.
* Don't do the enable call in xi_init() -- it should be done only in a process
context so it can sleep.
* Call xi_start() at the end of xi_init() to restart output.
* If the interface is already up, we only need to call xi_set_address() to
change state on SIOCSIFFLAGS.
devices) and a "xi" backend.
My CE2 and CEM2 cards are now probed correctly. However, there are still
some problems with one model of the CE2, and the CEM2 doesn't seem to get
any modem interrupts.
While I'm at it, fix several bugs:
* The tuple scan for the MAC address was broken in multiple ways.
* xi_intr() did not deal well with a shared interrupt.
* We were setting the wrong page number to look at the receive status. (How
did this work???)
* Remove the xi_full_reset() from xi_reset(). Move the parts of
xi_full_reset() needed to undo the effect of xi_stop() into xi_init(). This
allows a stop/init pair to DTRT, and much quicker, as used by various
ioctl()s.
* Set the TRS register before reading the TSO register, as the Linux driver
does. While I'm at it, fix the name.
* Fix numerous problems with xi_set_address(). "Where do I begin?" There's a
chance that multicast works now, but I haven't tested it.
* Explicitly clear the MSR register, and also force SELECT_MII to 0 if we
didn't find any PHYs.
* Clean up some cruft that appears to be bogus.
Probably needs more work, but it's a start.
functions taking a pcmcia* device structure.
XXX This is a method of last resort for dealing with stupid/insane cards that
we need to probe harder before we can choose a config entry. It should not be
used by most drivers.
* 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.
FIFOE/BCIS/LVBCI bits; it's is cleared automatically by the hardware.
- Separate AUICH_DEBUG out from AUDIO_DEBUG and make it possible to debug
interrupt handling separately.
- A little KNF.
work by:
* adding another product to the table,
* checking the function type (to reject the serial port),
* trying harder to find the MAC address in the CIS strings (it may occur in
one of two different places).
Also, PCMCIA_STR_* elimination.
* The DEPCM-XX cards don't need to be recognized by OUI or string -- they
work just fine with the IO-DATA PC-LAT/E attachment, and are probable OEM.
So, remove the DEPCM case.
* PCMCIA_STR_* elimination.
* The Megahertz EM3336 is not always an X-Jack device, so take the "XJ" out
of the product number.
The controller is handling them, calling scsipi_done() here will end up in the
xfer being scsipi_done()'ed a second time when it completes in the controller
code. In addition, the way the loop was done here would end up in an infinite
loop, because the channel kernel thread needs to run to remove a command from
this queue.
scsibusdetach(): scsipi_done() all commands from periph_xferq. The controller
is already gone, and these commands will never complete.
Shut down the channel (which will cause the kenrel thread to exit) after
detaching the childs, as they will need the kernel thread for
scsipi_wait_drain().
Fix kernel hang or deadlock when detaching devices (either by scsictl detach
or unplug) with active commands.
on transmit.
- On 82544 and up, allocate 4096 Tx descriptors rather than just 256.
82543 and down must still use 256, due to errata.
- Allow up to 256 DMA segments per packet. I have observed some truly
pathological mbuf chains under certain (admittedly uncommon) workloads
when jumbo frames are in use.
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.
- only call periph_switch->psw_start() if the device is active; if it is not
psw_start() may try to access invalid data.
- remove the TAILQ_FIRST(&periph->periph_xferq) != NULL diagnostic in
scsipi_kill_pending(). This can't be true at this point (unless the device
was idle at the time of the detach), because the scsipi channel kernel
thread has to run for the queue to be flushed.
There are still other problems to be fixed here ...
Allow to enable the game port on an ES1888, in case the firmware didn't
this. (Otherwise we still rely on the firmware having mapped the sound
related registers.)
Limit this to the "isa" attachment for now because this is the only
one I'm able to test.
Attach the "joy" device directly at "ess" to make sure the port is
enabled before the "joy" probe/attach.
This makes the joystick port usable on a "PWS" alpha (Miata).
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.
In default_chip_map() we'll do further checks to see if the channel should
really be enabled, and in case it's not we would keep the interrupt mapped.
Fix kern/26502 from Christian Biere.
* cardbusdevs -> pcidevs
* Add a Microsoft product.
* Use tlp_cardbus_{disable,enable}() in the powerhook. This is an experiment
and may need more work.
according to the controller-dependant registers while wdc was not waiting for
an interrupt). A reset can generate spurious interrupts (or even a flow of
spurious interrupts on the promise) that needs to be properly acknowledged.
Eliminating redundant pointers in the tables saves nearly 20K (20% of the table
size). In the process, add a pci_findproduct() and make that and
pci_findvendor() return a "const char *".
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'.
gets used if nothing else is defined in MD headers,
introduce a "PCI_MACHDEP_ENUMERATE_BUS" CPP definition which can
be used by MD headers (just 1 port atm) to plug in special code
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@.
Bump the default values for these to the values used by FreeBSD,
and also adjust ti_init_rx_ring_jumbo() to use the same constant
that FreeBSD uses. Yes, this consumes more kernel memory.
The effect of this is that you can use jumbo frames in a back-to-back
setup with TCP windows up to about 250KB and get ~930Mbit/s throughput,
while we were earlier limited to around 3-400Mbit/s, and trying to push
above that mark by widening the TCP window caused
ti0: jumbo buffer allocation failed
messages to be logged and a corresponding stall in the traffic.
NatSemi) Geode SC1100 controller (as found on the Soekris
NET4801). The chip has two bugs: the first requires dword
alignment, and the second cannot handle exact 64K transfers.
Also, fix a few typos while we're here.
Timings from FreeBSD. Reviewed by Manuel Bouyer.
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).
when setting CARD_LEADTEK. now with just
options BKTR_SYSTEM_DEFAULT=BROOKTREE_PAL
i get a shiny happy working card on my macppc box:
bktr0 at pci1 dev 18 function 0
bktr0: interrupting at irq 52
bktr0: Leadtek WinFast TV2000/VC100, Philips FR1216 PAL FM tuner.
mycroft