Interestingly, the USB 2.x specification states that a device must not draw more than 500uA (~2.5mW) while it is not being actively addressed by the host.
I frequently wonder how many devices actually adhere to that requirement. Probably not many.
That number is not for devices not actively adressed (whathever that means) but for devices that do not have power profile accepted by host. On the other hand it is slightly unclear how that is meant because that is awfully close to the power required for correct device-side Full speed USB termination network. Thus interpretation that I use is that before enumeration the device as a whole should not draw more than 1mA from VBUS.
If a company claims their product is "USB compatible", but the product doesn't 100% comply with the detailed technical specification, what's the company's liability?
And if the company knew the product didn't strictly meet the USB standard, but marketed the product as "USB compatible" anyway, does that rise to the level of fraud?
"We claimed our device met USB, which claimed a max power draw while unenumerated of 1mA, yet our device actually used 500mA. Whoops. How long did you have this device unenumerated for? 1 second each time you plugged it in? Well damages can be calculated then...
1 second * 365 (number of times plugged in per year) * 500mA * 5 volts * 5 years (expected lifespan) * $0.14 ($/kWh electricity)...
Total compensation is $0.00014... Would you like a check for that?
I looked up the laws in New York (other states may vary), and you can recover your damages or $500, whichever is greater. You have to prove that the advertiser knowingly misled you (which software bugs probably aren't), and that the false advertising is what influenced your purchase.
I doubt it's likely to succeed. Everyone on the jury will be easily convinced that software is hard to get right, since they have probably used a lot of shitty software and consider it normal.
I've thought about this a fair bit. Nothing can prevent you from plainly stating what your device does. You can claim interoperability with USB if your device works for the advertised use. You don't need to pay the USB consortium for licensing, but you can't use their branding.
If you don't make a claim about power draw, then I suspect your consumers can't complain unless the power draw is unexpectedly large. And even then, what are the actual damages you need to compensate them for?
Some controllers used to. It's not clear if most still do.
There is IOCTL_USB_HUB_CYCLE_PORT in Windows that power cycles a port (https://docs.microsoft.com/en-us/windows-hardware/drivers/dd...). My research seems to indicate it doesn't always work. The corresponding utility on Linux has problems on modern hardware but the driver may not be complete.
For both operating systems, you can likely use the autosuspend features, but this is gated by the driver (at least on Linux) and may not be able to reset a malfunctioning device.
For some reason PCIe and USB lack a way to do a hard reset.
I found a rare D-Link hub that supports it[1]. However it only supports it for a while. After a few port commands the hub crashes and only a hard "reboot" of the hub will fix it. In effect no.
Was curious so I read out HCCPARAMS1 from my Intel xHCI controller and it looks like port power control bit is zero, so no? I think the best you could hope for here is there is some ACPI function you could invoke to power down the whole hub.
I've delved into this somewhat in an attempt to get some badly-behaved USB cameras under control— the situation is not pretty, especially for USB 3 hubs. I ended up resorting us using a hub that had an internal jumper for disabling bus power, and then just using an external relay to toggle power to the hub itself and all attached devices.
This has worked fairly well, though it exposes some other interesting problems which I suspect are deeper issues in the Linux kernel, where "replugging" the same device hundreds of times over the course of days of runtime eventually exhausts some internal resource, causing the port to go completely dead until you unbind/bind the xhci device.
Note that if you're not on RPi or some other device with easily usable GPIO to control the relay, you can use any FTDI cable as 4x GPIO, and there are lots of cheap 5V relay breakout boards available.
I frequently wonder how many devices actually adhere to that requirement. Probably not many.