On 27 March 2013 20:00, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 27 Mar 2013, David Linares wrote: > >> Please correct me if I am wrong. >> On my iMX25 board, I have got a 1-port root_hub which will provide >> 500mA max to its unique child. > > You should check that against the iMX25's specs. It's possible that > the root hub has a current limit lower than 500 mA. > >> Now that's where I am getting confused. >> Its child, a 2-port hub, will then be bus-powered. But if it is, it >> won't provide these 500mA shared between the 2 ports. It will only >> provide 100mA per port, right? > > Actually, I don't know. What I said earlier was under the assumption > that the 2-port hub receives all its power from the USB bus. But in > theory, it's possible for the hub to receive power directly from the > iMX25 board's power supply. So the answer depends on how the hardware > is wired up. > > If the 2-port hub doesn't have an additional power source then you are > right -- it is bus powered and should provide only 100 mA to each port. > But if it does have an external (to the USB bus) supply then it could > very well try to provide 500 mA to each port. Even if the external > supply isn't strong enough to permit this. > >> But for me to be able to plug my wireless dongle, in the code, I guess >> I will need to have "hub->mA_per_port = 500;" and therefore have the >> USB_DEVICE_SELF_POWERED bit set in the hubstatus. Is that correct? >> Because otherwise, my dongle will always pass the test "if >> (c->desc.bMaxPower * 2 > udev->bus_mA)" if this udev->bus_mA is set to >> 100mA and always end up in insufficient power. > > Sort of. Your emphasis is backward; this is a hardware issue, and > whether or not a software test is passed won't affect the underlying > problem. That test is there so that the system will avoid trying to > use a device when there isn't enough power for it. Unfortunately the > test doesn't always work, because many devices lie about their power > sources. > > Also, hubs don't always limit the amount of current to their downstream > ports the way they should. A bus-powered hub is supposed to get an > over-current condition and turn off port power if the device attached > to the port tries to draw more than 100 mA. But not all of them do > this. > > In any case, you said there were occasional problems even without the > dongle attached. In that situation, power should not be an issue. > >> > You never posted any usbmon results. If you could see the actual data >> > sent by the hub when it's not working, you might get a better idea of >> > where the problem is. >> >> True. Didn't get a chance to do this experiment yet. As you can read, >> I am still having some difficulties understanding how it should work >> in practice and who gives which power :-) >> Will do that tomorrow too. > > Okay. Ok so here is what I did: - compiled all USB stuff as modules - boot up the device with nothing plugged in - Checked that "lsmod | grep usb" didn't return anything - modprobe usbmon (this will also load usbcore) - start the capture : cat /sys/kernel/debug/usb/usbmon/0u > mon.out & - modprobe ehci-hcd - kill the cat ;p I managed to get the capture for the failing case (NOK) and the OK case. Here are the results: OK case, dmesg output: http://pastebin.com/8DRP9L4E OK case, lsusb -v output: http://pastebin.com/HcFKhVeW OK case, usbmon output: http://pastebin.com/LrFuJ2cd NOK case, dmesg output: http://pastebin.com/7kXDCDmr NOK case, lsusb -v output: http://pastebin.com/zachs6FX NOK case, usbmon output: http://pastebin.com/RtyLjKt9 I still haven't analysed the results, but there are definitely some differences between the two usbmon results. Just wanted to post them as soon as possible, just in case I did something wrong. Cheers. David > > Alan Stern > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
