actually functional driver. It provides a local HCI interface to the
HCI-over-USB interface on standards-compliant Bluetooth USB devices.
Currently this device can be attached to the bthci driver for direct user-land
access to the device.
actually functional driver. It provides user access through a character
device to a Bluetooth HCI capable driver.
The device interface is the same (open/read/write) as the RAW HCI socket
(socket/recv/send) interface provided by the Linux and FreeBSD netgraph
Bluetooth stacks. This allows a (very small) number of diagnostic programs to
be trivially ported and actually work.
temperature to sysmon; in the near future we should be associating devices
in this thermal zone with this device so we can do active or passive
cooling on a zone-by-zone basis.
- Windows put the chip in suspended mode, make sure we unsuspend
it. 1.43, by Takefumi SAYO <stake@po.shiojiri.ne.jp>
- Detect the revision of the Rhine chip we're using, and force reset
when the chip supports it. 1.65, by silby@freebsd.org
bus_space_{read,write}_[1248]() functions, which will allow 16-bit
PCMCIA support to work without additional hacks in MI drivers.
this option is not enabled yet.
called twice. At least in NetBSD, the detach function is called when the
device is removed, even if the attach function has failed.
This is probably the cause of panics reported in kern/19326.
LINK_STAT notification for every change of BSSID, so the firmware's
BSSID and the driver's BSSID will get out of sync. This has two
bad affects. First, because the 802.11 framework filters received
packets based on BSSID, many packets can be dropped before the
driver adopts the firmware's BSSID. Second, ifconfig's tells a
misleading BSSID to the operator.
This problem is most apparent in networks where every station does
not hear every other. I reproduce these conditions in an office by
removing/replacing the antennas on my 802.11 cards.
As a solution, in IBSS mode, the driver will ask the firmware for
the BSSID every five seconds. Also, whenever the driver receives
a frame carrying a different BSSID than the driver's BSSID, then
the driver asks the firmware for the BSSID before handing the frame
to ieee80211_input.
USB protocol dictates that the port enable must be implied by the port
reset. To implement this on (at least) the VIA VT83C572 this means we
need to wait around tweaking the chip state until the port actually
transitions to enabled (or the device goes away). Likely fixes
kern/11018.
