27 Sep, 2011
1 commit
-
When DEBUG_DRIVER is activated, be verbose and explicitly state when a
devicedriver match was rejected by the probe-function of the driver.
Now all code-paths report what is currently happening which helps
debugging, because you don't have to remember that no printout means
the match is rejected (and then you still don't know if it was because
of ENODEV or ENXIO).Signed-off-by: Wolfram Sang
Signed-off-by: Greg Kroah-Hartman
20 May, 2011
1 commit
-
…/gregkh/driver-core-2.6
* 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6: (44 commits)
debugfs: Silence DEBUG_STRICT_USER_COPY_CHECKS=y warning
sysfs: remove "last sysfs file:" line from the oops messages
drivers/base/memory.c: fix warning due to "memory hotplug: Speed up add/remove when blocks are larger than PAGES_PER_SECTION"
memory hotplug: Speed up add/remove when blocks are larger than PAGES_PER_SECTION
SYSFS: Fix erroneous comments for sysfs_update_group().
driver core: remove the driver-model structures from the documentation
driver core: Add the device driver-model structures to kerneldoc
Translated Documentation/email-clients.txt
RAW driver: Remove call to kobject_put().
reboot: disable usermodehelper to prevent fs access
efivars: prevent oops on unload when efi is not enabled
Allow setting of number of raw devices as a module parameter
Introduce CONFIG_GOOGLE_FIRMWARE
driver: Google Memory Console
driver: Google EFI SMI
x86: Better comments for get_bios_ebda()
x86: get_bios_ebda_length()
misc: fix ti-st build issues
params.c: Use new strtobool function to process boolean inputs
debugfs: move to new strtobool
...Fix up trivial conflicts in fs/debugfs/file.c due to the same patch
being applied twice, and an unrelated cleanup nearby.
18 May, 2011
1 commit
-
The driver core tries to prevent race conditions between runtime PM
and driver removal from happening by incrementing the runtime PM
usage counter of the device and executing pm_runtime_barrier() before
running the bus notifier and the ->remove() callbacks provided by the
device's subsystem or driver. This guarantees that, if a future
runtime suspend of the device has been scheduled or a runtime resume
or idle request has been queued up right before the driver removal,
it will be canceled or waited for to complete and no other
asynchronous runtime suspend or idle requests for the device will be
put into the PM workqueue until the ->remove() callback returns.
However, it doesn't prevent resume requests from being queued up
after pm_runtime_barrier() has been called and it doesn't prevent
pm_runtime_resume() from executing the device subsystem's runtime
resume callback. Morever, it prevents the device's subsystem or
driver from putting the device into the suspended state by calling
pm_runtime_suspend() from its ->remove() routine. This turns out to
be a major inconvenience for some subsystems and drivers that want to
leave the devices they handle in the suspended state.To really prevent runtime PM callbacks from racing with the bus
notifier callback in __device_release_driver(), which is necessary,
because the notifier is used by some subsystems to carry out
operations affecting the runtime PM functionality, use
pm_runtime_get_sync() instead of the combination of
pm_runtime_get_noresume() and pm_runtime_barrier(). This will resume
the device if it's in the suspended state and will prevent it from
being suspended again until pm_runtime_put_*() is called.To allow subsystems and drivers to put devices into the suspended
state by calling pm_runtime_suspend() from their ->remove() routines,
execute pm_runtime_put_sync() after running the bus notifier in
__device_release_driver(). This will require subsystems and drivers
to make their ->remove() callbacks avoid races with runtime PM
directly, but it will allow of more flexibility in the handling of
devices during the removal of their drivers.Signed-off-by: Rafael J. Wysocki
23 Apr, 2011
2 commits
-
Before commit
b402843 (Driver core: move dev_get/set_drvdata to drivers/base/dd.c)
calling dev_set_drvdata with dev=NULL was an unchecked error. After some
discussion about what to return in this case removing the check (and so
producing a null pointer exception) seems fine.Signed-off-by: Uwe Kleine-König
Signed-off-by: Greg Kroah-Hartman -
When a device is registered to a bus it will be a) added to the list
of devices of the bus and b) bind to a driver (if one matches). As a
result of a driver being registered at this bus between a) and b) this
device could already be bound to a driver. This leads to a warning
and incorrect refcounting.
To fix this add a check to device_attach to identify an already bound
device.Signed-off-by: Sebastian Ott
Signed-off-by: Greg Kroah-Hartman
06 Aug, 2010
1 commit
-
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
Signed-off-by: Greg Kroah-Hartman
22 May, 2010
1 commit
-
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
Signed-off-by: Greg Kroah-Hartman
08 Mar, 2010
1 commit
-
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
Cc: Jean Delvare
Cc: Dave Young
Cc: Ming Lei
Cc: Jiri Kosina
Cc: Phil Carmody
Cc: Arjan van de Ven
Cc: Cornelia Huck
Cc: Rafael J. Wysocki
Cc: Pavel Machek
Cc: Len Brown
Cc: Magnus Damm
Cc: Alan Stern
Cc: Randy Dunlap
Cc: Stefan Richter
Cc: David Brownell
Cc: Vegard Nossum
Cc: Jesse Barnes
Cc: Alex Chiang
Cc: Kenji Kaneshige
Cc: Andrew Morton
Cc: Andrew Patterson
Cc: Yu Zhao
Cc: Dominik Brodowski
Cc: Samuel Ortiz
Cc: Wolfram Sang
Cc: CHENG Renquan
Cc: Oliver Neukum
Cc: Frans Pop
Cc: David Vrabel
Cc: Kay Sievers
Cc: Sarah Sharp
Signed-off-by: Greg Kroah-Hartman
04 Dec, 2009
1 commit
-
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
Signed-off-by: Jiri Kosina
16 Sep, 2009
1 commit
-
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
Signed-off-by: Greg Kroah-Hartman
23 Aug, 2009
1 commit
-
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
Acked-by: Magnus Damm
16 Jun, 2009
2 commits
-
We are looking for matching drivers, not devices.
Signed-off-by: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman
22 Apr, 2009
1 commit
-
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
Tested-by: Russell King
Signed-off-by: Linus Torvalds
25 Mar, 2009
3 commits
-
Nothing outside of the driver core should ever touch knode_driver, so
move it out of the public eye.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Cornelia Huck
Reviewed-by: Arjan van de Ven
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Cornelia Huck
Signed-off-by: Greg Kroah-Hartman
22 Feb, 2009
1 commit
-
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
Signed-off-by: Rafael J. Wysocki
Cc: Len Brown
Acked-by: Greg KH
Signed-off-by: Linus Torvalds
10 Jan, 2009
1 commit
-
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
Cc: Alan Cox
Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman
07 Jan, 2009
3 commits
-
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
Signed-off-by: Greg Kroah-Hartman -
Nothing outside of the driver core should ever touch knode_driver, so
move it out of the public eye.Cc: Kay Sievers
Signed-off-by: Greg Kroah-Hartman -
Signed-off-by: Kay Sievers
Signed-off-by: Greg Kroah-Hartman
17 Oct, 2008
1 commit
-
This patch adds a quick check for the driverdevice 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.svgNote 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
Cc: Alan Stern
Signed-off-by: Greg Kroah-Hartman
20 Apr, 2008
1 commit
-
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison
Signed-off-by: Greg Kroah-Hartman
25 Jan, 2008
5 commits
-
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
-
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
Signed-off-by: David Woodhouse
Signed-off-by: Greg Kroah-Hartman -
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.\nNote, 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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman
12 Jul, 2007
2 commits
-
Signed-off-by: Stefan Richter
Signed-off-by: Greg Kroah-Hartman -
Signed-off-by: Stefan Richter
Signed-off-by: Greg Kroah-Hartman
09 Jun, 2007
1 commit
-
CC drivers/base/dd.o
drivers/base/dd.c:211: warning: =E2=80=98device_probe_drivers=E2=80=99 defi=
ned but not usedLooks like the following is dead.
Signed-off-by: Stephen Hemminger
Signed-off-by: Greg Kroah-Hartman
03 May, 2007
1 commit
-
This patch removes the PCI_MULTITHREAD_PROBE option that had already
been marked as broken.Signed-off-by: Adrian Bunk
Signed-off-by: Greg Kroah-Hartman
28 Apr, 2007
2 commits
-
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
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman -
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
Cc: Benjamin Herrenschmidt
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman
10 Feb, 2007
1 commit
-
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
Signed-off-by: Jeff Garzik
08 Feb, 2007
2 commits
-
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman
02 Dec, 2006
2 commits
-
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
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Greg Kroah-Hartman
