On Wednesday 10 November 2004 12:05, Alan Stern wrote:
> On Tue, 9 Nov 2004, David Brownell wrote:
>
> 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!
Not until the relevant kernel trees (with lots of board
specific patches) catch up to that "near future". I
understand they're not that far behind, in this case.
Though I'll be glad to start offloading more of the
data structure init/teardown to that common code!
> > 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'd be beside the point ... those routines DO work with
untyped blocks of memory, always have, always will. The
type punning here involves two different data types, saying
they must be embedded within each other in a particular way.
Reminds me of what it was like to hack on a Mac+ ... where
you could rely on the bytes in front of _most_ OS pointers to
work in particular ways. ;)
> > 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?
I guess until there actually IS code that knows how to restart
a generic dead HCD, those issues don't matter much. And maybe
those recent patches to let drivers be bound/unbound through
sysfs could help in this area too ... though I don't much like
the notion of unbind/rebind instead of driver reset (it might
not be able to reclaim all the resources again!), that should
certainly work with any driver when resources arent' scarce.
> Shall I simply go ahead and submit my patches for Greg to review?
I don't think I'd have too many worries about them going on
top of those PM patches, except for the "type punning must
work" issue. I'll send Dales' third OHCI patch soonish
too, that'll have another HCD that'll need updates.
- 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
