linux-kernel - Re: [RFC] usb: dwc2: hcd: fix split schedule issue

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]

Date:	Fri, 13 Nov 2015 16:33:50 -0800
From:	Doug Anderson <dianders@...omium.org>
To:	John Youn <John.Youn@...opsys.com>
Cc:	Yunzhi Li <lyz@...k-chips.com>, Julius Werner <jwerner@...gle.com>,
	Dinh Nguyen <dinguyen@...nsource.altera.com>,
	"Kaukab, Yousaf" <yousaf.kaukab@...el.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	wulf <wulf@...k-chips.com>,
	Kever Yang <kever.yang@...k-chips.com>,
	caesar <caesar.wang@...k-chips.com>,
	Tao Huang <huangtao@...k-chips.com>,
	rockchip-discuss <rockchip-discuss@...omium.org>
Subject: Re: [RFC] usb: dwc2: hcd: fix split schedule issue

John,

On Thu, Nov 12, 2015 at 9:05 PM, John Youn <John.Youn@...opsys.com> wrote:
> It seems to be an issue with single TT hubs. I've tried several
> multi-TT hubs with no issues.

Agreed.


> With a single TT hub I do see a problem though not the exact one
> described. I see corrupted and dropped packets on the FS side of
> the hub. In a microframe with SSPLIT.begin, taking up the max
> bandwidth for the microframe, when another SSPLIT for a different
> device is issued, the data gets corrupted on the other side of
> the TT. Probably due to exceeding the bandwidth in the microframe
> since a single TT hub's ports all share the bandwidth.

Seems like different single TT hubs react differently.  I got one
where the mouse kept working but the audio was just static...


> With this fix, the next SSPLIT goes out in the same microframe as
> the SSPLIT.end and the data goes through fine.
>
> However I don't think this will work as a general fix. Since it
> is just skipping things without rescheduling. For example SSPLIT
> now happens a microframe later but the CSPLIT is not adjusted so
> it comes a microframe too early.
>
> I think the correct fix is to create a proper schedule based on
> all the active endpoints to make sure we don't go over the
> bandwidth for a single TT hub. Or to make the adjustments earlier
> like in dwc2_sched_periodic_split().

I've started working on this and just before I needed to leave my desk
I got something that seemed to work.  I'll keep at it on Monday.

At the moment I'm making the assumption that we never got a multi_tt
hub attached to us.  My code will always just schedule one split per
microframe.  Would that be OK for now until we make the scheduler
better?

To handle things smarter, I think I need to research how to deal with
hubs attached to hubs attached to hubs.  For instance:

dwc2
-> multi_tt hub
    -> single_tt hub
        -> device 1
        -> device 2
    -> single_tt hub
        -> device 3
        -> device 4
vs.

dwc2
-> single_tt hub
    -> multi_tt hub
        -> device 1
        -> device 2
    -> multi_tt hub
        -> device 3
        -> device 4

In the first case I presume I could schedule device 1 and device 3 at
the same time, but not device 2 and device 4.  In the 2nd case I
presume I could schedule all 4 devices independently.  ...but I
haven't dug through the spec to confirm that, yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/