linux-toradex.git/drivers/base, branch v2.6.19-rc1

[PATCH] hot-add-mem x86_64: use CONFIG_MEMORY_HOTPLUG_SPARSE

2006-10-01T07:39:18+00:00

Migate CONFIG_MEMORY_HOTPLUG to CONFIG_MEMORY_HOTPLUG_SPARSE where needed.

Signed-off-by: Keith Mannthey 
Cc: KAMEZAWA Hiroyuki 
Cc: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] kthread: drivers/base/firmware_class.c

2006-09-29T16:18:08+00:00

Replace kernel_thread() call in drivers/base/firmware_class.c with
kthread_create() since kernel_thread() is deprecated in drivers.

Signed-off-by: Sukadev Bhattiprolu 
Cc: Cedric Le Goater 
Cc: Serge E. Hallyn 
Cc: Dave Hansen 
Cc: Manuel Estrada Sainz 
Acked-by: Marcel Holtmann 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Fix parameter names in drivers/base/class.c

2006-09-29T16:18:06+00:00

Change parameter names to match arguments of functions.

Signed-off-by: Rolf Eike Beer 
Cc: Martin Waitz 
Cc: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] x86 microcode: using request_firmware to pull microcode

2006-09-27T15:26:18+00:00

Using request_firmware to pull ucode from userspace, so we don't need the
application 'microcode_ctl' to assist.  We name each ucode file according
to CPU's info as intel-ucode/family-model-stepping.  In this way we could
split ucode file as small one.  This has a lot of advantages such as
selectively update and validate microcode for specific models, better
manage microcode file, easily write tools for administerators and so on.
with the changes, we should put all intel-ucode/xx-xx-xx microcode files
into the firmware dir (I had a tool to split previous big data file into
small one and later we will release new style data file).  The init script
should be changed to just loading the driver without unloading

Signed-off-by: Shaohua Li 
Acked-by: Tigran Aivazian 
Cc: Greg KH 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6

2006-09-26T18:49:46+00:00

* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6: (47 commits)
  Driver core: Don't call put methods while holding a spinlock
  Driver core: Remove unneeded routines from driver core
  Driver core: Fix potential deadlock in driver core
  PCI: enable driver multi-threaded probe
  Driver Core: add ability for drivers to do a threaded probe
  sysfs: add proper sysfs_init() prototype
  drivers/base: check errors
  drivers/base: Platform notify needs to occur before drivers attach to the device
  v4l-dev2: handle __must_check
  add CONFIG_ENABLE_MUST_CHECK
  add __must_check to device management code
  Driver core: fixed add_bind_files() definition
  Driver core: fix comments in drivers/base/power/resume.c
  sysfs_remove_bin_file: no return value, dump_stack on error
  kobject: must_check fixes
  Driver core: add ability for devices to create and remove bin files
  Class: add support for class interfaces for devices
  Driver core: create devices/virtual/ tree
  Driver core: add device_rename function
  Driver core: add ability for classes to handle devices properly
  ...

[PATCH] ZVC: Support NR_SLAB_RECLAIMABLE / NR_SLAB_UNRECLAIMABLE

2006-09-26T15:48:51+00:00

Remove the atomic counter for slab_reclaim_pages and replace the counter
and NR_SLAB with two ZVC counter that account for unreclaimable and
reclaimable slab pages: NR_SLAB_RECLAIMABLE and NR_SLAB_UNRECLAIMABLE.

Change the check in vmscan.c to refer to to NR_SLAB_RECLAIMABLE.  The
intend seems to be to check for slab pages that could be freed.

Signed-off-by: Christoph Lameter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] reduce MAX_NR_ZONES: make display of highmem counters conditional on CONFIG_HIGHMEM

2006-09-26T15:48:46+00:00

Do not display HIGHMEM memory sizes if CONFIG_HIGHMEM is not set.

Make HIGHMEM dependent texts and make display of highmem counters optional

Some texts are depending on CONFIG_HIGHMEM.

Remove those strings and remove the display of highmem counter values if
CONFIG_HIGHMEM is not set.

[akpm@osdl.org: remove some ifdefs]
Signed-off-by: Christoph Lameter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Driver core: Remove unneeded routines from driver core

2006-09-26T04:08:40+00:00

This patch (as783) simplifies the driver core slightly by removing four
unnecessary _get and _put methods.

It is vital that when a driver is removed from its bus's klist of
registered drivers, or when a device is removed from a driver's klist
of bound devices, that the klist updates complete synchronously.
Otherwise the kernel might try binding an unregistered driver to a
newly-registered device, or adding a device to the klist for a new
driver before it has been removed from the old driver's klist.

Since the removals must be synchronous, they don't need to update any
reference counts.  Hence the _get and _put methods can be dispensed
with.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

Driver core: Fix potential deadlock in driver core

2006-09-26T04:08:40+00:00

There is a potential deadlock in the driver core.  It boils down to
the fact that bus_remove_device() calls klist_remove() instead of
klist_del(), thereby waiting until the reference count of the
klist_node in the bus's klist of devices drops to 0.  The refcount
can't reach 0 so long as a modprobe process is trying to bind a new
driver to the device being removed, by calling __driver_attach().  The
problem is that __driver_attach() tries to acquire the device's
parent's semaphore, but the caller of bus_remove_device() is quite
likely to own that semaphore already.

It isn't sufficient just to replace klist_remove() with klist_del().
Doing so runs the risk that the device would remain on the bus's klist
of devices for some time, and so could be bound to another driver even
after it was unregistered.  What's needed is a new way to distinguish
whether or not a device is registered, based on a criterion other than
whether its klist_node is linked into the bus's klist of devices.  That
way driver binding can fail when the device is unregistered, even if
it is still linked into the klist.

This patch (as782) implements the solution, by adding a new bitflag to
indiate when a struct device is registered, by testing the flag before
allowing a driver to bind a device, and by changing the definition of
the device_is_registered() inline.

Signed-off-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman

Driver Core: add ability for drivers to do a threaded probe

2006-09-26T04:08:40+00:00

This adds the infrastructure for drivers to do a threaded probe, and
waits at init time for all currently outstanding probes to complete.

A new kernel thread will be created when the probe() function for the
driver is called, if the multithread_probe bit is set in the driver
saying it can support this kind of operation.

I have tested this with USB and PCI, and it works, and shaves off a lot
of time in the boot process, but there are issues with finding root boot
disks, and some USB drivers assume that this can never happen, so it is
currently not enabled for any bus type.  Individual drivers can enable
this right now if they wish, and bus authors can selectivly turn it on
as well, once they determine that their subsystem will work properly
with it.

Signed-off-by: Greg Kroah-Hartman