speedtch usbatm.c,1.20,1.21 usbatm.h,1.13,1.14
Duncan Sands
baldrick at free.fr
Wed Apr 27 07:09:30 EDT 2005
Hi Roman,
> There's no need to restore these, the driver can access
> [rt]x_channel.endpoint directly, and that's how it works now.
I disagree - drivers shouldn't be mucking about in there. The channels
are private to the core (they are even commented as private in the
spec). The only reason I suggested this duplication was to maintain
a clear distinction between public (driver can use) and private (driver
shouldn't use) parts of the struct usbatm_data.
> Note, however, that here we use pipes under the name of endpoints, so in
> my first comment above I suggested to access bmAttributes in the
> endpoint descriptor and figure out the right pipe type to use for
> channel.endpoint. But in this case there's no easy way for the driver
> to change its mind on which endpoint it wants to use.
I guess you mean without it recalculating that itself?
> So in the end it may be not such a bad idea to leave it the way it is
> now: that is, initialize .endpoint, .stride and .buf_size in each
> channel from struct usbatm_driver before bind, and let the driver
> override them if needed in its .bind().
Not .buf_size, surely?
D.
More information about the Usbatm
mailing list