On Fri, Sep 26, 2003 at 06:55:41PM -0700, Neil Whelchel wrote:
> > Hm, so what happens if the driver does not define a write_int_callback
> > function? We don't provide a default one, so it might be pretty easy to
> > oops a driver this way. Care to provide a default dummy one?
>
> Very good point...
> I had already thought about that, however I did not see a generic
> read_int_callback anywhere, I thought that there might be a reason so I
> left out the generic write_int_callback.
Ah, good point, I missed that one :)
> One reason that comes to mind is: I would assume that any
> interrupt transfer to or from a serial converter (unless it was for some
> sort of synchronous serial) would have some particular packet format.
> For example the Cypress device I am dealing with now sends 16 bytes per
> transfer, the second byte tells how many of the following bytes are valid
> data. As far as I know there is no generic packet format, so a generic
> function would (probably) never be correct for the device.
>
> I have another idea however...
> If the driver does not define a write_int_callback or read_int_callback,
> we simply don't create the URB.. For example we just add an if around the
> function...
>
>
> if (serial->type->write_int_callback) {
> ...
> }
>
> What do you think?
Looks good to me. Can you do the same thing for the read_int_callback
too?
> > > @@ -193,6 +202,8 @@
> > > * of the devices this structure can support.
> > > * @num_interrupt_in: the number of interrupt in endpoints this device will
> > > * have.
> > > + * @num_interrupt_out: the number of interrupt out endpoints this device will
> > > + * have.
> > > * @num_bulk_in: the number of bulk in endpoints this device will have.
> > > * @num_bulk_out: the number of bulk out endpoints this device will have.
> > > * @num_ports: the number of different ports this device will have.
> > > @@ -225,6 +236,7 @@
> > > char *short_name;
> > > const struct usb_device_id *id_table;
> > > char num_interrupt_in;
> > > + char num_interrupt_out;
> >
> > I don't think you use this, right? Hm, looks like we don't use the
> > num_interrupt_in field either. I guess I could remove those, for some
> > reason I thought I did in the past...
>
> Once again, I put it there based upon what seemed to be already going
> on. There are several other drivers that are in the version that I am
> working on that set the value of num_interrupt_in, but I don't see
> anywhere that it is actually used. I would be happy to provide a patch to
> remove all of them as well as the num_interrupt_out if you think that it
> should be done..
Yes, that should be done. But you can do that in a separate patch after
the interrupt in one.
thanks,
greg k-h
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
