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]
Message-ID: <4F414230.5040506@lwfinger.net>
Date:	Sun, 19 Feb 2012 12:40:48 -0600
From:	Larry Finger <Larry.Finger@...inger.net>
To:	LKML <linux-kernel@...r.kernel.org>,
	driverdevel <devel@...verdev.osuosl.org>,
	wireless <linux-wireless@...r.kernel.org>,
	linux-hotplug@...r.kernel.org
Subject: will these methods work with firmware loading?

I sent a previous messages to most of these lists, but got no answer, thus a 
second try.

When a driver loads firmware synchronously in the module_init() path using 
request_firmware(), then there is trouble with timeouts when booting.

I know that changing the request_firmware() call to request_firmware_nowait() 
solves the problem; however, that gives some trouble for driver b43legacy as it 
loads 3 or 4 firmware files depending on the hardware version. When I launch the 
3 or 4 nowait requests, I get an error because the system is trying to start 
several tasks with the same name.

Would it be OK to load the first file with the nowait version, and issue a 
request_firmware() for the others from the callback routine? I think that would 
not cause any problems, but I would like to get confirmation from an expert.

Similarly, if I were to create a work queue, init and schedule it from 
module_init(), and then use synchronous loads to get the firmware from the work 
queue callback, would that get around the boot problem? I know it works as I 
have trial patches; however, my version of udev is not one affected. This method 
is very easy to implement, but again I would like confirmation from an expert.

Thanks,

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