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
