Re: [Patch] Increase USBFS Bulk Transfer size

[Markus Rechberger]

On Fri, Oct 14, 2011 at 10:51 AM, James Courtier-Dutton
<james.dutton@xxxxxxxxx> wrote:
> On 14 October 2011 07:23, Markus Rechberger <mrechberger@xxxxxxxxx> wrote:
>> On Fri, Oct 14, 2011 at 7:47 AM,  <Valdis.Kletnieks@xxxxxx> wrote:
>>> On Fri, 14 Oct 2011 05:42:44 +0200, Markus Rechberger said:
>>>
>>>> The inflexible device which uses 24064 bytes works with all other
>>>> Operating systems by using that value
>>>> and gives exactly the same results with other transfer sizes than that.
>>>
>>> -ENOPARSE.  If it's inflexible,
>>
>> the particular device in question is inflexible yes.
>>
> Here is what I think the actual situation is.
> Your transfers over the USB are done in 512 Bytes chunks.
> If the device wishes to send 512 bytes, it sends one chunk.
> If the device wishes to send 513 bytes, it sends only one chunk,
> missing one byte.
> if the device wishes to send 1023 bytes, it sends only one chunk,
> missing 511 bytes.
> if the device wishes to send 1024 bytes, it sends two chunks, missing 0 bytes.
> So, the device is sending 1 too few chunks unless the bytes size
> exactly matches the chunk size * n.
> Another constraint is the device sends multiples of 188 bytes.
> So, unless we can find a lowest common multiple of 188 and 512, there
> is no transfer size that will work with this device. The LCM is 24064
> and this is the only value that will work with this device.
>
> Conclusion:
> The hardware on the Linux PC and the kernel on the Linux PC are
> working correctly.
> Your external USB device has an off-by-one error in its
> hardware/embedded software and the hardware/embedded software
> manufacturer is not prepared to fix it.
>
> Workaround in software: Increase MAX from 16384 to 24064 or above.
>
> My own feeling, throw away this faulty bit of hardware and use a different part.
> The hardware is not compatible with USB standards.
>

I agree with that one, and think this conclusion comes closest to the
real issue.
I can imagine that the chip fifo has some issues with that one.
However the device has been tested for a long time without turning to
corrupted data so
the only issue remaining is the buffer alignment.

Thanks for having a look at all that, I wish all requests would have
that kind of review, instead
of "I don't believe you, not acceptable, not right solution at all"

BR,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/