Uploaded scripts work better if they are little endian, as the
card's engine expects, so convert to le first.
Also clean up attach routine a bit (use pa_id and PCI_REVISION
instead of fetching it ourselves).
This makes the driver work on my macppc G4, it can decode and
display video and tuner input. Sound does not seem to work, but
this may be my wonky formac bktr-for-macintosh card.
unless ACPI_FDC_DEBUG
array returned from _FDE contains UINT32 values, not UINT8; also change
the magic number '14' to '5 * sizeof(UINT32)' for clarity
remove XXX for the tape presence comment; it's Just Okay to not use the info
fdc_acpi_getknownfds(): if fdc_acpi_nvtotype() returns NULL, don't
attempt to attach the drive at all
XXX not tested
which is safer than the loop there used to be here.
wi_mwrite_bap: if wi_write_bap fails, don't keep on going: this
way you avoid writing garbage to the radio. First time you see
an odd-length mbuf, copy the remainder of the chain to sc_txbuf
and from there to the MAC. This way, you do not read an mbuf past
the end of its data (occasionally you will cross a page doing
that!) and you avoid expensive, excess seeks in the radio's own
buffer chain.
wi_rx_intr: clamp the frame length told to us by the driver to the
most bytes we can fit in our mbuf cluster.
I am still getting e-mails from my testers telling me how much
better this makes things.
XXX - need to move this (as well as the equivalent sparc stuff added
recently) outa here into sbus_machdep or something. We should not need
to know details of the actual bus_space implementation here.
* Improve acpi interrupt fixup a bit
* Source is an array, don't compare it to NULL, instead
look for an empty string to denote a link-device-less
entry.
* For root PCI busses, try to use the _BBN method to get
numbering right.
* Add acpi_md_callback() function for MD handling after the init,
but before * at acpi probing.
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.
augustss