That sounds familiar. Was a patch submitted to make OHCI init
behave better in the face of such major init problems ... like,
by refusing to initialize?
- Dave
"Dunlap, Randy" wrote:
>
> Richard and I discussed this some more.
> We agreed that
>
> > > num_ports = readl (&ohci->regs->roothub.a) & 0xff;
>
> num_ports in this case is bogus because hc_reset()
> has already failed with both "USB HC TakeOver failed" and
> "USB HC reset timed out" messages.
> In his log file, num_ports was reported as 255, so this
> readl() was returning at least 0xff, maybe even 0xff...ff.
>
> ~Randy
>
> > -----Original Message-----
> > From: David Brownell [mailto:[EMAIL PROTECTED]]
> >
> > That could be masking with 0x0f ... the spec says that OHCI may
> > have from one to fifteen ports, but allocates an extra four bits
> > in that register. Better, maybe have the driver report an error
> > if those extra four bits aren't zero (num_ports > 15). Something
> > clearly is pretty broken if that's ever seen ... as you noticed.
> >
> > If the alpha is really looking at the right location for that
> > register, then whatever OHCI its using has a big problem. I'd
> > guess that it's got the wrong OHCI register base address.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
