From: David Brownell <david-b@pacbell.net>
To: Greg KH <gregkh@suse.de>
Cc: Kay Sievers <kay.sievers@vrfy.org>, "Marco d'Itri" <md@Linux.IT>,
linux-kernel@vger.kernel.org
Subject: [patch 2.6.19-rc6] fix hotplug for legacy platform drivers
Date: Wed, 29 Nov 2006 14:50:58 -0800 [thread overview]
Message-ID: <200611291450.59165.david-b@pacbell.net> (raw)
In-Reply-To: <20061127190315.GA28107@suse.de>
On Monday 27 November 2006 11:03 am, Greg KH wrote:
> David, any chance you can fix this up, as people are seeing this bug
> today.
Here's my fix. Unlike the fix Kay suggested, it causes at worst only
a minor loss of functionality, so that tradeoff seems fair for a late
merge. I audited all the drivers using the relevant APIs, and I can't
see many (if any!) folk hitting problems from this.
- Dave
============== CUT HERE
We've had recent reports of some legacy "probe the hardware" style platform
drivers having nasty problems with hotplug support.
The core issue is that those drivers don't fully conform to the driver model.
They assume a role that's the responsibility of infrastructure code: they
create their own device nodes. But hotplugging relies on drivers to have split
those roles into different modules, hence the problems. If the driver creates
nodes for devices that don't exist, the "modprobe $MODALIAS" step of hotplugging
can become an endless loop *when driver load aborts* (it's safe otherwise).
This fix adds a per-device flag saying whether its driver can't be hotplugged,
which is set by APIs used for "probe the hardware" style drivers. The flag
is used to bypass relevant hotplug logic (setting the $MODALIAS environment
variable) for those problematic drivers.
The minor glitch is that in a few cases those APIs are used by platform code,
instead of by drivers. Examples include most places where a "pcspkr" device is
created (although a recent un-merged patch fixed that for X86_PC), or the way
platform devices are created for OpenFirmware nodes ... all those cases seem
to kick in before userspace (and hotplug) is active though.
So the net of this patch is removing some nasty failures with legacy drivers,
while retaining hotplug capability for those platform drivers which are well
behaved (the majority).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Index: g26/include/linux/device.h
===================================================================
--- g26.orig/include/linux/device.h 2006-11-27 21:01:30.000000000 -0800
+++ g26/include/linux/device.h 2006-11-27 21:03:48.000000000 -0800
@@ -330,6 +330,7 @@ struct device {
struct kobject kobj;
char bus_id[BUS_ID_SIZE]; /* position on parent bus */
unsigned is_registered:1;
+ unsigned is_driver_not_hotpluggable:1;
struct device_attribute uevent_attr;
struct device_attribute *devt_attr;
Index: g26/drivers/base/platform.c
===================================================================
--- g26.orig/drivers/base/platform.c 2006-11-27 21:03:46.000000000 -0800
+++ g26/drivers/base/platform.c 2006-11-29 11:02:04.000000000 -0800
@@ -160,6 +160,11 @@ static void platform_device_release(stru
*
* Create a platform device object which can have other objects attached
* to it, and which will have attached objects freed when it is released.
+ *
+ * This device will be marked as not supporting hotpluggable drivers. In
+ * the unusual case that the device isn't being dynamically allocated as
+ * of a legacy "probe the hardware" driver, infrastructure code should
+ * consider reversing this marking.
*/
struct platform_device *platform_device_alloc(const char *name, unsigned int id)
{
@@ -172,6 +177,7 @@ struct platform_device *platform_device_
pa->pdev.id = id;
device_initialize(&pa->pdev.dev);
pa->pdev.dev.release = platform_device_release;
+ pa->pdev.dev.is_driver_not_hotpluggable = 1;
}
return pa ? &pa->pdev : NULL;
@@ -349,6 +355,13 @@ EXPORT_SYMBOL_GPL(platform_device_unregi
* memory allocated for the device allows drivers using such devices
* to be unloaded iwithout waiting for the last reference to the device
* to be dropped.
+ *
+ * This interface is primarily intended for use with legacy drivers
+ * which probe hardware directly. Because such drivers create device
+ * nodes themselves, rather than letting system infrastructure handle
+ * such device enumeration tasks, they don't fully conform to the Linux
+ * driver model. In particular, when such drivers are built as modules,
+ * they can't be "hotplugged".
*/
struct platform_device *platform_device_register_simple(char *name, unsigned int id,
struct resource *res, unsigned int num)
@@ -525,6 +538,13 @@ static int platform_uevent(struct device
{
struct platform_device *pdev = to_platform_device(dev);
+ /* prevent hotplug "modprobe $(MODALIAS)" from causing trouble in
+ * legacy probe-the-hardware drivers, which don't properly split
+ * out enumeration logic from drivers.
+ */
+ if (dev->is_driver_not_hotpluggable)
+ return 0;
+
envp[0] = buffer;
snprintf(buffer, buffer_size, "MODALIAS=%s", pdev->name);
return 0;
next parent reply other threads:[~2006-11-29 22:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20061122135948.GA7888@bongo.bofh.it>
[not found] ` <1164623293.3702.4.camel@pim.off.vrfy.org>
[not found] ` <20061127190315.GA28107@suse.de>
2006-11-29 22:50 ` David Brownell [this message]
2006-11-29 23:02 ` [patch 2.6.19-rc6] fix hotplug for legacy platform drivers Greg KH
2006-11-30 1:27 ` [Bulk] " David Brownell
2006-12-01 7:04 ` Greg KH
2006-12-05 2:28 ` David Brownell
2006-12-05 10:01 ` Marco d'Itri
2006-12-06 0:03 ` David Brownell
2006-12-06 6:08 ` Greg KH
2006-12-07 0:25 ` [Bulk] " David Brownell
2006-12-06 23:56 ` Marco d'Itri
2006-12-09 6:03 ` David Brownell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200611291450.59165.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=gregkh@suse.de \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=md@Linux.IT \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox