From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH]snd-usb-usx2y 0.8.1 against alsa-kernel cvshead: OHCI doesn't crash anymore Date: Wed, 20 Oct 2004 11:35:36 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <200409302046.29798.annabellesgarden@yahoo.de> <200410181406.43903.annabellesgarden@yahoo.de> <200410200228.16228.annabellesgarden@yahoo.de> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <200410200228.16228.annabellesgarden@yahoo.de> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Karsten Wiese Cc: alsa-devel@lists.sourceforge.net, Rui Nuno Capela List-Id: alsa-devel@alsa-project.org At Wed, 20 Oct 2004 02:28:15 +0200, Karsten Wiese wrote: > > Am Dienstag 19 Oktober 2004 15:33 schrieb Takashi Iwai: > > > > I'm afraid it's still racy. > > In usX2Y_urbs_start(), the complete callback may be called between > > usb_submit_urb() and the loop of schedule_timeout(). > > So, the loop should check at first the condition before sleeping like > > below: > > > > while (atomic_read(&subs->state) != state_PREPARED) { > > timeout = schedule_timeout(timeout); > > if (signal_pending(current)) > > ... > > if (! timeout) > > ... > > } > > > ok, thanks! > But there is still a small race window between > while (atomic_read(&subs->state) != state_PREPARED) { > and /* right here the complete callback may be called */ > timeout = schedule_timeout(timeout); > no? Oh yes, sure. > Is there a trick to avoid even this small race window? As I wrote before, use spinlock around it or completion. The latter might be easier although it's UNINTERRUPTIBLE only. > > Regarding the new config stuff: > > Let's kill CONFIG_SND_USB_USX2Y_NRPACKS_VARIABLE option. > > No one will want to disable such a module option. > > > Well, me wants to disable it as it works best with nrpacks=1 here and I'd like > the machine code to not contain the unneeded loops then... > (gcc optimizes those loops away if it reads "#define nrpacks 1") > Can I keep some (commented out?) define switch inside the source (invisible to > KConfig) to suit my needs? Then it's ok. Having a new stuff in Kconfig would make it difficult to build for older systems. > > Also, please avoid the Kconfig int value as much as possible if you > > want to support the driver for 2.2/2.4 kernels, too. I believe it's > > ok to put a hardcoded value 4 like usbaudio.c if you describe the > > module option properly in the document. > > > Erm, which document? Create a new one for your driver ;) > And I'm not too keen to do the driver (sup/back)port for 2.2/2.4 kernels > myself. I'll avoid the Kconfig int value, making it simpler for volunteers. Ok, thanks. Takashi ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl