On Wednesday 17 July 2002 17:16, David Brownell wrote:
> Duncan Sands wrote:
> > Summary: not a problem with the modem.
>
> I think you'd shown this was most likely a problem with the
> UHCI driver you're using ... right? Did you verify this
> happens with both UHCIs?
Hi Dave, it is the same with both UHCIs. I've been looking
at where the port reset (which kills the modem) actually happens.
It is in uhci-hub.c, in the routine uhci_hub_control (case SetPortFeature).
The code is as follows (not my favorite coding style):
SET_RH_PORTSTAT(USBPORTSC_PR);
mdelay(50); /* USB v1.1 7.1.7.3 */
c_p_r[wIndex - 1] = 1;
CLR_RH_PORTSTAT(USBPORTSC_PR);
udelay(10);
SET_RH_PORTSTAT(USBPORTSC_PE);
mdelay(10);
SET_RH_PORTSTAT(0xa);
OK(0);
Who knows why c_p_r is set - the value is not used anywhere.
And the OK function sets the value of len - which is not used anywhere
either! By the way the macros are
#define OK(x) len = (x); break <= Nice place to put break, hey!
#define CLR_RH_PORTSTAT(x) \
status = inw(io_addr + USBPORTSC1 + 2 * (wIndex-1)); \
status = (status & 0xfff5) & ~(x); \
outw(status, io_addr + USBPORTSC1 + 2 * (wIndex-1))
#define SET_RH_PORTSTAT(x) \
status = inw(io_addr + USBPORTSC1 + 2 * (wIndex-1)); \
status = (status & 0xfff5) | (x); \
outw(status, io_addr + USBPORTSC1 + 2 * (wIndex-1))
Do you know which spec this sequence of operations is defined in?
I want to check that the code is correct. Another possibility is a timing
problem. At least one Microsoft knowledge base article mentions timing
problems with my VIA uhci hub.
All the best,
Duncan.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
