- 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.
