which is ukbd0. Specifically, the keyboard driver structures for ukbd0
are not allocated/freed but are statically allocated via a persistent
global variable. There is some additional magic for the ukbd0 such that
if the keyboard is marked as probed in this global variable, then we
don't check to see if the device_t we are probing has an interface.
This causes a problem if an attach of ukbd0 fails without fulling clearing
the state in the global variable. Specifically, if the keyboard fails to
initialize in init_keyboard() or kbd_register(), then the keyboard will
still be marked as probed. The USB layer will then try to offer the
"generic" version of the USB keyboard device (as opposed to the
per-interface sub-devices) and the ukbd(4) driver will see that the
keyboard is marked probe and will skip the "is this a per-interface device"
check. Later in ukbd_attach() it panics because it tries to dereference
the interface pointer which is NULL.
The fix is to clear the flags in the persistent keyboard data for ukbd0
when init_keyboard() or kbd_register() fail.
MFC after: 1 week
Reviewed by: imp
with all functions supported. This is done adding usb device IDs
to the table of recognised devices (because there is no standard
'scanner' class, so no other way to recognise them), and with
a small change to the uscanner attach routine that prevents
reconfiguring the whole USB device while we are dealing only with
one of its USB interfaces.
The latter part has been suggested by Steinar Hamre in
http://www.freebsd.org/cgi/query-pr.cgi?pr=107665 , i have
only added a bit of explaination to the code.
I have personally tried this on the Epson DX-5050 and DX-6000
devices (on the US market they have different names, CX-something).
I have good reasons to think that, possibly with the mere addition
of more USB ids to the table in uscanner.c, this should work with
all Epson multifunction devices in that family (from DX-3800 to
DX-7000 - these units are in the 50-120$ price range).
More details on related topics (SANE configuration, OCR, etc.)
at http://info.iet.unipi.it/~luigi/FreeBSD/dx5050.html
Manpage updates coming soon.
Approved by: re, imp
MFC after: 3 days
controller if it's sole child device has the "usb" device class.
Previously ehci(4) would think that PCI-ISA bridges on the same slot
(such as in some Intel ICHs) were "neighbors" resulting in spurious
warnings about neighbor count mismatches.
- Fix a memory leak when looking for neighbors.
MFC after: 1 week
Approved by: re (kensmith)
Tested by: phk
o add driver callback to handle notification of beacon changes;
this is required for devices that manage beacon frames themselves
(devices must override the default handler which does nothing)
o move beacon update-related flags from ieee80211com to the beacon
offsets storage (or handle however a driver wants)
o expand beacon offsets structure with members needed for 11h/dfs
and appie's
o change calling convention for ieee80211_beacon_alloc and
ieee80211_beacon_update
o add overlapping bss support for 11g; requires driver to pass
beacon frames from overlapping bss up to net80211 which is not
presently done by any driver
o move HT beacon contents update to a routine in the HT code area
Reviewed by: avatar, thompsa, sephe
Approved by: re (blanket wireless)
that can lead to a panic when the stick is yanked.
- make sure that zyd_attach() returns 0 or errno.
Submitted by: Weongyo Jeong <weongyo.jeong@gmail.com>
Reported by: Ted Lindgreen <ted@tednet.nl>
Reviewed by: sam
Approved by: re (blanket wireless)
o update ic_lastdata to reflect time of last outbound frame
o outbound traffic must preempt/cancel bg scanning to avoid delays
This stuff was somehow missed in the initial import.
Reviewed by: thompsa, avatar, sephe (earlier version)
Approved by: re (blanket wireless)
ZD1211/ZD1211B USB IEEE 802.11b/g wireless network devices. Not (yet)
connected to the build process (next batch of commits once I've looped
the current back back).
Submitted by: Weongyo Jeong
Reviewed by: sam@
Approved by: re@
differ in their details with calls to a new function, ehci_hcreset(),
that performs the reset.
The original sequences either had no delay or a 1ms delay between
telling the controller to stop and asserting the controller reset
bit. One instance of the original reset sequence waited for the
controller to indicate that its reset was complete before continuing,
but the other two immediately let the subsequent code execute. The
latter is a problem on some hardware, because a read of the HCCPARAMS
register returns an incorrect value while the reset is in progress,
which triggers an infinite loop in ehci_pci_givecontroller(), which
hangs the system on shutdown.
The reset sequence in ehci_hcreset() starts with the most complete
instance from the original code, which contains a loop to wait for
the controller to indicate that its reset is complete. This appears
to be the correct thing to do according to "Enhanced Host Controller
Interface Specification for Universal Serial Bus" revision 1.0,
section 2.3.1. Add another loop to wait for the controller to
indicate that it has stopped before setting the HCRESET bit. This
is required by the section 2.3.1 in the specification, which says
that setting HCRESET before the controller has halted "will result
in undefined behaviour".
Reviewed by: imp (previous patch version without the extra wait loop)
Tested by: se (previous patch version without the extra wait loop)
Approved by: re (bmah)
MFC after: 1 week
to repeat if you had more than two keys down at any given time (which
happened to me all the time with emacs).
This is taken from PR 110681, although what URATAN Shigenobu describes
there is different than the pathology that I have been seeing. I'm
seeing this only in X, while he sees it on his console, yet I think
the two problems are related. I've also reworked the patch slightly
to conform to the coding standards of adjacent code.
It is unclear to me if this merely masks the maddening bug that I have
seen, or if this is a real fix. I typically see the problem when I'm
typing fast in emacs and using lots of motion keys (meta and control).
In either case, my workstation at work again is finally useful with
this patch.
PR: 110681
Submitted by: URATAN Shigenobu
Approved by: re (blanket)
the protocol to be report on each open, but ignore any errors as set
protocol for mice that don't implement the boot protocol can generate
an error. Evidentally, the Gyration GyroPoint RF Technology Receiver
(Gyration Ultra Cordless) device has this problem.
Submitted by: Eugene M. Kim
PR: 106565
Approved by: re (blanket)
do the heavy lifting of the 'mii_tick' function, rue was left behind.
Implement this in a naive way. Reports from the field show this makes
the driver functional with some locking issues, as opposed to an
instant panic. Those will be addressed in a later version of the
driver.
Approved by: re@ (bmah)
Sort NETGEAR list per convention.
Swap QUALCOMM and QUALCOMM2.
Add a few vendor products.
no md5 changes with this file (except when USBVERBOSE is enabled)
Approved by: re@ (blanket)
in. These are exclusively in the name of the company for this round.
No new devices have been added, but the MITEL entry has been
eliminated because nothing uses it. You won't see any difference
unless you have USBVERBOSE defined for the kernel.
Approved by: re@ (blanket)
o Adonics Cable 205
o Aiptek PocketCAM 3Mega
o Belkin USB2SCSI
o Casio QV DigiCam
o CCYU EasyDisk ED1064
o Desknote UCR-61S2B
o Epson Stylus Photo 875DC Card Reader
o Epson Stylus Photo 895 Card Reader
o Feiya 5-in-1 Card Reader
o Hitachi Dvd-CAM DZ-MV100A Camcorder
o HP CD-WRiter+ CD-4e
o Insystem Storage Adapter v2
o Kyocera Finecam S3x
o Kyocera Finecam S4
o Kyocera Finecam S5
o Kyocera Finecam L3
o Lexar USB CF Reader
o MindAtWork Digital Wallet
o Minolta Dimage F300
o Minolta Dimage E223
o Minsumi USB Fdd
o Netac USB-CF-Card
o NetChip USB Clik! 40
o Onspec MDCFE-B USB CF Reader
o Onspec SIIG/Datafab Memory Stick + CF Reader/Writer
o Onspec Datafab-based Reader
o Onspec PNY/Datafab CF+SM Reader
o Onspec SimpleTech/Datafab CF+SM Reader
o Onspec MDSM-b Reader
o Onspec USB To CF + SM Combo (LC1)
o Onspec ImageMate SDDR55
o Panasonic LS-120 Camera
o Samsung Techwin Digimax 410
o Shuttle eUSB SmartMedia / CompactFlash Adapter
o Skanhex MD 7425 Camera
o Skanhex SX 520z Camera
o Sony Memorystick NW-MS7
o Sony Portable USB Hardrive V2
o Sony Memorystick PEG N760c
o Sony Memorystick MSC-U03
o TREK/IBM USB memory key
o Trumpion T33520 USB Flash Card Controller
o Trumpion MP3 Player
o Vivtar Vivicam 35Xx
o WinMaxGroup USB Flash Disk 64M-C
o Zoran Digital Camera EX-20 DSC
and maybe a few others...
Submitted by: Vaidas Damosevicius and flz
PR: 79893
Reviewed by: njl, flz
Approved by: re (blanket)
(1) Add size parameter to usbd_get_string()
(2) Properly limit speed when a full speed hub is plugged into a high
speed hub.
Submitted by: Hans Petter Selasky
PR: 80773, 79725
Approved by: re@ (kensmith)
yet supported by this driver. Support will be committed soon, or a
filter on all the 'newer' devices will be installed before the
release.
Approved by: re@ (blanket)
Obtained from: NetBSD, OpenBSD
Small Furry Animals by: Pink Floyd
the command. Make UFI devices return 'success' when asked to do a
SYNC_CACHE. There's no support for write caching in the UFI spec, so
this is the most appropriate action to undertake.
Reviewed by: scottl
Approved by: re@ (blanket)
Hellmuth with some refinements by myself and flz@. It works for me
with my non-MS mice, so nothing should be broken by it.
Submitted by: Hellmuth Michaelis
PR: 90162
Approved by: re (blanket)
pr, the submitter says:
Found this while running freebsd as guest in qemu with -usb
parameter. The patch implements the missing dynamic size based on
number of ports a hub has.
Submitted by: Lonnie Mendez
PR: 94946
Approved by: re@ (blanket)
