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.
16-bit mono recording seems to work OK. 16-bit stereo recording
is missing the left channel for reasons unknown, fixes welcome.
8-bit recording still unsupported.
international. Drop Hungarian map that is a proper subset of
international map (and I strongly suspect the "Hungarian" is a
misnomer in the first place). Adjust hpckbd_keymap_table accordingly.
With this change selecting "US" in hpcboot will give you real US
layout. Selecting "Hungarian" will give you international layout and
I think hpcboot shall be changed accordingly.
I'm not sure if there's separate "German" layout for hpcs. I think
any layout that is not different from us/international on the primary
layer shall be handled with wsconsctl.
Our default keymaps map "<=" to KS_Delete (i.e. vt-style rubout)
anyway, so default behavior is not changed, but some people might
prefer to map "<=" and "del" differently. Let them distinguish
between the two. Fix the flying windows key mapping it should be 219,
not 221 (menu). Drop non-existent keycode 125.
my ThinkPad 600E.
XXX isa_dmainit isn't called early enough for the 'audio at wss' attachment
XXX to work, so I'm deferring the call to 'wssattach' until later on. This
XXX should be fixed soon.
576000bps and 1152000bps. In the current published version of the data
sheet the MIR support documentation is gone, and the MIR mode bit is
documented as reserved. Possibly the device has a design flaw affecting
the MIR data rates? Document here that this information came from an
earlier data sheet, but leave MIR support in for the moment.
If a series of outputs are delivered to the device before the kernel thread
has polled for input data, any input data will be lost. As a
counter measure, always force an input check between outputs.
and avoid using MD myetheraddr() function.
This makes the driver MI, and closes PR kern/13797.
The PCI HME is a PCIO chip, which is composed of two functions:
function 0: PCI-EBus2 bridge, and
function 1: HappyMeal Ethernet controller.
The Ethernet address is (expected to be) in the PCI FCode PROM connected
to the EBus bridge (function 0) of the device.
Since the HME is on function 1, some magic is used to access to the PROM.
We don't have MI EBus driver since no EBus device exists (besides the
FCode PROM) on add-on HME boards. The ``not configured'' message for
function 0 is what is expected.
The SPARC case is currently unchanged. It needs interaction with OpenBoot.
card contains only one clock, which is already used by the other
DAC. The FM DAC can handle a few fixed-frequency choices.
thanks to Matthew Green for testing
- Fix typo in printf message.
- Don't use PCI_PRODUCT_DELTA_8139 (0x1360) for args of cardbus_conf_read()
and cardbus_conf_write(); use CARDBUS_INTERRUPT_REG (0x3c) instead.
cannot change the recording or playback mode of the device, it can
only change other mode-like values (like AUMODE_PLAY_ALL). Be very
explicit about fixing up the user's mode value based on the mode of
the device. Before, giving AUMODE_PLAY_ALL could cause AUMODE_PLAY
to become set on the device, and once AUMODE_PLAY_ALL was set it
was impossible to clear.
the MIF Configuration Register PHY_Select, there is no use in pretending
we could talk to both at the MII interface layer.
If both PHY are reported to be present, prefer the external one.
Remember this selection and enforce it in hme_mii_{read,write}reg.
This fixes problems with one of the dual hmes in Netra T1s.
From OpenBSD.
various orders depending how the upper level driver is flushing it's queue's.
This prevents the deadlocks I was seeing before with >8k writes.
XXX: Still not completely there as > 64k copies trigger bugs and the page
table support still needs to be written to break those down.
FreeBSD, with cleanup/KNF by me.
Note: These chipsets are not well supported by the i810 driver in
NetBSD's in-tree xsrc (based on XFree86 4.2.1 at this time). However,
the driver works perfectly using bleeding-edge XFree86-current on my
Omnibook's i830MG with these agp changes.
accept ranges as well as single addresses. Still need to go through any key
areas and remove the malloc's and replace these with some sort of pooling
instead.
The driver puts the adapter in promisc mode to receive multicast addresses.
At last set the IFF_PROMISC flag so that the upper layer filters frames
that are not for us.
Sure, the real fix would be to get multicast filters working ...
least 1us. Documentation I've found for the simple (SPP) parallel port
mode says that data should be stable 500ns before STROBE, STROBE should
be pulsed for no less than 500ns, and that data should be stable another
500ns after STROBE has been de-asserted.
Makes lpt@ebus on my Sun Ultra5 work with my HP DeskJet 712C, at least in
polled mode. Thanks to Martin for astutely noting it was probably a bug
with STROBE being pulsed too quickly.
1. Reduce debugging level to sane levels
2. Fix bugs in alloc_data_map related to allocing whole bytes of bitmap at
a time.
At this point the driver is functional. It talks to a local drive here and
can label/newfs. Performance is...lacking at the moment as its chewing cpu
heavily (probably due to the number of memcpy's) and will be the next area
attacked.
support up to the max ohci descriptor segments. Then attempt to fill it in
via a load. Use the number of segments filled in as the basis for figuring
out how many descriptors to supply to the ohci DMA engine.
XXX: Still needs to account for requests which because of splits may overflow
the 6 dma descriptors available today. For now this fixes cases where a
single 512 byte write was getting split into 2 dma segments from 1 incoming
iov request
The definitions were not the same between the scsi_messages file and this
definition so simply removing it here and letting the other one be used
results in incorrect behavior (regardless of whether it made the code
compile....)
wiz