Ask for the descriptor size corresponding to the number of ports present
in the hub, not from some random value from the stack.

Correctly recognize Super Speed devices, this is part of the work to
be able to use USB 3.0 devices behind an external hub.

This is a bit tricky because the SS status use a different power bit
that

Correctly recognize Super Speed devices, this is part of the work to
be able to use USB 3.0 devices behind an external hub.

This is a bit tricky because the SS status use a different power bit
that maps to the Low speed one. So no longer accept devices without
power bit and fallback to the parent hub's speed in case the status
does not report any particular speed.

Note that xhci(4) root hubs still set the traditionnal UPS_PORT_POWER
bit with the correct device speed.

show more ...

Handle super speed hub descriptors.

Do not store the whole USB hub descriptor in the "struct usbd_hub"
to help integrating super speed hubs that use a different descriptor.

add a size argument to free. will be used soon, but for now default to 0.
after discussions with beck deraadt kettenis.

autoconf(9) is your friend and it knows you more than you think. It
even knows your children! So let him handle the seperation correctly.

Do not rewrite your own custom config_detach_children(9) a

autoconf(9) is your friend and it knows you more than you think. It
even knows your children! So let him handle the seperation correctly.

Do not rewrite your own custom config_detach_children(9) and as a bonus
start removing the usbd_port tentacles from the stack.

ok pirofti@, yuo@, miod@, deraadt@

show more ...

Apart from the early exploration done to find a console keyboard during
the boot process, USB devices must be attached or detached from the usb
task thread in order to avoid races with periodical exp

Apart from the early exploration done to find a console keyboard during
the boot process, USB devices must be attached or detached from the usb
task thread in order to avoid races with periodical explorations issued
by uhub(4) interrupts.

Respect this rule when detaching root hubs during a suspend/resume cycle
and avoid some hangs due to the aforementioned race.

Tested by Mattieu Baptiste, thanks!

show more ...

Kill dead links.

Recognize super speed devices, note that this driver sill uses
non-superspeed hub descriptors. This is the minimal change I
came with to be able to properly attach and use USB 3.0 devices
attached t

Recognize super speed devices, note that this driver sill uses
non-superspeed hub descriptors. This is the minimal change I
came with to be able to properly attach and use USB 3.0 devices
attached to a xHCI root hub, uhub(4) clearly needs some love.

show more ...

Indtroduce usbd_get_hub_descriptor() to start cleaning uhub(4)'s mess.
This will help us deal with the different hub device descriptors used
by super speed devices.

Make uhub_explore() return an int rather than a usbd_satus. This has
no direct impact since its return value is never checked but it allows
me to get rid of one (usless) status value.

Note that usb

Make uhub_explore() return an int rather than a usbd_satus. This has
no direct impact since its return value is never checked but it allows
me to get rid of one (usless) status value.

Note that usbd_status should be used for USB transfers.

show more ...

Simplify the debug output to help diagnose problems without needing
special glasses.

No object change if UHUB_DEBUG is not defined.

Get rid of various 'typedef struct' definitions and use plain structure
definitions instead. We don't change usb.h for now to stay compatible
with userland.

Tested by mpi@ on macppc and myself on i

Get rid of various 'typedef struct' definitions and use plain structure
definitions instead. We don't change usb.h for now to stay compatible
with userland.

Tested by mpi@ on macppc and myself on i386.

ok mpi@

show more ...

proc.h is way too much header for usb to handle.

Avoid a potential NULL dereference if nports == 0.
Found by Amit Kulkarni using clang.
Fix from jakemsr; his diff was sitting on tech@ since February.
ok myself, phessler, sthen, jasper
and also piro

Avoid a potential NULL dereference if nports == 0.
Found by Amit Kulkarni using clang.
Fix from jakemsr; his diff was sitting on tech@ since February.
ok myself, phessler, sthen, jasper
and also pirofti, mikeb, krw (back in February)

show more ...

Remove config_activate() and DVACT_ACTIVATE. PCMCIA's the only thing
that's ever used it, and it's long since been changed to use
DVACT_{QUIESCE,SUSPEND,RESUME} instead.

ok deraadt@, dlg@; miod@ al

Remove config_activate() and DVACT_ACTIVATE. PCMCIA's the only thing
that's ever used it, and it's long since been changed to use
DVACT_{QUIESCE,SUSPEND,RESUME} instead.

ok deraadt@, dlg@; miod@ also agreed with this idea when I brought it
up a few weeks ago

show more ...

garbage collect "usb events". without /dev/usb there is no way to access
them from userland, and nothing in the kernel uses them.

ok krw@, miod@

* replace per-driver dying and/or other state variables with use of
usbd_deactivete() and usbd_is_dying()
* use usbd_deactivate() in activate()/DEACTIVATE
* convert a few more direct checks of the

* replace per-driver dying and/or other state variables with use of
usbd_deactivete() and usbd_is_dying()
* use usbd_deactivate() in activate()/DEACTIVATE
* convert a few more direct checks of the associated bus' dying flag
with usbd_is_dying()

show more ...

add a 'dying' flag to struct usbd_bus. use this to signify the bus
is dying, instead of setting a flag in struct usb_softc. as
usbd_device_handle has a pointer to the usbd_bus it's attached to,
usb

add a 'dying' flag to struct usbd_bus. use this to signify the bus
is dying, instead of setting a flag in struct usb_softc. as
usbd_device_handle has a pointer to the usbd_bus it's attached to,
usb devices, and functions they run or functions run on their behalf,
can now easily check if their bus is dying. use this to stop
usbd_do_request* from running and the usb task thread from adding
new tasks when a device's bus is dying.

show more ...

instead of running usb_explore() from individual kthreads for each
USB bus, make usb_explore() a usb_task. reduces races during normal
USB device detach, since now usb_tasks and detach happen in the

instead of running usb_explore() from individual kthreads for each
USB bus, make usb_explore() a usb_task. reduces races during normal
USB device detach, since now usb_tasks and detach happen in the same
process.
ok yuo@, matthew@ helped with the task thread loop

show more ...

The size of sc_status[] (the buffer for USB hub's interrupt pipe) will be
determined by bNbrPorts in hub descriptor.

USB hub sends status packet to host, it contains status bits for each port
and hu

The size of sc_status[] (the buffer for USB hub's interrupt pipe) will be
determined by bNbrPorts in hub descriptor.

USB hub sends status packet to host, it contains status bits for each port
and hub itself. So, the packet size is ceil((port + 1) / 8) bytes.

If host requests smaller than that size, the hub behavior is undefined.
Some hub (Intel's RMH for example) sends whole status every time,
it makes babble of USB. This is the reason that uhub_intr() of old code
was suffered from USBD_IOERROR,

Okay deraadt@ and yuo@.

show more ...

do not need to pad up the uhub allocation anymore, from miod

Avoid using the trick of malloc'ing more than a struct to grow the array
of the last element. Bad technique. Use a pointer to the array. The
author (or later people) will often not pay attention t

Avoid using the trick of malloc'ing more than a struct to grow the array
of the last element. Bad technique. Use a pointer to the array. The
author (or later people) will often not pay attention to the consequences
of structure padding & alignment issues when they add new fields to the
base structure, and there will be fireworks.
tested by jasper, too

show more ...

Get rid of devact enum, substitute it with an int and coresponding defines.

This is needed for the addition of further suspend/resume actions.

Okay deraadt@, marco@.

First pass at removing clauses 3 and 4 from NetBSD licenses.

Not sure what's more surprising: how long it took for NetBSD to
catch up to the rest of the BSDs (including UCB), or the amount of
code t

First pass at removing clauses 3 and 4 from NetBSD licenses.

Not sure what's more surprising: how long it took for NetBSD to
catch up to the rest of the BSDs (including UCB), or the amount of
code that NetBSD has claimed for itself without attributing to the
actual authors.

OK deraadt@

show more ...