summaryrefslogtreecommitdiffstats
path: root/drivers/base/dd.c
Commit message (Collapse)AuthorAgeFilesLines
* base:dd - Fix for typo in comment to function driver_deferred_probe_trigger().Shailendra Verma2015-06-011-1/+1
| | | | | Signed-off-by: Shailendra Verma <shailendra.capricorn@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver-core: fix build for !CONFIG_MODULESDmitry Torokhov2015-05-241-1/+1
| | | | | | | | | | | | | Commit f2411da74698 ("driver-core: add driver module asynchronous probe support") broke build in case modules are disabled, because in this case "struct module" is not defined and we can't dereference it. Let's define module_requested_async_probing() helper and stub it out if modules are disabled. Reported-by: kbuild test robot <fengguang.wu@intel.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver-core: make __device_attach() staticDmitry Torokhov2015-05-241-1/+1
| | | | | | | | It is only used within dd.c and thus need not be global. Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver-core: enable drivers to opt-out of async probeLuis R. Rodriguez2015-05-201-4/+10
| | | | | | | | | | | | | | | | | | | There are drivers that can not be probed asynchronously. One such group is platform drivers registered with platform_driver_probe(), which expects driver's probe routine be discarded after the driver has been registered and initial binding attempt executed. Also platform_driver_probe() an error when no devices were bound to the driver, allowing failing to load such driver module altogether. Other drivers do not work well with asynchronous probing because of driver bug or not optimal driver organization. To allow using such drivers even when user requests asynchronous probing as default boot strategy, let's allow them to opt out. Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver-core: add driver module asynchronous probe supportLuis R. Rodriguez2015-05-201-1/+7
| | | | | | | | | | | | | | | | | Some init systems may wish to express the desire to have device drivers run their probe() code asynchronously. This implements support for this and allows userspace to request async probe as a preference through a generic shared device driver module parameter, async_probe. Implementation for async probe is supported through a module parameter given that since synchronous probe has been prevalent for years some userspace might exist which relies on the fact that the device driver will probe synchronously and the assumption that devices it provides will be immediately available after this. Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver-core: add asynchronous probing support for driversDmitry Torokhov2015-05-201-19/+130
| | | | | | | | | | | | | | | | | | | | | | | | | Some devices take a long time when initializing, and not all drivers are suited to initialize their devices when they are open. For example, input drivers need to interrogate their devices in order to publish device's capabilities before userspace will open them. When such drivers are compiled into kernel they may stall entire kernel initialization. This change allows drivers request for their probe functions to be called asynchronously during driver and device registration (manual binding is still synchronous). Because async_schedule is used to perform asynchronous calls module loading will still wait for the probing to complete. Note that the end goal is to make the probing asynchronous by default, so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary measure that allows us to speed up boot process while we validating and fixing the rest of the drivers and preparing userspace. This change is based on earlier patch by "Luis R. Rodriguez" <mcgrof@suse.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'pm+acpi-4.1-rc1' of ↵Linus Torvalds2015-04-151-0/+14
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management and ACPI updates from Rafael Wysocki: "These are mostly fixes and cleanups all over, although there are a few items that sort of fall into the new feature category. First off, we have new callbacks for PM domains that should help us to handle some issues related to device initialization in a better way. There also is some consolidation in the unified device properties API area allowing us to use that inferface for accessing data coming from platform initialization code in addition to firmware-provided data. We have some new device/CPU IDs in a few drivers, support for new chips and a new cpufreq driver too. Specifics: - Generic PM domains support update including new PM domain callbacks to handle device initialization better (Russell King, Rafael J Wysocki, Kevin Hilman) - Unified device properties API update including a new mechanism for accessing data provided by platform initialization code (Rafael J Wysocki, Adrian Hunter) - ARM cpuidle update including ARM32/ARM64 handling consolidation (Daniel Lezcano) - intel_idle update including support for the Silvermont Core in the Baytrail SOC and for the Airmont Core in the Cherrytrail and Braswell SOCs (Len Brown, Mathias Krause) - New cpufreq driver for Hisilicon ACPU (Leo Yan) - intel_pstate update including support for the Knights Landing chip (Dasaratharaman Chandramouli, Kristen Carlson Accardi) - QorIQ cpufreq driver update (Tang Yuantian, Arnd Bergmann) - powernv cpufreq driver update (Shilpasri G Bhat) - devfreq update including Tegra support changes (Tomeu Vizoso, MyungJoo Ham, Chanwoo Choi) - powercap RAPL (Running-Average Power Limit) driver update including support for Intel Broadwell server chips (Jacob Pan, Mathias Krause) - ACPI device enumeration update related to the handling of the special PRP0001 device ID allowing DT-style 'compatible' property to be used for ACPI device identification (Rafael J Wysocki) - ACPI EC driver update including limited _DEP support (Lan Tianyu, Lv Zheng) - ACPI backlight driver update including a new mechanism to allow native backlight handling to be forced on non-Windows 8 systems and a new quirk for Lenovo Ideapad Z570 (Aaron Lu, Hans de Goede) - New Windows Vista compatibility quirk for Sony VGN-SR19XN (Chen Yu) - Assorted ACPI fixes and cleanups (Aaron Lu, Martin Kepplinger, Masanari Iida, Mika Westerberg, Nan Li, Rafael J Wysocki) - Fixes related to suspend-to-idle for the iTCO watchdog driver and the ACPI core system suspend/resume code (Rafael J Wysocki, Chen Yu) - PM tracing support for the suspend phase of system suspend/resume transitions (Zhonghui Fu) - Configurable delay for the system suspend/resume testing facility (Brian Norris) - PNP subsystem cleanups (Peter Huewe, Rafael J Wysocki)" * tag 'pm+acpi-4.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (74 commits) ACPI / scan: Fix NULL pointer dereference in acpi_companion_match() ACPI / scan: Rework modalias creation when "compatible" is present intel_idle: mark cpu id array as __initconst powercap / RAPL: mark rapl_ids array as __initconst powercap / RAPL: add ID for Broadwell server intel_pstate: Knights Landing support intel_pstate: remove MSR test cpufreq: fix qoriq uniprocessor build ACPI / scan: Take the PRP0001 position in the list of IDs into account ACPI / scan: Simplify acpi_match_device() ACPI / scan: Generalize of_compatible matching device property: Introduce firmware node type for platform data device property: Make it possible to use secondary firmware nodes PM / watchdog: iTCO: stop watchdog during system suspend cpufreq: hisilicon: add acpu driver ACPI / EC: Call acpi_walk_dep_device_list() after installing EC opregion handler cpufreq: powernv: Report cpu frequency throttling intel_idle: Add support for the Airmont Core in the Cherrytrail and Braswell SOCs intel_idle: Update support for Silvermont Core in Baytrail SOC PM / devfreq: tegra: Register governor on module init ...
| * driver core / PM: Add PM domain callbacks for device setup/cleanupRafael J. Wysocki2015-03-221-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If PM domains are in use, it may be necessary to prepare the code handling a PM domain for driver probing. For example, in some cases device drivers rely on the ability to power on the devices with the help of the IO runtime PM framework and the PM domain code needs to be ready for that. Also, if that code has not been fully initialized yet, the driver probing should be deferred. Moreover, after the probing is complete, it may be necessary to put the PM domain in question into the state reflecting the current needs of the devices in it, for example, so that power is not drawn in vain. The same should be done after removing a driver from a device, as the PM domain state may need to be changed to reflect the new situation. For these reasons, introduce new PM domain callbacks, ->activate, ->sync and ->dismiss called, respectively, before probing for a device driver, after the probing has completed successfully and if the probing has failed or the driver has been removed. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Kevin Hilman <khilman@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | driver core: Make probe deferral more quietMark Brown2015-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently probe deferral prints a message every time a device requests deferral at info severity (which is displayed by default). This can have an impact on system boot times with serial consoles and is generally quite noisy. Since subsystems and drivers should already be logging the specific reason for probe deferral in order to aid users in understanding problems the messages from the driver core should be redundant lower the severity of the messages printed, cutting down on the volume of output on the console. This does mean that if the drivers and subsystems aren't doing a good job we get no output on the console by default. Ideally we'd be able to arrange to print if nothing else printed, though that's a little fun. Even better would be to come up with a mechanism that explicitly does dependencies so we don't have to keep polling and erroring. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | driver core: use *switch* statement in really_probe()Sergei Shtylyov2015-03-251-5/+9
|/ | | | | | | | There are series of comparisons of the 'ret' variable on the failure path of really_probe(), so the *switch* statement seems more appropriate there. Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver core: Remove kerneldoc from local functionThierry Reding2014-09-241-1/+1
| | | | | | | | | | | The deferred_probe_work_func() function is locally scoped, therefore an associated kerneldoc comment isn't very useful. Replace the kerneldoc opening marker (/**) with a regular block comment marker (/*) to avoid the comment from being parsed by kerneldoc. This gets rid of a warning caused by a missing description for the "work" argument. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver core: Inline dev_set/get_drvdataJean Delvare2014-05-271-16/+0Star
| | | | | | | | dev_set_drvdata and dev_get_drvdata are now simple enough again that we can inline them as they used to be before commit b40284378. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver core: dev_get_drvdata: Don't check for NULL devJean Delvare2014-05-271-3/+1Star
| | | | | | | | | | | | | | | There is no point in calling dev_get_drvdata without a valid device. So checking for dev == NULL is pointless. If such a check is ever needed - which I doubt - the driver should do it before calling dev_get_drvdata. We were returning NULL if dev was NULL, which the caller certainly did not expect anyway, so that was only delaying the crash if the caller is not paying attention. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver core: dev_set_drvdata returns voidJean Delvare2014-05-271-2/+1Star
| | | | | | | | | | dev_set_drvdata can no longer fail, so it could return void. All callers have hopefully been updated to no longer check for the return value. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver core: Move driver_data back to struct deviceJean Delvare2014-05-271-10/+3Star
| | | | | | | | | | | Having to allocate memory as part of dev_set_drvdata() is a problem because that memory may never get freed if the device itself is not created. So move driver_data back to struct device. This is a partial revert of commit b4028437. Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drivercore: deferral race condition fixGrant Likely2014-04-291-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the kernel is built with CONFIG_PREEMPT it is possible to reach a state when all modules loaded but some driver still stuck in the deferred list and there is a need for external event to kick the deferred queue to probe these drivers. The issue has been observed on embedded systems with CONFIG_PREEMPT enabled, audio support built as modules and using nfsroot for root filesystem. The following log fragment shows such sequence when all audio modules were loaded but the sound card is not present since the machine driver has failed to probe due to missing dependency during it's probe. The board is am335x-evmsk (McASP<->tlv320aic3106 codec) with davinci-evm machine driver: ... [ 12.615118] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: ENTER [ 12.719969] davinci_evm sound.3: davinci_evm_probe: ENTER [ 12.725753] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card [ 12.753846] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component [ 12.922051] davinci-mcasp 4803c000.mcasp: davinci_mcasp_probe: snd_soc_register_component DONE [ 12.950839] davinci_evm sound.3: ASoC: platform (null) not registered [ 12.957898] davinci_evm sound.3: davinci_evm_probe: snd_soc_register_card DONE (-517) [ 13.099026] davinci-mcasp 4803c000.mcasp: Kicking the deferred list [ 13.177838] davinci-mcasp 4803c000.mcasp: really_probe: probe_count = 2 [ 13.194130] davinci_evm sound.3: snd_soc_register_card failed (-517) [ 13.346755] davinci_mcasp_driver_init: LEAVE [ 13.377446] platform sound.3: Driver davinci_evm requests probe deferral [ 13.592527] platform sound.3: really_probe: probe_count = 0 In the log the machine driver enters it's probe at 12.719969 (this point it has been removed from the deferred lists). McASP driver already executing it's probing (since 12.615118). The machine driver tries to construct the sound card (12.950839) but did not found one of the components so it fails. After this McASP driver registers all the ASoC components (the machine driver still in it's probe function after it failed to construct the card) and the deferred work is prepared at 13.099026 (note that this time the machine driver is not in the lists so it is not going to be handled when the work is executing). Lastly the machine driver exit from it's probe and the core places it to the deferred list but there will be no other driver going to load and the deferred queue is not going to be kicked again - till we have external event like connecting USB stick, etc. The proposed solution is to try the deferred queue once more when the last driver is asking for deferring and we had drivers loaded while this last driver was probing. This way we can avoid drivers stuck in the deferred queue. Signed-off-by: Grant Likely <grant.likely@linaro.org> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Mark Brown <broonie@kernel.org> Cc: Stable <stable@vger.kernel.org> # v3.4+
* drivers/base/dd.c incorrect pr_debug() parametersFrank Rowand2014-04-171-2/+2
| | | | | | | pr_debug() parameters are reverse order of format string Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* PM / runtime: Use pm_runtime_put_sync() in __device_release_driver()Rafael J. Wysocki2013-11-071-1/+1
| | | | | | | | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com> Fixes: fa180eb448fa (PM / Runtime: Idle devices asynchronously after probe|release) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Kevin Hilman <khilman@linaro.org> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
* PM / Runtime: Idle devices asynchronously after probe|releaseUlf Hansson2013-04-111-3/+3
| | | | | | | | | | | | | | | | | 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 <ulf.hansson@linaro.org> Acked-by: Kevin Hilman <khilman@linaro.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Alan Stern <stern@rowland.harvard.edu> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'driver-core-3.9-rc1' of ↵Linus Torvalds2013-02-211-0/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core patches from Greg Kroah-Hartman: "Here is the big driver core merge for 3.9-rc1 There 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() ...
| * drivercore: Fix ordering between deferred_probe and exiting initcallsGrant Likely2013-02-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <grant.likely@secretlab.ca> Tested-by: Haojian Zhuang <haojian.zhuang@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Russell King <linux@arm.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: stable <stable@vger.kernel.org> # 3.4+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | drivers/pinctrl: grab default handles from device coreLinus Walleij2013-01-231-0/+7
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=2 A 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 <linux/kref.h> 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 <balbi@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Mitch Bradley <wmb@firmworks.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Cc: Rickard Andersson <rickard.andersson@stericsson.com> Cc: Russell King <linux@arm.linux.org.uk> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> [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 <swarren@nvidia.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
* PM / Runtime: Do not increment device usage counts before probingRafael J. Wysocki2012-07-171-4/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <khilman@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver core: Move deferred devices to the end of dpm_list before probingMark Brown2012-07-171-0/+12
| | | | | | | | | | | | | | | | | | | | | | | 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 <broonie@opensource.wolfsonmicro.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Cc: Grant Likely <grant.likely@secretlab.ca>, Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge v3.5-rc5 into driver-core-nextGreg Kroah-Hartman2012-07-051-1/+1
|\ | | | | | | | | | | | | This picks up the big printk fixes, and resolves a merge issue with: drivers/extcon/extcon_gpio.c Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| * driver core: fixup reversed deferred probe orderKuninori Morimoto2012-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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 <kuninori.morimoto.gx@renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | device-core: Ensure drvdata = NULL when no driver is boundHans de Goede2012-06-141-0/+2
|/ | | | | | | | | | | | | | | | | 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 <hdegoede@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver core: minor comment formatting cleanupsGreg Kroah-Hartman2012-03-081-8/+16
| | | | | | | | | 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 <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* driver core: move the deferred probe pointer into the private areaGreg Kroah-Hartman2012-03-081-8/+10
| | | | | | | | | 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 <grant.likely@secretlab.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drivercore: Add driver probe deferral mechanismGrant Likely2012-03-081-1/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <grant.likely@secretlab.ca> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dilan Lee <dilee@nvidia.com> Cc: Manjunath GKondaiah <manjunath.gkondaiah@linaro.org> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Tony Lindgren <tony@atomide.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Reviewed-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: David Daney <david.daney@cavium.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drivers: base: print rejected matches with DEBUG_DRIVERWolfram Sang2011-09-271-0/+3
| | | | | | | | | | | | When DEBUG_DRIVER is activated, be verbose and explicitly state when a device<->driver 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 <w.sang@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* Merge branch 'driver-core-next' of ↵Linus Torvalds2011-05-201-4/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/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.
| * driver core: let dev_set_drvdata return int instead of void as it can failUwe Kleine-König2011-04-231-4/+3Star
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <u.kleine-koenig@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| * driver-core: fix race between device_register and driver_registerSebastian Ott2011-04-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 <sebott@linux.vnet.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* | PM / Runtime: Rework runtime PM handling during driver removalRafael J. Wysocki2011-05-171-3/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <rjw@sisk.pl>
* Driver core: Add BUS_NOTIFY_BIND_DRIVERMagnus Damm2010-08-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-211-2/+2
| | | | | | | | | | | | | | | 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-081-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-041-1/+1
| | | | | | | | | | 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-151-2/+29
| | | | | | | | | | | | | 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-231-0/+11
| | | | | | | | | | | | | | | 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-161-1/+1
| | | | | | | | 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-161-0/+4
| | | | | | | | | | | 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-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | 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-251-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-251-6/+2Star
| | | | | | | | | | | | | | | | | | 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-251-12/+7Star
| | | | | | | | | | | | | | | | | | | | | | 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/+5Star
| | | | | | | | | | | | | 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/+0Star
| | | | | | | | | | | 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>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-11-06 10:35:29 +0100