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-next>] [day] [month] [year] [list]
Date:	Tue, 11 May 2010 22:10:58 -0700
From:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
To:	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	Clemens Ladisch <clemens@...isch.de>,
	Tejun Heo <tj@...nel.org>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Joe Perches <joe@...ches.com>
Cc:	linux-usb@...r.kernel.org, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org
Subject: Use of start_frame in usbusx2yaudio.c

Are there any drivers in the kernel that set urb->start_frame on every
URB?

Could those drivers handle it if only the first URB they submitted to
the host controller was scheduled for that frame ID, and all the rest of
the URBs were scheduled ASAP?

I see there are three drivers that set start_frame (while not setting
URB_ISO_ASAP):
 - drivers/isdn/hisax/st5481_d.c
 - drivers/usb/core/devio.c
 - sound/usb/usx2y/usbusx2yaudio.c

I'm not really sure what usbusx2yaudio.c is doing.  I think when one URB
completes, it sets the next URB's start_frame to the previous URB's
start_frame plus the number of URBs (2 by default) times the number of
packets (4 by default).  Isn't this basically like setting URB_ISO_ASAP?
I really can't tell what fall back method is if this submission fails.

What is usbusx2yaudio.c attempting to do?  I've tried to get an overall
picture of what it expects the isochronous scheduling to look like, but
I'm finding the driver a bit hard to read.

I'm not too worried about the other two drivers.  The code in st5481_d.c
seems to fall back fine to URB_ISO_ASAP if the submission with the
start_frame set failed.  devio.c is usbfs, and I can't tell what
userspace drivers do. (It could be argued that if they needed such tight
control over isoc, they should have written a kernel driver.)

Sarah Sharp
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ