summaryrefslogtreecommitdiffstats
path: root/drivers/base/dd.c
Commit message (Collapse)AuthorAgeFilesLines
* driver core: move knode_driver into private structureGreg Kroah-Hartman2009-03-241-5/+8
| | | | | | | | | 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-241-6/+2
| | | | | | | | | | | | | | | | | | 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-241-12/+7
| | | | | | | | | | | | | | | | | | | | | | 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-211-0/+17
| | | | | | | | | | | | 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-091-8/+5
| | | | | | | | | | | | | 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-061-1/+0
| | | | | | | | | | | 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-061-5/+8
| | | | | | | | | 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-061-6/+6
| | | | | | 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-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-191-7/+7
| | | | | | | | __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-241-61/+58
| | | | | | | 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-241-3/+2
| | | | | | | | | | | | | | | | | | 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-241-8/+8
| | | | | | | | | | | | | | | | 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-241-12/+12
| | | | | | | | | | 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-241-2/+2
| | | | | | | | | | | | | | | 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-111-9/+9
| | | | | | 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-111-2/+1
| | | | | | 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-081-13/+0
| | | | | | | | | | | | | 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-021-38/+3
| | | | | | | | | | 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-271-1/+5
| | | | | | | | | | | | | | | | 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-271-31/+31
| | | | | | | | | | | | | | | | 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-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-071-2/+6
| | | | | | | | | | | 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-071-7/+6
| | | | | | | | | | | | 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-011-30/+52
| | | | | | | | | | | 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-011-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-271-0/+30
| | | | | | | | | | | | | | | | | | 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-181-0/+2
| | | | | | | | 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-181-1/+1
| | | | | | | | 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-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-251-27/+81
| | | | | | | | | | | | | | | | | | | | 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-251-10/+27
| | | | | | | | | | | 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-141-1/+1
| | | | | | | | | | 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-131-2/+10
| | | | | | | | | | | | | | | 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-041-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-231-5/+3
| | | | | | | | | | | | | | | 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-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-051-1/+1
| | | | | | | | | | | | | | | | | | 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-291-1/+1
| | | | | | | | | | | | | | | 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-201-1/+2
| | | | | | | | | 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-201-13/+38
| | | | | | | | | | | | | | | | | | 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>
* [PATCH] Driver Core: fix bk-driver-core kills ppc64Patrick Mochel2005-06-201-68/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no check to see if the device is already bound to a driver, which could do bad things. The first thing to go wrong is that it will try to match a driver with a device already bound to one. In some cases (it appears with USB with drivers/usb/core/usb.c::usb_match_id()), some drivers will match a device based on the class type, so it would be common (especially for HID devices) to match a device that is already bound. The fun comes when ->probe() is called, it fails, then driver_probe_device() does this: dev->driver = NULL; Later on, that pointer could be be dereferenced without checking and cause hell to break loose. This problem could be nasty. It's very hardware dependent, since some devices could have a different set of matching qualifiers than others. Now, I don't quite see exactly where/how you were getting that crash. You're dereferencing bad memory, but I'm not sure which pointer was bad and where it came from, but it could have come from a couple of different places. The patch below will hopefully fix it all up for you. It's against 2.6.12-rc2-mm1, and does the following: - Move logic to driver_probe_device() and comments uncommon returns: 1 - If device is bound 0 - If device not bound, and no error error - If there was an error. - Move locking to caller of that function, since we want to lock a device for the entire time we're trying to bind it to a driver (to prevent against a driver being loaded at the same time). - Update __device_attach() and __driver_attach() to do that locking. - Check if device is already bound in __driver_attach() - Update the converse device_release_driver() so it locks the device around all of the operations. - Mark driver_probe_device() as static and remove export. It's an internal function, it should stay that way, and there are no other callers. If there is ever a need to export it, we can audit it as necessary. Signed-off-by: Andrew Morton <akpm@osdl.org>
* [PATCH] Driver core: Fix up the driver and device iterators to be quietergregkh@suse.de2005-06-201-13/+19
| | | | | | Also stops looping over the lists when a match is found. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de
* [PATCH] Call klist_del() instead of klist_remove().mochel@digitalimplant.org2005-06-201-1/+1
| | | | | | | | - Can't wait on removing the current item in the list (the positive refcount *because* we are using it causes it to deadlock). Signed-off-by: Patrick Mochel <mochel@digitalimplant.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] Use bus_for_each_{dev,drv} for driver binding.mochel@digitalimplant.org2005-06-201-33/+39
| | | | | | | | - Now possible, since the lists are locked using the klist lock and not the global rwsem. Signed-off-by: Patrick Mochel <mochel@digitalimplant.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] Add a klist to struct device_driver for the devices bound to it.mochel@digitalimplant.org2005-06-201-15/+19
| | | | | | | | | | | | | - Use it in driver_for_each_device() instead of the regular list_head and stop using the bus's rwsem for protection. - Use driver_for_each_device() in driver_detach() so we don't deadlock on the bus's rwsem. - Remove ->devices. - Move klist access and sysfs link access out from under device's semaphore, since they're synchronized through other means. Signed-off-by: Patrick Mochel <mochel@digitalimplant.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* [PATCH] Move device/driver code to drivers/base/dd.cmochel@digitalimplant.org2005-06-201-0/+200
This relocates the driver binding/unbinding code to drivers/base/dd.c. This is done for two reasons: One, it's not code related to the bus_type itself; it uses some from that, some from devices, and some from drivers. And Two, it will make it easier to do some of the upcoming lock removal on that code.. Signed-off-by: Patrick Mochel <mochel@digitalimplant.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-28 23:03:57 +0000