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

[Roman Kagan]

On Wed, Apr 27, 2005 at 01:09:30PM +0200, Duncan Sands wrote:
> > 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.

That would be somewhat too many: the endpoint information would be in
struct usbatm_driver, usbatm_data, and usbatm_channel.

> > 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?

No, I thought about using static endpoint number from usbatm_driver.in
or .out and poking at the endpoint descriptor after .bind() (that can't
be done before .bind() because it may need to choose the proper
altsetting).

> > 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?

Absolutely :)

Cheers,
  Roman.