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.
> > > len = 64, xfer_size = 8, mps = 64, xfer_type = 3
> > >
> > It looks like your blocksize for the INT transfer buffer is set to 8
> > and the device requires 64 byte max packet size.
>
> If the endpoint descriptor says "at most 64 bytes", and
> a read says "at most 8 bytes", that's perfectly legal.
>
see above.
> > A data block of >
> > max_packet_size byte is divided into an integral number of packets of
> > max_packet_size byte plus one packet (the last one) that may carry
> > less than max_packet_size byte of data. Thus the block size of each
> > buffer area need to be at least 'max_packet_size' of the corresponding
> > transfer type.
>
> No it doesn't. It's perfectly reasonable for a driver
> to know that the next IN transaction will be a short packet;
> sometimes they even know the exact size. That "integral
> number" can be zero (for buffers less than maxpacket).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I was talking about "A data block of > max_packet_size byte" which
as far as my math reaches excludes "buffers less than maxpacket" ;-)
Lothar Wassmann
-------------------------------------------------------
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
