>
> 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?
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.
>
> > > 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 my Linux driver I have added Get-Descriptor requests at various points
so I can look at it with the analyzer.
>
> > 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.
Sorry. There were 2 resets at the beginning of the trace. These occurred
immediately after plugging in the device but before the first Get-Descriptor.
I just inadvertently omitted them.
>
> > 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.
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 the config descriptor still shows 500ma and the
device is configured and functioning properly. 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.
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.
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().
>
> > 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?
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.
>
> Alan Stern
>
Thanks,
Mike
-------------------------------------------------------------------------
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
