They do not seem well-justified according to anyone's understanding
of what they really do, and it seems especially inappropriate to
call them at attach- and resume-time.
Leave alone the Latency Timer set by the Cardbus bridge.
With version 1.152 of dev/pci/pccbb.c, we can power down the card
when it is not in-use, so do that.
Let the Cardbus bridge driver set our Latency Timer, but round down
to the nearest multiple of 0x10, since the RTL8180 datasheet may
be trying to tell us that is necessary.
Activate Parity & System Error reporting.
Use a more meaningful variable name, reg -> csr.
Let the TI1420 PCI-Cardbus bridge do burst reads from the primary
(PCI) bus. This ought to improve Tx performance on Cardbus NICs.
This optimization may apply to other TI bridges, but I only have
a datasheet for the TI1420. :-/
Activate PCI Parity Error and System Error reporting on PCI-Cardbus
bridges.
To avoid data destruction, set the Master Abort mode to 1. Stops
the bridge from silently discarding writes from the secondary bus
to the primary bus (Cardbus writes to PCI). Also, stops the bridge
from fulfilling a read by a bus master on the secondary bus that
failed on the primary bus with 0xffffffff (Cardbus reads from PCI).
Now the bus will indicate an error condition (SERR) instead of
silently destroying/corrupting data.
Forward system error indications from the secondary to the primary
bus. Detect parity errors on the secondary.
Set a Cardbus card's Latency Timer to something reasonable, according
to the Cardbus card's Minimum Grant and the bandwidth available on
the PCI bus. Restore the Latency Timer when re-enabling a card
(e.g., after power reactivation).
- replace rtk_type member in rtk_softc which has chip types
with new rtk_quirk that represents quirks on each chip:
- RTKQ_8129 doesn't have internal MII (used in rtk(4))
- RTKQ_8139CPLUS has different register layout (for re(4))
- RTKQ_8169NONS (original 8169) requires some settings on init
- RTKQ_PCIE requires different settings in setmulti
so that we don't have to check each hwrev values or types everywhere
and newer variants will also work without changes if they don't
have other quirks
(sc_rev is unchenged for now for reference to the Realtek's driver)
- don't check hwrev register in re_pci_match() but check
only PCI_VENDER(), PCI_PRODUCT() and PCI_REVISION()
so that we no longer have to map pci space there
- add a new HWREV value for another 8168 variant
- try to map PCI mem space more properly
- remove (probably unneeded) ifp->if_baudrate initialization
Tested on a newer 8168 variant by Dennis den Brok on tech-kern,
and also tested on 8139 and 8169C on macppc, and 8139C+ on landisk
by me.
in the bus layer and remove from common ath_attach().
Having it in both layers (on some bus architectures)
was causing a double call to ath_stop() on shutdown
which in turn was tickling the bus lockup described
therin on slower machines.
This allows us to convert aucom to just another com attachment, and cleanup
some code in the com_arbus.c.
Additionally, we use a common com_cleanup routine rather than having a
zillion copies of it in the attachment points.
This has been tested on a number architectures, and it has been shown to get
close to comparable performance when COM_REGMAP is defined, and comparable
when it is not defined.
Approved by core@. Fixes PR port-evbmips/32362.
New HAL includes some driver changes to register accesses.
Adds support for WLAN devices on AR5312 family devices.
Adds support 32-bit SPARC ath devices (untested).
ath enabled in SPARC64 GENERIC builds.
This HAL is tested and known to work for i386 PCI devices, SPARC64 PCI devices,
and AR5312 WiSoC devices. MIPS PCI devices appear to be busted (possibly only
on Alchemy hardware, unconfirmed), and cardbus support is untested due to
lack of test hardware.
Please report any new problems with this import to garrett@.
http://mail-index.netbsd.org/tech-net/2006/03/15/0000.html.
The new layout almost precisely matches FreeBSD, and should make
future imports much easier.
At the same time, import the current 0.9.16.16 HAL from FreeBSD. According
to sam@, this is the proper version we should be using.
