aboutsummaryrefslogtreecommitdiff
path: root/drivers/base/platform.c
AgeCommit message (Collapse)Author
2007-05-09drivers/base/platform.c: fix small typo in docMárton Németh
Typo: iwithout -> without. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2007-05-08fix hotplug for legacy platform driversDavid Brownell
We've had various reports of some legacy "probe the hardware" style platform drivers having nasty problems with hotplug support. The core issue is that those legacy drivers don't fully conform to the driver model. They assume a role that should be the responsibility of infrastructure code: creating device nodes. The "modprobe" step in hotplugging relies on drivers to have split those roles into different modules. The lack of this split causes the problems. When a driver creates nodes for devices that don't exist (sending a hotplug event), then exits (aborting one modprobe) before the "modprobe $MODALIAS" step completes (by failing, since it's in the middle of a modprobe), the result can be an endless loop of modprobe invocations ... badness. This fix uses the newish per-device flag controlling issuance of "add" events. (A previous version of this patch used a per-device "driver can hotplug" flag, which only scrubbed $MODALIAS from the environment rather than suppressing the entire hotplug event.) It also shrinks that flag to one bit, saving a word in "struct device". So the net of this patch is removing some nasty failures with legacy drivers, while retaining hotplug capability for the majority of platform drivers. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Cc: Greg KH <gregkh@suse.de> Cc: Andres Salomon <dilinger@debian.org> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-02platform: reorder platform_device_delJean Delvare
In platform_device_del(), we currently delete the device resources first, then we delete the device itself. This causes a (minor) bug to occur when one unregisters a platform device before unregistering its platform driver, and the driver is requesting (in .probe()) and releasing (in .remove()) a resource of the device. The device resources are already gone by the time the driver gets the chance to release the resources it had been requesting, causing an error like: Trying to free nonexistent resource <0000000000000295-0000000000000296> If the platform driver is unregistered first, the problem doesn't occur, as the driver will have the opportunity to release the resources it had requested before the device resources themselves are released. It's a bit odd that unregistering the driver first or the device first doesn't lead to the same result. So I believe that we should delete the device first in platform_device_del(). I've searched the git history and found that it used to be the case before 2.6.8, but was changed here: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git;a=commitdiff;h=96ef7b3689936ee1e64b711511342026a8ce459c > 2004/07/14 16:09:44-07:00 dtor_core > [PATCH] Driver core: Fix OOPS in device_platform_unregister > > Driver core: platform_device_unregister should release resources first > and only then call device_unregister, otherwise if there > are no more references to the device it will be freed and > the fucntion will try to access freed memory. However we now have an explicit call to put_device() at the end of platform_device_unregister() so I guess the original problem no longer exists and it is safe to revert that change. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-07driver core fixes: device_register() retval check in platform.cCornelia Huck
Check the return value of device_register() in platform_bus_init(). Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-13Driver core: Make platform_device_add_data accept a const pointerScott Wood
platform_device_add_data() makes a copy of the data that is given to it, and thus the parameter can be const. This removes a warning when data from get_property() on powerpc is handed to platform_device_add_data(), as get_property() returns a const pointer. Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-13Driver core: "platform_driver_probe() can save codespace": save codespaceAndrew Morton
This function can be __init Cc: David Brownell <dbrownell@users.sourceforge.net> Cc: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-12-01Driver core: platform_driver_probe(), can save codespaceDavid Brownell
This defines a new platform_driver_probe() method allowing the driver's probe() method, and its support code+data, to safely live in __init sections for typical system configurations. Many system-on-chip processors could benefit from this API, to the tune of recovering hundreds to thousands of bytes per driver. That's memory which is currently wasted holding code which can never be called after system startup, yet can not be removed. It can't be removed because of the linkage requirement that pointers to init section code (like, ideally, probe support) must not live in other sections (like driver method tables) after those pointers would be invalid. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-09-25PM: platform_bus and late_suspend/early_resumeDavid Brownell
Teach platform_bus about the new suspend_late/resume_early PM calls, issued with IRQs off. Do we really need sysdev and friends any more, or can janitors start switching its users over to platform_device so we can do a minor code-ectomy? Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-21[PATCH] Driver Core: Fix platform_device_add to use device_addRussell King
platform_device_add() should be using device_add() rather than device_register() - any platform device passed to platform_device_add() should have already been initialised, either by platform_device_alloc() or platform_device_register(). Signed-off-by: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-06-21[PATCH] platform_bus learns about modaliasDavid Brownell
This patch adds modalias support to platform devices, for simpler hotplug/coldplug driven driver setup. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-03-22Fix "frist", "fisrt", typosUwe Zeisberger
Signed-off-by: Uwe Zeisberger <Uwe_Zeisberger@digi.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-03-20[PATCH] driver core: platform_get_irq*(): return -ENXIO on errorDavid Vrabel
platform_get_irq*() cannot return 0 on error as 0 is a valid IRQ on some platforms, return -ENXIO instead. Signed-off-by: David Vrabel <dvrabel@arcom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-13[PATCH] platform-device-del typo fixJean Delvare
Please fold this typo fix into platform-device-del.patch, as was discussed earlier on LKML: http://lkml.org/lkml/2005/12/10/76 Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-04[PATCH] Driver Core: Rearrange exports in platform.cDmitry Torokhov
Driver core: rearrange exports in platform.c The new way is to specify export right after symbol definition. Rearrange exports to follow new style to avoid mixing two styles in one file. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-04[PATCH] Driver Core: Add platform_device_del()Dmitry Torokhov
Driver core: add platform_device_del function Having platform_device_del90 allows more straightforward error handling code in drivers registering platform devices. Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-04[PATCH] Allow overlapping resources for platform devicesKumar Gala
There are cases in which a device's memory mapped registers overlap with another device's memory mapped registers. On several PowerPC devices this occurs for the MDIO bus, whose registers tended to overlap with one of the ethernet controllers. By switching from request_resource to insert_resource we can register the MDIO bus as a proper platform device and not hack around how we handle its memory mapped registers. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-09[DRIVER MODEL] Add platform_driverRussell King
Introduce struct platform_driver. This allows the platform device driver methods to be passed a platform_device structure instead of instead of a plain device structure, and therefore requiring casting in every platform driver. We introduce this in such a way that any existing platform drivers registered directly via driver_register continue to work as before, thereby allowing a gradual conversion to the new platform_driver methods. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-11-05[DRIVER MODEL] Improved dynamically allocated platform_device interfaceRussell King
Re-jig the simple platform device support to allow private data to be attached to a platform device, as well as allowing the parent device to be set. Example usage: pdev = platform_device_alloc("mydev", id); if (pdev) { err = platform_device_add_resources(pdev, &resources, ARRAY_SIZE(resources)); if (err == 0) err = platform_device_add_data(pdev, &platform_data, sizeof(platform_data)); if (err == 0) err = platform_device_add(pdev); } else { err = -ENOMEM; } if (err) platform_device_put(pdev); Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-31Merge master.kernel.org:/home/rmk/linux-2.6-drvmodelLinus Torvalds
Manual #include fixups for clashes - there may be some unnecessary
2005-10-30[PATCH] fix missing includesTim Schmielau
I recently picked up my older work to remove unnecessary #includes of sched.h, starting from a patch by Dave Jones to not include sched.h from module.h. This reduces the number of indirect includes of sched.h by ~300. Another ~400 pointless direct includes can be removed after this disentangling (patch to follow later). However, quite a few indirect includes need to be fixed up for this. In order to feed the patches through -mm with as little disturbance as possible, I've split out the fixes I accumulated up to now (complete for i386 and x86_64, more archs to follow later) and post them before the real patch. This way this large part of the patch is kept simple with only adding #includes, and all hunks are independent of each other. So if any hunk rejects or gets in the way of other patches, just drop it. My scripts will pick it up again in the next round. Signed-off-by: Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-29Create platform_device.h to contain all the platform device details.Russell King
Convert everyone who uses platform_bus_type to include linux/platform_device.h. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-28[PATCH] DRIVER MODEL: Get rid of the obsolete tri-level suspend/resume callbacksRussell King
In PM v1, all devices were called at SUSPEND_DISABLE level. Then all devices were called at SUSPEND_SAVE_STATE level, and finally SUSPEND_POWER_DOWN level. However, with PM v2, to maintain compatibility for platform devices, I arranged for the PM v2 suspend/resume callbacks to call the old PM v1 suspend/resume callbacks three times with each level in order so that existing drivers continued to work. Since this is obsolete infrastructure which is no longer necessary, we can remove it. Here's an (untested) patch to do exactly that. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-10-28[PATCH] drivers/base - fix sparse warningsBen Dooks
There are a number of sparse warnings from the latest sparse snapshot being generated from the drivers/base build. The main culprits are due to the initialisation functions not being declared in a header file. Also, the firmware.c file should include <linux/device.h> to get the prototype of firmware_register() and firmware_unregister(). This patch moves the init function declerations from the init.c file to the base.h, and ensures it is included in all the relevant c sources. It also adds <linux/device.h> to the included headers for firmware.c. The patch does not solve all the sparse errors generated, but reduces the count significantly. drivers/base/core.c:161:1: warning: symbol 'devices_subsys' was not declared. Should it be static? drivers/base/core.c:417:12: warning: symbol 'devices_init' was not declared. Should it be static? drivers/base/sys.c:253:6: warning: symbol 'sysdev_shutdown' was not declared. Should it be static? drivers/base/sys.c:326:5: warning: symbol 'sysdev_suspend' was not declared. Should it be static? drivers/base/sys.c:428:5: warning: symbol 'sysdev_resume' was not declared. Should it be static? drivers/base/sys.c:450:12: warning: symbol 'system_bus_init' was not declared. Should it be static? drivers/base/bus.c:133:1: warning: symbol 'bus_subsys' was not declared. Should it be static? drivers/base/bus.c:667:12: warning: symbol 'buses_init' was not declared. Should it be static? drivers/base/class.c:759:12: warning: symbol 'classes_init' was not declared. Should it be static? drivers/base/platform.c:313:12: warning: symbol 'platform_bus_init' was not declared. Should it be static? drivers/base/cpu.c:110:12: warning: symbol 'cpu_dev_init' was not declared. Should it be static? drivers/base/firmware.c:17:5: warning: symbol 'firmware_register' was not declared. Should it be static? drivers/base/firmware.c:23:6: warning: symbol 'firmware_unregister' was not declared. Should it be static? drivers/base/firmware.c:28:12: warning: symbol 'firmware_init' was not declared. Should it be static? drivers/base/init.c:28:13: warning: symbol 'driver_init' was not declared. Should it be static? drivers/base/dmapool.c:174:10: warning: implicit cast from nocast type drivers/base/attribute_container.c:439:1: warning: symbol 'attribute_container_init' was not declared. Should it be static? drivers/base/power/runtime.c:76:6: warning: symbol 'dpm_set_power_state' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-09-13[PATCH] drivers/base/*: use kzalloc instead of kmalloc+memsetJiri Slaby
Fixes a bunch of memset bugs too. Signed-off-by: Lion Vollnhals <webmaster@schiggl.de> Signed-off-by: Jiri Slaby <xslaby@fi.muni.cz> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01[PATCH] DocBook: fix some descriptionsMartin Waitz
Some KernelDoc descriptions are updated to match the current code. No code changes. Signed-off-by: Martin Waitz <tali@admingilde.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-18[PATCH] export platform_add_devicesRobert Schwebel
platform_add_devices can be used from within modules, so it should be exported. This can for example happen if you have hotpluggable firmware in an FPGA on a system on chip processor; in our case the FPGA is probed for devices and the FPGA base code registers the devices it has found with the kernel. (akpm: I think this is reasonable from a licensing POV: it's unlikely that anyone would be interested in merging such specialised modules into mainline, and it's a GPL export). Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!