Am Donnerstag, 4. Januar 2007 08:25 schrieb Mike King:
> >
> > Am Donnerstag, 4. Januar 2007 07:58 schrieb Mike King:
> > > >
> > > > Am Donnerstag, 4. Januar 2007 07:30 schrieb Mike King:
> > > > > 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. A normal reset causes it
> > > > > to default to the normal power setting.
> > > > >
> > > > > So, my basic problem is that the Linux USB core does the
> > > > > SET_CONFIGURATION
> > > > > as part of device initialization after the device is plugged in, long
> > > > > before my driver is probed. I never get the opportunity to send
> > > > > the secret command to the device. If I actually write the secret
> > > > > command followed by a SET_CONFIGURATION from my driver the BB device
> > > > > will reset itself but the Linux core does another SET_CONFIGURATION
> > > > > upon seeing the reset and so the hidden device descriptor data has
> > > > > reverted back to the low power setting.
> > > >
> > > > Does it work if you issue the secret command, wait and then reset the
> > > > device
> > > > in your probe method?
> > > >
> > > > Regards
> > > > Oliver
> > > >
> > >
> > > Oliver,
> > >
> > > Nope. Writing the secret command and the SET_CONFIGURATION causes the
> > > device to reset itself. USB Core reassigns the address and issues yet
> > > another SET_CONFIGURATION which causes the default device descriptor to
> > > reappear.
> >
> > Sorry, I was unclear. I am suggesting that in your probe() method you:
> >
> > - issue the secret command
> > - wait the settling time
> > - issue a full device reset, not SET_CONFIGURATION
> >
> > If that doesn't work I can't see a nice way to deal with this problem.
> >
> > Claiming a full device is major surgery. If you need to, you can claim all
> > other interfaces from the probe() method for the first interface.
> > If the little trick suggested above doesn't work, I don't see a way to get
> > around this without messing with usbcore.
> >
> > Regards
> > Oliver
> >
>
> Oliver,
>
> The settling time is only necessary after the secret command and the
> SET_CONFIGURATION. The device resets itself and is coming out of reset
> and I assume that the memory controller is not quite ready to be used.
>
> By full device reset do you mean the usb_reset_configuration() call ?
>
> Once the device sees a new USB_REQ_SET_CONFIGURATION preceeded by the
> secret command it resets itself, causing the hub to think the
> device has been unplugged and replugged consequently reassinging device
> address and issuing another USB_REQ_SET_CONFIGURATION that is not
> preceeded by the secret command, so the default descriptor has been restored.
Hi,
maybe I am dense. On Windows you see:
secret command -> SET_CONFIGURATION -> {device resets by itself} ->
SET_CONFIGURATION >> 500 mA
don't you? If so, I am suggesting you do:
secret command -> usb_reset_device() -> {device is reset by the hub} ->
SET_CONFIGURATION (from normal probe)
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.
Regards
Oliver
-------------------------------------------------------------------------
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
