LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [patch 2.6.21-rc5-git 2/2] update Documentation/driver-model/platform.txt
@ 2007-03-31 21:58 David Brownell
  2007-04-02 20:16 ` Dmitry Torokhov
  0 siblings, 1 reply; 3+ messages in thread
From: David Brownell @ 2007-03-31 21:58 UTC (permalink / raw)
  To: Greg KH, Linux Kernel list; +Cc: Andres Salomon

Make note of the legacy "probe-the-hardware" drivers, and some APIs that are
mostly unused except by such drivers.  We probably can't escape having legacy
drivers for a while (e.g. old ISA drivers), but we can at least discourage
this style code for new drivers, and unless it's unavoidable.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

--- g26.orig/Documentation/driver-model/platform.txt	2007-03-31 14:26:14.000000000 -0700
+++ g26/Documentation/driver-model/platform.txt	2007-03-31 14:49:42.000000000 -0700
@@ -96,6 +96,46 @@ System setup also associates those clock
 calls to clk_get(&pdev->dev, clock_name) return them as needed.
 
 
+Legacy Drivers:  Device Probing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Some drivers are not fully converted to the driver model, because they take
+on a non-driver role:  the driver registers its platform device, rather than
+leaving that for system infrastructure.  Such drivers can't be hotplugged
+or coldplugged, since those mechanisms require device creation to be in a
+different system component than the driver.
+
+The only "good" reason for this is to handle older system designs which, like
+original IBM PCs, rely on error-prone "probe-the-hardware" models for hardware
+configuration.  Newer systems have largely abandoned that model, in favor of
+bus-level support for dynamic configuration (PCI, USB), or device tables
+provided by the boot firmware (e.g. PNPACPI on x86).  There are too many
+conflicting options about what might be where, and even educated guesses by
+an operating system will be wrong often enough to make trouble.
+
+This style of driver is discouraged.  If you're updating such a driver,
+please try to move the device enumeration to a more appropriate location,
+outside the driver.  This will usually be cleanup, since such drivers
+tend to already have "normal" modes, such as ones using device nodes that
+were created by PNP or by platform device setup.
+
+None the less, there are some APIs to support such legacy drivers.  Avoid
+using these calls except with such hotplug-deficient drivers.
+
+	struct platform_device *platform_device_alloc(
+			char *name, unsigned id);
+
+You can use platform_device_alloc() to dynamically allocate a device, which
+you will then initialize with resources and platform_device_register().
+A better solution is usually:
+
+	struct platform_device *platform_device_register_simple(
+			char *name, unsigned id,
+			struct resource *res, unsigned nres);
+
+You can use platform_device_register_simple() as a one-step call to allocate
+and register a device.
+
+
 Device Naming and Driver Binding
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 The platform_device.dev.bus_id is the canonical name for the devices.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [patch 2.6.21-rc5-git 2/2] update Documentation/driver-model/platform.txt
  2007-03-31 21:58 [patch 2.6.21-rc5-git 2/2] update Documentation/driver-model/platform.txt David Brownell
@ 2007-04-02 20:16 ` Dmitry Torokhov
  2007-04-02 21:59   ` Russell King
  0 siblings, 1 reply; 3+ messages in thread
From: Dmitry Torokhov @ 2007-04-02 20:16 UTC (permalink / raw)
  To: David Brownell; +Cc: Greg KH, Linux Kernel list, Andres Salomon

On 3/31/07, David Brownell <david-b@pacbell.net> wrote:
> +A better solution is usually:
> +
> +       struct platform_device *platform_device_register_simple(
> +                       char *name, unsigned id,
> +                       struct resource *res, unsigned nres);
> +
> +You can use platform_device_register_simple() as a one-step call to allocate
> +and register a device.

DIdn't Russell want to convert eberything to platform_device_alloc and
then nuke platfrom_device_register_simple()?

-- 
Dmitry

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [patch 2.6.21-rc5-git 2/2] update Documentation/driver-model/platform.txt
  2007-04-02 20:16 ` Dmitry Torokhov
@ 2007-04-02 21:59   ` Russell King
  0 siblings, 0 replies; 3+ messages in thread
From: Russell King @ 2007-04-02 21:59 UTC (permalink / raw)
  To: Dmitry Torokhov
  Cc: David Brownell, Greg KH, Linux Kernel list, Andres Salomon

On Mon, Apr 02, 2007 at 04:16:03PM -0400, Dmitry Torokhov wrote:
> On 3/31/07, David Brownell <david-b@pacbell.net> wrote:
> >+A better solution is usually:
> >+
> >+       struct platform_device *platform_device_register_simple(
> >+                       char *name, unsigned id,
> >+                       struct resource *res, unsigned nres);
> >+
> >+You can use platform_device_register_simple() as a one-step call to 
> >allocate
> >+and register a device.
> 
> DIdn't Russell want to convert eberything to platform_device_alloc and
> then nuke platfrom_device_register_simple()?

That was my long term plan - since I don't like APIs which "grow" lots
of different and redundant interfaces.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-04-02 21:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-31 21:58 [patch 2.6.21-rc5-git 2/2] update Documentation/driver-model/platform.txt David Brownell
2007-04-02 20:16 ` Dmitry Torokhov
2007-04-02 21:59   ` Russell King

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).