Hi Lothar,
On Friday 17 December 2004 6:53 am, Lothar Wassmann wrote:
> Hi David,
>
> > On Friday 17 December 2004 1:51 am, Lothar Wassmann wrote:
> > > > xfer_size = ptd_xfer_size(ptd_q, xfer_type, len);
> > > > printk("len = %d, xfer_size = %d, mps = %d, xfer_type = %d\n",
> > > > len, xfer_size, mps, xfer_type);
> > > > if (xfer_size < len && xfer_size % mps) {
> > > > BUG_ON(xfer_size < mps);
> > > > // round down to an integer multiple of max_packet_size
> > > > xfer_size -= xfer_size % mps;
> > > >
> > > If xfer_size is less than mps this assignment would give a bogus
> > > result, thus the BUG_ON() macro to catch this case.
> >
> > Not that I know that Philips chip or driver, but I don't see
> > why this should be a BUG either ... looks like the test is wrong,
> > the "if" should include "xfer_size > mps".
> >
> No. The test is absolutely correct! 'xfer_size' is calculated by
> ptd_xfer_size() as the maximum chunk of data that can be transferred
> in one block based on mps and the block size that is configured for
> the chip internal buffer. 'len' is the amount of data that read()
> expects.
My point still remains that the maximum chunk for any given
transfer can easily be less than the maximum packet size.
Though it's not clear how that maps to the state variables
you have there ...
Whether that relates to the original question is a different
question, which I can't answer since I don't know that driver.
But having any BUG_ON() fire is trouble ... :)
- Dave
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
