On Mon, Jun 24, 2013 at 11:04 PM, Felipe Balbi <balbi@xxxxxx> wrote:
> On Mon, Jun 24, 2013 at 10:56:30PM +0800, Ming Lei wrote:
>> On Mon, Jun 24, 2013 at 10:33 PM, Denis V. Lunev <den@xxxxxxxxxx> wrote:
>> > From: Konstantin Filatov <kfilatov@xxxxxxxxxxxxx>
>> >
>> > This patch shortens TD's packet not only for the last TD in sg list,
>> > but also for the last TD in sg element.
>> >
>> > Signed-off-by: Konstantin Filatov <kfilatov@xxxxxxxxxxxxx>
>> > Signed-off-by: Denis V. Lunev <den@xxxxxxxxxx>
>>
>> Considered that:
>>
>> - the change violates USB spec(1.1/2.0/3.0)
>
> I can't see how this would violate USB spec. USB specifications have no
> knowledge of scatter-gather.
Per USB spec, short packet can only be the last packet of one transfer.
In our linux USB implementation, we think the sg list passed to URB or one
URB as one single transfer, so the middle short packet will cause the URB
to be understood as two or more transfers by device.
>
> It really doesn't matter how the data gets into the HW's FIFO, as long
> as it *does* get there. IOW an SG table like below:
>
> sg[0].length = 512
> sg[1].length = 512
> sg[2].length = 20
>
> is no different than:
>
> sg[0].length = 502
> sg[1].length = 512
> sg[2].length = 30
>
> from the USB perspective, all is sees is 1044 bytes being shifted
> through the data lines.
Suggest to see the discussion in the below link:
http://marc.info/?t=137182258200003&r=1&w=2
>
>> - the problem should be avoided in usbcore since it isn't a uhci
>> specific problem
>
> to this I agree.
>
>> - this patch only hides problem, doesn't help to fix real problem.
>
> what is the problem then ? Are you saying that it's wrong to have an sg
> which is not aligned to wMaxPacketSize somewhere in the middle of an
> sg-table ? How so ? What does that have to do with USB at all ?
The problem is that short packet can only be the last packet of one transfer.
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
