On Tue, 9 Nov 2004, David Brownell wrote:
> 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.
Well, assuming my changes are applied in the near future, when the SL-811
driver finally gets updated to use the hcd stuff then it will be
compatible with the changes!
> > 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 think it's not so bad, when done in controlled ways like here. You
might just as well complain about the types returned by kmalloc and
accepted by kfree. :-)
(That's not an idle analogy, by the way. In each case, a core routine
must deal with pointers to regions of memory storing types defined by a
less-central routine. There's no alternative to using a generic pointer
type. If I could have defined the new last field in struct usb_hcd as
"void hcd_priv[0]" I would have.)
> > > > 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.
So what? They are still relieved of the code, because now hcd->state is
set to USB_STATE_HALT when hcd_pci_probe calls usb_create_hcd, before
driver->reset instead of after. Unless you think there's some reason the
driver is going to change hcd->state to something else and it needs to be
changed back?
Shall I simply go ahead and submit my patches for Greg to review?
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
