in the loopback test in the probe. The delay was too short for consoles
at speeds lower than about 3200 bps. This shouldn't have caused many
problems, since such low speeds are rare and the probe is forced to
succeed for consoles.
and the Z8530 drivers used the I/O address as a quick and dirty way to
determine which channel they operated on, but formalizing this by
introducing iobase is not a solution. How for example would a driver
know which channel it controls for a multi-channel UART that only has a
single I/O range?
Instead, add an explicit field, called chan, to struct uart_bas that
holds the channel within a device, or 0 otherwise. The chan field is
initialized both by the system device probing (i.e. a system console)
or it is passed down to uart_bus_probe() by any of the bus front-ends.
As such, it impacts all platforms and bus drivers and makes it a rather
large commit.
Remove the use of iobase in uart_cpu_eqres() for pc98. It is expected
that platforms have the capability to compare tag and handle pairs for
equality; as to determine whether two pairs access the same device or
not. The use of iobase for pc98 makes it impossible to formalize this
and turn it into a real newbus function later. This commit reverts
uart_cpu_eqres() for pc98 to an unimplemented function. It has to be
reimplemented using only the tag and handle fields in struct uart_bas.
Rewrite the SAB82532 and Z8530 drivers to use the chan field in struct
uart_bas. Remove the IS_CHANNEL_A and IS_CHANNEL_B macros. We don't
need to abstract anything anymore.
Discussed with: nyan
Tested on: i386, ia64, sparc64
aic7xxx_pci.c:
When performing our register test, be careful
to avoid resetting the chip when pausing the
controller. The test reads the HCNTRL register
and then writes it back with the PAUSE bit
explicitly set. If the last write to the controller
before our probe is to reset it, the CHIPRST
bit will still be set, so we must mask it off
before the PAUSE operation. On some chip versions,
we cannot access registers for a few 100us after
a reset, so this inadvertant reset was causing PCI
errors to occur on the read to check for paused
status.
Submitted by: gibbs
Instead, use EXCA_MEMREG_WIN_SHIFT which is the amount we shift the
bus address by to write into upper memory (eg above 24MB). Use the
latter in this case.
1.186: onoe; Sony's PEGA-WL110 CF WLAN (which strangely has fujitsu's
vendor id)
1.185: ichiro; Quatech Inc, PCMCIA Enhanced Parallel Port Card
Also:
o update $NetBSD$
o minor tweaks to FUJITSU. We've tried to keep the CIS only entries seprate
from vendor id/product id.
Fix to the messages output under CAM_DEBUG_CCB: the summary sense
information (error bits and sense key) is in the error field, not
in the result field, of struct ata_request. No other functional change.
device to access 64-bit addresses from a 32-bit PCI bus. While the
RealTek manual says you can set this bit and the chip will perform
DAC only if you give it a DMA address with any of the upper 32
bits set, this appears not to be the case. If I turn on the DAC
bit, the chip sets the 'system error' bit in the status register
when I to do a DMA on my Athlon test box with 32-bit PCI bus (VIA
chipset) even though I only have 128MB of physical memory, and thus
can never give the chip a 64-bit address.
Obviously, I can't just set it and forget it, so until I figure
out the right rule for when it's safe/necessary to enable it, keep
it turned off.
Tested at 100Mbit only, using Asus P4P800 onboard 3C940.
The -stable version of this patch I have in use for ~2 weeks now, and works
just fine for me.
Based on: Nathan L. Binkert's patch for OpenBSD
Patch submitted by and thanks to: Jung-uk Kim <jkim@niksun.com>
MFC after: 2 weeks
