Commit Graph

10 Commits

Author SHA1 Message Date
Greg Kroah-Hartman 1740757e8f [PATCH] Driver Core: remove unused exports
Cc: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-21 12:40:48 -07:00
Ben Dooks a1bdc7aad8 [PATCH] drivers/base - fix sparse warnings
There are a number of sparse warnings from the latest sparse
snapshot being generated from the drivers/base build. The
main culprits are due to the initialisation functions not
being declared in a header file.

Also, the firmware.c file should include <linux/device.h>
to get the prototype of  firmware_register() and
firmware_unregister().

This patch moves the init function declerations from the
init.c file to the base.h, and ensures it is included in
all the relevant c sources. It also adds <linux/device.h>
to the included headers for firmware.c.

The patch does not solve all the sparse errors generated,
but reduces the count significantly.

drivers/base/core.c:161:1: warning: symbol 'devices_subsys' was not declared. Should it be static?
drivers/base/core.c:417:12: warning: symbol 'devices_init' was not declared. Should it be static?
drivers/base/sys.c:253:6: warning: symbol 'sysdev_shutdown' was not declared. Should it be static?
drivers/base/sys.c:326:5: warning: symbol 'sysdev_suspend' was not declared. Should it be static?
drivers/base/sys.c:428:5: warning: symbol 'sysdev_resume' was not declared. Should it be static?
drivers/base/sys.c:450:12: warning: symbol 'system_bus_init' was not declared. Should it be static?
drivers/base/bus.c:133:1: warning: symbol 'bus_subsys' was not declared. Should it be static?
drivers/base/bus.c:667:12: warning: symbol 'buses_init' was not declared. Should it be static?
drivers/base/class.c:759:12: warning: symbol 'classes_init' was not declared. Should it be static?
drivers/base/platform.c:313:12: warning: symbol 'platform_bus_init' was not declared. Should it be static?
drivers/base/cpu.c:110:12: warning: symbol 'cpu_dev_init' was not declared. Should it be static?
drivers/base/firmware.c:17:5: warning: symbol 'firmware_register' was not declared. Should it be static?
drivers/base/firmware.c:23:6: warning: symbol 'firmware_unregister' was not declared. Should it be static?
drivers/base/firmware.c:28:12: warning: symbol 'firmware_init' was not declared. Should it be static?
drivers/base/init.c:28:13: warning: symbol 'driver_init' was not declared. Should it be static?
drivers/base/dmapool.c:174:10: warning: implicit cast from nocast type
drivers/base/attribute_container.c:439:1: warning: symbol 'attribute_container_init' was not declared. Should it be static?
drivers/base/power/runtime.c:76:6: warning: symbol 'dpm_set_power_state' was not declared. Should it be static?

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-28 09:52:55 -07:00
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
Linus Torvalds caf39e87cc [SCSI] Re-do "final klist fixes"
With the previous commit that introduces the klist enhancements, we can
now re-do 2b7d6a8cb9 again.
2005-09-07 18:44:33 -07:00
Linus Torvalds df4edad178 [SCSI] Revert "final klist fixes"
Revert commit 2b7d6a8cb9.

The "fix" was known to not even compile.  Duh.  That's not a fix.
That's just stupid.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-07 17:50:58 -07:00
James Bottomley 2b7d6a8cb9 [SCSI] attribute container final klist fixes
Since the attribute container deletes from a klist while it's walking
it, it is vulnerable to the problem (and fix) here:

http://marc.theaimsgroup.com/?l=linux-scsi&m=112485448830217

The attached fixes this (but won't compile without the above).

It also fixes the logical reversal in the traversal loop which meant
that we were never actually traversing the loop to hit this bug in the
first place.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-30 22:44:32 -05:00
James Bottomley 53c165e0a6 [SCSI] correct attribute_container list usage
One of the changes in the attribute_container code in the scsi-misc tree
was to add a lock to protect the list of devices per container.  This,
unfortunately, leads to potential scheduling while atomic problems if
there's a sleep in the function called by a trigger.

The correct solution is to use the kernel klist infrastructure instead
which allows lockless traversal of a list.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-30 22:44:20 -05:00
James Bottomley ebd8bb7647 [SCSI] fix transport class corner case after rework
If your transport class sets the ATTRIBUTE_CONTAINER_NO_CLASSDEVS flag,
then its configure method never gets called.  This patch fixes that so
that the configure method is called with a NULL classdev.

Also remove a spurious inverted comma in the transport_class comments.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-28 11:14:06 -05:00
James Bottomley d0a7e57400 [SCSI] correct transport class abstraction to work outside SCSI
I recently tried to construct a totally generic transport class and
found there were certain features missing from the current abstract
transport class.  Most notable is that you have to hang the data on the
class_device but most of the API is framed in terms of the generic
device, not the class_device.

These changes are two fold

- Provide the class_device to all of the setup and configure APIs
- Provide and extra API to take the device and the attribute class and
  return the corresponding class_device

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
2005-08-14 17:21:27 -05: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