Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category.

[SPAM]: Re: [SPAM]: Re: [SPAM]: How to Trigger a USB Host Reset of Device?

R0b0t1R0b0t1 Posts: 130
On Mon, Jun 4, 2018 at 12:25 AM, xxxxx@probo.com <xxxxx@lists.osr.com> wrote:
> On Jun 3, 2018, at 6:11 PM, xxxxx@gmail.com <xxxxx@lists.osr.com> wrote:
>>
>> Per http://microchipdeveloper.com/usb:reset-suspend-resume, which
>> 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
>> (https://www.osronline.com/showthread.cfm?link=252223) 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
overkill.

>> 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
selected.

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.

Cheers,
R0b0t1

Comments

  • Tim_RobertsTim_Roberts Posts: 12,616
    On Jun 3, 2018, at 10:44 PM, xxxxx@gmail.com wrote:
    >
    > On Mon, Jun 4, 2018 at 12:25 AM, xxxxx@probo.com wrote:
    >>
    >> 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+.

    Why do you say that? Section 11.24.2.2 of the USB 2 spec describes the CLEAR_FEATURE and SET_FEATURE hub requests with the PORT_POWER and the PORT_RESET bit. I'm pretty sure that's what the IOCTL_USB_HUB_CYCLE_PORT request sends.


    > 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
    > overkill.

    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 number.


    > 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.


    > 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.

    https://www.osronline.com/showthread.cfm?link=252223


    >> 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 the hub request to affect the hardware.



    > 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
    > selected.

    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..

    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • R0b0t1R0b0t1 Posts: 130
    On Mon, Jun 4, 2018 at 1:37 AM, xxxxx@probo.com <xxxxx@lists.osr.com> wrote:
    >> On Jun 3, 2018, at 10:44 PM, xxxxx@gmail.com <xxxxx@lists.osr.com> wrote:
    >>
    >>
    >>> On Mon, Jun 4, 2018 at 12:25 AM, xxxxx@probo.com <xxxxx@lists.osr.com> wrote:
    >>>
    >>>
    >>> 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+.
    >
    >
    > Why do you say that? Section 11.24.2.2 of the USB 2 spec describes the
    > CLEAR_FEATURE and SET_FEATURE hub requests with the PORT_POWER and the
    > PORT_RESET bit. I'm pretty sure that's what the IOCTL_USB_HUB_CYCLE_PORT
    > request sends.
    >
    >

    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
    >> overkill.
    >
    >
    > 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
    > number.
    >
    >

    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
    explanation.

    >> 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.
    >
    > https://www.osronline.com/showthread.cfm?link=252223
    >
    >

    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
    > the hub request to affect the hardware.
    >
    >

    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
    > selected.
    >
    >
    > 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.

    Cheers,
    R0b0t1
  • <ASIDE>
    (There's SO much that I want to write in this thread. But I realize that Mr. Roberts is already handling the situation admirably. And the depth and extent of my imagined contributions are unlikely to be appreciated by Mr. R0b0t1. So... you know, I'll abstain.)
    </ASIDE>

    Peter
    OSR
    @OSRDrivers

    (Funny aside to the aside... the initial test migration of NTDEV to the new forum software stripped out all these faux HTML tags such as <quote> and <aside> and <rant>... The forum folks found our use of these tags... unusual and perplexing.)

    Peter Viscarola
    OSR
    @OSRDrivers

  • R0b0t1R0b0t1 Posts: 130
    On Wed, Jun 6, 2018 at 10:56 AM, xxxxx@osr.com <xxxxx@lists.osr.com> wrote:
    > <ASIDE>
    > (There's SO much that I want to write in this thread. But I realize that Mr. Roberts is already handling the situation admirably. And the depth and extent of my imagined contributions are unlikely to be appreciated by Mr. R0b0t1. So... you know, I'll abstain.)
    > </ASIDE>
    >
    > Peter
    > OSR
    > @OSRDrivers
    >
    > (Funny aside to the aside... the initial test migration of NTDEV to the new forum software stripped out all these faux HTML tags such as <quote> and <aside> and <rant>... The forum folks found our use of these tags... unusual and perplexing.)
    >
    >

    I apologize if my behavior on the list has been problematic, sir. It
    is the case I am not very smart. I do not offer this as justification,
    only explanation.

    In other news I have gotten USB enumeration working properly. Only
    until a good way in did I find the USBView project in the driver
    examples. I compared the code to the likes of libusb and so on, and
    seeing as I need to invoke the reset IOCTL manually myself, using the
    driver interfaces on my own is not that much harder.

    One thing I do not understand: I can't resolve the device link given
    by WM_DEVICECHANGE DBT_DEVICEARRIVAL DBT_DEVTYPE_DEVICEINTERFACE
    events to a hub. On Linux, the corresponding udev message gives me a
    path that I can invoke USBDEVFS_RESET on directly. The extra work I
    need to do to match a device with its hub is a cause for lament.


    If anyone has anything to add I will listen to it, especially in
    regards to general experience with the USB subsystem or the design of
    the hardware subsystems in Windows. But, I am now wary of Window's
    implementation and any conclusions that might be drawn from studying
    it.


    There is one instance I think I will need to file a documentation
    issue about: the remarks section of some IOCTL states USB 2.0 and USB
    3.0 buses can be used concurrently. While I would agree that the
    documentation doesn't preclude this my reading of it gleans nothing
    about the implementation of bus cooperation, which leaves device
    manufacturers open to having either electrical interfaces tie up the
    internal control logic of a hub. And indeed, many do. An example is
    Cypress, who states that cooperation of USB 2 and USB 3 signalling is
    disallowed by the specification.

    An easy test is to check the throughput of a mass storage device while
    a keyboard or mouse is connected to the same hub. This is how I
    originally found the issue.

    Cheers,
    R0b0t1
  • I have a fundamental question: Are you doing this from a driver? If so, can't you just send whatever you want to send to reset the hub to your PDO?

    If you're pushing firmware to your USB device via an application, I'd suggest that there might be a different/better way to do that... one that would involve you writing a driver (perhaps a user-mode driver) to do that firmware update.

    Peter
    OSR
    @OSRDrivers

    Peter Viscarola
    OSR
    @OSRDrivers

  • Tim_RobertsTim_Roberts Posts: 12,616
    xxxxx@gmail.com wrote:
    >
    > One thing I do not understand: I can't resolve the device link given
    > by WM_DEVICECHANGE DBT_DEVICEARRIVAL DBT_DEVTYPE_DEVICEINTERFACE
    > events to a hub. On Linux, the corresponding udev message gives me a
    > path that I can invoke USBDEVFS_RESET on directly. The extra work I
    > need to do to match a device with its hub is a cause for lament.

    It's true.  WM_DEVICECHANGE tells you "something has changed".  It does
    not tell you exactly what has changed.  It is your responsibility to
    track the state of the hardware you're interested in, and go scan for
    changes in that hardware.

    As I mentioned on the [libusb] list, this is just a fundamental
    philosophy difference between Linux and Windows.  Linux expects the user
    app to be deeply aware of and involved in the exact make-up of the
    device tree.  Libusb happened to follow that philosophy.  Windows is
    entirely different.  The device tree is abstracted as much as possible. 
    This allows for a much wider range of device support, but it means apps
    that want to be very specific have a lot more work to do.


    > But, I am now wary of Window's
    > implementation and any conclusions that might be drawn from studying
    > it.

    There's no need to be wary.  You just need to understand the basic
    philosophies of the system.  When you try to plug a square peg into a
    round hole, it is natural that some kind of adapter will be required.


    > There is one instance I think I will need to file a documentation
    > issue about: the remarks section of some IOCTL states USB 2.0 and USB
    > 3.0 buses can be used concurrently.

    What do you mean, exactly?  A device decides at reset time through J/K
    negotiation whether it is low-speed, full-speed, high-speed, or
    super-speed.  There is no mixing of personalities.  A single hub can
    have devices running various different speeds, so a single piece of wire
    can be running devices of different speeds.


    > And indeed, many do. An example is
    > Cypress, who states that cooperation of USB 2 and USB 3 signalling is
    > disallowed by the specification.

    That's true, to an extent.  A USB 3 cable contains both USB 2 wires and
    USB 3 wires, separate from each other.  If a hub has USB 2 devices,
    their traffic will go down the USB 2 wires and be shown under an EHCI
    host controller.  If that hub has USB 3 devices, their traffic will go
    down the USB 3 wires and be shown under an XHCI host controller.  The
    reset-time negotiation decides which wires a given device will be using.

    --
    Tim Roberts, xxxxx@probo.com
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!