[SPAM]: Re: [SPAM]: Re: [SPAM]: How to Trigger a USB Host Reset of Device?
On Mon, Jun 4, 2018 at 1:37 AM, firstname.lastname@example.org wrote:
>> On Jun 3, 2018, at 10:44 PM, email@example.com wrote:
>>> On Mon, Jun 4, 2018 at 12:25 AM, firstname.lastname@example.org
>>> 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.
<...excess quoted lines suppressed...>
Yes, but which IOCTL exposes this? Which userspace IOCTL? This in
addition to the fact that not all hubs actually seem to support it
(taken from Linux user's experience with hardware). Historically such
bad decisions have been made due to the presence or lack of a feature
in Windows, regardless of what the actual specification says.
>> 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
> Well, that's your opinion. Device manipulation in Windows has always been
> a kernel-mode. However, as it turns out, IOCTL_USB_HUB_CYCLE_PORT is a
> user-mode request. You just have to find the hub and figure out the port
It might be my opinion but I have given strong evidence as to why it
would also be the opinion of the specification. The Windows
documentation and yourself provide no rationale at all.
>> 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.
> Yes. It's there. I'm not sure why you think this is not available.
1) Because the previous OSR discussion on this seems to paint the
device reset functionality as abnormal.
2) No IOCTL actually refers to the USB reset condition by name, while
many refer to resetting internal structures.
3) The IOCTL that may do what I want was previously deprecated with no
>> 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.
> I suspect it's just the level of abstraction. BTW, here's a thread from 4
> years ago about this topic.
Yes, though the direction that conversation went was mistaken and in
direct contradiction of the USB DFU specification. Host initiated
device resets are possible and normal.
>>> 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:
> You're just inventing things to fit your scenario.
> IOCTL_INTERNAL_USB_RESET_PORT, like IOCTL_USB_HUB_RESET_PORT, is a software
> thing. IOCTL_INTERNAL_USB_CYCLE_PORT, like IOCTL_USB_HUB_CYCLE_PORT, sends
If that's what I gleaned from the documentation I wouldn't calling it
inventing, but sure, I could have misunderstood it.
> 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
> No, the xxx_RESET_PORT ioctl does not send a reset. It is a software
> operation that clears out and re-establishes the data structures in the
> driver stack..
Ok, thank you for the clarification.