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...
children will not detach, the instance is not left in an inconsistent
state.
If uhub(4) port is disconnected, forcefully detach the children on
that port.
Simplify detachment hooks. (sc_dying must die!)
Pass along and respect detachment flags, esp. DETACH_FORCE,
throughout.
- Addresses the issue described in PR/38828.
- Some simplification in threading and sleepq subsystems.
- Eliminates pmap_collect() and, as a side note, allows pmap optimisations.
- Eliminates XS_CTL_DATA_ONSTACK in scsipi code.
- Avoids few scans on LWP list and thus potentially long holds of proc_lock.
- Cuts ~1.5k lines of code. Reduces amd64 kernel size by ~4k.
- Removes __SWAP_BROKEN cases.
Tested on x86, mips, acorn32 (thanks <mpumford>) and partly tested on
acorn26 (thanks to <bjh21>).
Discussed on <tech-kern>, reviewed by <ad>.
XXX: Adapter seems to be generally functional, but at least on -nb5
WPA didn't work very well (managed to get authenticated and sometimes
an address via dhcp, but that's it). I can't currently test non-wpa
networks, so don't know if it's an issue only with wpa or with the
connectivity in general.
1. expand the USB_ATTACH_SETUP macro (requested by jmcneill)
2. reorder the attach function so that the first thing it does is print
newlines.
3. after this, we can call usbd_devinfo_alloc(), which polls the device
allowing a context switch, and aprint_normal() the device information.
this avoids problems where autoconf messages are getting mixed up.
you repeatedly enable/disable a ubt device it sometimes hangs in
the bluetooth initialisation where the device responses never arrive,
but if you interrupt and try again it works fine.
additionally aborting the default pipe on shutdown seems to fix that
descriptor. I have a USB ATA device that spins up it's (removable) hard
disk and only returns the real descriptor if the disk is present - this
takes too long with the default 5 seconds timeout, so we were unable to
properly attach this device.
block - we know the device will be able to handle it already.
This fixes a strange failure mode when attaching a (apparently non standard
conformant) USB ATA device I have, and *should* not cause any harm.
Apparently the device in question answered with the full descriptor despite
our short request - a failure mode not handled gracefully, leading to a
port reset. From Jeremy Morse.
Print Screen/Sys Req keys so xf86-input-keyboard can figure out
what we want.
Additionally, fix dead URL, and add a note that this emulation
is not completely identical to a real pckbd.
Ott: every ioctl but SIOCSIFFLAGS fails with ENXIO (Device not
configured). Let ioctls complete even if initialization is not
complete (!sc->attached). Do exit immediately from zyd_newstate
with ENXIO if !sc->attached, however: zyd_newstate tries to call
some USB routines for which it is probably not ready.
channels.
- tested on 232BM, 232RL and 2232D chips.
- now capable of quad channel FT4232H.
- minor format nit and legacy title comment removal.
- non UART type bit stream (!= ucom) support is under planning.
our uhci_poll_hub callout might strike. The detaching of the uhub has left
the device member in the pipe NULL, so make sure we do not dereference it.
We could halt the callout before detaching child devices, but it this
would likely interfere with proper servicing the child devices while
they are still around.
