Re: [PATCH] USBNET: fix handling padding packet

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 19, 2013 at 3:18 PM, Bjørn Mork <bjorn@xxxxxxx> wrote:
> Oliver Neukum <oneukum@xxxxxxx> writes:
>> On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote:
>>> Oliver Neukum <oneukum@xxxxxxx> wrote:
>>
>>> >No, USB 3.0 uses no companion controllers, so you can have devices
>>> >of any speed connected to it.
>>> >
>>>
>>> Ah, right. I don't own such modern hardware, but I should have known
>>> this anyway.
>>>
>>> This still doesn't change the fact that the driver is brand new for
>>> brand new devices. I believe we should assume such devices will
>>> support ZLPs unless we have documentation stating anything else.
>>
>> For such devices we might assume it. But how does that matter for
>> generic code?
>
> The code isn't generic yet.  Most of it is placed inside the
> ax88179_178a minidriver.

No, the patch doesn't touch code of ax99179_178a.

And it is really generic to fix the padding in case of dma sg.

>
> But I do agree that adding this padding support can be seen as one step
> towards making the code generic.  So if you really anticipate this being
> enabled for e.g. the ECM class driver, then yes, padding must be
> supported.

1byte padding frame is already supported by usbnet before, isn't it?

>
> I would have had less trouble understanding the value if this patch was
> part of a generalisation series, though...

As my below test on ax99179_178a, I believe the patch should fix padding
for dma sg, but need a little update, and I will send out v1 later:

           $ping -s 974 another_machine  #from host with ax99179_178a attached

If FLAG_SEND_ZLP is set for ax99179_178a, the above ping won't work any
more either on USB3.0 or USB 2.0 host controller.

So don't assume that these brand new devices can support ZLP well.

>
>> As any kind of device may be connected to XHCI, the sg
>> code is relevant for every driver. And I certainly don't want trouble
>> for older devices' drivers converted to sg.
>
> I wonder what the gain of that really is?  Yes, I can see the advantage
> of making the class drivers more effective.  But padding is only
> relevant for the ECM class, isn't it? And are there any ECM class
> devices where SG support matters?

Why is padding only relevant for the ECM? Of course, other devices
need it too, such as asix devices.

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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux