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

[Roman Kagan]

On Wed, Apr 27, 2005 at 12:06:52PM +0200, Duncan Sands wrote:
> > > One thing is special, however: the endpoints are initialized to bulk
> > > pipes from usbatm_driver.in and .out, and I assumed that the subdriver
> > > could override it by an iso pipe, if needed.  I guess I should better
> > > check the endpoint descriptor instead to determine if it's bulk or iso,
> > > and this all can (and should) be done after bind.
> > 
> > Having given it some thought, I'm not so certain this is the right thing
> > to do.  E.g. if the driver only chooses in its bind() which endpoint it
> > wants to use, how does it make the core know?
> 
> I don't understand what the problem is.  Anyway, we could do the following:
> restore these fields in the public part of struct usbatm_data:
> 
>         int tx_endpoint;
>         int rx_endpoint;
>         int tx_padding;
>         int rx_padding;
> 
> The driver can set them in the bind method if it wants.

There's no need to restore these, the driver can access
[rt]x_channel.endpoint directly, and that's how it works now.

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.

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().

Cheers,
  Roman.