On Tuesday 09 November 2004 07:23, Alan Stern wrote:
> On Mon, 8 Nov 2004, David Brownell wrote:
>
> > The SL-811 code will need updates too (or it will, once
> > there's one that compiles and runs),
>
> Actually no. The SL-811 code doesn't currently use the hcd glue layer at
> all!
It will. So far as I'm concerned, once it does then it'll
finally be reasonable to remove that old 2.2 bus framework.
> > also EHCI ...
>
> That's written, I just didn't include it in the last message. Plus the
> non-PCI OHCI drivers and dummy_hcd.
>
> > plus there's another OHCI patch pending, for those
> > big-endian PPC variants.
>
> Sigh... More adjustments to make.
Just to the new drivers/usb/host/ohci-ocp.c file ... :)
> > That doesn't look too heinous, though I don't see
> > where you hand the HCDs their private data; that's
> > what I'd expect in hcd->self.hcpriv, but that's just
> > "hcd" which clearly is already known. If you're using
> > the alloc_etherdev() model, the hardware-specific
> > struct doesn't contain the generic one.
>
> I didn't change the meaning of hcd->self.hcpriv; it was useless before and
> it's still useless. The model I copied from was the SCSI host code.
> Look at the patch for the uhci_hcd.h file to see the definitions of
> uhci_to_hcd() and hcd_to_uhci(). The hardware-specific structure is
> allocated at the end of the generic one rather than containing it; they
> share the same refcount.
But as I said: that relies on type punning ("knowing"
that pointer-to-A is also pointer-to-B), which is a
practice best observed by avoiding it.
> > I'm still not planning to start on my part of that
> > (analagous changes for usb_device) till 2.6.11 gets
> > closer ... maybe we can get rid of "usb_operations"
> > at that time, too.
>
> I'd be happy to see usb_bus and usb_hcd merged, along with all the other
> implications of flattening out the glue layer.
>
>
> > > hcd->state is explicitly initialized to USB_STATE_HALT when the
> > > hcd structure is created.
> >
> > As opposed to implicitly as part of bzeroing the memory.
>
> No, as opposed to being set explictly following the call to
> driver->reset() in usb_hcd_pci_probe.
But the definition of reset() involves leaving the HCD in
that HALT state. The notion is that reset() should be used
not just during initialization, but also after recovering
from dead HCDs. That assignment relieves HCDs of code.
> There was one other thing that needed to be changed in the OHCI driver.
> The initialization code in ohci_hcd_alloc (for next_statechange, lock,
> pending, and rh_resume) had to be moved since ohci_hcd_alloc itself
> disappeared. I created a new routine, ohci_hcd_init, to handle those
> things and called it at the start of ohci_pci_reset. (I also called it
> explicitly from the probe routines for the non-PCI OHCI drivers). Will
> that work okay? I couldn't test it because of the failure-to-resume bug.
I don't see why not. A lot of the init sequencing logic there
is just old code that I've been in no rush to change (since chip
init sequences can be fragile), but that doesn't mean it should
work that way forever!
- Dave
> Alan Stern
>
>
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
