On Monday 13 February 2006 8:02 pm, Alan Stern wrote:
> > I don't know why you do that for UHCI, but for OHCI the reason for the
> > code duplication is:  just in case some non-PCI system needs the handoff.
> > That seems to be a purely theoretical case just now.
> 
> There are two reasons why I did it that way in uhci-hcd.  First, the
> possibility that the early handoff didn't take place; 

Current kernels can't do that though, right?  If so I'd just say
that's old code that could safely be deleted.  UHCI could do the
same, relying only on pci-quirks.c and eliminating one copy of that
bios-quirky code.


> second, the need to 
> reinitialize the controller if power was lost during a suspend (since the
> quirks routine might not get called during a resume). 

Same:  how could a current kernel do that?


> > > However the EHCI handoff is not called anywhere in ehci-hcd.  If the 
> > > quirks code doesn't run then the handoff will never take place.
> > 
> > Right; EHCI handoff (unlike OHCI) is specified as PCI-specific; those
> > registers sit in PCI config space.
> 
> BTW, the OHCI driver does the extra handoff even when it is built as a PCI 
> driver.  A minor point... but it shows that PCI-specificity isn't really 
> the issue.

Isn't all of the issue.  Systems with both PCI and non-PCI implementations
of OHCI are non-theoretical.  Adding an "if (not-on-pci)" clause to the
instance of the handoff code in the OHCI driver hasn't seemed worth the
time; it wouldn't save much time over the existing "test one bit" code.

 
> > > Some systems require that the OHCI handoff not take place at the time the
> > > quirk_usb_early_handoff routine runs, but only later (after the i8042 has
> > > been initialized).  It's possible that other systems may end up having a
> > > similar requirement for the EHCI handoff.
> > 
> > Or UHCI.  But the input system isn't ready to handle such stuff yet, right?
> 
> I'm not sure what you mean.  The input system should work just fine.  In 
> fact, on the systems where we've been getting the bug reports, the input 
> system doesn't work _unless_ the handoff is delayed.

What's the mechanism to delay it?

Last I knew, there was no such mechanism.

 
> On the chance that preventing all the handoffs is the way we go, I think
> it would be good to have all the HCDs written to do a redundant handoff
> during controller initialization, as uhci-hcd and ohci-hcd do now.  No
> changes to the input layer should be needed.

Doing that cleanly can just export the ehci handoff from the single copy
of that code living in pci-quirks, yes.  UHCI could work the same.

At this point OHCI is the only HCD that needs handoff code but can't
tie it to the pci-quirks.c source code.  It might be good to rename
that to hcd-handoff.c so it'd be fair to link on non-PCI boxes, then
export the OHCI handoff code from there.

- Dave



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to