IEEE 802.11b/g WLAN device, ported from OpenBSD by FUKAUMI Naoki:
http://mail-index.NetBSD.org/current-users/2010/05/28/msg013570.html
Slightly modified by me to use recently added config_mountroot(9)
to defer some device initialization until mountroot for firmload(9).
Tested on Sharp W-ZERO3 WS003SH with internal WLAN.
Note currently we cannot redistribute firmware files for upgt(4) so
they have to be downloaded and copied into /libdata/firmware/upgt manually.
See upgt(4) man page about firmware details.
phone cables and in cheap stand alone usb<->serial devices. From OpenBSD.
The hardware is crap, avoid it if possible. There is no documentation and
even the vendor supllied win32 driver gets it wrong.
This driver mostly works, but you can't send a break.
by defining 'options USBVERBOSE' in the kernel config file (no change
from current behavior), or it can be loaded at boot time on those
architectures that support the boot loader's "load" command.
The module is built for all architectures, whether or not USB support
exists.
that only come as a umass device in the default configuration and
forces them to reinitialize in 3D mode and detach.
The u3g part attaches to individual interfaces for the 3G functionality,
leaving the umass interface(s) for that driver.
With this change I can use the MMC card in my Huawey stick (as well as
the integrated windows driver CD, which of course is pretty useless) and
the 3G modem at the same time.
Fixes PR 42577.
Code contributed anonymously, minor tweaks (and all bugs) by me.
Ported by FUKAUMI Naoki from OpenBSD with many modification.
No particular comments (except from me) on tech-kern@.
There are still many TODO even in MI wscons(4) API to handle this device:
* No detach function for wsdisplay(9).
Unpluging a device causes a panic. (should be trivial?)
* ioctl() for X server support is currently commented out. ("notyet")
OpenBSD allows device depedent ioctl()s and they introduced
UDLIO_DAMAGE ioctl for the damage extension ops of X servers for udl(4).
Before blindly pulling such ioctl(), probably we should discuss
how such specific operations should be handled in MI wscons(4) API.
* Screen text of wsemul tty could be mangled during large scroll ops.
All tty output operations are invoked via ttstart() with the giant
tty_lock mutex held, so we can't call cv_wait(9) to wait resources
for data xfers via usbdi(9).h, then text output is silently discarded
on resource shortage. To handle this without tty_lock reorganization,
we have to change wsdisplay(9) APIs (especially wsdisplaystart()) to
return a number of actually handled characters as OpenBSD does, but
it may require whole API changes around child rasops(9) etc.
* No MI API definition to convert mmap(9) cookie to physical address.
The conversion is required to create a cookie which will be passed to
pmap_phys_address(9) in uvm/uvm_device.c:udv_fault(). Most other
drivers use bus_dmamem_mmap(9) or bus_space_mmap(9), but udl(4) uses
kmem_alloc(9)'ed memory for bitmap data.
Furthermore, pmap(9) man page says about pmap_phys_address(9):
"This function is provided to accommodate systems which have
physical address spaces larger than can be directly addressed
by the platform's paddr_t type. The existence of this function is
highly dubious, and it is expected that this function will be
removed from the pmap API in a future release of NetBSD."
As the man page says we have already had split paddr_t and vaddr_t,
so it's time to remove such old ugly cookie and change all mmap(4)
functions (mostly in MD bus_dma(9) and bus_space(9) APIs) to return
simple physical address in paddr_t?
* We need proper device names for wsdisplay1 (and more devices).
Currently wsdisplay0 uses ttyE0 through ttyE253 (minor 0 to 253)
for screens, ttyEstat (254) for status, and ttyEcfg (255) for config.
The next wsdisplay1 will use 256 through 509 for screens, 510 for stat,
and 511 for config but what names should we use for them? ttyFxxx?
* How to handle multiple sets of wskbd/wsdisplay on a single machine.
rc.d/wscons doesn't provide method to specify wscons control devices.
There is no proper interface to specify which keyboard should be connected
to which wsdisplay, etc.
* And maybe more...
the configuration. The match/attach code was assuming whole-device
attach args all the time.
-Use the first (ie index 0) configuration for ubsa -- it makes the
code work in at least one case (PR kern/39211 by Frank Wille), and
there is no indication that an alternative configuration would
be needed. (I've admittedly never seen a usb device with more than
one configuration.)
This fixes mistakes when uhmodem support was added, and the changes were
not tested with a Huawei device yet. So please test if you can.
than a zero-terminated list; this makes the code simpler and also
hopefully fixes the recent "childdet" botch, see PR kern/38528
-handle the root hub specially a bit earlier, this allows to kick out
the "submatch" functions completely which needed to second-guess
from the port number (where "0" meant root hub")
(we could handle the root hub specially even earlier, but as done
now big parts of the hub emulation code are exercised regularely,
this would bitrot otherwise)
PR/37692 from Yojiro UO
---
uhmodem: device driver for huawei 3G wireless modem
* what it is?
A device driver for huawei 3G wireless modem, E220 and its valiations.
The devices are very simuler to ubsa device, but they need special care
to use as modem device.
This patch introduce "uhmodem (USB Huawei modem)" for the devices.
A uhmodem device has two com devices and one USB mass strage device.
The driver enable to use all of them.
* dmesg:
uhmodem0 at uhub0 port 1 configuration 1 interface 0
uhmodem0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
uhmodem0: mass storage only mode, reattach to enable modem
uhmodem0: at uhub0 port 1 (addr 2) disconnected
uhmodem0 detached
uhmodem0 at uhub0 port 1 configuration 1 interface 0
uhmodem0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
ucom0 at uhmodem0 portno 0: modem
ucom1 at uhmodem0 portno 1: monitor
umass0 at uhub0 port 1 configuration 1 interface 2
umass0: HUAWEI Technologies HUAWEI Mobile, rev 1.10/0.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
cd0 at scsibus0 target 0 lun 0: <HUAWEI, Mass Storage, 2.31> cdrom removable
matching (and handling) a whole device and those which match an
interface only. This will allow to enforce some rules, eg that
the former don't use interface information for matching or that the
latter don't modify global device state.
The previous way left too much freedom do the drivers which led to
inconsistencies and abuse.
For now, I've not changed locators and submatch rules, this will
happen later.
There should not be any change in behaviour, except in the case of
some drivers which did behave inconsistently:
if_atu, if_axe, uep: matched the configured device in the interface
stage, but did configuration again. I've converted them to match
in the device stage.
ustir, utoppy: matched in the interface stage, but only against
vendor/device information, and used any configuration/interface
without checking. Changed to match in device stage, and added
some simple code to configure and use the first interface.
If you have one of those devices, please test!
wsmouse device for now; easy enough to make it a joystick driver in the
future.
Mappings:
Left analog stick: Mouse movement
Right analog stick: Scroll wheel (4 directions)
A button: Left click
B button: Right click
X button: Middle click
Y button: injected to wsmouse as a fourth mouse button click
remove pseudo-device btdev(4) and inherent limitations
add bthub(4) which autoconfigures at bluetooth controllers as they
are enabled. bluetooth devices now attach here.
btdevctl(8) and its cache is updated to handle new semantics
etc/rc.d/btdevctl is updated to configure devices from a list
in /etc/bluetooth/btdevctl.conf
While it can be made to compile, the paradigm is not quite right because
it attempts to contact the filesystem during autoconfig which sometimes
causes a panic. Even if that was fixed, there is another potential problem
in that the driver tries/sleeps/tries/sleeps and the sleep could
theoretically sleep past the rc.d/btconfig stage and the controller
would remain unconfigured.
So, I have prepared a different method for loading the firmware to
Broadcom BCM2033 chip based devices. A package 'sysutils/bcmfw' will load
the firmware files via a ugen(4) device interface.
This update removes the ubtbcmfw(4) driver and adds a table to the ubt(4)
driver so that it will not attach to Broadcom BCM2033 based devices before
the firmware was loaded.
This fixes kern/34219
ahead and write behind, improving performance for the Universal
Software Radio Peripheral (USRP) used with GNU Radio.
Enable UGEN_BULK_RA_WB in GENERIC and GENERIC_LAPTOP; behavior is
unchanged unless the new ioctl is called.
This code was written by Joanne Mikkelson under funding from DARPA's
ACERT program.
ok'd by christos@, tested by Berndt Josef Wulf
NetBSD Foundation Membership still pending.) This stack was written by
Iain under sponsorship from Itronix Inc.
The stack includes support for rfcomm networking (networking via your
bluetooth enabled cell phone), hid devices (keyboards/mice), and headsets.
Drivers for both PCMCIA and USB bluetooth controllers are included.
of digital video recorders popular in Europe and Australia.
These devices have a USB client port which can be used to upload and
download recordings (and other files, such as MIPS binaries for execution
on the DVR's CPU) to/from their internal hard disk, in addition to some
other operations on files and directories.
Xenarc, Liliput, etc. small touchpanel LCD displays.
TODO:
- manpage
- calibration support (make hpc's tpcalib stuff more MI?)
- On i386 and other xfree-ish xservers, (currently-uncomitted) patches
are needed for X to honor wscons absolute mouse position events.
christos