Re: [PATCH] USBNET: fix handling padding packet

On Thu, Sep 19, 2013 at 3:18 PM, Bjørn Mork [off-list ref] wrote:

Oliver Neukum [off-list ref] writes:

quoted

On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote:

quoted

Oliver Neukum [off-list ref] wrote:

quoted

quoted

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.

quoted

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html