netdev - Re: [PATCH] USBNET: fix handling padding packet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87wqmd46vj.fsf@nemi.mork.no>
Date:	Thu, 19 Sep 2013 09:18:08 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	Oliver Neukum <oneukum@...e.de>
Cc:	Ming Lei <ming.lei@...onical.com>,
	"David S. Miller" <davem@...emloft.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Network Development <netdev@...r.kernel.org>,
	linux-usb <linux-usb@...r.kernel.org>
Subject: Re: [PATCH] USBNET: fix handling padding packet

Oliver Neukum <oneukum@...e.de> writes:
> On Wed, 2013-09-18 at 20:56 +0200, Bjørn Mork wrote:
>> Oliver Neukum <oneukum@...e.de> 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.

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.

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

> 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?

Bjørn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html