aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/base/dd.c
Commit message (Collapse)AuthorAge
* Driver core: Add BUS_NOTIFY_BIND_DRIVERMagnus Damm2010-08-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add BUS_NOTIFY_BIND_DRIVER as a bus notifier event. For driver binding/unbinding we with this in place have the following bus notifier events: - BUS_NOTIFY_BIND_DRIVER - before ->probe() - BUS_NOTIFY_BOUND_DRIVER - after ->probe() - BUS_NOTIFY_UNBIND_DRIVER - before ->remove() - BUS_NOTIFY_UNBOUND_DRIVER - after ->remove() The event BUS_NOTIFY_BIND_DRIVER allows bus code to be notified that ->probe() is about to be called. Useful for bus code that needs to setup hardware before the driver gets to run. With this in place platform drivers can be loaded and unloaded as modules and the new BIND event allows bus code to control for instance device clocks that must be enabled before the driver can be executed. Without this patch there is no way for the bus code to get notified that a modular driver is about to be probed. Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver-core: fix potential race condition in drivers/base/dd.cStefani Seibold2010-05-21
| | | | | | | | | | | | | | | This patch fix a potential race condition in the driver_bound() function in the file driver/base/dd.c. The broadcast of the BUS_NOTIFY_BOUND_DRIVER notifier should be done after adding the new device to the driver list. Otherwise notifier listener will fail if they use functions like usb_find_interface(). The patch is against kernel 2.6.33. Please merge it. Signed-off-by: Stefani Seibold <stefani@seibold.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Driver core: create lock/unlock functions for struct deviceGreg Kroah-Hartman2010-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the future, we are going to be changing the lock type for struct device (once we get the lockdep infrastructure properly worked out) To make that changeover easier, and to possibly burry the lock in a different part of struct device, let's create some functions to lock and unlock a device so that no out-of-core code needs to be changed in the future. This patch creates the device_lock/unlock/trylock() functions, and converts all in-tree users to them. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jean Delvare <khali@linux-fr.org> Cc: Dave Young <hidave.darkstar@gmail.com> Cc: Ming Lei <tom.leiming@gmail.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Phil Carmody <ext-phil.2.carmody@nokia.com> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Pavel Machek <pavel@ucw.cz> Cc: Len Brown <len.brown@intel.com> Cc: Magnus Damm <damm@igel.co.jp> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Randy Dunlap <randy.dunlap@oracle.com> Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Vegard Nossum <vegard.nossum@gmail.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Alex Chiang <achiang@hp.com> Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andrew Patterson <andrew.patterson@hp.com> Cc: Yu Zhao <yu.zhao@intel.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Wolfram Sang <w.sang@pengutronix.de> Cc: CHENG Renquan <rqcheng@smu.edu.sg> Cc: Oliver Neukum <oliver@neukum.org> Cc: Frans Pop <elendil@planet.nl> Cc: David Vrabel <david.vrabel@csr.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* tree-wide: fix assorted typos all over the placeAndré Goddard Rosa2009-12-04
| | | | | | | | | | That is "success", "unknown", "through", "performance", "[re|un]mapping" , "access", "default", "reasonable", "[con]currently", "temperature" , "channel", "[un]used", "application", "example","hierarchy", "therefore" , "[over|under]flow", "contiguous", "threshold", "enough" and others. Signed-off-by: André Goddard Rosa <andre.goddard@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Driver core: move dev_get/set_drvdata to drivers/base/dd.cGreg Kroah-Hartman2009-09-15
| | | | | | | | | | | | | No one should directly access the driver_data field, so remove the field and make it private. We dynamically create the private field now if it is needed, to handle drivers that call get/set before they are registered with the driver core. Also update the copyright notices on these files while we are there. Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PM: Introduce core framework for run-time PM of I/O devices (rev. 17)Rafael J. Wysocki2009-08-22
| | | | | | | | | | | | | | | Introduce a core framework for run-time power management of I/O devices. Add device run-time PM fields to 'struct dev_pm_info' and device run-time PM callbacks to 'struct dev_pm_ops'. Introduce a run-time PM workqueue and define some device run-time PM helper functions at the core level. Document all these things. Special thanks to Alan Stern for his help with the design and multiple detailed reviews of the pereceding versions of this patch and to Magnus Damm for testing feedback. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Magnus Damm <damm@igel.co.jp>
* Driver core: fix comment for device_attach()Dmitry Torokhov2009-06-16
| | | | | | | | We are looking for matching drivers, not devices. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: add BUS_NOTIFY_UNBOUND_DRIVER eventJoerg Roedel2009-06-16
| | | | | | | | | | | This patch adds a new bus notifier event which is emitted _after_ a device is removed from its driver. This event will be used by the dma-api debug code to check if a driver has released all dma allocations for that device. Signed-off-by: Joerg Roedel <joerg.roedel@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver synchronization: make scsi_wait_scan more advancedArjan van de Ven2009-04-21
| | | | | | | | | | | | | | | | | | | | | | | | | There is currently only one way for userspace to say "wait for my storage device to get ready for the modules I just loaded": to load the scsi_wait_scan module. Expectations of userspace are that once this module is loaded, all the (storage) devices for which the drivers were loaded before the module load are present. Now, there are some issues with the implementation, and the async stuff got caught in the middle of this: The existing code only waits for the scsy async probing to finish, but it did not take into account at all that probing might not have begun yet. (Russell ran into this problem on his computer and the fix works for him) This patch fixes this more thoroughly than the previous "fix", which had some bad side effects (namely, for kernel code that wanted to wait for the scsi scan it would also do an async sync, which would deadlock if you did it from async context already.. there's a report about that on lkml): The patch makes the module first wait for all device driver probes, and then it will wait for the scsi parallel scan to finish. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Tested-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* driver core: move knode_driver into private structureGreg Kroah-Hartman2009-03-24
| | | | | | | | | Nothing outside of the driver core should ever touch knode_driver, so move it out of the public eye. Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: remove polling for driver_probe_done(v5)Ming Lei2009-03-24
| | | | | | | | | | | | | | | | | | This patch removes 100ms polling for driver_probe_done in wait_for_device_probe(), and uses wait_event() instead. Removing polling in fs initialization may lead to a faster boot. This patch also changes the return type of wait_for_device_done() from int to void. This patch is against Arjan's patch in linux-next tree. Signed-off-by: Ming Lei <tom.leiming@gmail.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Reviewed-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: check bus->match without holding device lockMing Lei2009-03-24
| | | | | | | | | | | | | | | | | | | | | | This patch moves bus->match out from driver_probe_device and does not hold device lock to check the match between a device and a driver. The idea has been verified by the commit 6cd495860901, which leads to a faster boot. But the commit 6cd495860901 has the following drawbacks: 1),only does the quick check in the path of __driver_attach->driver_probe_device, not in other paths; 2),for a matched device and driver, check the same match twice. It is a waste of cpu ,especially for some drivers with long device id table (eg. usb-storage driver). This patch adds a helper of driver_match_device to check the match in all paths, and testes the match only once. Signed-off-by: Ming Lei <tom.leiming@gmail.com> Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Consolidate driver_probe_done() loops into one placeArjan van de Ven2009-02-21
| | | | | | | | | | | | there's a few places that currently loop over driver_probe_done(), and I'm about to add another one. This patch abstracts it into a helper to reduce duplication. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Len Brown <lenb@kernel.org> Acked-by: Greg KH <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Revert "driver core: move knode_driver into private structure"Greg Kroah-Hartman2009-01-09
| | | | | | | | | | | | | This reverts commit 93e746db183b3bdbbda67900f79b5835f9cb388f. Turns out that device_initialize shouldn't fail silently. This series needs to be reworked in order to get into proper shape. Reported-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core:fix duplicate removing driver link in __device_release_driverMing Lei2009-01-06
| | | | | | | | | | | In __device_release_driver(),driver_sysfs_remove() has removed the driver link under device dir in sysfs, but sysfs_remove_link() is called again to do such thing. Remove the duplicate call to sys_remove_link(). Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: move knode_driver into private structureGreg Kroah-Hartman2009-01-06
| | | | | | | | | Nothing outside of the driver core should ever touch knode_driver, so move it out of the public eye. Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: struct device - replace bus_id with dev_name(), dev_set_name()Kay Sievers2009-01-06
| | | | | | Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* device model: Do a quickcheck for driver binding before doing an expensive checkArjan van de Ven2008-10-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a quick check for the driver<->device match before taking the locks and doin gthe expensive checks. Taking the lock hurts in asynchronous boot context where the device lock gets hit; one of the init functions takes the lock and goes to do an expensive hardware init; the other init functions walk the same PCI list and get stuck on the lock as a result. For the common case, we can know there's no chance whatsoever of a match if the device isn't in the drivers ID table... so this patch does that check as a best-effort-avoid-the-lock approach. Bootcharts for before and after can be seen at http://www.fenrus.org/before.svg http://www.fenrus.org/after.svg Note the long time "agp_ali_init" takes in the first graph; my laptop doesn't even have an ALI chip in it! (the bootgraphs look a bit dissimilar, but that's the point, the first one has a bunch of arbitrary delays in it that cause it to look very different) This reduces my kernel boot time by about 20% Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: replace remaining __FUNCTION__ occurrencesHarvey Harrison2008-04-19
| | | | | | | | __FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Driver core: coding style fixesGreg Kroah-Hartman2008-01-25
| | | | | | | Fix up a number of coding style issues in the drivers/base/ directory that have annoyed me over the years. checkpatch.pl is now very happy. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Driver core: fix race in __device_release_driverAlan Stern2008-01-24
| | | | | | | | | | | | | | | | | | This patch (as1013) was suggested by David Woodhouse; it fixes a race in the driver core. If a device is unregistered at the same time as its driver is unloaded, the driver's code pages may be unmapped while the remove method is still running. The calls to get_driver() and put_driver() were intended to prevent this, but they don't work if the driver's module count has already dropped to 0. Instead, the patch keeps the device on the driver's list until after the remove method has returned. This forces the necessary synchronization to occur. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Driver core: clean up debugging messagesGreg Kroah-Hartman2008-01-24
| | | | | | | | | | | | | | | | The driver core debugging messages are a mess. This provides a unified message that makes them actually useful. The format for new kobject debug messages should be: driver/bus/class: 'OBJECT_NAME': FUNCTION_NAME: message.\n Note, the class code is not changed in this patch due to pending patches in my queue that this would conflict with. A later patch will clean them up. Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Driver core: move the static kobject out of struct driverGreg Kroah-Hartman2008-01-24
| | | | | | | | | | This patch removes the kobject, and a few other driver-core-only fields out of struct driver and into the driver core only. Now drivers can be safely create on the stack or statically (like they currently are.) Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: remove fields from struct bus_typeGreg Kroah-Hartman2008-01-24
| | | | | | | | | | | | | | | struct bus_type is static everywhere in the kernel. This moves the kobject in the structure out of it, and a bunch of other private only to the driver core fields are now moved to a private structure. This lets us dynamically create the backing kobject properly and gives us the chance to be able to document to users exactly how to use the struct bus_type as there are no fields they can improperly access. Thanks to Kay for the build fixes on this patch. Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: fix kernel doc of device_release_driverStefan Richter2007-07-11
| | | | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: properly get driver in device_release_driverStefan Richter2007-07-11
| | | | | | Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Driver core: kill unused codeStephen Hemminger2007-06-08
| | | | | | | | | | | | | CC drivers/base/dd.o drivers/base/dd.c:211: warning: =E2=80=98device_probe_drivers=E2=80=99 defi= ned but not used Looks like the following is dead. Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* PCI: remove the broken PCI_MULTITHREAD_PROBE optionAdrian Bunk2007-05-02
| | | | | | | | | | This patch removes the PCI_MULTITHREAD_PROBE option that had already been marked as broken. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: don't fail attaching the device if it cannot be boundCornelia Huck2007-04-27
| | | | | | | | | | | | | | | | 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: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: per-subsystem multithreaded probingCornelia Huck2007-04-27
| | | | | | | | | | | | | | | | Make multithreaded probing work per subsystem instead of per driver. It doesn't make much sense to probe the same device for multiple drivers in parallel (after all, only one driver can bind to the device). Instead, create a probing thread for each device that probes the drivers one after another. Also make the decision to use multi-threaded probe per bus instead of per device and adapt the pci code. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* devres: device resource managementTejun Heo2007-02-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement device resource management, in short, devres. A device driver can allocate arbirary size of devres data which is associated with a release function. On driver detach, release function is invoked on the devres data, then, devres data is freed. devreses are typed by associated release functions. Some devreses are better represented by single instance of the type while others need multiple instances sharing the same release function. Both usages are supported. devreses can be grouped using devres group such that a device driver can easily release acquired resources halfway through initialization or selectively release resources (e.g. resources for port 1 out of 4 ports). This patch adds devres core including documentation and the following managed interfaces. * alloc/free : devm_kzalloc(), devm_kzfree() * IO region : devm_request_region(), devm_release_region() * IRQ : devm_request_irq(), devm_free_irq() * DMA : dmam_alloc_coherent(), dmam_free_coherent(), dmam_declare_coherent_memory(), dmam_pool_create(), dmam_pool_destroy() * PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed() * iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(), devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(), pcim_iomap(), pcim_iounmap() Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
* driver core: Change function call order in device_bind_driver().Cornelia Huck2007-02-07
| | | | | | | | | | | Change function call order in device_bind_driver(). If we create symlinks (which might fail) before adding the device to the list we don't have to clean up afterwards (which we didn't). Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* driver core: Don't stop probing on ->probe errors.Cornelia Huck2007-02-07
| | | | | | | | | | | | Don't stop on the first ->probe error that is not -ENODEV/-ENXIO. There might be a driver registered returning an unresonable return code, and this stops probing completely even though it may make sense to try the next possible driver. At worst, we may end up with an unbound device. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Driver core: fix "driver" symlink timingKay Sievers2006-12-01
| | | | | | | | | | | Create the "driver" link before the child device may be created by the probing logic. This makes it possible for userspace (udev), to determine the driver property of the parent device, at the time the child device is created. Signed-off-by: Kay Sievers <kay.sievers@novell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Driver core: add notification of bus eventsBenjamin Herrenschmidt2006-12-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] drivers: wait for threaded probes between initcall levelsAndrew Morton2006-10-27
| | | | | | | | | | | | | | | | | | The multithreaded-probing code has a problem: after one initcall level (eg, core_initcall) has been processed, we will then start processing the next level (postcore_initcall) while the kernel threads which are handling core_initcall are still executing. This breaks the guarantees which the layered initcalls previously gave us. IOW, we want to be multithreaded _within_ an initcall level, but not between different levels. Fix that up by causing the probing code to wait for all outstanding probes at one level to complete before we start processing the next level. Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* driver core: kmalloc() failure check in driver_probe_deviceAkinobu Mita2006-10-18
| | | | | | | | driver_probe_device() is missing kmalloc() failure check. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Driver core: plug device probe memory leakDuncan Sands2006-10-18
| | | | | | | | Make sure data is freed if the kthread fails to start. Signed-off-by: Duncan Sands <baldrick@free.fr> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Driver core: Fix potential deadlock in driver coreAlan Stern2006-09-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Driver Core: add ability for drivers to do a threaded probeGreg Kroah-Hartman2006-09-26
| | | | | | | | | | | | | | | | | | | | 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 <gregkh@suse.de>
* drivers/base: check errorsAndrew Morton2006-09-26
| | | | | | | | | | | Add lots of return-value checking. <pcornelia.huck@de.ibm.com>: fix bus_rescan_devices()] Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] driver core: safely unbind drivers for devices not on a busAlan Stern2006-04-14
| | | | | | | | | | This patch (as667) changes the __device_release_driver() routine to prevent it from crashing when it runs across a device not on any bus. This seems logical, inasmuch as the corresponding bus_add_device() routine has an explicit check allowing it to accept such devices. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] Add bus_type probe, remove, shutdown methods.Russell King2006-01-13
| | | | | | | | | | | | | | | Add bus_type probe, remove and shutdown methods to replace the corresponding methods in struct device_driver. This matches the way we handle the suspend/resume methods. Since the bus methods override the device_driver methods, warn if a device driver is registered whose methods will not be called. The long-term idea is to remove the device_driver methods entirely. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] Hold the device's parent's lock during probe and removeAlan Stern2006-01-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] Small fixes to driver coreAlan Stern2005-11-24
| | | | | | | | | | | | | | | This patch (as603) makes a few small fixes to the driver core: Change spin_lock_irq for a klist lock to spin_lock; Fix reference count leaks; Minor spelling and formatting changes. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by Patrick Mochel <mochel@digitalimplant.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Driver Core: fis bus rescan devices raceDaniel Ritz2005-09-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bus_rescan_devices_helper() does not hold the dev->sem when it checks for !dev->driver(). device_attach() holds the sem, but calls again device_bind_driver() even when dev->driver is set. What happens is that a first device_attach() call (module insertion time) is on the way binding the device to a driver. Another thread calls bus_rescan_devices(). Now when bus_rescan_devices_helper() checks for dev->driver it is still NULL 'cos the the prior device_attach() is not yet finished. But as soon as the first one releases the dev->sem the second device_attach() tries to rebind the already bound device again. device_bind_driver() does this blindly which leads to a corrupt driver->klist_devices list (the device links itself, the head points to the device). Later a call to device_release_driver() sets dev->driver to NULL and breaks the link it has to itself on knode_driver. Rmmoding the driver later calls driver_detach() which leads to an endless loop 'cos the list head in klist_devices still points to the device. And since dev->driver is NULL it's stuck with the same device forever. Boom. And rmmod hangs. Very easy to reproduce with new-style pcmcia and a 16bit card. Just loop modprobe <pcmcia-modules> ;cardctl eject; rmmod <card driver, pcmcia modules>. Easiest fix is to check if the device is already bound to a driver in device_bind_driver(). This avoids the double binding. Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] klist: fix klist to have the same klist_add semantics as list_headJames Bottomley2005-09-05
| | | | | | | | | | | | | | | | | | at the moment, the list_head semantics are list_add(node, head) whereas current klist semantics are klist_add(head, node) This is bound to cause confusion, and since klist is the newcomer, it should follow the list_head semantics. I also added missing include guards to klist.h Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] driver core: Add the ability to bind drivers to devices from userspaceGreg Kroah-Hartman2005-06-30
| | | | | | | | | | | | | | | This adds a single file, "bind", to the sysfs directory of every driver registered with the driver core. To bind a device to a driver, write the bus id of the device you wish to bind to that specific driver to the "bind" file (remember to not add a trailing \n). If that bus id matches a device on that bus, and it does not currently have a driver bound to it, the probe sequence will be initiated with that driver and device. Note, this requires that the driver itself be willing and able to accept that device (usually through a device id type table). This patch does not make it possible to override the driver's id table. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] driver core: fix error handling in bus_add_deviceHannes Reinecke2005-06-20
| | | | | | | | | The error handling in bus_add_device() and device_attach() is simply non-existing. This patch propagates any error from device_attach to the upper layers to allow for a proper recovery. From: Hannes Reinecke <hare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] driver core: Fix races in driver_detach()Alan Stern2005-06-20
| | | | | | | | | | | | | | | | | | This patch is intended for your "driver" tree. It fixes several subtle races in driver_detach() and device_release_driver() in the driver-model core. The major change is to use klist_remove() rather than klist_del() when taking a device off its driver's list. There's no other way to guarantee that the list pointers will be updated before some other driver binds to the device. For this to work driver_detach() can't use a klist iterator, so the loop over the devices must be written out in full. In addition the patch protects against the possibility that, when a driver and a device are unregistered at the same time, one may be unloaded from memory before the other is finished using it. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-19 22:25:35 -0500