OK, after playing with uvisor and USB sniffer software for the weekend I
have fixed this for me... *sigh* there is a lot of stuff going on in the
CLIE Windows driver that the CLIE doesn't like and it seems the driver
filters all the nastiness out.
After struggling with stalled commands, timeouts etc. etc. I found that the
CLIE PEG-T625 (which identifies as USB_PRODUCT_SONY_CLIE_40) actually
returns it's pipes on command 03 like a Visor. Simply switching the table
doesn't fix it though because when the call to get the Free Space at the end
of the init function times out it puts the CLIE end of the USB serial to
sleep :(... this wasn't obvious and I wasted a lot of time finding this out.
One simple fix is to disable that part of the function.
Here is a little patch that you can try if you have a device that is
returning STALLED on the init part of uvisor, it's only flagged to turn off
the Free Space call on the USB_PRODUCT_SONY_CLIE_40 device (also changes it
to use the Visor hooks rather than the Palm 4 hooks which stall the device).
Apply patch to /sys/dev/usb/uvisor.c
170a171
> #define NOFRE 0x0004
186c187
< {{ USB_VENDOR_SONY, USB_PRODUCT_SONY_CLIE_40 }, PALM4 },
---
> {{ USB_VENDOR_SONY, USB_PRODUCT_SONY_CLIE_40 }, VISOR | NOFRE },
446a448,450
> /* Skip the free bytes check.. this hangs some sony CLIE devices */
> if (sc->sc_flags & NOFRE) return (err);
>
457d460
<
Then make yourself a Kernel.
It's hardly a patch really it simply adds another device bitmap, sets that
on the device that you want to skip the free space check and in the init
function returns before the free space check if the flag is set.
To enable on other devices simply replace PALM4 with VISOR | NOFRE.
I'm now curious if anyone actually has a CLIE model that identifies as this
entry and actually works with the current driver... please tell me if you
do.
This patch has been tested on 3.8 -release on i386 and 3.9 -current on ARM -
ahem yes I have had my CLIE syncing with my Sharp Zaurus :)
- Andy
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Andrew Smith
Sent: 04 February 2006 14:00
To: misc@openbsd.org
Subject: Any conclusions on the uvisor STALLED status with CLIE devices?
I have an old CLIE PEG-T625C device that I have been trying to make work
with the uvisor driver to get ucom endpoints mapped to cuaUx with a USB
cable.
The device IDs itself to the driver (based upon the standard table in the
driver) as USB_PRODUCT_SONY_CLIE_40 which is mapped to the PALM4 handler,
however, when the usbd_do_request_flags call is made in the PALM4 section of
the uvisor_init function I always get back USBD_STALLED as status.
I have been down two routes to try to fix this (although I am not familiar
with the kernel debug features of OpenBSD yet).
i. I have set up a VMWare machine running Windows XP, CLIE
Palmdesktop and installed 'snoopypro' from http://usbsnoop.sourceforge.net
<http://usbsnoop.sourceforge.net/> with this I have examined the USB
conversation that the commercial Sony driver has with the CLIE. - not
particularly different from the uvisor init but some extra vendor endpoint
stuff.
ii. I have compared the working Linux 2.6 visor driver (I
have a Gentoo system running this driver and it works well) - I have made
the minimal changes to the uvisor driver necessary to change the 03 command
that is normally used to 04 as used by this driver and checked that the data
structures are the same as the ones used in the Linux driver. They are byte
for byte the same (unless there is a packing issue of course).
Both experiments still result in the call to usbd_do_request_flags returning
the STALLED status - where I was previously convinced that the device was
stalling because it was being sent a command it didn't recognise now I am
not so sure.. I'm beginning to speculate that something in the USB transfer
handler is fouling up.
The question is, has anybody else tried this with this model or any other
model showing the STALLED status on init and what conclusions/speculations
did you come to if you didn't fix it?
- Andy
