1. 05 Jan, 2006 11 commits
    • Kumar Gala's avatar
      [PATCH] Allow overlapping resources for platform devices · d960bb4d
      Kumar Gala authored
      There are cases in which a device's memory mapped registers overlap
      with another device's memory mapped registers.  On several PowerPC
      devices this occurs for the MDIO bus, whose registers tended to overlap
      with one of the ethernet controllers.
      
      By switching from request_resource to insert_resource we can register
      the MDIO bus as a proper platform device and not hack around how we
      handle its memory mapped registers.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      d960bb4d
    • Frank Pavlic's avatar
      [PATCH] klist: Fix broken kref counting in find functions · e22dafbc
      Frank Pavlic authored
      The klist reference counting in the find functions that use
      klist_iter_init_node is broken.  If the function (for example
      driver_find_device) is called with a NULL start object then everything is
      fine, the first call to next_device()/klist_next increases the ref-count of
      the first node on the list and does nothing for the start object which is
      NULL.
      
      If they are called with a valid start object then klist_next will decrement
      the ref-count for the start object but nobody has incremented it.  Logical
      place to fix this would be klist_iter_init_node because the function puts a
      reference of the object into the klist_iter struct.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarFrank Pavlic <pavlic@de.ibm.com>
      Cc: Patrick Mochel <mochel@digitalimplant.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e22dafbc
    • Alan Stern's avatar
      [PATCH] Hold the device's parent's lock during probe and remove · bf74ad5b
      Alan Stern authored
      This patch (as604) makes the driver core hold a device's parent's lock
      as well as the device's lock during calls to the probe and remove
      methods in a driver.  This facility is needed by USB device drivers,
      owing to the peculiar way USB devices work:
      
      	A device provides multiple interfaces, and drivers are bound
      	to interfaces rather than to devices;
      
      	Nevertheless a reset, reset-configuration, suspend, or resume
      	affects the entire device and requires the caller to hold the
      	lock for the device, not just a lock for one of the interfaces.
      
      Since a USB driver's probe method is always called with the interface
      lock held, the locking order rules (always lock parent before child)
      prevent these methods from acquiring the device lock.  The solution
      provided here is to call all probe and remove methods, for all devices
      (not just USB), with the parent lock already acquired.
      
      Although currently only the USB subsystem requires these changes, people
      have mentioned in prior discussion that the overhead of acquiring an
      extra semaphore in all the prove/remove sequences is not overly large.
      
      Up to now, the USB core has been using its own set of private
      semaphores.  A followup patch will remove them, relying entirely on the
      device semaphores provided by the driver core.
      
      The code paths affected by this patch are:
      
      	device_add and device_del: The USB core already holds the parent
      	lock, so no actual change is needed.
      
      	driver_register and driver_unregister: The driver core will now
      	lock both the parent and the device before probing or removing.
      
      	driver_bind and driver_unbind (in sysfs): These routines will
      	now lock both the parent and the device before binding or
      	unbinding.
      
      	bus_rescan_devices: The helper routine will lock the parent
      	before probing a device.
      
      I have not tested this patch for conflicts with other subsystems.  As
      far as I can see, the only possibility of conflict would lie in the
      bus_rescan_devices pathway, and it seems pretty remote.  Nevertheless,
      it would be good for this to get a lot of testing in -mm.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      bf74ad5b
    • Paul Jackson's avatar
      [PATCH] driver kill hotplug word from sn and others fix · 6d20b035
      Paul Jackson authored
      The first of these changes s/hotplug/uevent/ was needed to
      compile sn2_defconfig (ia64/sn).  The other three files
      changed are blind changes of all remaining bus_type.hotplug
      references I could find to bus_type.uevent.
      
      This patch attempts to finish similar changes made in the
      gregkh-driver-kill-hotplug-word-from-driver-core Nov 22 patch.
      Signed-off-by: default avatarPaul Jackson <pj@sgi.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      6d20b035
    • Greg Kroah-Hartman's avatar
      [PATCH] HOTPLUG: always enable the .config option, unless EMBEDDED · 712f47ce
      Greg Kroah-Hartman authored
      With modules, dynamic /dev, and uevents, people really want
      CONFIG_HOTPLUG to be enabled in their kernels.  If not, they can still
      disable it, but it is discouraged.
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      712f47ce
    • Kay Sievers's avatar
      [PATCH] driver core: replace "hotplug" by "uevent" · 312c004d
      Kay Sievers authored
      Leave the overloaded "hotplug" word to susbsystems which are handling
      real devices. The driver core does not "plug" anything, it just exports
      the state to userspace and generates events.
      Signed-off-by: default avatarKay Sievers <kay.sievers@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      312c004d
    • Kay Sievers's avatar
      [PATCH] merge kobject_uevent and kobject_hotplug · 5f123fbd
      Kay Sievers authored
      The distinction between hotplug and uevent does not make sense these
      days, netlink events are the default.
      
      udev depends entirely on netlink uevents. Only during early boot and
      in initramfs, /sbin/hotplug is needed. So merge the two functions and
      provide only one interface without all the options.
      
      The netlink layer got a nice generic interface with named slots
      recently, which is probably a better facility to plug events for
      subsystem specific events.
      Also the new poll() interface to /proc/mounts is a nicer way to
      notify about changes than sending events through the core.
      The uevents should only be used for driver core related requests to
      userspace now.
      Signed-off-by: default avatarKay Sievers <kay.sievers@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      5f123fbd
    • Kay Sievers's avatar
      [PATCH] remove mount/umount uevents from superblock handling · 033b96fd
      Kay Sievers authored
      The names of these events have been confusing from the beginning
      on, as they have been more like claim/release events. We needed these
      events for noticing HAL if storage devices have been mounted.
      
      Thanks to Al, we have the proper solution now and can poll()
      /proc/mounts instead to get notfied about mount tree changes.
      Signed-off-by: default avatarKay Sievers <kay.sievers@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      033b96fd
    • Kay Sievers's avatar
      [PATCH] add uevent_helper control in /sys/kernel/ · 0f76e5ac
      Kay Sievers authored
      This deprecates the /proc/sys/kernel/hotplug file, as all
      this stuff should be in /sys some day, right? :)
      In /sys/kernel/ we have now uevent_seqnum and uevent_helper.
      The seqnum is no longer used by udev, as the version for this
      kernel depends on netlink which events will never get
      out-of-order.
      
      Recent udev versions disable the /sbin/hotplug helper with
      an init script, cause it leads to OOM on big boxes by running
      hundreds of shells in parallel. It should be done now by:
        echo "" > /sys/kernel/uevent_helper
      
      (Note that "-n" does not work, cause neighter proc nor sysfs
      support truncate().)
      Signed-off-by: default avatarKay Sievers <kay.sievers@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0f76e5ac
    • Kay Sievers's avatar
      [PATCH] remove CONFIG_KOBJECT_UEVENT option · 0296b228
      Kay Sievers authored
      It makes zero sense to have hotplug, but not the netlink
      events enabled today. Remove this option and merge the
      kobject_uevent.h header into the kobject.h header file.
      Signed-off-by: default avatarKay Sievers <kay.sievers@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0296b228
    • Kay Sievers's avatar
      [PATCH] keep pnpbios usermod_helper away from hotplug_path[] · 03438211
      Kay Sievers authored
      These days we use udev to manage all kernel events. /proc/sys/kernel/hotplug
      will usually be disabled by an init-script. pnpnbios is not integrated with
      the driver core and should stay away from the now disabled /sbin/hotplug.
      
      Set the helper to /sbin/phpbios, even when there is probably no current
      user of this faciliy. If it's needed, it should definitely get proper driver
      core integration instead of forking binaries from the kernel.
      Signed-off-by: default avatarKay Sievers <kay.sievers@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      03438211
  2. 03 Jan, 2006 2 commits
  3. 02 Jan, 2006 2 commits
    • Dag-Erling Smrgrav's avatar
      [PATCH] Avoid namespace pollution in <asm/param.h> · abe842eb
      Dag-Erling Smrgrav authored
      In commit 3D59121003721a8fad11ee72e646fd9d3076b5679c, the x86 and x86-64
      <asm/param.h> was changed to include <linux/config.h> for the
      configurable timer frequency.
      
      However, asm/param.h is sometimes used in userland (it is included
      indirectly from <sys/param.h>), so your commit pollutes the userland
      namespace with tons of CONFIG_FOO macros.  This greatly confuses
      software packages (such as BusyBox) which use CONFIG_FOO macros
      themselves to control the inclusion of optional features.
      
      After a short exchange, Christoph approved this patch
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      abe842eb
    • Benjamin Herrenschmidt's avatar
      [PATCH] powerpc: more g5 overtemp problem fix · f12f4d90
      Benjamin Herrenschmidt authored
      Some G5s still occasionally experience shutdowns due to overtemp
      conditions despite the recent fix. After analyzing logs from such
      machines, it appears that the overtemp code is a bit too quick at
      shutting the machine down when reaching the critical temperature (tmax +
      8) and doesn't leave the fan enough time to actually cool it down. This
      happens if the temperature of a CPU suddenly rises too high in a very
      short period of time, or occasionally on boot (that is the CPUs are
      already overtemp by the time the driver loads).
      
      This patches makes the code a bit more relaxed, leaving a few seconds to
      the fans to do their job before kicking the machine shutown.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f12f4d90
  4. 01 Jan, 2006 2 commits
  5. 31 Dec, 2005 3 commits
    • Linus Torvalds's avatar
      35f349ee
    • Yi Yang's avatar
      [PATCH] Fix false old value return of sysctl · 82c9df82
      Yi Yang authored
      For the sysctl syscall, if the user wants to get the old value of a
      sysctl entry and set a new value for it in the same syscall, the old
      value is always overwritten by the new value if the sysctl entry is of
      string type and if the user sets its strategy to sysctl_string.  This
      issue lies in the strategy being run twice if the strategy is set to
      sysctl_string, the general strategy sysctl_string always returns 0 if
      success.
      
      Such strategy routines as sysctl_jiffies and sysctl_jiffies_ms return 1
      because they do read and write for the sysctl entry.
      
      The strategy routine sysctl_string return 0 although it actually read
      and write the sysctl entry.
      
      According to my analysis, if a strategy routine do read and write, it
      should return 1, if it just does some necessary check but not read and
      write, it should return 0, for example sysctl_intvec.
      Signed-off-by: default avatarYi Yang <yang.y.yi@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      82c9df82
    • Linus Torvalds's avatar
      sysctl: don't overflow the user-supplied buffer with '\0' · 8febdd85
      Linus Torvalds authored
      If the string was too long to fit in the user-supplied buffer,
      the sysctl layer would zero-terminate it by writing past the
      end of the buffer. Don't do that.
      
      Noticed by Yi Yang <yang.y.yi@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8febdd85
  6. 30 Dec, 2005 5 commits
  7. 29 Dec, 2005 14 commits
  8. 28 Dec, 2005 1 commit