Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 13 10月, 2007 1 次提交
  3. 12 7月, 2007 3 次提交
    • T
      sysfs: kill unnecessary attribute->owner · 7b595756
      由 Tejun Heo 提交于 
      sysfs is now completely out of driver/module lifetime game.  After
deletion, a sysfs node doesn't access anything outside sysfs proper,
so there's no reason to hold onto the attribute owners.  Note that
often the wrong modules were accounted for as owners leading to
accessing removed modules.

This patch kills now unnecessary attribute->owner.  Note that with
this change, userland holding a sysfs node does not prevent the
backing module from being unloaded.

For more info regarding lifetime rule cleanup, please read the
following message.

  http://article.gmane.org/gmane.linux.kernel/510293

(tweaked by Greg to not delete the field just yet, to make it easier to
merge things properly.)
Signed-off-by: NTejun Heo <htejun@gmail.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7b595756
    • C
      Driver core: coding style cleanup · dc0afa83
      由 Cornelia Huck 提交于 
      This converts code of the form

	if ((error = some_func()))
		goto fixup;
to
	error = some_func();
	if (error)
		goto fixup;
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      dc0afa83
    • K
      Driver core: add missing kset uevent · 80f03e34
      由 Kay Sievers 提交于 
      We get uevents for a bus/class going away, but not one registering.
Add the missing uevent in kset_register(), which will send an
event for a new bus/class. Suppress all unwanted uevents for bus
subdirectories like /bus/*/devices/, /bus/*/drivers/.

Now we get for module usbcore:
  add      /module/usbcore (module)
  add      /bus/usb (bus)
  add      /class/usb_host (class)
  add      /bus/usb/drivers/hub (drivers)
  add      /bus/usb/drivers/usb (drivers)
  remove   /bus/usb/drivers/usb (drivers)
  remove   /bus/usb/drivers/hub (drivers)
  remove   /class/usb_host (class)
  remove   /bus/usb (bus)
  remove   /module/usbcore (module)

instead of:
  add      /module/usbcore (module)
  add      /bus/usb/drivers/hub (drivers)
  add      /bus/usb/drivers/usb (drivers)
  remove   /bus/usb/drivers/usb (drivers)
  remove   /bus/usb/drivers/hub (drivers)
  remove   /class/usb_host (class)
  remove   /bus/usb/drivers (bus)
  remove   /bus/usb/devices (bus)
  remove   /bus/usb (bus)
  remove   /module/usbcore (module)
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      80f03e34
  5. 03 5月, 2007 1 次提交
  7. 28 4月, 2007 4 次提交
    • G
      driver core: bus_add_driver should return an error if no bus · 4f6e1945
      由 Greg Kroah-Hartman 提交于 
      As pointed out by Dave Jones.

Cc: Dave Jones <davej@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4f6e1945
    • G
      Driver core: remove unneeded completion from driver release path · 74e9f5fa
      由 Greg Kroah-Hartman 提交于 
      The completion in the driver release path is due to ancient history in
the _very_ early 2.5 days when we were not tracking the module reference
count of attributes.  It is not needed at all and can be removed.

Note, we now have an empty release function for the driver structure.
This is due to the fact that drivers are statically allocated in the
system at this point in time, something which I want to change in the
future.  But remember, drivers are really code, which is reference
counted by the module, unlike devices, which are data and _must_ be
reference counted properly in order to work correctly.


Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      74e9f5fa
    • C
      driver core: don't fail attaching the device if it cannot be bound · c6a46696
      由 Cornelia Huck 提交于 
      Don't fail bus_attach_device() if the device cannot be bound.

If dev->driver has been specified, reset it to NULL if device_bind_driver()
failed and add the device as an unbound device.  As a result,
bus_attach_device() now cannot fail, and we can remove some checking from
device_add().

Also remove an unneeded check in bus_rescan_devices_helper().
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c6a46696
    • K
      Driver core: udev triggered device-<>driver binding · b8c5cec2
      由 Kay Sievers 提交于 
      We get two per-bus sysfs files:
  ls-l /sys/subsystem/usb
  drwxr-xr-x 2 root root    0 2007-02-16 16:42 devices
  drwxr-xr-x 7 root root    0 2007-02-16 14:55 drivers
  -rw-r--r-- 1 root root 4096 2007-02-16 16:42 drivers_autoprobe
  --w------- 1 root root 4096 2007-02-16 16:42 drivers_probe

The flag "drivers_autoprobe" controls the behavior of the bus to bind
devices by default, or just initialize the device and leave it alone.

The command "drivers_probe" accepts a bus_id and the bus tries to bind a
driver to this device.

Systems who want to control the driver binding with udev, switch off the
bus initiated probing:
  echo 0 > /sys/subsystem/usb/drivers_autoprobe
  echo 0 > /sys/subsystem/pcmcia/drivers_autoprobe
  ...

and initiate the probing with udev rules like:
  ACTION=="add", SUBSYSTEM=="usb", ATTR{subsystem/drivers_probe}="$kernel"
  ACTION=="add", SUBSYSTEM=="pcmcia", ATTR{subsystem/drivers_probe}="$kernel"
  ...

Custom driver binding can happen in earlier rules by something like:
  ACTION=="add", SUBSYSTEM=="usb", \
  ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678" \
  ATTR{subsystem/drivers/<custom-driver>/bind}="$kernel"

This is intended to solve the modprobe.conf mess with "install-rules", custom
bind/unbind-scripts and all the weird things people invented over the years.
It should also provide the functionality "libusual" was supposed to do.

With udev, one can just write a udev rule to drive all USB-disks at the
third port of USB-hub by the "ub" driver, and everything else by
usb-storage. One can also instruct udev to bind different wireless
drivers to identical cards - just selected by the pcmcia slot-number, and
whatever ...

To use the mentioned rules, it needs udev version 106, to be able to
write ATTR{}="$kernel" to sysfs files.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b8c5cec2
  9. 17 2月, 2007 1 次提交
  11. 02 12月, 2006 2 次提交
    • K
      CONFIG_SYSFS_DEPRECATED - bus symlinks · b9cafc7d
      由 Kay Sievers 提交于 
      Turn off the bus symlinks if CONFIG_SYSFS_DEPRECATED is enabled
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b9cafc7d
    • B
      Driver core: add notification of bus events · 116af378
      由 Benjamin Herrenschmidt 提交于 
      I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.

That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.

There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.

The usage I have for these are:

 - The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.

 - The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      116af378
  13. 19 10月, 2006 4 次提交
  15. 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
  17. 13 7月, 2006 1 次提交
  19. 01 7月, 2006 1 次提交
  21. 22 6月, 2006 3 次提交
  23. 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
  25. 15 3月, 2006 1 次提交
  27. 08 2月, 2006 1 次提交
  29. 07 2月, 2006 1 次提交
  31. 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
  33. 24 11月, 2005 1 次提交
  35. 08 9月, 2005 1 次提交
  37. 06 9月, 2005 2 次提交
  39. 18 8月, 2005 1 次提交
  41. 30 6月, 2005 4 次提交