device having the same name like a previous one is not created before the old
one is gone. This fixes some panics due to asserts in the devfs code which
were added recently.
Approved by: re (kib)
MFC after: 1 week
ID. This fixes USB_SET_IMMED call (synchronous operation) of the uhid(4)
driver on devices with single report ID.
Reviewed by: hselasky
Approved by: re (kib)
MFC after: 1 week
coordinates, such as digitizers and touch-screens, leaving these devices
to uhid(4) and user-level. Specially patched xf86-input-mouse driver can
handle them, that isn't done and can't be done properly with ums(4)
because of mouse(4) protocol limitations.
Approved by: re (kib)
Back in 2009 I changed the ABI of the GIO_KEYMAP and PIO_KEYMAP ioctls
to support wide characters. I created a patch to add ABI compatibility
for the old calls, but I didn't get any feedback to that.
It seems now people are upgrading from 8 to 9 they experience this
issue, so add it anyway.
supports IPv4/IPv6 checksum offloading and VLAN tag insertion/
stripping as well as WOL. Because uether does not provide a way
to announce driver specific offload capabilities to upper stack,
checksum offloading support needs more work and will be done in
future.
Special thanks to ASIX for donating sample hardware.
H/W donated by: ASIX Electronics
Reviewed by: hselasky
system timer is stopped during shutdown and that the pause() statement in ukbd
causes infinite hang in this regard. The fix is to use mi_switch() instead of
pause() to do the required task switch to ensure that the required USB processes
get executed.
Reported by: Mike_Karels@mcafee.com
MFC after: 1 week
setting (either default or if supported as set by SIOCSIFFIB, e.g.
from ifconfig).
Submitted by: Alexander V. Chernikov (melifaro ipfw.ru)
Reviewed by: julian
MFC after: 2 weeks
latter.
It appears that the addition to uath(4) came in through PR kern/135009,
which had tested another device, the SMCWUSBTG2, successfully with uath(4)
and included the SMCWUSBG as it "has the same chipset". I can find no
other evidence that these two do actually share the same chipset. Moreover,
Linux treats the SMCWUSBG as a zyd(4) device also.
This reverts r223537.
Discussed with: hselasky, kevlo
MFC after: 1 week
dynamically loaded device drivers get a chance to run their event hooks.
- Decouple the USB suspend and resume lock from witness. It produces some
false warnings due to reusing the lock name among multiple devices.
MFC after: 3 days
is now required by bus_autoconf.
- Allow interface class matching even if device class is vendor specific.
- Update bus_autoconf tool to not generate system and subsystem match lines
for the nomatch event.
PR: misc/157903
MFC after: 14 days
sorted according to the mode which they support:
host, device or dual mode
- Add generic tool to extract these data:
tools/bus_autoconf
Discussed with: imp
Suggested by: Robert Millan <rmh@debian.org>
PR: misc/157903
MFC after: 14 days
High-speed USB HUB by resetting the transaction translator (TT)
before trying re-enumeration. Also when clear-stall fails multiple times
try a re-enumeration.
Suggested by: Trevor Blackwell
MFC after: 14 days
This brings USB bus more in line with how newbus is supposed to be used.
Also, because of the two-pass probing the following message was produced
by devd in default configuration when almost any USB device was
connected:
Unknown USB device: vendor <> product <> bus <>
This should be fixed now.
Note that many USB device drivers pass some information from probe
method to attach method via ivars. For this to continue working we rely
on the fact that the subr_bus code calls probe method of a winning driver
again before calling its attach method in the case where multiple
drivers claim to support a device. This is done because device
description is set in successful probe methods and we want to get a correct
device description from a winning driver. So now this logic is re-used
for setting ivars too.
Reviewed by: hselasky
MFC after: 1 month
(reporting IFM_LOOP based on BMCR_LOOP is left in place though as
it might provide useful for debugging). For most mii(4) drivers it
was unclear whether the PHYs driven by them actually support
loopback or not. Moreover, typically loopback mode also needs to
be activated on the MAC, which none of the Ethernet drivers using
mii(4) implements. Given that loopback media has no real use (and
obviously hardly had a chance to actually work) besides for driver
development (which just loopback mode should be sufficient for
though, i.e one doesn't necessary need support for loopback media)
support for it is just dropped as both NetBSD and OpenBSD already
did quite some time ago.
- Let mii_phy_add_media() also announce the support of IFM_NONE.
- Restructure the PHY entry points to use a structure of entry points
instead of discrete function pointers, and extend this to include
a "reset" entry point. Make sure any PHY-specific reset routine is
always used, and provide one for lxtphy(4) which disables MII
interrupts (as is done for a few other PHYs we have drivers for).
This includes changing NIC drivers which previously just called the
generic mii_phy_reset() to now actually call the PHY-specific reset
routine, which might be crucial in some cases. While at it, the
redundant checks in these NIC drivers for mii->mii_instance not being
zero before calling the reset routines were removed because as soon
as one PHY driver attaches mii->mii_instance is incremented and we
hardly can end up in their media change callbacks etc if no PHY driver
has attached as mii_attach() would have failed in that case and not
attach a miibus(4) instance.
Consequently, NIC drivers now no longer should call mii_phy_reset()
directly, so it was removed from EXPORT_SYMS.
- Add a mii_phy_dev_attach() as a companion helper to mii_phy_dev_probe().
The purpose of that function is to perform the common steps to attach
a PHY driver instance and to hook it up to the miibus(4) instance and to
optionally also handle the probing, addition and initialization of the
supported media. So all a PHY driver without any special requirements
has to do in its bus attach method is to call mii_phy_dev_attach()
along with PHY-specific MIIF_* flags, a pointer to its PHY functions
and the add_media set to one. All PHY drivers were updated to take
advantage of mii_phy_dev_attach() as appropriate. Along with these
changes the capability mask was added to the mii_softc structure so
PHY drivers taking advantage of mii_phy_dev_attach() but still
handling media on their own do not need to fiddle with the MII attach
arguments anyway.
- Keep track of the PHY offset in the mii_softc structure. This is done
for compatibility with NetBSD/OpenBSD.
- Keep track of the PHY's OUI, model and revision in the mii_softc
structure. Several PHY drivers require this information also after
attaching and previously had to wrap their own softc around mii_softc.
NetBSD/OpenBSD also keep track of the model and revision on their
mii_softc structure. All PHY drivers were updated to take advantage
as appropriate.
- Convert the mebers of the MII data structure to unsigned where
appropriate. This is partly inspired by NetBSD/OpenBSD.
- According to IEEE 802.3-2002 the bits actually have to be reversed
when mapping an OUI to the MII ID registers. All PHY drivers and
miidevs where changed as necessary. Actually this now again allows to
largely share miidevs with NetBSD, which fixed this problem already
9 years ago. Consequently miidevs was synced as far as possible.
- Add MIIF_NOMANPAUSE and mii_phy_flowstatus() calls to drivers that
weren't explicitly converted to support flow control before. It's
unclear whether flow control actually works with these but typically
it should and their net behavior should be more correct with these
changes in place than without if the MAC driver sets MIIF_DOPAUSE.
Obtained from: NetBSD (partially)
Reviewed by: yongari (earlier version), silence on arch@ and net@
will generate a short terminated USB transfer if
the maximum NCM frame size is greater than what
the driver can handle.
Reported by: Matthias Benesch
MFC after: 7 days
Approved by: thompsa (mentor)
bus driver at detach, hence ehci_detach() does exactly this since r199718.
Submitted by: Luiz Otavio O Souza
MFC after: 7 days
Approved by: thompsa (mentor)
SCSI status errors to CAM (that was wrong, as it too often turned retriable
wire errors into non-retriable REQUEST SENSE errors), do it only for STALL
errors on control pipe of the CBI devices. STALL on control pipe is just
a one of the ways to report error for CBI devices.
PR: usb/150401, usb/154593.
Reviewed by: hselasky
MFC after: 1 week
- Add more fields for USB device and host mode
- Add more information to USB PF header so that decoding
can easily be done by software analyzer tools like
Wireshark.
- Optimise usbdump to display USB streams in text format
more efficiently.
- Software using USB PF must be recompiled after
this commit, due to structure changes.
MFC after: 7 days
Approved by: thompsa (mentor)
report descriptor information, sysctl utility
will show it for us.
- Modify sysctl node description to make it more
understanable.
Found by: Alexander Best <arundel@freebsd.org>
Submitted by: Eygene Ryabinkin <rea@freebsd.org>
MFC after: 14 days
Approved by: thompsa (mentor)
value is updated after that we read it in the queue-head. This patch can
fix problems with BULK timeouts. The issue was found on a Nvidia chipset.
MFC after: 14 days
Approved by: thompsa (mentor)
means of allowing vendor specific interface class for audio and MIDI devices.
- Add new quirks for this. The vendor and product list in OpenBSD's
dev/usb/umidi_quirks.c was used as reference.
MFC after: 14 days
Approved by: thompsa (mentor)
While updating Tx stats, already freed node could be referred and cause
page fault. To avoid such panic, spool Tx stats in driver's softc. Then,
on every ratectl interval, grab node though ieee80211_iterate_nodes() and
update ratectl stats.
* Simplify some code in run_iter_func().
* Fix typo
* Use memset instead of bzero (hselasky @)
PR: kern/153938
Submitted by: PseudoCylon <moonlightakkiy@yahoo.ca>
Approved by: thompsa (mentor)
Drivers which rely on net80211 to create the beacon need to call
ieee80211_beacon_update() on iv_update_beacon() calls. This is required
that certain bits, e.g. TIM, get updated. A call to ieee80211_beacon_alloc()
is not enough because it does not care about flags which can only change
during runtime. By design a beacon is supposed to be allocated only once
while moving into RUN state.
To handle all possible calls to iv_update_beacon() the run_updateslot()
function has been revived and run_updateprot() has been added.
run_updateslot() handles slot time changes and run_updateprot() changes
to protection, both can change while nodes associate/leave.
Submitted by: Alexander Zagrebin <alex at zagrebin.ru>,
PseudoCylon <moonlightakkiy atyahoo.ca>
MFC after: 3 weeks
- use device_printf() instead of printf() to give more accurate warnings.
- use memcpy() instead of bcopy().
- add missing #if's for non-FreeBSD compilation.
Approved by: thompsa (mentor)
error address on a decoding error to unlatch it and to allow
us to print a better diagnostics message. This also has the
side effect of clearing the condition, which prevents an
interrupt storm.
This fixes hostap mode for at least ral(4) and run(4), because there is
no sufficient call into drivers which could be used initialize the node
related ratectl variables.
MFC after: 3 days
all new devices added between our r211022 and their git revision
93ad03d60b5b18897030038234aa2ebae8234748
Also correct a Foxconn entry.
MFC after: 1 week
AX88772 controllers. ASIX added a new feature for AX88178/AX88772
controllers which allows combining multiple TX frames into a single
big frame. This was to overcome one of USB limitation where it
can't generate more than 8k interrupts/sec which in turn means USB
ethernet controllers can not send more than 8k packets per second.
Using ASIX's feature greatly enhanced TX performance(more than 3~4
times) compared to 7.x driver. However it seems r184610 removed
boundary checking for buffered frames which in turn caused
instability issues under certain conditions. In addition, using
ASIX's feature triggered another issue which made USB controller
hang under certain conditions. Restarting ethernet controller
didn't help under this hang condition and unplugging and replugging
the controller was the only solution. I believe there is a silicon
bug in TX frame combining feature on AX88178/AX88772 controllers.
To address these issues, reintroduce the boundary checking for both
AX88178 and AX88772 after copying a frame to USB buffer and do not
use ASIX's multiple frame combining feature. Instead, use USB
controller's multi-frame transmit capability to enhance TX
performance as suggested by Hans[1].
This should fix a long standing axe(4) instability issues reported
on AX88772 and AX88178 controllers. While I'm here remove
unnecessary TX frame length check since upper stack always
guarantee the size of a frame to be less than MCLBYTES.
Special thanks to Derrick Brashear who tried numerous patches
during last 4 months and waited real fix with patience. Without
this enthusiastic support, patience and H/W donation I couldn't fix
it since I was not able to trigger the issue on my box.
Suggested by: hselasky [1]
Tested by: Derrick Brashear (shadow <> gmail dot com>
H/W donated by: Derrick Brashear (shadow <> gmail dot com>
PR: usb/140883
isn't configurable in a meaningful way. This is for ifconfig(8) or
other tools not to change code whenever IFT_USB-like interfaces are
registered at the interface list.
Reviewed by: brooks
No objections: gavin, jkim
or detached. Normally it should be changed through user land ioctl(2)
system calls but it looks there's no apps for USB and no need.
With this patch, libpcap would detect the usbus interfaces correctly and
tcpdump(1) could dump the USB packets into PCAP format with -w option.
However it couldn't print the output to console because there's no
printer-routine at tcpdump(1).
hence existing applications like webcamd are expecting that.
This problem was introduced by SVN change 214221 where cdev=
was replaced by ugen= by accident. Solve this problem by
redefining cdev= in devd notifications.
MFC after 3 days.
Approved by: thompsa (mentor)
(wrong unit number for a host controller) when the module is load /
unloaded repeatly. Attaching the USB pf is moved to usbus device's
attach.
Pointed by: yongari
Shorten the descriptive strings for Huawei devices. The vendor or
operator name should not be included in the device name.
Submitted by: Emile Coetzee
MFC after: 3 days
packets which go through each USB host controllers. Its implementations
are almost based on BPF code and very similar with it except it's
little bit customized for USB packet only. The userland program
usbdump(8) would be committed soon.
Discussed with: hps, thompsa, yongari
K3765 datacard. After ejecting this device, it reappears using
the normal K3765 ID. It does not switch automatically
Reviewed by: n_hibma
Obtained from: OpenBSD
MFC after: 2 weeks
and updated comments in the usb_quirk.h header file.
The main purpose of this is to expose the quirks for ejecting 3G
modules. usb_modeswitch in Linux does a great job of collecting
information on these, and with the quirks module people can try out the
modeswitch config file entries on FreeBSD, hence the SCSI strings in the
man page.
MFC after: 2 weeks
the IEEE80211_C_RATECTL flag set, default to NONE for all drivers. Only if
a driver calls ieee80211_ratectl_init() check if the NONE algo is still
selected and try to use AMRR in that case. Drivers are still free to use
any other algo by calling ieee80211_ratectl_set() prior to the
ieee80211_ratectl_init() call.
After this change it is now safe to assume that a ratectl algo is always
available and selected, which renders the IEEE80211_C_RATECTL flag pretty
much useless. Therefore revert r211314 and 211546.
Reviewed by: rpaulo
MFC after: 2 weeks
based devices (QUALCOMMINC 0x2000). He made it use SCSI eject instead of
ZTE STOR eject. This prevented my ZTE MF626 dongle from switching.
- Apply both eject methods for ZTE STOR based devices. Works on my as
well as mav's device.
- Remove the duplicate.
- Sort the usbdevs entries for Qualcomm so this won't happen again.
- Add bootverbose message displaying the fact that we are ejecting (and
how).
Reviewed by: mav
MFC after: 2 weeks
information through devd. My E220 now produces the notification (1 line):
+u3g0 at bus=1 hubaddr=1 port=0 devaddr=2 interface=0 \
vendor=0x12d1 product=0x1003 devclass=0x00 devsubclass=0x00 \
sernum="" release=0x0000 intclass=0xff intsubclass=0xff \
ttyname=U0 ttyports=2 on uhub0
Note: serial/ufoma and net/uhso still provide port number and tty name
(uhso only) information through sysctls, which should now be removed.
Reviewed by: hpselasky
- Fix the loop count on detach (causing a panic on detaching a serial
dongle).
- Increase a buffer in case some driver want extra long tty device names
(postfixing the purpose of the tty for example, e.g. u3g.ppp).
notification. devd would stop evaluating at 'at' (not '<k>=<v>') and
hence prevent 'port=X' (and 'bus=<"on" string>) from making it into the
environment for the devd action.
Reviewed by: hselasky
MFC after: 2 weeks
- hw.usb.ucom.cons_unit is now split into
hw.usb.ucom.cons_unit/...cons_subunit.
Note: The tunable/sysctl hw.usb.ucom.cons_unit needs to be reviewed if
a) a console was defined a USB serial devices, and a USB device with
more than 1 subunit is present, and this device is attached before the
device functioning as a console
or
b) a console was defined on a USB device with more than 1 subunit
Reviewed by: hps
MFC after: 2 weeks
within the first 4 bytes of the EHCI memory space. For controllers that
use big-endian MMIO, reading them with 1- and 2-byte reads would then
return the wrong values. Instead, read the combined register with a 4-byte
read and mask out the interesting quantities.
important for USB 2.0 devices and some of them reported to have problems
with large transactions. But USB 3.0 benchmarks show that limited number
of transactions per second on USB makes impossible to reach high transfer
speeds without using bigger transactions.
On my tests this change allows to read up to 220MB/s from USB-attached SSD
(at block size of 256-512KB), comparing to only 113MB/s without it.
Reviewed by: hselasky
proper solution which is to not use the TERMINATE pointer, but rather
link to a halted TD. The initial fix was due to a misunderstanding
about how the EHCI hardware works. Thanks to Alan Stern for clearing
this up. This patch can increase mass storage read performance
significantly when the IRQ rate is less than 8000 IRQ/s.
Approved by: thompsa (mentor)
