(and by extension, the 2422).
One peculiar thing I've found with the 2322 is that if you
don't force it to do Hard LoopID acquisition, the firmware
crashes. This took a while to figure out.
While we're at it, fix various bugs having to do with NVRAM
reading and option setting with respect to pieces of NVRAM.
is never taken since there aren't any 802.11a ural(4) sticks available
on the market.
PR: kern/99676
Submitted by: KIYOHARA Takashi
Reviewed by: damien
MFC after: 1 week
tree... John Baldwin noted that sio might pass values between probe
and attach via softc. It appears that sio does leave the hardware in
a known state after probing, so other drivers that try to probe might
leave it in a worse state. It doesn't seem to pass any data in softc,
however, that I could find... I think we should not be probing for
anything but nonPnP isa, but that's a change for another day.
Submitted by: Frank Behrens
PR: 87845
cards: the chips are all marked "RTL8111B", but they put stickers on the
back that say "RTL8168B/8111B". The manual says there's only one HWREV code
for both the 8111B and 8168B devices, which is 0x30000000, but the cards
they sent me actually report HWREV of 0x38000000. Deciding to trust the
hardware in front of me rather than a possibly incorrect manual (it wouldn't
be the first time the HWREVs were incorrectly documented), I changed the
8168 revision code. It turns out this was a mistake though: 0x30000000
really is a valid for the 8168.
There are two possible reasons for there to be two different HWREVs:
1) 0x30000000 is used only for the 8168B and 0x38000000 is only for
the 8111B.
2) There were 8111/8168 rev A devices which both used code 0x30000000,
and the 8111B/8168B both use 0x38000000.
The product list on the RealTek website doesn't mention the existence of
any 8168/8111 rev A chips being in production though, and I've never seen
one, so until I get clarification from RealTek, I'm going to assume that
0x30000000 is just for the 8168B and 0x38000000 is for the 8111B only.
So, the HWREV code for the 8168 has been put back to 0x30000000,
a new 8111 HWREV code has been added, and there are now separate
entries for recognizing both devices in the device list. This will
allow all devices to work, though if it turns out I'm wrong I may
need to change the ID strings
BCM5787 based NICs.
- Recognize BCM5703 B0 ASIC.
- Rewrite the jumbo capability matching macro, so that chips known
to work are listed there. [*]
[*] I'm still not sure about this. Probably more corrections
will be done to this macro after discussion with davidch@
and brad@OpenBSD.
Obtained from: OpenBSD (brad)
This driver was ported from OpenBSD by Shigeaki Tagashira
<shigeaki@se.hiroshima-u.ac.jp> and posted at
http://www.se.hiroshima-u.ac.jp/~shigeaki/software/freebsd-nfe.html
It was additionally cleaned up by me.
It is still a work-in-progress and thus is purposefully not in GENERIC.
And it conflicts with nve(4), so only one should be loaded.
latter is a PCIe 10/100 chip.
Finally fix the EEPROM reading code so that we can access the EEPROMs on all
devices. In order to access the EEPROM, we must select 'EEPROM programming'
mode, and then set the EEPROM chip select bit. Previously, we were setting
both bits simultaneously, which doesn't work: they must be set in the
right sequence.
Always obtain the station address from the EEPROM, now that EEPROM
reading works correctly.
Make the TX interrupt moderation code based on the internal timer
optional and turned off by default.
Make the re_diag() routine conditional and off by default. When it is
on, only use it for the original 8169, which was the only device that
that really needed it.
Modify interrupt handling to use a fast interrupt handler and fast
taskqeueue.
Correct the rgephy driver so that it only applies the DSP fixup for
PHY revs 0 and 1. Later chips are fixed and don't need the fixup.
Make the rgephy driver advertise both 1000_FD and 1000_HD bits in
autoneg mode. A couple of the devices don't autoneg correctly unless
configured this way.
stations in power save: add a new q where mcast frames are stashed
and on beacon update (at DTIM) move frames from the mcast q to the
cabq and start it. This ensures the cabq is only manipulated in
one place.
Sponsored by: Hobnob
MFC after: 2 weeks
Don't enable/disable I/O space except for SAS adapters.
This fixes a problem with VMware 4.5 Workstation.
Fix an egregious bug introduced to target mode so it actually
will not panic when you first enable a lun.
Minor fixes:
Take more infor from port facts and configuration pages.
MFC after: 1 week
- Add a new function linker_release_module() as a more intuitive complement
to linker_reference_module() that wraps linker_file_unload().
linker_release_module() can either take the module name and version info
passed to linker_reference_module() or it can accept the linker file
object returned by linker_reference_module().
- Curitel PC5740 Wireless Modem (Verizon's PCMCIA card)
- Sierra MC5720 Wireless Modem (Built in to Thinkpad X60s)
The scanner in the PR is already supported.
PR: 98908
Submitted by: Michael Collette <metrol@metrol.net>
blinks by default. When the operating system (read: normally an Xbox
360) initializes the gamepad, the LED stops blinking.
Change our uhid code to do the same.
PR: 97169
Submitted by: Ed Schouten <ed@fxq.nl>
