On Thu, 4 Jan 2007, Mike King wrote:
> Alan,
>
> >
> > On Thu, 4 Jan 2007, Mike King wrote:
> >
> > > > > > > Anytime a SET_CONFIGURATION is sent to the device without being
> > > > > > > preceeded
> > > > > > > by the secret vendor specific command the device reverts to the
> > > > > > > previous
> > > > > > > device descriptor data indicating 100ma.
> >
> > When you say "preceeded by", do you mean "immediately preceeded by"? How
> > long a time, and what other requests, are allowed to come between the
> > secret command and the Set-Config? What if there are two consecutive
> > Set-Configs -- will the second one cause the device to revert?
>
> 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?
> > BTW, it's very unusual -- bordering on illegal -- for a device to change
> > the contents of its configuration descriptor without re-enumerating. Are
> > you sure it really does this? Or does it leave the descriptor the same
> > (500 mA) but revert to drawing only 100 mA of current?
>
> I'm sure it does this as I'm watching with a hardware analyzer (Finisar
> Bus Doctor).
A bus analyzer won't tell you what's in the descriptor unless the host
sends a Get-Descriptor request. Normally Linux does not send any such
request after a Set-Config. So how can you be certain a second Set-Config
causes the device to restore the power-on default device descriptor
indicating 100 mA?
> In terms of actual current draw, I don't know. I don't have
> a current probe to see what is happening. I do know that on the display
> it will say "insufficient charging current" if it has not gone thru this
> secret command / set-config sequence.
>
> >
> >
> > > > The settling time is only necessary after the secret command and the
> > > > SET_CONFIGURATION. The device resets itself and is coming out of reset
> >
> > Note: You say the device "resets" itself, but you really mean that it
> > disconnects itself from the USB bus and then reconnects. That's different
> > from a reset.
>
> Thanks for correcting me. I am still trying to teach myself about USB
> devices as well as the Linux USB implementation. What the analyzer indicates
> is a reset. Here is the full sequence as shown by the Finisar :
>
>
> 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
Those "resets" are SE0 bus states. They could indicate either a
disconnect or a port reset. Only the device can initiate a disconnect and
only the host can initiate a port reset.
However port resets are generally pretty short. For example, there must
have been one between the first two lines in the log above, but it doesn't
show up. So these "resets" probably mean the device has disconnected.
> 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.
> BULK
> BULK
> BULK
> ...
> ...
> ... ad infinitum
> > > I am speculating that the device firmware has code like:
> > >
> > > switch (command) {
> > > case SECRET_COMMAND:
> > > reset_upon_set_config = 1;
> > > full_power = 1;
> > > break;
> > > case SET_CONFIGURATION:
> > > if (reset_upon_set_config) {
> > > reset();
> > > } else {
> > > set_config();
> > > }
> > >
> > > So it might not matter how the reset is done.
> >
> > When is full_power cleared? If it gets cleared at the end of the
> > SET_CONFIGURATION case then you will have the following sequence:
> >
> > secret command (reset_upon_set_config = full_power = 1)
> >
> > Set Configuration (Does a disconnect & reset, turns on full power
> > mode, and does reset_upon_set_config = full_power = 0)
> >
> > Re-enumerate (Reads 500 mA power usage in the new descriptor)
> >
> > Device recharges its battery but is unusable because it is in
> > the unconfigured state
> >
> > Set Configuration (Now the device is usable but it has reverted
> > to 100 mA since full_power was 0)
> >
> > This doesn't seem to square with what Mike wrote earlier.
> >
> > You should note also that in this situation it won't help to call
> > usb_reset_device() from the probe routine. You still won't be able to
> > avoid the Set Configuration request after the reset completes.
>
> 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?
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.
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
