17 Apr, 2014
1 commit
-
pr_debug() parameters are reverse order of format string
Signed-off-by: Frank Rowand
Signed-off-by: Greg Kroah-Hartman
08 Nov, 2013
1 commit
-
Commit fa180eb448fa (PM / Runtime: Idle devices asynchronously after
probe|release) modified __device_release_driver() to call
pm_runtime_put(dev) instead of pm_runtime_put_sync(dev) before
detaching the driver from the device. However, that was a mistake,
because pm_runtime_put(dev) causes rpm_idle() to be queued up and
the driver may be gone already when that function is executed.
That breaks the assumptions the drivers have the right to make
about the core's behavior on the basis of the existing documentation
and actually causes problems to happen, so revert that part of
commit fa180eb448fa and restore the previous behavior of
__device_release_driver().Reported-by: Tomi Valkeinen
Fixes: fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release)
Signed-off-by: Rafael J. Wysocki
Acked-by: Kevin Hilman
Acked-by: Ulf Hansson
Cc: 3.10+ # 3.10+
12 Apr, 2013
1 commit
-
Putting devices into idle|suspend in a synchronous manner means we are
waiting for each device to become idle|suspended before the probe|release
is fully done.This patch switch to use the asynchronous runtime PM API:s instead and
thus improves the parallelism since we can move on and handle the next
device in queue in an earlier phase.Signed-off-by: Ulf Hansson
Acked-by: Kevin Hilman
Acked-by: Rafael J. Wysocki
Cc: Alan Stern
Acked-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman
22 Feb, 2013
1 commit
-
Pull driver core patches from Greg Kroah-Hartman:
"Here is the big driver core merge for 3.9-rc1There are two major series here, both of which touch lots of drivers
all over the kernel, and will cause you some merge conflicts:- add a new function called devm_ioremap_resource() to properly be
able to check return values.- remove CONFIG_EXPERIMENTAL
Other than those patches, there's not much here, some minor fixes and
updates"Fix up trivial conflicts
* tag 'driver-core-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (221 commits)
base: memory: fix soft/hard_offline_page permissions
drivercore: Fix ordering between deferred_probe and exiting initcalls
backlight: fix class_find_device() arguments
TTY: mark tty_get_device call with the proper const values
driver-core: constify data for class_find_device()
firmware: Ignore abort check when no user-helper is used
firmware: Reduce ifdef CONFIG_FW_LOADER_USER_HELPER
firmware: Make user-mode helper optional
firmware: Refactoring for splitting user-mode helper code
Driver core: treat unregistered bus_types as having no devices
watchdog: Convert to devm_ioremap_resource()
thermal: Convert to devm_ioremap_resource()
spi: Convert to devm_ioremap_resource()
power: Convert to devm_ioremap_resource()
mtd: Convert to devm_ioremap_resource()
mmc: Convert to devm_ioremap_resource()
mfd: Convert to devm_ioremap_resource()
media: Convert to devm_ioremap_resource()
iommu: Convert to devm_ioremap_resource()
drm: Convert to devm_ioremap_resource()
...
16 Feb, 2013
1 commit
-
One of the side effects of deferred probe is that some drivers which
used to be probed before initcalls completed are now happening slightly
later. This causes two problems.
- If a console driver gets deferred, then it may not be ready when
userspace starts. For example, if a uart depends on pinctrl, then the
uart will get deferred and /dev/console will not be available
- __init sections will be discarded before built-in drivers are probed.
Strictly speaking, __init functions should not be called in a drivers
__probe path, but there are a lot of drivers (console stuff again)
that do anyway. In the past it was perfectly safe to do so because all
built-in drivers got probed before the end of initcalls.This patch fixes the problem by forcing the first pass of the deferred
list to complete at late_initcall time. This is late enough to catch the
drivers that are known to have the above issues.Signed-off-by: Grant Likely
Tested-by: Haojian Zhuang
Cc: Arnd Bergmann
Cc: Russell King
Cc: Linus Torvalds
Cc: stable # 3.4+
Signed-off-by: Greg Kroah-Hartman
23 Jan, 2013
1 commit
-
This makes the device core auto-grab the pinctrl handle and set
the "default" (PINCTRL_STATE_DEFAULT) state for every device
that is present in the device model right before probe. This will
account for the lion's share of embedded silicon devcies.A modification of the semantics for pinctrl_get() is also done:
previously if the pinctrl handle for a certain device was already
taken, the pinctrl core would return an error. Now, since the
core may have already default-grabbed the handle and set its
state to "default", if the handle was already taken, this will
be disregarded and the located, previously instanitated handle
will be returned to the caller.This way all code in drivers explicitly requesting their pinctrl
handlers will still be functional, and drivers that want to
explicitly retrieve and switch their handles can still do that.
But if the desired functionality is just boilerplate of this
type in the probe() function:struct pinctrl *p;
p = devm_pinctrl_get_select_default(&dev);
if (IS_ERR(p)) {
if (PTR_ERR(p) == -EPROBE_DEFER)
return -EPROBE_DEFER;
dev_warn(&dev, "no pinctrl handle\n");
}The discussion began with the addition of such boilerplate
to the omap4 keypad driver:
http://marc.info/?l=linux-input&m=135091157719300&w=2A previous approach using notifiers was discussed:
http://marc.info/?l=linux-kernel&m=135263661110528&w=2
This failed because it could not handle deferred probes.This patch alone does not solve the entire dilemma faced:
whether code should be distributed into the drivers or
if it should be centralized to e.g. a PM domain. But it
solves the immediate issue of the addition of boilerplate
to a lot of drivers that just want to grab the default
state. As mentioned, they can later explicitly retrieve
the handle and set different states, and this could as
well be done by e.g. PM domains as it is only related
to a certain struct device * pointer.ChangeLog v4->v5 (Stephen):
- Simplified the devicecore grab code.
- Deleted a piece of documentation recommending that pins
be mapped to a device rather than hogged.
ChangeLog v3->v4 (Linus):
- Drop overzealous NULL checks.
- Move kref initialization to pinctrl_create().
- Seeking Tested-by from Stephen Warren so we do not disturb
the Tegra platform.
- Seeking ACK on this from Greg (and others who like it) so I
can merge it through the pinctrl subsystem.
ChangeLog v2->v3 (Linus):
- Abstain from using IS_ERR_OR_NULL() in the driver core,
Russell recently sent a patch to remove it. Handle the
NULL case explicitly even though it's a bogus case.
- Make sure we handle probe deferral correctly in the device
core file. devm_kfree() the container on error so we don't
waste memory for devices without pinctrl handles.
- Introduce reference counting into the pinctrl core using
so that we don't release pinctrl handles
that have been obtained for two or more places.
ChangeLog v1->v2 (Linus):
- Only store a pointer in the device struct, and only allocate
this if it's really used by the device.Cc: Felipe Balbi
Cc: Benoit Cousson
Cc: Dmitry Torokhov
Cc: Thomas Petazzoni
Cc: Mitch Bradley
Cc: Ulf Hansson
Cc: Rafael J. Wysocki
Cc: Jean-Christophe PLAGNIOL-VILLARD
Cc: Rickard Andersson
Cc: Russell King
Reviewed-by: Mark Brown
Acked-by: Greg Kroah-Hartman
Signed-off-by: Linus Walleij
[swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to
correctly handle deferred probe. Removed admonition from docs not to use
pinctrl hogs for devices]
Signed-off-by: Stephen Warren
Signed-off-by: Linus Walleij
17 Jul, 2012
2 commits
-
The pm_runtime_get_noresume() calls before really_probe() and
before executing __device_attach() for each driver on the
device's bus cause problems to happen if probing fails and if the
driver has enabled runtime PM for the device in its .probe()
callback. Namely, in that case, if the device has been resumed
by the driver after enabling its runtime PM and if it turns out that
.probe() should return an error, the driver is supposed to suspend
the device and disable its runtime PM before exiting .probe().
However, because the device's runtime PM usage counter was
incremented by the core before calling .probe(), the driver's attempt
to suspend the device will not succeed and the device will remain in
the full-power state after the failing .probe() has returned.To fix this issue, remove the pm_runtime_get_noresume() calls from
driver_probe_device() and from device_attach() and replace the
corresponding pm_runtime_put_sync() calls with pm_runtime_idle()
to preserve the existing behavior (which is to check if the device
is idle and to suspend it eventually in that case after probing).Reported-and-tested-by: Kevin Hilman
Reviewed-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
When deferred probe was originally added the idea was that devices which
defer their probes would move themselves to the end of dpm_list in order
to try to keep the assumptions that we're making about the list being in
roughly the order things should be suspended correct. However this hasn't
been what's been happening and doing it requires a lot of duplicated code
to do the moves.Instead take a simple, brute force solution and have the deferred probe
code push devices to the end of dpm_list before it retries the probe. This
does mean we lock the dpm_list a bit more often but it's very simple and
the code shouldn't be a fast path. We do the move with the deferred mutex
dropped since doing things with fewer locks held simultaneously seems like
a good idea.This approach was most recently suggested by Grant Likely.
Signed-off-by: Mark Brown
Acked-by: Rafael J. Wysocki
Cc: Grant Likely ,
Signed-off-by: Greg Kroah-Hartman
05 Jul, 2012
1 commit
-
This picks up the big printk fixes, and resolves a merge issue with:
drivers/extcon/extcon_gpio.cSigned-off-by: Greg Kroah-Hartman
14 Jun, 2012
2 commits
-
1) drvdata is for a driver to store a pointer to driver specific data
2) If no driver is bound, there is no driver specific data associated with
the device
3) Thus logically drvdata should be NULL if no driver is bound.But many drivers don't clear drvdata on device_release, or set drvdata
early on in probe and leave it set on probe error. Both of which results
in a dangling pointer in drvdata.This patch enforce for drvdata to be NULL after device_release or on probe
failure.Signed-off-by: Hans de Goede
Signed-off-by: Greg Kroah-Hartman -
If driver requests probe deferral,
it will be added to deferred_probe_pending_list
by driver_deferred_probe_add(), but, it used list_add().
Because of that, deferred probe will be run as reversed order.
This patch uses list_add_tail(), and solved this issue.Signed-off-by: Kuninori Morimoto
Signed-off-by: Greg Kroah-Hartman
09 Mar, 2012
3 commits
-
Came in in the deferred probe patch, quick, clean them up before a
kernel janitor finds them and sends me 4 individual patches to fix them
up...Cc: Grant Likely
Signed-off-by: Greg Kroah-Hartman -
Nothing outside of the driver core needs to get to the deferred probe
pointer, so move it inside the private area of 'struct device' so no one
tries to mess around with it.Cc: Grant Likely
Signed-off-by: Greg Kroah-Hartman -
Allow drivers to report at probe time that they cannot get all the resources
required by the device, and should be retried at a later time.This should completely solve the problem of getting devices
initialized in the right order. Right now this is mostly handled by
mucking about with initcall ordering which is a complete hack, and
doesn't even remotely handle the case where device drivers are in
modules. This approach completely sidesteps the issues by allowing
driver registration to occur in any order, and any driver can request
to be retried after a few more other drivers get probed.v4: - Integrate Manjunath's addition of a separate workqueue
- Change -EAGAIN to -EPROBE_DEFER for drivers to trigger deferral
- Update comment blocks to reflect how the code really works
v3: - Hold off workqueue scheduling until late_initcall so that the bulk
of driver probes are complete before we start retrying deferred devices.
- Tested with simple use cases. Still needs more testing though.
Using it to get rid of the gpio early_initcall madness, or to replace
the ASoC internal probe deferral code would be ideal.
v2: - added locking so it should no longer be utterly broken in that regard
- remove device from deferred list at device_del time.
- Still completely untested with any real use case, but has been
boot tested.Signed-off-by: Grant Likely
Cc: Mark Brown
Cc: Arnd Bergmann
Cc: Dilan Lee
Cc: Manjunath GKondaiah
Cc: Alan Stern
Cc: Tony Lindgren
Cc: Alan Cox
Reviewed-by: Mark Brown
Acked-by: David Daney
Reviewed-by: Arnd Bergmann
Signed-off-by: Greg Kroah-Hartman
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
2 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
