On Mon, Jun 4, 2018 at 12:25 AM, email@example.com <firstname.lastname@example.org> wrote:
> On Jun 3, 2018, at 6:11 PM, email@example.com <firstname.lastname@example.org> wrote:
>> Per http://microchipdeveloper.com/usb:reset-suspend-resume
>> references the USB specification, a host can issue a device a reset
>> command by holding both D- and D+ low for 10ms.
> The HOST cannot do this. It has to come from a hub, since it is specific to a port. The hub is commanded by the host, but it happens farther away from the host than the host controller.
Well, yes, if you really want to make that distinction.
>> However per a past thread about USB DFU and device resets
) seems to imply
>> that Windows does not expose this functionality for some reason. Per
>> the documentation for IOCTL_USB_HUB_CYCLE_PORT it was unavailable in
>> some versions of Windows.
> Very old versions of Windows used IOCTL_USB_HUB_RESET_PORT as the "power cycle" signal. CYCLE has now been separated out, and RESET does a software-oriented reset.
I think there is a distinction to be made: as far as I can tell there
is no uniform way to cycle power to a USB device, though some hubs do
expose that functionality. The "reset" signal is sent by asserting an
unusual state for D- and D+.
It is necessary that I reset the port from userspace, or, if not that,
that I reset it based on user input and not based on some line state
that may occasionally happen. Writing a driver to do so seems
>> It is my understanding these versions of Windows are thus noncompliant
>> with the USB specification.
> That's just imaginative nonsense. The USB specification does not say what functionality the operating system has to expose. Besides, the power cycling ability is available in all versions.
Taking this to an extreme, all devices are USB compliant regardless of
whether or not they have USB ports.
My point is the USB standard proper and the DFU standard documents
both describe functionality that is not available for a reason which
is not justified. The standard clearly intends for "effectively
userspace" initiation of reset signals.
>> Further, it is not very clear to me if any
>> IOCTLs actually generate the condition described by the standard or a
>> condition that provokes reenumeration as is intended by the DFU
>> specification. There is no clear distinction about what is being reset
>> for some USB IOCTLs. Some do specifically mention they only reset
>> internal structures.
> Right. IOCTL_USB_HUB_RESET_PORT is an internal structure thing. IOCTL_USB_HUB_CYCLE_PORT sends a reset request to the hub. It is the hub that executes the actual disconnect sequence, not Windows, not the host controller.
I will do what I can to follow up with that IOCTL then. I am confused
as to why it is not implemented in WinUSB.
>> Can anyone provide some clarification? I have filed a documentation
>> bug at https://github.com/MicrosoftDocs/windows-driver-docs-ddi/issues/97
>> but this may be a more serious issue.
> In what way do you believe the documentation is flawed?
For example, IOCTL_INTERNAL_USB_RESET_PORT looks like it pulls low
both D- and D+ to achieve the reset signal. However, it adds:
"After a successful reset, the bus driver reselects the
configuration and any alternative interface settings that the device
had before the reset occurred. All pipe handles, configuration handles
and interface handles remain valid."
This to me seems like it sends a reset, but then selects *exactly the
same configuration as before* which would preclude this from doing
what is needed for a DFU device, where an alternate configuration is
Note that none of the IOCTLs (to my knowledge) reference explicitly a
USB device reset. They may all be talking about internal structures,
or something that does not propagate fully to the device.