fixes a longstanding issue WRT resetting the chip after startup- it
would fail if we were connected as an F-port to a switch. If we
were connected as an F-port, we got assigned a hard loop ID of 255,
which is really a bogus loop id. Then when we turned around to
reset ourselves, the firmware would reject the ICB_INIT request
because the loop id was bogus. *sputter*
Minor fixlet from somebody in NetBSD with too much time on their
hands (dma -> DMA).
the "compatible" property too in the ns8250 case. This gets the serial
console to work on Blade 100s, where the device name is just "serial".
Reviewed by: marcel
Second (PPS) timing interface. The support is non-optional and by
default uses the DCD line signal as the pulse input. A compile-time
option (UART_PPS_ON_CTS) can be used to have uart(4) use the CTS line
signal.
Include <sys/timepps.h> in uart_bus.h to avoid having to add the
inclusion of that header in all source files.
Reviewed by: phk
This commit puts the relevant code snippets under #ifdef GONE_IN_5
(rather than #ifndef BURN_BRIDGES) thereby disabling the code now.
The code wil be entirely removed before 5.2 unless we find reasons
why this would be a bad idea.
Approach suggested by: imp
seems to be necessary for the 8139C+ under certain circumstances, and
doesn't appear to hurt the other chips. (In the failure case, the
packet would be sent through the TX DMA ring but not get echoed
back. I suspect this has something to do with the link state changing
unexpectedly.)
autoload and then copying the contends of the station address
registers. For some reason, reading the EEPROM on the 8169S doesn't
work right. This gets around the problem, and allows us to read
the station address correctly on the 8169S.
- Insert a delay after initiating packet transmition in re_diag() to
allow lots of time for the frame to echo back to the host, and wait
for both the 'RX complete' and 'timeout expired' bits in the ISR
register to be set.
- Deal more intelligently with the fact that the frame length
field in the RX descriptor is a different width on the 8139C+
than it is on the 8169/8169S/8110S
- For the 8169, you have to set bit 17 in the TX config register
to enter digital loopback mode, but for the 8139C+, you have to
set both bits 17 and 18. Take this into account so that re_diag()
works properly for both types of chips.
ethernet chips. This driver is pretty simple, however it contains
special DSP initialization code which is needed in order to get
the chip to negotiate a gigE link. (This special initialization
may not be needed in subsequent chip revs.) Also:
- Fix typo in if_rlreg.h (RL_GMEDIASTAT_1000MPS -> RL_GMEDIASTAT_1000MBPS)
- Deal with shared interrupts in re_intr(): if interface isn't up,
return.
- Fix another bug in re_gmii_writereg() (properly apply data field mask)
- Allow PHY driver to read the RL_GMEDIASTAT register via the
re_gmii_readreg() register (this is register needed to determine
real time link/media status).
method. This is necessary on ia64 where it's known that serial interfaces
described in the ACPI namespace may not have the well-known IRQs assigned
to them. This confuses us in thinking they are PCI based interrupts and
wrongly program the APIC.
for the 8169S, according to my sample board. The RealTek Linux driver
mentions 0x00800000. I'm assigning this to the 8110S until I get
more info on it. (The (preliminary) RealTek docs only say that 8169S/8110S
chips will have some combination of those two bits set, but doesn't say
exactly what bit combination goes with which chip variant.)
is not a size of 1. Since we already know there is a FIFO, we can
safely assume that it is at least 16 bytes. Note that all this is
mostly academic anyway. We don't use the size of the Rx FIFO
currently. If we add support for hardware flow control, we only
care about Rx FIFO sizes larger than 16.
written by Stuart Walsh and Duncan Barclay (with some kibbitzing by
me). I'm checking it in on Stuart's behalf.
The BCM4401 is built into several x86 laptop and desktop systems. For the
moment, I have only enabled it in the x86 kernel config because although
it's a PCI device, I haven't heard of any standalone NICs that use it. If
somebody knows of one, we can easily add it to the other arches.
This driver uses register/structure data gleaned from the Linux
driver released by Broadcom, but does not contain any of the code
from the Linux driver itself. It uses busdma.
rl(4) driver and put it in a new re(4) driver. The re(4) driver shares
the if_rlreg.h file with rl(4) but is a separate module. (Ultimately
I may change this. For now, it's convenient.)
rl(4) has been modified so that it will never attach to an 8139C+
chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to
match the 8169/8169S/8110S gigE chips. if_re.c contains the same
basic code that was originally bolted onto if_rl.c, with the
following updates:
- Added support for jumbo frames. Currently, there seems to be
a limit of approximately 6200 bytes for jumbo frames on transmit.
(This was determined via experimentation.) The 8169S/8110S chips
apparently are limited to 7.5K frames on transmit. This may require
some more work, though the framework to handle jumbo frames on RX
is in place: the re_rxeof() routine will gather up frames than span
multiple 2K clusters into a single mbuf list.
- Fixed bug in re_txeof(): if we reap some of the TX buffers,
but there are still some pending, re-arm the timer before exiting
re_txeof() so that another timeout interrupt will be generated, just
in case re_start() doesn't do it for us.
- Handle the 'link state changed' interrupt
- Fix a detach bug. If re(4) is loaded as a module, and you do
tcpdump -i re0, then you do 'kldunload if_re,' the system will
panic after a few seconds. This happens because ether_ifdetach()
ends up calling the BPF detach code, which notices the interface
is in promiscuous mode and tries to switch promisc mode off while
detaching the BPF listner. This ultimately results in a call
to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init()
to handle the IFF_PROMISC flag change. Unfortunately, calling re_init()
here turns the chip back on and restarts the 1-second timeout loop
that drives re_tick(). By the time the timeout fires, if_re.ko
has been unloaded, which results in a call to invalid code and
blows up the system.
To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(),
which stops the ioctl routine from trying to reset the chip.
- Modified comments in re_rxeof() relating to the difference in
RX descriptor status bit layout between the 8139C+ and the gigE
chips. The layout is different because the frame length field
was expanded from 12 bits to 13, and they got rid of one of the
status bits to make room.
- Add diagnostic code (re_diag()) to test for the case where a user
has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some
NICs have the REQ64# and ACK64# lines connected even though the
board is 32-bit only (in this case, they should be pulled high).
This fools the chip into doing 64-bit DMA transfers even though
there is no 64-bit data path. To detect this, re_diag() puts the
chip into digital loopback mode and sets the receiver to promiscuous
mode, then initiates a single 64-byte packet transmission. The
frame is echoed back to the host, and if the frame contents are
intact, we know DMA is working correctly, otherwise we complain
loudly on the console and abort the device attach. (At the moment,
I don't know of any way to work around the problem other than
physically modifying the board, so until/unless I can think of a
software workaround, this will have do to.)
- Created re(4) man page
- Modified rlphy.c to allow re(4) to attach as well as rl(4).
Note that this code works for the sample 8169/Marvell 88E1000 NIC
that I have, but probably won't work for the 8169S/8110S chips.
RealTek has sent me some sample NICs, but they haven't arrived yet.
I will probably need to add an rlgphy driver to handle the on-board
PHY in the 8169S/8110S (it needs special DSP initialization).
from the SAB82532 and the Z8530 hardware drivers by introducing
uart_cpu_busaddr(). The assumption is not true on pc98 where
bus_space_handle_t is a pointer to a structure.
The uart_cpu_busaddr() function will return the bus address
corresponding the tag and handle given to it by the BAS.
WARNING: the intend of the function is STRICTLY to allow hardware
drivers to determine which logical channel they control and is NOT
to be used for actual I/O. It is therefore EXPLICITLY allowed that
uart_cpu_busaddr() returns only the lower 8 bits of the address
and garbage in all other bits. No mistakes...
(ns8250 copied and s/ns8250/i8251/g), but there for linkage purposes.
Real code to follow, once I get past some boot issues on my pc98 boxes
with recent current.
It improves on sio(4) in the following areas:
o Fully newbusified to allow for memory mapped I/O. This is a must
for ia64 and sparc64,
o Machine dependent code to take full advantage of machine and firm-
ware specific ways to define serial consoles and/or debug ports.
o Hardware abstraction layer to allow the driver to be used with
various UARTs, such as the well-known ns8250 family of UARTs, the
Siemens sab82532 or the Zilog Z8530. This is especially important
for pc98 and sparc64 where it's common to have different UARTs,
o The notion of system devices to unkludge low-level consoles and
remote gdb ports and provides the mechanics necessary to support
the keyboard on sparc64 (which is UART based).
o The notion of a kernel interface so that a UART can be tied to
something other than the well-known TTY interface. This is needed
on sparc64 to present the user with a device and ioctl handling
suitable for a keyboard, but also allows us to cleanly hide an
UART when used as a debug port.
Following is a list of features and bugs/flaws specific to the ns8250
family of UARTs as compared to their support in sio(4):
o The uart(4) driver determines the FIFO size and automaticly takes
advantages of larger FIFOs and/or additional features. Note that
since I don't have sufficient access to 16[679]5x UARTs, hardware
flow control has not been enabled. This is almost trivial to do,
provided one can test. The downside of this is that broken UARTs
are more likely to not work correctly with uart(4). The need for
tunables or knobs may be large enough to warrant their creation.
o The uart(4) driver does not share the same bumpy history as sio(4)
and will therefore not provide the necessary hooks, tweaks, quirks
or work-arounds to deal with once common hardware. To that extend,
uart(4) supports a subset of the UARTs that sio(4) supports. The
question before us is whether the subset is sufficient for current
hardware.
o There is no support for multiport UARTs in uart(4). The decision
behind this is that uart(4) deals with one EIA RS232-C interface.
Packaging of multiple interfaces in a single chip or on a single
expansion board is beyond the scope of uart(4) and is now mostly
left for puc(4) to deal with. Lack of hardware made it impossible
to actually implement such a dependency other than is present for
the dual channel SAB82532 and Z8350 SCCs.
The current list of missing features is:
o No configuration capabilities. A set of tunables and sysctls is
being worked out. There are likely not going to be any or much
compile-time knobs. Such configuration does not fit well with
current hardware.
o No support for the PPS API. This is partly dependent on the
ability to configure uart(4) and partly dependent on having
sufficient information to implement it properly.
As usual, the manpage is present but lacks the attention the
software has gotten.
o Introduce PUC_PORT_TYPE_UART so that we can attach to uart(4),
o Introduce port sub-types (eg PUC_PORT_UART_NS8250, PUC_PORT_UART_Z8530)
to handle different hardware and determine resource sizes.
o Introduce two new IVARs: PUC_IVAR_SUBTYPE and PUC_IVAR_REGSHFT. Both
are used by uart(4) to get sufficient information to talk to the HW.
o Introduce PUC_FLAGS_ALTRES to tell puc(4) to try memory mapped I/O
if I/O port space cannot be allocated, or vice versa.
o Have ports of type PUC_PORT_TYPE_COM attach to uart(1) if attaching
to sio(4) fails (due to not having the sio driver).
o Put struct puc_device_description in struct puc_softc instead of
having a pointer to a device description in the softc. This allows
us to create device descriptions on the fly without having to use
malloc() or otherwise have them staticly defined.
o Move puc_find_description() from puc.c to puc_pci.c as it's specific
to PCI.
o Add EBUS and SBUS frontends for use on sparc64. Note that the P in
puc stands for PCI, so we kinda mess things up here. It's too soon
to worry about it though. We'll know what to do about it in time.
NOTE: This commit changes the behaviour of puc(4) to not quieten the
device probe and attach for child devices. The uart(4) driver provides
additional device description that is valuable to have.
For the floppy driver, use fdcontrol to manipulate density selection.
For the CD drivers, the 'a' and 'c' suffix is without actual effect and
any applications insisting on it can be satisfied with a symlink:
ln -s /dev/cd0 /dev/cd0a
Ongoing discussion may result in these pieces of code being removed before
the 5-stable branch as opposed to after.
such a card is ejected, we'd panic. Instead, just ignore it.
I should also add a sanity check in the FUNCID code as well, but this
isn't wrong since the check is cheap and happens infrequently.
and replace it with the more intuitive name PCIR_BARS.
- Add a PCIR_BAR(x) macro that returns the config space register offset of
the 32-bit BAR x.
MFC after: 3 days
switched from PCCARD_MEM_FOO to PCCARD_A_MEM_FOO, yet we didn't change
exca in all the right places. Do so now. Also use PCCARD_WIDTH_AUTO
rather than the magic cookie 0.
change also disables interrupts around non-S4 suspends whereas before we
did not do this. Our version of AcpiEnterSleepStateS4bios was almost
identical to the ACPICA version.
- Add a new PCIM_HDRTYPE constant for the field in PCIR_HDRTYPE that holds
the header type.
- Replace several magic numbers with appropriate constants for the header
type register and a couple of PCI_FUNCMAX.
- Merge to amd64 the fix to the i386 bridge code to skip devices with
unknown header types.
Requested by: imp (1, 2)
reading the CIS on some cards. However, not all just yet. This makes
at least some of the xircom cards that weren't working to work. It
doesn't make my home and away card work, however.
o Don't get the card offset wrong. This is the biggest hassle for
reading the CIS. The old code was just so wrong I can't believe that
it worked at all.
o Don't set the bit that allows/forces 16-bit memory access to the
memory. It is hard coded with 0x80.
o Don't need to slow down memory access with wait-states. OLDCARD didn't
need them and it doesn't hurt anything.
o remove bogus grousying in comment.
Bug Fixes:
- Allow users to use LAA
- Remember promiscuous mode settings while bridging
- Allow gratuitous arp's to be sent
PR: 52966/54488
MFC after: 1 week
METEORSSIGNAL ioctl. Applications use this ioctl with the value
METEOR_SIG_MODE_MASK (0xFFFF0000, -65536) to reset signal delivery,
but revision 1.126 caused the driver to return EINVAL in this case.
Interestingly, the same METEORSSIGNAL ioctl in the meteor driver uses
0 to reset signal delivery.
This commit allows METEOR_SIG_MODE_MASK as a synonym for 0 in the
bktr driver, and restructures the code a bit so that it is otherwise
identical between the bktr and meteor drivers.
compatibility routine, go ahead and accept that as 'success'. A
properly written compatible driver should return < 0 for both the
compat match and compat probe routines, so this will wind up doing the
right thing.
This will get rid of the warnings issued at shutdown (that seems to
worry alot of users), but will also no flush cache on lots of
devices that can, but doesn't set the right support bits...
Restructure the way ATA/ATAPI commands are processed, use a common
ata_request structure for both. This centralises the way requests
are handled so locking is much easier to handle.
The driver is now layered much more cleanly to seperate the lowlevel
HW access so it can be tailored to specific controllers without touching
the upper layers. This is needed to support some of the newer
semi-intelligent ATA controllers showing up.
The top level drivers (disk, ATAPI devices) are more or less still
the same with just corrections to use the new interface.
Pull ATA out from under Gaint now that locking can be done in a sane way.
Add support for a the National Geode SC1100. Thanks to Soekris engineering
for sponsoring a Soekris 4801 to make this support.
Fixed alot of small bugs in the chipset code for various chips now
we are around in that corner anyways.
support stripped out and minimally renamed to owi. This driver
attaches to lucent cards only. This is designed to aid in the testing
of fixes to the wi driver for lucent cards. It is supported only as a
module (you cannot compile it into your kernel). You cannot have the
wi driver in your kernel (or loaded as a moudle) to use the owi
module.
I've not connected it to build, as this module is currently for
debugging purposes. This is for developers only at the present time.
If we can't get lucent support fixed by 5.2 code freeze, then we'll
re-evaulate this support level. Please use this to fix the lucent
support in dev/wi. This will be removed from the system when lucent
support has been fixed in dev/wi.
Note to developers: Do not connect this to the build, make it possible
to build into the kernel or otherwise 'integrate' this into system
without checking with me first. This is for debugging purposes only.
If this doesn't work for you, I don't want to hear about it unless you
are fixing the wi driver :-)
gfb_draw if 'flip' is specified. This causes the mouse cut region
to be displayed in reverse color so it is visbile.
- Use the "other" implementation of gfb_cursor for the creator driver,
which doesn't assume there is a hardware cursor. It seems that the
hardware cursor that creator provides doesn't display the character
under the cursor in reverse colors, so the driver does this manually
and uses the hardware cursor for the mouse pointer (which it also works
much better for). This is wedged here because it required less hoops
than accessing the syscons vtb from inside the video driver, which is
needed to read the character and color attributes under the new cursor
position.
These are fixed resolution and operate only in pixel mode so they present
a challenge to syscons (square peg, round hole, etc, etc). The driver
provides a video driver interface for syscons and a separate character
device for X to mmap. Wherever possible the creator's accelarated graphics
functions are used so text mode is very fast.
Based roughly on the openbsd driver.
round the result up to a multiple of 4 bytes so that it will always
be a multiple of the sample size. Also use the actual buffer size
from sc->bufsz instead of the default DS1_BUFFSIZE.
This fixes panics and bad distortion I have seen on Yamaha DS-1
hardware, mainly when playing certain Real Audio media.
Reviewed by: orion (an earlier version of the patch)
first sample in the buffer to be ignored. The bug caused a repetitive
glitch in one of the stereo channels when playing mono sound on
configurations that use the monotostereo16 feeder.
Reviewed by: orion
to intptr_t. This fixes a compiler warning (integer from pointer
without cast) in scvgarndr.c when SC_PIXEL_MODE is defined.
o Define readb() and writeb(). Both are used in scvgarndr.c when,
guess what, SC_PIXEL_MODE is defined.
Both changes are ia64 specific.
Found by: LINT
CB710, CB720, CB1211, CB1225, CB1410 and CB1420
These are likely licensed designed from TI, and the Linux PCMCIA code
treats them as TI chips.
Add comment, but no ID for the 711E1 from O2Micro.
vendors that list the vendor ID in the proper byte order. The second
section is for vendors that get it backwards. The third is for what
appear to be 'random' ones (although 0xcxxx appears to be coherent
enough that maybe somebody else is assigning those numbers).
o AD1980 hook.
o ac97_fix_auxout.
and:
o Associate AC97_MIX_AUXOUT with SOUND_MIXER_OGAIN rather than
SOUND_MIXER_MONITOR.
o Add ac97_fix_tone to remove tone controls from mixer if invalid.
are all bogus, and the cards that don't decode things quite right
often have hundreds of them. This will fix starvation of small dmesg
buffers and allow better debugging to happen. I thought about adding
an override, but there is such a thing as too many knobs. :-)
- Fix up TX speed changes.
- Make mpi-350 cards sort-of work with new firmware. It RXs okay but TXs
only work for about 14 packets then fails to get an interrupt. The
TX watchdog fires. It has been reported that my hack for now doesn't
break cards with the older firmware. It appears my card has lost
the ability to RX or TX at all but other peoples cards work. I assume
it got damaged in tansport.
MFC: 1 week.
count handling of station entries in hostap mode:
Input path:
o driver is now expected to find the node associated with the
sender of a received frame; use ic_bss if none is located
o driver passes the (referenced) node into ieee80211_input for
use within the wlan module and is responsible for cleaning up
on return
o the antenna state is no longer passed up with each frame; this
is now considered driver-private state and drivers are responsible
for keeping it in the driver-private part of a node
Output path:
Revamp output path for management frames to eliminate redundant
locking that causes problems and to correct reference counting
bogosity that occurs when stations are timed out due to inactivity
(in AP mode). On output the refcnt'd node is stashed in the pkthdr's
recvif field (yech) and retrieved by the driver. This eliminates
an unref/ref scenario and related node table unlock/lock due to the
driver looking up the node. This is particularly important when
stations are timed out as this causes a lock order reversal that
can result in a deadlock. As a byproduct we also reduce the overhead
for sending management frames (minimal). Additional fallout from
this is a change to ieee80211_encap to return a refcn't node for
tieing to the outbound frame. Node refcnts are not reclaimed until
after a frame is completely processed (e.g. in the tx interrupt
handler). This is especially important for timed out stations as
this deref will be the final one causing the node entry to be
reclaimed.
Additional semi-related changes:
o replace m_copym use with m_copypacket (optimization)
o add assert to verify ic_bss is never free'd during normal operation
o add comments explaining calling conventions by drivers for frames
going in each direction
o remove extraneous code that "cannot be executed" (e.g. because
pointers may never be null)
quietly discard them; this just permits them to be collected with bpf)
o add a counter for the number of rate control frames discarded when not in
monitor mode
o move the rx "too short" statistic in the stat structure so non-error rx stats
are together (NB: ABI change to apps that collect stats via driver ioctl)
mistakes (this mistake was not an issue because the length is only used to
decide whether or not to allocate a cluster)
o while here, move a beacon length comment to the "right place"
