On Mon, Jun 4, 2018 at 12:25 AM, xxxxx@probo.com wrote:
> On Jun 3, 2018, at 6:11 PM, xxxxx@gmail.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
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 https:
>> 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.</https:>
On Mon, Jun 4, 2018 at 1:37 AM, xxxxx@probo.com wrote:
>> 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.
>
>
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
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
On Wed, Jun 6, 2018 at 10:56 AM, xxxxx@osr.com wrote:
>
>
> 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
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
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.