Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 19 10月, 2006 1 次提交
  3. 26 9月, 2006 4 次提交
    • A
      Driver core: Remove unneeded routines from driver core · 81107bf5
      由 Alan Stern 提交于 
      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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      81107bf5
    • A
      Driver core: Fix potential deadlock in driver core · f2eaae19
      由 Alan Stern 提交于 
      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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f2eaae19
    • A
      drivers/base: check errors · f86db396
      由 Andrew Morton 提交于 
      Add lots of return-value checking.

<pcornelia.huck@de.ibm.com>: fix bus_rescan_devices()]
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      f86db396
    • Y
      Driver core: fixed add_bind_files() definition · 35acfdd7
      由 Yoichi Yuasa 提交于 
      When CONFIG_HOTPLUG is n, add_bind_files() definition is wrong.
This patch has fixed it.
Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      35acfdd7
  5. 13 7月, 2006 1 次提交
  7. 01 7月, 2006 1 次提交
  9. 22 6月, 2006 3 次提交
  11. 15 4月, 2006 1 次提交
    • R
      [PATCH] driver core: driver_bind attribute returns incorrect value · 37225401
      由 Ryan Wilson 提交于 
      The manual driver <-> device binding attribute in sysfs doesn't return
the correct value on failure or success of driver_probe_device.
driver_probe_device returns 1 on success (the driver accepted the
device) or 0 on probe failure (when the driver didn't accept the
device but no real error occured). However, the attribute can't just
return 0 or 1, it must return the number of bytes consumed from buf
or an error value. Returning 0 indicates to userspace that nothing
was written (even though the kernel has tried to do the bind/probe and
failed). Returning 1 indicates that only one character was accepted in
which case userspace will re-try the write with a partial string.

A more correct version of driver_bind would return count (to indicate
the entire string was consumed) when driver_probe_device returns 1
and -ENODEV when driver_probe_device returns 0. This patch makes that
change.
Signed-off-by: NRyan Wilson <hap9@epoch.ncsc.mil>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      37225401
  13. 15 3月, 2006 1 次提交
  15. 08 2月, 2006 1 次提交
  17. 07 2月, 2006 1 次提交
  19. 05 1月, 2006 2 次提交
    • G
      [PATCH] Driver core: only all userspace bind/unbind if CONFIG_HOTPLUG is enabled · 874c6241
      由 Greg Kroah-Hartman 提交于 
      Thanks to drivers making their id tables __devinit, we can't allow
userspace to bind or unbind drivers from devices manually through sysfs.
So we only allow this if CONFIG_HOTPLUG is enabled.

Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      874c6241
    • A
      [PATCH] Hold the device's parent's lock during probe and remove · bf74ad5b
      由 Alan Stern 提交于 
      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: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bf74ad5b
  21. 24 11月, 2005 1 次提交
  23. 08 9月, 2005 1 次提交
  25. 06 9月, 2005 2 次提交
  27. 18 8月, 2005 1 次提交
  29. 30 6月, 2005 4 次提交
  31. 23 6月, 2005 1 次提交
  33. 21 6月, 2005 7 次提交
  35. 18 5月, 2005 1 次提交
    • D
      [PATCH] Driver Core: remove driver model detach_state · 0b405a0f
      由 David Brownell 提交于 
      The driver model has a "detach_state" mechanism that:

 - Has never been used by any in-kernel drive;
 - Is superfluous, since driver remove() methods can do the same thing;
 - Became buggy when the suspend() parameter changed semantics and type;
 - Could self-deadlock when called from certain suspend contexts;
 - Is effectively wasted documentation, object code, and headspace.

This removes that "detach_state" mechanism; net code shrink, as well
as a per-device saving in the driver model and sysfs.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0b405a0f
  37. 05 5月, 2005 1 次提交
    • R
      [PATCH] drivers/base/bus.c: fix iteration in driver_detach() · b2d84f07
      由 Roman Kagan 提交于 
      With 2.6.11 and 2.6.12-rc2 (and perhaps a few versions before) usb
drivers for multi-interface devices, which do
usb_driver_release_interface() in their disconnect(), make rmmod hang.

It turns out to be due to a bug in drivers/base/bus.c:driver_detach(),
that iterates over the list of attached devices with
list_for_each_safe() under an assumption that device_release_driver()
only releases the current device, while it may also call
device_release_driver() for other devices on the same list.

The following patch fixes it.  Please consider applying.
Signed-off-by: NRoman Kagan <rkagan@mail.ru>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b2d84f07
  39. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      由 Linus Torvalds 提交于 
      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!
      1da177e4