On Fri, 5 Jan 2007, Mike King wrote: > > > What I see with the analyzer is that the secret command immediately > > > preceeds > > > the set-config. And, yes, a second set-config causes the device to > > > restore the power-on default device descriptor indicating 100ma. > > > > How do you know the descriptor changes back to 100 mA? > > The sequence list that I included showed the secret command, followed by > a SET_CONFIG that caused the device to disconnect and reconnect and > then another SET_CONFIG that causes the config to be active with the > descriptor now indicating 500ma. At this point in time there are still > some config descpiptor requests that go by so I can see the 500ma.
Okay. > > > GET_DESCRIPTOR DEVICE > > > SET_ADDRESS > > > GET_DESCRIPTOR DEVICE > > > GET_DESCRIPTOR CONFIG (9 bytes) > > > bMaxPower = 100ma > > > 0x09 0x02 0x2e 0x00 0x01 0x01 0x00 0x80 0x32 > > > GET_DESCRIPTOR CONFIG (full config) > > > GET_DESCRIPTOR STRING (repeated 4 times with different indexes) > > > CLASS_SPECIFIC CMD (secret command) value=0, index=1, length=0 > > > SET_CONFIGURATION config value = 1,index=0,length=0 > > > reset > > > reset > > > reset > > > GET_DESCRIPTOR DEVICE > > > SET_ADDRESS > > > GET_DESCRIPTOR DEVICE > > > GET_DESCRIPTOR CONFIG (9 bytes) > > > bMaxPower = 500ma, all other settings are same as previous > > > 0x09 0x02 0x2e 0x00 0x01 0x01 0x00 0x80 0xfa > > > GET_DESCRIPTOR CONFIG (full config) > > > GET_DESCRIPTOR STRING (repeated 4 times with different indexes) > > > SET_CONFIGURATION config value = 1, index=0,length=0 > > > > At this point presumably the configuration descriptor changes back to > > indicating 100 mA, since this is the second Set-Config following the > > secret command. > > I don't think so. I can't say for sure because the trace I gave you was for > the Windows driver and I haven't modified my Windows filter driver to inject > another Get-Descriptor request. You did say above that a second Set-Config after the secret command causes the device to restore its default 100 mA descriptor. Was that not correct? > But, what I can say is that I have experimented with various sequences on > Linux and what I know for sure is that it is not the CLASS_SPECIFIC cmd > that causes the device to disconnect. It is the SET_CONFIG following > the CLASS_SPECIFIC cmd that causes the device to disconnect. > > What is really puzzling is that after Linux core USB sets the address, gets > some descriptors (device,config,strings) and does a SET_CONFIG that the > firmware has reverted back to 100ma. But, if I #ifdef out the SET_CONFIG in > the usb_reset_configuration() and usb_set_configuration() and manage doing the > 2nd SET_CONFIG in my driver That would be the first Set-Config following the secret command, right? > the config descriptor still shows 500ma and the > device is configured and functioning properly. How can it be configured? The Set-Config sent by your driver caused the device to disconnect and reset itself, and you prevented the USB core from sending any more Set-Config requests. So the device should remain in the unconfigured state following re-enumeration. Or do you perhaps mean that your driver actually sends _two_ Set-Config requests: one to reset the device and then one to congfigure it afterward? > And it stays that way forever. > I know this because I have placed a number of Get-Descriptor requests at > various points in my driver. If you did mean that your driver sends two Set-Config requests, then this contradicts what you wrote above: "And, yes, a second set-config causes the device to restore the power-on default device descriptor indicating 100ma." > The only thing I can come up with is that the device is somehow sensitive to > the additional descriptor requests that Linux USB core makes as it is > setting up the device so it can register the interfaces to let them get > bound to drivers. Linux makes a few Get-Descriptor requests before issuing the second Set-Config, but nothing out of the ordinary. You should make a detailed comparison of the requests sent by Linux with your driver and by Windows. > At Olivers' suggestion I tried using usb_reset_configuration() but that > just doesn't have the proper sequence because the firmware always reverts > back to 100ma during USB core configuration. > > So, I can make the device work properly but I have to keep the USB core > from doing the USB_REQ_SET_CONFIGURATION during usb_set_configuration() > and during usb_reset_configuration(). Obviously not a usable scenario... > > > Full power is never cleared. The device stays in this state as long as > > > it is connected. > > > > How do you know? You said above that you have no way of measuring current > > draw. Are you going by what the device says on its display? > > You're right. At that point in time I was using just the display on the > Blackberry as an indication. I didn't know for sure then but I am fairly > well convinced of it now. > > > > > Furthermore, this would mean that the device continues to draw 500 mA of > > current even though the descriptor reverts back to indicating only 100 mA. > > That doesn't make sense. > > I agree. Based on further experiments it stays at 500ma setting. Not that > the device is drawing that much current. So maybe you don't need to worry about anything. Even though the descriptor value changes back to 100 mA (which the USB core won't notice since it pays attention only to the descriptor that it read during the re-enumeration), the device may continue charging its battery and using up to 500 mA of current. In other words, it's doing what you want even though the descriptor value is wrong. In which case there doesn't appear to be any problem. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
