speedtch usbatm.c,1.20,1.21 usbatm.h,1.13,1.14

[Duncan Sands]

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.