dect
/
linux-2.6
Archived
13
0
Fork 0
Commit Graph

5 Commits

Author SHA1 Message Date
Jiri Slaby 4aed0644d6 [PATCH] drivers/base/*: use kzalloc instead of kmalloc+memset
Fixes a bunch of memset bugs too.

Signed-off-by: Lion Vollnhals <webmaster@schiggl.de>
Signed-off-by: Jiri Slaby <xslaby@fi.muni.cz>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-13 08:22:27 -07:00
Abhay Salunke 6e3eaab020 [PATCH] modified firmware_class.c to support no hotplug
Upgrade the request_firmware_nowait function to not start the hotplug
action on a firmware update.

This patch is tested along with dell_rbu driver on i386 and x86-64 systems.

Signed-off-by: Abhay Salunke <Abhay_Salunke@dell.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07 16:57:26 -07:00
Stanislaw W. Gruszka b92eac01c3 [PATCH] request_firmware(): avoid race conditions
Avoid race occurs when some process have open file descriptor for class
device attributes and already firmware allocated memory are freed.  Don't
allow negative loading timeout.

Signed-off-by: Stanislaw W. Gruszka <stf_xl@wp.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-28 21:20:30 -07:00
kay.sievers@vrfy.org 6897089c5f [PATCH] add TIMEOUT to firmware_class hotplug event
On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote:
> The current implementation of the firmware class breaks a fundamental
> assumption in udevd: that the physical device can be initialised fully
> prior to executing the next event for that device.

Here we add a TIMEOUT value to the hotplug environment of the firmware
requesting event. I will adapt udevd not to wait for anything else, if
it finds a TIMEOUT key.

Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-18 21:57:31 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00