2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* device.h - generic, centralized driver model
|
|
|
|
*
|
|
|
|
* Copyright (c) 2001-2003 Patrick Mochel <mochel@osdl.org>
|
2009-05-12 05:16:57 +08:00
|
|
|
* Copyright (c) 2004-2009 Greg Kroah-Hartman <gregkh@suse.de>
|
|
|
|
* Copyright (c) 2008-2009 Novell Inc.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* This file is released under the GPLv2
|
|
|
|
*
|
|
|
|
* See Documentation/driver-model/ for more information.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _DEVICE_H_
|
|
|
|
#define _DEVICE_H_
|
|
|
|
|
|
|
|
#include <linux/ioport.h>
|
|
|
|
#include <linux/kobject.h>
|
2005-03-22 03:49:14 +08:00
|
|
|
#include <linux/klist.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/list.h>
|
2008-05-29 00:28:39 +08:00
|
|
|
#include <linux/lockdep.h>
|
2006-08-15 13:43:17 +08:00
|
|
|
#include <linux/compiler.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/types.h>
|
2011-05-27 01:46:22 +08:00
|
|
|
#include <linux/mutex.h>
|
drivers/pinctrl: grab default handles from device core
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>
2013-01-23 01:56:14 +08:00
|
|
|
#include <linux/pinctrl/devinfo.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/pm.h>
|
2011-07-27 07:09:06 +08:00
|
|
|
#include <linux/atomic.h>
|
2012-05-14 15:47:57 +08:00
|
|
|
#include <linux/ratelimit.h>
|
2013-04-07 00:56:00 +08:00
|
|
|
#include <linux/uidgid.h>
|
2013-10-12 04:11:38 +08:00
|
|
|
#include <linux/gfp.h>
|
2006-11-11 14:18:39 +08:00
|
|
|
#include <asm/device.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
struct device;
|
2008-12-17 04:23:36 +08:00
|
|
|
struct device_private;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct device_driver;
|
2007-11-29 07:59:15 +08:00
|
|
|
struct driver_private;
|
2011-05-27 01:46:22 +08:00
|
|
|
struct module;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct class;
|
2010-11-16 06:13:18 +08:00
|
|
|
struct subsys_private;
|
Driver core: udev triggered device-<>driver binding
We get two per-bus sysfs files:
ls-l /sys/subsystem/usb
drwxr-xr-x 2 root root 0 2007-02-16 16:42 devices
drwxr-xr-x 7 root root 0 2007-02-16 14:55 drivers
-rw-r--r-- 1 root root 4096 2007-02-16 16:42 drivers_autoprobe
--w------- 1 root root 4096 2007-02-16 16:42 drivers_probe
The flag "drivers_autoprobe" controls the behavior of the bus to bind
devices by default, or just initialize the device and leave it alone.
The command "drivers_probe" accepts a bus_id and the bus tries to bind a
driver to this device.
Systems who want to control the driver binding with udev, switch off the
bus initiated probing:
echo 0 > /sys/subsystem/usb/drivers_autoprobe
echo 0 > /sys/subsystem/pcmcia/drivers_autoprobe
...
and initiate the probing with udev rules like:
ACTION=="add", SUBSYSTEM=="usb", ATTR{subsystem/drivers_probe}="$kernel"
ACTION=="add", SUBSYSTEM=="pcmcia", ATTR{subsystem/drivers_probe}="$kernel"
...
Custom driver binding can happen in earlier rules by something like:
ACTION=="add", SUBSYSTEM=="usb", \
ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678" \
ATTR{subsystem/drivers/<custom-driver>/bind}="$kernel"
This is intended to solve the modprobe.conf mess with "install-rules", custom
bind/unbind-scripts and all the weird things people invented over the years.
It should also provide the functionality "libusual" was supposed to do.
With udev, one can just write a udev rule to drive all USB-disks at the
third port of USB-hub by the "ub" driver, and everything else by
usb-storage. One can also instruct udev to bind different wireless
drivers to identical cards - just selected by the pcmcia slot-number, and
whatever ...
To use the mentioned rules, it needs udev version 106, to be able to
write ATTR{}="$kernel" to sysfs files.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-17 00:33:36 +08:00
|
|
|
struct bus_type;
|
2010-04-14 07:12:28 +08:00
|
|
|
struct device_node;
|
2011-08-26 22:48:26 +08:00
|
|
|
struct iommu_ops;
|
2012-05-31 04:18:41 +08:00
|
|
|
struct iommu_group;
|
Driver core: udev triggered device-<>driver binding
We get two per-bus sysfs files:
ls-l /sys/subsystem/usb
drwxr-xr-x 2 root root 0 2007-02-16 16:42 devices
drwxr-xr-x 7 root root 0 2007-02-16 14:55 drivers
-rw-r--r-- 1 root root 4096 2007-02-16 16:42 drivers_autoprobe
--w------- 1 root root 4096 2007-02-16 16:42 drivers_probe
The flag "drivers_autoprobe" controls the behavior of the bus to bind
devices by default, or just initialize the device and leave it alone.
The command "drivers_probe" accepts a bus_id and the bus tries to bind a
driver to this device.
Systems who want to control the driver binding with udev, switch off the
bus initiated probing:
echo 0 > /sys/subsystem/usb/drivers_autoprobe
echo 0 > /sys/subsystem/pcmcia/drivers_autoprobe
...
and initiate the probing with udev rules like:
ACTION=="add", SUBSYSTEM=="usb", ATTR{subsystem/drivers_probe}="$kernel"
ACTION=="add", SUBSYSTEM=="pcmcia", ATTR{subsystem/drivers_probe}="$kernel"
...
Custom driver binding can happen in earlier rules by something like:
ACTION=="add", SUBSYSTEM=="usb", \
ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678" \
ATTR{subsystem/drivers/<custom-driver>/bind}="$kernel"
This is intended to solve the modprobe.conf mess with "install-rules", custom
bind/unbind-scripts and all the weird things people invented over the years.
It should also provide the functionality "libusual" was supposed to do.
With udev, one can just write a udev rule to drive all USB-disks at the
third port of USB-hub by the "ub" driver, and everything else by
usb-storage. One can also instruct udev to bind different wireless
drivers to identical cards - just selected by the pcmcia slot-number, and
whatever ...
To use the mentioned rules, it needs udev version 106, to be able to
write ATTR{}="$kernel" to sysfs files.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-17 00:33:36 +08:00
|
|
|
|
|
|
|
struct bus_attribute {
|
|
|
|
struct attribute attr;
|
2008-01-25 13:04:46 +08:00
|
|
|
ssize_t (*show)(struct bus_type *bus, char *buf);
|
|
|
|
ssize_t (*store)(struct bus_type *bus, const char *buf, size_t count);
|
Driver core: udev triggered device-<>driver binding
We get two per-bus sysfs files:
ls-l /sys/subsystem/usb
drwxr-xr-x 2 root root 0 2007-02-16 16:42 devices
drwxr-xr-x 7 root root 0 2007-02-16 14:55 drivers
-rw-r--r-- 1 root root 4096 2007-02-16 16:42 drivers_autoprobe
--w------- 1 root root 4096 2007-02-16 16:42 drivers_probe
The flag "drivers_autoprobe" controls the behavior of the bus to bind
devices by default, or just initialize the device and leave it alone.
The command "drivers_probe" accepts a bus_id and the bus tries to bind a
driver to this device.
Systems who want to control the driver binding with udev, switch off the
bus initiated probing:
echo 0 > /sys/subsystem/usb/drivers_autoprobe
echo 0 > /sys/subsystem/pcmcia/drivers_autoprobe
...
and initiate the probing with udev rules like:
ACTION=="add", SUBSYSTEM=="usb", ATTR{subsystem/drivers_probe}="$kernel"
ACTION=="add", SUBSYSTEM=="pcmcia", ATTR{subsystem/drivers_probe}="$kernel"
...
Custom driver binding can happen in earlier rules by something like:
ACTION=="add", SUBSYSTEM=="usb", \
ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678" \
ATTR{subsystem/drivers/<custom-driver>/bind}="$kernel"
This is intended to solve the modprobe.conf mess with "install-rules", custom
bind/unbind-scripts and all the weird things people invented over the years.
It should also provide the functionality "libusual" was supposed to do.
With udev, one can just write a udev rule to drive all USB-disks at the
third port of USB-hub by the "ub" driver, and everything else by
usb-storage. One can also instruct udev to bind different wireless
drivers to identical cards - just selected by the pcmcia slot-number, and
whatever ...
To use the mentioned rules, it needs udev version 106, to be able to
write ATTR{}="$kernel" to sysfs files.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-17 00:33:36 +08:00
|
|
|
};
|
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
#define BUS_ATTR(_name, _mode, _show, _store) \
|
2013-07-15 07:05:54 +08:00
|
|
|
struct bus_attribute bus_attr_##_name = __ATTR(_name, _mode, _show, _store)
|
|
|
|
#define BUS_ATTR_RW(_name) \
|
|
|
|
struct bus_attribute bus_attr_##_name = __ATTR_RW(_name)
|
|
|
|
#define BUS_ATTR_RO(_name) \
|
|
|
|
struct bus_attribute bus_attr_##_name = __ATTR_RO(_name)
|
Driver core: udev triggered device-<>driver binding
We get two per-bus sysfs files:
ls-l /sys/subsystem/usb
drwxr-xr-x 2 root root 0 2007-02-16 16:42 devices
drwxr-xr-x 7 root root 0 2007-02-16 14:55 drivers
-rw-r--r-- 1 root root 4096 2007-02-16 16:42 drivers_autoprobe
--w------- 1 root root 4096 2007-02-16 16:42 drivers_probe
The flag "drivers_autoprobe" controls the behavior of the bus to bind
devices by default, or just initialize the device and leave it alone.
The command "drivers_probe" accepts a bus_id and the bus tries to bind a
driver to this device.
Systems who want to control the driver binding with udev, switch off the
bus initiated probing:
echo 0 > /sys/subsystem/usb/drivers_autoprobe
echo 0 > /sys/subsystem/pcmcia/drivers_autoprobe
...
and initiate the probing with udev rules like:
ACTION=="add", SUBSYSTEM=="usb", ATTR{subsystem/drivers_probe}="$kernel"
ACTION=="add", SUBSYSTEM=="pcmcia", ATTR{subsystem/drivers_probe}="$kernel"
...
Custom driver binding can happen in earlier rules by something like:
ACTION=="add", SUBSYSTEM=="usb", \
ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678" \
ATTR{subsystem/drivers/<custom-driver>/bind}="$kernel"
This is intended to solve the modprobe.conf mess with "install-rules", custom
bind/unbind-scripts and all the weird things people invented over the years.
It should also provide the functionality "libusual" was supposed to do.
With udev, one can just write a udev rule to drive all USB-disks at the
third port of USB-hub by the "ub" driver, and everything else by
usb-storage. One can also instruct udev to bind different wireless
drivers to identical cards - just selected by the pcmcia slot-number, and
whatever ...
To use the mentioned rules, it needs udev version 106, to be able to
write ATTR{}="$kernel" to sysfs files.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-17 00:33:36 +08:00
|
|
|
|
|
|
|
extern int __must_check bus_create_file(struct bus_type *,
|
|
|
|
struct bus_attribute *);
|
|
|
|
extern void bus_remove_file(struct bus_type *, struct bus_attribute *);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-05-05 07:55:36 +08:00
|
|
|
/**
|
|
|
|
* struct bus_type - The bus type of the device
|
|
|
|
*
|
|
|
|
* @name: The name of the bus.
|
2011-12-15 06:29:38 +08:00
|
|
|
* @dev_name: Used for subsystems to enumerate devices like ("foo%u", dev->id).
|
|
|
|
* @dev_root: Default device to use as the parent.
|
2011-05-05 07:55:36 +08:00
|
|
|
* @dev_attrs: Default attributes of the devices on the bus.
|
2013-08-09 06:22:57 +08:00
|
|
|
* @bus_groups: Default attributes of the bus.
|
2013-08-09 06:22:55 +08:00
|
|
|
* @dev_groups: Default attributes of the devices on the bus.
|
2013-08-09 06:22:56 +08:00
|
|
|
* @drv_groups: Default attributes of the device drivers on the bus.
|
2011-05-05 07:55:36 +08:00
|
|
|
* @match: Called, perhaps multiple times, whenever a new device or driver
|
|
|
|
* is added for this bus. It should return a nonzero value if the
|
|
|
|
* given device can be handled by the given driver.
|
|
|
|
* @uevent: Called when a device is added, removed, or a few other things
|
|
|
|
* that generate uevents to add the environment variables.
|
|
|
|
* @probe: Called when a new device or driver add to this bus, and callback
|
|
|
|
* the specific driver's probe to initial the matched device.
|
|
|
|
* @remove: Called when a device removed from this bus.
|
|
|
|
* @shutdown: Called at shut-down time to quiesce the device.
|
Driver core: Add offline/online device operations
In some cases, graceful hot-removal of devices is not possible,
although in principle the devices in question support hotplug.
For example, that may happen for the last CPU in the system or
for memory modules holding kernel memory.
In those cases it is nice to be able to check if the given device
can be gracefully hot-removed before triggering a removal procedure
that cannot be aborted or reversed. Unfortunately, however, the
kernel currently doesn't provide any support for that.
To address that deficiency, introduce support for offline and
online operations that can be performed on devices, respectively,
before a hot-removal and in case when it is necessary (or convenient)
to put a device back online after a successful offline (that has not
been followed by removal). The idea is that the offline will fail
whenever the given device cannot be gracefully removed from the
system and it will not be allowed to use the device after a
successful offline (until a subsequent online) in analogy with the
existing CPU offline/online mechanism.
For now, the offline and online operations are introduced at the
bus type level, as that should be sufficient for the most urgent use
cases (CPUs and memory modules). In the future, however, the
approach may be extended to cover some more complicated device
offline/online scenarios involving device drivers etc.
The lock_device_hotplug() and unlock_device_hotplug() functions are
introduced because subsequent patches need to put larger pieces of
code under device_hotplug_lock to prevent race conditions between
device offline and removal from happening.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-03 04:15:29 +08:00
|
|
|
*
|
|
|
|
* @online: Called to put the device back online (after offlining it).
|
|
|
|
* @offline: Called to put the device offline for hot-removal. May fail.
|
|
|
|
*
|
2011-05-05 07:55:36 +08:00
|
|
|
* @suspend: Called when a device on this bus wants to go to sleep mode.
|
|
|
|
* @resume: Called to bring a device on this bus out of sleep mode.
|
|
|
|
* @pm: Power management operations of this bus, callback the specific
|
|
|
|
* device driver's pm-ops.
|
2011-11-02 02:15:40 +08:00
|
|
|
* @iommu_ops: IOMMU specific operations for this bus, used to attach IOMMU
|
2011-08-26 22:48:26 +08:00
|
|
|
* driver implementations to a bus and allow the driver to do
|
|
|
|
* bus-specific setup
|
2011-05-05 07:55:36 +08:00
|
|
|
* @p: The private data of the driver core, only the driver core can
|
|
|
|
* touch this.
|
2013-06-26 11:57:06 +08:00
|
|
|
* @lock_key: Lock class key for use by the lock validator
|
2011-05-05 07:55:36 +08:00
|
|
|
*
|
|
|
|
* A bus is a channel between the processor and one or more devices. For the
|
|
|
|
* purposes of the device model, all devices are connected via a bus, even if
|
|
|
|
* it is an internal, virtual, "platform" bus. Buses can plug into each other.
|
|
|
|
* A USB controller is usually a PCI device, for example. The device model
|
|
|
|
* represents the actual connections between buses and the devices they control.
|
|
|
|
* A bus is represented by the bus_type structure. It contains the name, the
|
|
|
|
* default attributes, the bus' methods, PM operations, and the driver core's
|
|
|
|
* private data.
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
struct bus_type {
|
2008-01-25 13:04:46 +08:00
|
|
|
const char *name;
|
2011-12-15 06:29:38 +08:00
|
|
|
const char *dev_name;
|
|
|
|
struct device *dev_root;
|
2013-08-09 06:22:55 +08:00
|
|
|
struct device_attribute *dev_attrs; /* use dev_groups instead */
|
2013-08-09 06:22:57 +08:00
|
|
|
const struct attribute_group **bus_groups;
|
2013-08-09 06:22:55 +08:00
|
|
|
const struct attribute_group **dev_groups;
|
2013-08-09 06:22:56 +08:00
|
|
|
const struct attribute_group **drv_groups;
|
2008-01-25 13:04:46 +08:00
|
|
|
|
|
|
|
int (*match)(struct device *dev, struct device_driver *drv);
|
|
|
|
int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
|
|
|
|
int (*probe)(struct device *dev);
|
|
|
|
int (*remove)(struct device *dev);
|
|
|
|
void (*shutdown)(struct device *dev);
|
|
|
|
|
Driver core: Add offline/online device operations
In some cases, graceful hot-removal of devices is not possible,
although in principle the devices in question support hotplug.
For example, that may happen for the last CPU in the system or
for memory modules holding kernel memory.
In those cases it is nice to be able to check if the given device
can be gracefully hot-removed before triggering a removal procedure
that cannot be aborted or reversed. Unfortunately, however, the
kernel currently doesn't provide any support for that.
To address that deficiency, introduce support for offline and
online operations that can be performed on devices, respectively,
before a hot-removal and in case when it is necessary (or convenient)
to put a device back online after a successful offline (that has not
been followed by removal). The idea is that the offline will fail
whenever the given device cannot be gracefully removed from the
system and it will not be allowed to use the device after a
successful offline (until a subsequent online) in analogy with the
existing CPU offline/online mechanism.
For now, the offline and online operations are introduced at the
bus type level, as that should be sufficient for the most urgent use
cases (CPUs and memory modules). In the future, however, the
approach may be extended to cover some more complicated device
offline/online scenarios involving device drivers etc.
The lock_device_hotplug() and unlock_device_hotplug() functions are
introduced because subsequent patches need to put larger pieces of
code under device_hotplug_lock to prevent race conditions between
device offline and removal from happening.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-03 04:15:29 +08:00
|
|
|
int (*online)(struct device *dev);
|
|
|
|
int (*offline)(struct device *dev);
|
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
int (*suspend)(struct device *dev, pm_message_t state);
|
|
|
|
int (*resume)(struct device *dev);
|
Driver core: udev triggered device-<>driver binding
We get two per-bus sysfs files:
ls-l /sys/subsystem/usb
drwxr-xr-x 2 root root 0 2007-02-16 16:42 devices
drwxr-xr-x 7 root root 0 2007-02-16 14:55 drivers
-rw-r--r-- 1 root root 4096 2007-02-16 16:42 drivers_autoprobe
--w------- 1 root root 4096 2007-02-16 16:42 drivers_probe
The flag "drivers_autoprobe" controls the behavior of the bus to bind
devices by default, or just initialize the device and leave it alone.
The command "drivers_probe" accepts a bus_id and the bus tries to bind a
driver to this device.
Systems who want to control the driver binding with udev, switch off the
bus initiated probing:
echo 0 > /sys/subsystem/usb/drivers_autoprobe
echo 0 > /sys/subsystem/pcmcia/drivers_autoprobe
...
and initiate the probing with udev rules like:
ACTION=="add", SUBSYSTEM=="usb", ATTR{subsystem/drivers_probe}="$kernel"
ACTION=="add", SUBSYSTEM=="pcmcia", ATTR{subsystem/drivers_probe}="$kernel"
...
Custom driver binding can happen in earlier rules by something like:
ACTION=="add", SUBSYSTEM=="usb", \
ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678" \
ATTR{subsystem/drivers/<custom-driver>/bind}="$kernel"
This is intended to solve the modprobe.conf mess with "install-rules", custom
bind/unbind-scripts and all the weird things people invented over the years.
It should also provide the functionality "libusual" was supposed to do.
With udev, one can just write a udev rule to drive all USB-disks at the
third port of USB-hub by the "ub" driver, and everything else by
usb-storage. One can also instruct udev to bind different wireless
drivers to identical cards - just selected by the pcmcia slot-number, and
whatever ...
To use the mentioned rules, it needs udev version 106, to be able to
write ATTR{}="$kernel" to sysfs files.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2007-02-17 00:33:36 +08:00
|
|
|
|
2009-07-25 13:11:32 +08:00
|
|
|
const struct dev_pm_ops *pm;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-21 05:00:01 +08:00
|
|
|
|
2011-08-26 22:48:26 +08:00
|
|
|
struct iommu_ops *iommu_ops;
|
|
|
|
|
2010-11-16 06:13:18 +08:00
|
|
|
struct subsys_private *p;
|
2013-03-13 00:21:19 +08:00
|
|
|
struct lock_class_key lock_key;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2013-03-13 00:21:19 +08:00
|
|
|
extern int __must_check bus_register(struct bus_type *bus);
|
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
extern void bus_unregister(struct bus_type *bus);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
extern int __must_check bus_rescan_devices(struct bus_type *bus);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* iterator helpers for buses */
|
2011-12-15 06:29:38 +08:00
|
|
|
struct subsys_dev_iter {
|
|
|
|
struct klist_iter ki;
|
|
|
|
const struct device_type *type;
|
|
|
|
};
|
2012-04-20 10:17:30 +08:00
|
|
|
void subsys_dev_iter_init(struct subsys_dev_iter *iter,
|
2011-12-15 06:29:38 +08:00
|
|
|
struct bus_type *subsys,
|
|
|
|
struct device *start,
|
|
|
|
const struct device_type *type);
|
|
|
|
struct device *subsys_dev_iter_next(struct subsys_dev_iter *iter);
|
|
|
|
void subsys_dev_iter_exit(struct subsys_dev_iter *iter);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
int bus_for_each_dev(struct bus_type *bus, struct device *start, void *data,
|
|
|
|
int (*fn)(struct device *dev, void *data));
|
|
|
|
struct device *bus_find_device(struct bus_type *bus, struct device *start,
|
|
|
|
void *data,
|
|
|
|
int (*match)(struct device *dev, void *data));
|
2008-01-28 02:29:20 +08:00
|
|
|
struct device *bus_find_device_by_name(struct bus_type *bus,
|
|
|
|
struct device *start,
|
|
|
|
const char *name);
|
2011-12-15 06:29:38 +08:00
|
|
|
struct device *subsys_find_device_by_id(struct bus_type *bus, unsigned int id,
|
|
|
|
struct device *hint);
|
2010-06-16 17:44:18 +08:00
|
|
|
int bus_for_each_drv(struct bus_type *bus, struct device_driver *start,
|
|
|
|
void *data, int (*fn)(struct device_driver *, void *));
|
2008-08-27 00:00:57 +08:00
|
|
|
void bus_sort_breadthfirst(struct bus_type *bus,
|
|
|
|
int (*compare)(const struct device *a,
|
|
|
|
const struct device *b));
|
Driver core: add notification of bus events
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.
That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.
There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.
The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.
- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-25 11:44:59 +08:00
|
|
|
/*
|
|
|
|
* Bus notifiers: Get notified of addition/removal of devices
|
|
|
|
* and binding/unbinding of drivers to devices.
|
|
|
|
* In the long run, it should be a replacement for the platform
|
|
|
|
* notify hooks.
|
|
|
|
*/
|
|
|
|
struct notifier_block;
|
|
|
|
|
|
|
|
extern int bus_register_notifier(struct bus_type *bus,
|
|
|
|
struct notifier_block *nb);
|
|
|
|
extern int bus_unregister_notifier(struct bus_type *bus,
|
|
|
|
struct notifier_block *nb);
|
|
|
|
|
|
|
|
/* All 4 notifers below get called with the target struct device *
|
|
|
|
* as an argument. Note that those functions are likely to be called
|
2010-02-18 02:57:05 +08:00
|
|
|
* with the device lock held in the core, so be careful.
|
Driver core: add notification of bus events
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.
That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.
There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.
The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.
- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-25 11:44:59 +08:00
|
|
|
*/
|
|
|
|
#define BUS_NOTIFY_ADD_DEVICE 0x00000001 /* device added */
|
|
|
|
#define BUS_NOTIFY_DEL_DEVICE 0x00000002 /* device removed */
|
2010-07-23 18:56:18 +08:00
|
|
|
#define BUS_NOTIFY_BIND_DRIVER 0x00000003 /* driver about to be
|
|
|
|
bound */
|
|
|
|
#define BUS_NOTIFY_BOUND_DRIVER 0x00000004 /* driver bound to device */
|
|
|
|
#define BUS_NOTIFY_UNBIND_DRIVER 0x00000005 /* driver about to be
|
Driver core: add notification of bus events
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.
That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.
There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.
The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.
- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-25 11:44:59 +08:00
|
|
|
unbound */
|
2010-07-23 18:56:18 +08:00
|
|
|
#define BUS_NOTIFY_UNBOUND_DRIVER 0x00000006 /* driver is unbound
|
2009-04-24 20:57:00 +08:00
|
|
|
from the device */
|
Driver core: add notification of bus events
I finally did as you suggested and added the notifier to the struct
bus_type itself. There are still problems to be expected is something
attaches to a bus type where the code can hook in different struct
device sub-classes (which is imho a big bogosity but I won't even try to
argue that case now) but it will solve nicely a number of issues I've
had so far.
That also means that clients interested in registering for such
notifications have to do it before devices are added and after bus types
are registered. Fortunately, most bus types that matter for the various
usage scenarios I have in mind are registerd at postcore_initcall time,
which means I have a really nice spot at arch_initcall time to add my
notifiers.
There are 4 notifications provided. Device being added (before hooked to
the bus) and removed (failure of previous case or after being unhooked
from the bus), along with driver being bound to a device and about to be
unbound.
The usage I have for these are:
- The 2 first ones are used to maintain a struct device_ext that is
hooked to struct device.firmware_data. This structure contains for now a
pointer to the Open Firmware node related to the device (if any), the
NUMA node ID (for quick access to it) and the DMA operations pointers &
iommu table instance for DMA to/from this device. For bus types I own
(like IBM VIO or EBUS), I just maintain that structure directly from the
bus code when creating the devices. But for bus types managed by generic
code like PCI or platform (actually, of_platform which is a variation of
platform linked to Open Firmware device-tree), I need this notifier.
- The other two ones have a completely different usage scenario. I have
cases where multiple devices and their drivers depend on each other. For
example, the IBM EMAC network driver needs to attach to a MAL DMA engine
which is a separate device, and a PHY interface which is also a separate
device. They are all of_platform_device's (well, about to be with my
upcoming patches) but there is no say in what precise order the core
will "probe" them and instanciate the various modules. The solution I
found for that is to have the drivers for emac to use multithread_probe,
and wait for a driver to be bound to the target MAL and PHY control
devices (the device-tree contains reference to the MAL and PHY interface
nodes, which I can then match to of_platform_devices). Right now, I've
been polling, but with that notifier, I can more cleanly wait (with a
timeout of course).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-10-25 11:44:59 +08:00
|
|
|
|
2007-11-02 10:41:16 +08:00
|
|
|
extern struct kset *bus_get_kset(struct bus_type *bus);
|
2007-11-02 10:41:16 +08:00
|
|
|
extern struct klist *bus_get_device_klist(struct bus_type *bus);
|
2007-11-02 10:41:16 +08:00
|
|
|
|
2011-05-05 07:55:36 +08:00
|
|
|
/**
|
|
|
|
* struct device_driver - The basic device driver structure
|
|
|
|
* @name: Name of the device driver.
|
|
|
|
* @bus: The bus which the device of this driver belongs to.
|
|
|
|
* @owner: The module owner.
|
|
|
|
* @mod_name: Used for built-in modules.
|
|
|
|
* @suppress_bind_attrs: Disables bind/unbind via sysfs.
|
|
|
|
* @of_match_table: The open firmware table.
|
driver core / ACPI: Move ACPI support to core device and driver types
With ACPI 5 we are starting to see devices that don't natively support
discovery but can be enumerated with the help of the ACPI namespace.
Typically, these devices can be represented in the Linux device driver
model as platform devices or some serial bus devices, like SPI or I2C
devices.
Since we want to re-use existing drivers for those devices, we need a
way for drivers to specify the ACPI IDs of supported devices, so that
they can be matched against device nodes in the ACPI namespace. To
this end, it is sufficient to add a pointer to an array of supported
ACPI device IDs, that can be provided by the driver, to struct device.
Moreover, things like ACPI power management need to have access to
the ACPI handle of each supported device, because that handle is used
to invoke AML methods associated with the corresponding ACPI device
node. The ACPI handles of devices are now stored in the archdata
member structure of struct device whose definition depends on the
architecture and includes the ACPI handle only on x86 and ia64. Since
the pointer to an array of supported ACPI IDs is added to struct
device_driver in an architecture-independent way, it is logical to
move the ACPI handle from archdata to struct device itself at the same
time. This also makes code more straightforward in some places and
follows the example of Device Trees that have a poiter to struct
device_node in there too.
This changeset is based on Mika Westerberg's work.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Acked-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-01 05:44:33 +08:00
|
|
|
* @acpi_match_table: The ACPI match table.
|
2011-05-05 07:55:36 +08:00
|
|
|
* @probe: Called to query the existence of a specific device,
|
|
|
|
* whether this driver can work with it, and bind the driver
|
|
|
|
* to a specific device.
|
|
|
|
* @remove: Called when the device is removed from the system to
|
|
|
|
* unbind a device from this driver.
|
|
|
|
* @shutdown: Called at shut-down time to quiesce the device.
|
|
|
|
* @suspend: Called to put the device to sleep mode. Usually to a
|
|
|
|
* low power state.
|
|
|
|
* @resume: Called to bring a device from sleep mode.
|
|
|
|
* @groups: Default attributes that get created by the driver core
|
|
|
|
* automatically.
|
|
|
|
* @pm: Power management operations of the device which matched
|
|
|
|
* this driver.
|
|
|
|
* @p: Driver core's private data, no one other than the driver
|
|
|
|
* core can touch this.
|
|
|
|
*
|
|
|
|
* The device driver-model tracks all of the drivers known to the system.
|
|
|
|
* The main reason for this tracking is to enable the driver core to match
|
|
|
|
* up drivers with new devices. Once drivers are known objects within the
|
|
|
|
* system, however, a number of other things become possible. Device drivers
|
|
|
|
* can export information and configuration variables that are independent
|
|
|
|
* of any specific device.
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
struct device_driver {
|
2007-11-29 07:59:15 +08:00
|
|
|
const char *name;
|
|
|
|
struct bus_type *bus;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-11-29 07:59:15 +08:00
|
|
|
struct module *owner;
|
2009-10-13 11:17:41 +08:00
|
|
|
const char *mod_name; /* used for built-in modules */
|
|
|
|
|
|
|
|
bool suppress_bind_attrs; /* disables bind/unbind via sysfs */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-04-14 07:13:01 +08:00
|
|
|
const struct of_device_id *of_match_table;
|
driver core / ACPI: Move ACPI support to core device and driver types
With ACPI 5 we are starting to see devices that don't natively support
discovery but can be enumerated with the help of the ACPI namespace.
Typically, these devices can be represented in the Linux device driver
model as platform devices or some serial bus devices, like SPI or I2C
devices.
Since we want to re-use existing drivers for those devices, we need a
way for drivers to specify the ACPI IDs of supported devices, so that
they can be matched against device nodes in the ACPI namespace. To
this end, it is sufficient to add a pointer to an array of supported
ACPI device IDs, that can be provided by the driver, to struct device.
Moreover, things like ACPI power management need to have access to
the ACPI handle of each supported device, because that handle is used
to invoke AML methods associated with the corresponding ACPI device
node. The ACPI handles of devices are now stored in the archdata
member structure of struct device whose definition depends on the
architecture and includes the ACPI handle only on x86 and ia64. Since
the pointer to an array of supported ACPI IDs is added to struct
device_driver in an architecture-independent way, it is logical to
move the ACPI handle from archdata to struct device itself at the same
time. This also makes code more straightforward in some places and
follows the example of Device Trees that have a poiter to struct
device_node in there too.
This changeset is based on Mika Westerberg's work.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Acked-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-01 05:44:33 +08:00
|
|
|
const struct acpi_device_id *acpi_match_table;
|
2010-04-14 07:13:01 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
int (*probe) (struct device *dev);
|
|
|
|
int (*remove) (struct device *dev);
|
|
|
|
void (*shutdown) (struct device *dev);
|
|
|
|
int (*suspend) (struct device *dev, pm_message_t state);
|
|
|
|
int (*resume) (struct device *dev);
|
2009-06-25 01:06:31 +08:00
|
|
|
const struct attribute_group **groups;
|
2007-11-29 07:59:15 +08:00
|
|
|
|
2009-07-25 13:11:32 +08:00
|
|
|
const struct dev_pm_ops *pm;
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-21 05:00:01 +08:00
|
|
|
|
2007-11-29 07:59:15 +08:00
|
|
|
struct driver_private *p;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
extern int __must_check driver_register(struct device_driver *drv);
|
|
|
|
extern void driver_unregister(struct device_driver *drv);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
extern struct device_driver *driver_find(const char *name,
|
|
|
|
struct bus_type *bus);
|
2006-07-19 01:59:59 +08:00
|
|
|
extern int driver_probe_done(void);
|
2009-02-21 16:45:07 +08:00
|
|
|
extern void wait_for_device_probe(void);
|
2009-02-14 08:59:06 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2007-02-18 02:13:42 +08:00
|
|
|
/* sysfs interface for exporting driver attributes */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
struct driver_attribute {
|
2008-01-25 13:04:46 +08:00
|
|
|
struct attribute attr;
|
|
|
|
ssize_t (*show)(struct device_driver *driver, char *buf);
|
|
|
|
ssize_t (*store)(struct device_driver *driver, const char *buf,
|
|
|
|
size_t count);
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2013-07-15 07:05:54 +08:00
|
|
|
#define DRIVER_ATTR(_name, _mode, _show, _store) \
|
|
|
|
struct driver_attribute driver_attr_##_name = __ATTR(_name, _mode, _show, _store)
|
|
|
|
#define DRIVER_ATTR_RW(_name) \
|
|
|
|
struct driver_attribute driver_attr_##_name = __ATTR_RW(_name)
|
|
|
|
#define DRIVER_ATTR_RO(_name) \
|
|
|
|
struct driver_attribute driver_attr_##_name = __ATTR_RO(_name)
|
2013-08-24 06:02:56 +08:00
|
|
|
#define DRIVER_ATTR_WO(_name) \
|
|
|
|
struct driver_attribute driver_attr_##_name = __ATTR_WO(_name)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
extern int __must_check driver_create_file(struct device_driver *driver,
|
2009-12-18 21:34:21 +08:00
|
|
|
const struct driver_attribute *attr);
|
2008-01-25 13:04:46 +08:00
|
|
|
extern void driver_remove_file(struct device_driver *driver,
|
2009-12-18 21:34:21 +08:00
|
|
|
const struct driver_attribute *attr);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
extern int __must_check driver_for_each_device(struct device_driver *drv,
|
|
|
|
struct device *start,
|
|
|
|
void *data,
|
|
|
|
int (*fn)(struct device *dev,
|
|
|
|
void *));
|
|
|
|
struct device *driver_find_device(struct device_driver *drv,
|
|
|
|
struct device *start, void *data,
|
|
|
|
int (*match)(struct device *dev, void *data));
|
2005-03-22 02:59:56 +08:00
|
|
|
|
2011-12-15 06:29:38 +08:00
|
|
|
/**
|
|
|
|
* struct subsys_interface - interfaces to device functions
|
2012-01-22 03:02:51 +08:00
|
|
|
* @name: name of the device function
|
|
|
|
* @subsys: subsytem of the devices to attach to
|
|
|
|
* @node: the list of functions registered at the subsystem
|
|
|
|
* @add_dev: device hookup to device function handler
|
|
|
|
* @remove_dev: device hookup to device function handler
|
2011-12-15 06:29:38 +08:00
|
|
|
*
|
|
|
|
* Simple interfaces attached to a subsystem. Multiple interfaces can
|
|
|
|
* attach to a subsystem and its devices. Unlike drivers, they do not
|
|
|
|
* exclusively claim or control devices. Interfaces usually represent
|
|
|
|
* a specific functionality of a subsystem/class of devices.
|
|
|
|
*/
|
|
|
|
struct subsys_interface {
|
|
|
|
const char *name;
|
|
|
|
struct bus_type *subsys;
|
|
|
|
struct list_head node;
|
|
|
|
int (*add_dev)(struct device *dev, struct subsys_interface *sif);
|
|
|
|
int (*remove_dev)(struct device *dev, struct subsys_interface *sif);
|
|
|
|
};
|
|
|
|
|
|
|
|
int subsys_interface_register(struct subsys_interface *sif);
|
|
|
|
void subsys_interface_unregister(struct subsys_interface *sif);
|
|
|
|
|
|
|
|
int subsys_system_register(struct bus_type *subsys,
|
|
|
|
const struct attribute_group **groups);
|
2013-03-13 02:30:05 +08:00
|
|
|
int subsys_virtual_register(struct bus_type *subsys,
|
|
|
|
const struct attribute_group **groups);
|
2011-12-15 06:29:38 +08:00
|
|
|
|
2011-05-05 07:55:36 +08:00
|
|
|
/**
|
|
|
|
* struct class - device classes
|
|
|
|
* @name: Name of the class.
|
|
|
|
* @owner: The module owner.
|
|
|
|
* @class_attrs: Default attributes of this class.
|
2013-07-15 07:05:58 +08:00
|
|
|
* @dev_groups: Default attributes of the devices that belong to the class.
|
2011-05-05 07:55:36 +08:00
|
|
|
* @dev_kobj: The kobject that represents this class and links it into the hierarchy.
|
|
|
|
* @dev_uevent: Called when a device is added, removed from this class, or a
|
|
|
|
* few other things that generate uevents to add the environment
|
|
|
|
* variables.
|
|
|
|
* @devnode: Callback to provide the devtmpfs.
|
|
|
|
* @class_release: Called to release this class.
|
|
|
|
* @dev_release: Called to release the device.
|
|
|
|
* @suspend: Used to put the device to sleep mode, usually to a low power
|
|
|
|
* state.
|
|
|
|
* @resume: Used to bring the device from the sleep mode.
|
|
|
|
* @ns_type: Callbacks so sysfs can detemine namespaces.
|
|
|
|
* @namespace: Namespace of the device belongs to this class.
|
|
|
|
* @pm: The default device power management operations of this class.
|
|
|
|
* @p: The private data of the driver core, no one other than the
|
|
|
|
* driver core can touch this.
|
|
|
|
*
|
|
|
|
* A class is a higher-level view of a device that abstracts out low-level
|
|
|
|
* implementation details. Drivers may see a SCSI disk or an ATA disk, but,
|
|
|
|
* at the class level, they are all simply disks. Classes allow user space
|
|
|
|
* to work with devices based on what they do, rather than how they are
|
|
|
|
* connected or how they work.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
struct class {
|
2008-01-25 13:04:46 +08:00
|
|
|
const char *name;
|
|
|
|
struct module *owner;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
struct class_attribute *class_attrs;
|
2013-07-15 07:05:58 +08:00
|
|
|
const struct attribute_group **dev_groups;
|
2008-04-22 01:51:07 +08:00
|
|
|
struct kobject *dev_kobj;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
int (*dev_uevent)(struct device *dev, struct kobj_uevent_env *env);
|
2011-07-24 08:24:48 +08:00
|
|
|
char *(*devnode)(struct device *dev, umode_t *mode);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
void (*class_release)(struct class *class);
|
|
|
|
void (*dev_release)(struct device *dev);
|
2006-06-25 05:50:29 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
int (*suspend)(struct device *dev, pm_message_t state);
|
|
|
|
int (*resume)(struct device *dev);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-21 05:00:01 +08:00
|
|
|
|
2010-03-31 02:31:25 +08:00
|
|
|
const struct kobj_ns_type_operations *ns_type;
|
|
|
|
const void *(*namespace)(struct device *dev);
|
|
|
|
|
2009-07-25 13:11:32 +08:00
|
|
|
const struct dev_pm_ops *pm;
|
|
|
|
|
2010-11-16 06:13:18 +08:00
|
|
|
struct subsys_private *p;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2008-08-26 01:50:19 +08:00
|
|
|
struct class_dev_iter {
|
|
|
|
struct klist_iter ki;
|
|
|
|
const struct device_type *type;
|
|
|
|
};
|
|
|
|
|
2008-04-22 01:51:07 +08:00
|
|
|
extern struct kobject *sysfs_dev_block_kobj;
|
|
|
|
extern struct kobject *sysfs_dev_char_kobj;
|
2008-05-29 00:28:39 +08:00
|
|
|
extern int __must_check __class_register(struct class *class,
|
|
|
|
struct lock_class_key *key);
|
2008-01-25 13:04:46 +08:00
|
|
|
extern void class_unregister(struct class *class);
|
2008-05-29 00:28:39 +08:00
|
|
|
|
|
|
|
/* This is a #define to keep the compiler from merging different
|
|
|
|
* instances of the __key variable */
|
|
|
|
#define class_register(class) \
|
|
|
|
({ \
|
|
|
|
static struct lock_class_key __key; \
|
|
|
|
__class_register(class, &__key); \
|
|
|
|
})
|
|
|
|
|
2009-08-04 18:55:34 +08:00
|
|
|
struct class_compat;
|
|
|
|
struct class_compat *class_compat_register(const char *name);
|
|
|
|
void class_compat_unregister(struct class_compat *cls);
|
|
|
|
int class_compat_create_link(struct class_compat *cls, struct device *dev,
|
|
|
|
struct device *device_link);
|
|
|
|
void class_compat_remove_link(struct class_compat *cls, struct device *dev,
|
|
|
|
struct device *device_link);
|
|
|
|
|
2012-04-20 10:17:30 +08:00
|
|
|
extern void class_dev_iter_init(struct class_dev_iter *iter,
|
|
|
|
struct class *class,
|
|
|
|
struct device *start,
|
|
|
|
const struct device_type *type);
|
2008-08-26 01:50:19 +08:00
|
|
|
extern struct device *class_dev_iter_next(struct class_dev_iter *iter);
|
|
|
|
extern void class_dev_iter_exit(struct class_dev_iter *iter);
|
|
|
|
|
2008-05-23 05:21:08 +08:00
|
|
|
extern int class_for_each_device(struct class *class, struct device *start,
|
|
|
|
void *data,
|
2008-01-22 15:27:08 +08:00
|
|
|
int (*fn)(struct device *dev, void *data));
|
2008-05-23 05:21:08 +08:00
|
|
|
extern struct device *class_find_device(struct class *class,
|
2013-02-02 03:40:17 +08:00
|
|
|
struct device *start, const void *data,
|
|
|
|
int (*match)(struct device *, const void *));
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
struct class_attribute {
|
2008-01-25 13:04:46 +08:00
|
|
|
struct attribute attr;
|
2010-01-05 19:48:07 +08:00
|
|
|
ssize_t (*show)(struct class *class, struct class_attribute *attr,
|
|
|
|
char *buf);
|
|
|
|
ssize_t (*store)(struct class *class, struct class_attribute *attr,
|
|
|
|
const char *buf, size_t count);
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2013-07-15 07:05:54 +08:00
|
|
|
#define CLASS_ATTR(_name, _mode, _show, _store) \
|
|
|
|
struct class_attribute class_attr_##_name = __ATTR(_name, _mode, _show, _store)
|
|
|
|
#define CLASS_ATTR_RW(_name) \
|
|
|
|
struct class_attribute class_attr_##_name = __ATTR_RW(_name)
|
|
|
|
#define CLASS_ATTR_RO(_name) \
|
|
|
|
struct class_attribute class_attr_##_name = __ATTR_RO(_name)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-09-12 10:29:04 +08:00
|
|
|
extern int __must_check class_create_file_ns(struct class *class,
|
|
|
|
const struct class_attribute *attr,
|
|
|
|
const void *ns);
|
|
|
|
extern void class_remove_file_ns(struct class *class,
|
|
|
|
const struct class_attribute *attr,
|
|
|
|
const void *ns);
|
|
|
|
|
|
|
|
static inline int __must_check class_create_file(struct class *class,
|
|
|
|
const struct class_attribute *attr)
|
|
|
|
{
|
|
|
|
return class_create_file_ns(class, attr, NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void class_remove_file(struct class *class,
|
|
|
|
const struct class_attribute *attr)
|
|
|
|
{
|
|
|
|
return class_remove_file_ns(class, attr, NULL);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-01-05 19:48:08 +08:00
|
|
|
/* Simple class attribute that is just a static string */
|
|
|
|
struct class_attribute_string {
|
|
|
|
struct class_attribute attr;
|
|
|
|
char *str;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Currently read-only only */
|
|
|
|
#define _CLASS_ATTR_STRING(_name, _mode, _str) \
|
|
|
|
{ __ATTR(_name, _mode, show_class_attr_string, NULL), _str }
|
|
|
|
#define CLASS_ATTR_STRING(_name, _mode, _str) \
|
|
|
|
struct class_attribute_string class_attr_##_name = \
|
|
|
|
_CLASS_ATTR_STRING(_name, _mode, _str)
|
|
|
|
|
|
|
|
extern ssize_t show_class_attr_string(struct class *class, struct class_attribute *attr,
|
|
|
|
char *buf);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
struct class_interface {
|
|
|
|
struct list_head node;
|
|
|
|
struct class *class;
|
|
|
|
|
2006-09-13 21:34:05 +08:00
|
|
|
int (*add_dev) (struct device *, struct class_interface *);
|
|
|
|
void (*remove_dev) (struct device *, struct class_interface *);
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2006-08-15 13:43:17 +08:00
|
|
|
extern int __must_check class_interface_register(struct class_interface *);
|
2005-04-17 06:20:36 +08:00
|
|
|
extern void class_interface_unregister(struct class_interface *);
|
|
|
|
|
2008-05-29 00:28:39 +08:00
|
|
|
extern struct class * __must_check __class_create(struct module *owner,
|
|
|
|
const char *name,
|
|
|
|
struct lock_class_key *key);
|
2005-03-16 03:54:21 +08:00
|
|
|
extern void class_destroy(struct class *cls);
|
|
|
|
|
2008-05-29 00:28:39 +08:00
|
|
|
/* This is a #define to keep the compiler from merging different
|
|
|
|
* instances of the __key variable */
|
|
|
|
#define class_create(owner, name) \
|
|
|
|
({ \
|
|
|
|
static struct lock_class_key __key; \
|
|
|
|
__class_create(owner, name, &__key); \
|
|
|
|
})
|
|
|
|
|
2007-03-13 04:08:57 +08:00
|
|
|
/*
|
|
|
|
* The type of device, "struct device" is embedded in. A class
|
|
|
|
* or bus can contain devices of different types
|
|
|
|
* like "partitions" and "disks", "mouse" and "event".
|
|
|
|
* This identifies the device type and carries type-specific
|
|
|
|
* information, equivalent to the kobj_type of a kobject.
|
|
|
|
* If "name" is specified, the uevent will contain it in
|
|
|
|
* the DEVTYPE variable.
|
|
|
|
*/
|
2006-10-08 03:54:55 +08:00
|
|
|
struct device_type {
|
2007-03-13 04:08:57 +08:00
|
|
|
const char *name;
|
2009-06-25 01:06:31 +08:00
|
|
|
const struct attribute_group **groups;
|
2007-08-14 21:15:12 +08:00
|
|
|
int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
|
2013-04-07 00:56:00 +08:00
|
|
|
char *(*devnode)(struct device *dev, umode_t *mode,
|
2013-04-12 02:43:29 +08:00
|
|
|
kuid_t *uid, kgid_t *gid);
|
2006-10-08 03:54:55 +08:00
|
|
|
void (*release)(struct device *dev);
|
Introduce new top level suspend and hibernation callbacks
Introduce 'struct pm_ops' and 'struct pm_ext_ops' ('ext' meaning
'extended') representing suspend and hibernation operations for bus
types, device classes, device types and device drivers.
Modify the PM core to use 'struct pm_ops' and 'struct pm_ext_ops'
objects, if defined, instead of the ->suspend(), ->resume(),
->suspend_late(), and ->resume_early() callbacks (the old callbacks
will be considered as legacy and gradually phased out).
The main purpose of doing this is to separate suspend (aka S2RAM and
standby) callbacks from hibernation callbacks in such a way that the
new callbacks won't take arguments and the semantics of each of them
will be clearly specified. This has been requested for multiple
times by many people, including Linus himself, and the reason is that
within the current scheme if ->resume() is called, for example, it's
difficult to say why it's been called (ie. is it a resume from RAM or
from hibernation or a suspend/hibernation failure etc.?).
The second purpose is to make the suspend/hibernation callbacks more
flexible so that device drivers can handle more than they can within
the current scheme. For example, some drivers may need to prevent
new children of the device from being registered before their
->suspend() callbacks are executed or they may want to carry out some
operations requiring the availability of some other devices, not
directly bound via the parent-child relationship, in order to prepare
for the execution of ->suspend(), etc.
Ultimately, we'd like to stop using the freezing of tasks for suspend
and therefore the drivers' suspend/hibernation code will have to take
care of the handling of the user space during suspend/hibernation.
That, in turn, would be difficult within the current scheme, without
the new ->prepare() and ->complete() callbacks.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2008-05-21 05:00:01 +08:00
|
|
|
|
2009-07-25 13:11:32 +08:00
|
|
|
const struct dev_pm_ops *pm;
|
2006-10-08 03:54:55 +08:00
|
|
|
};
|
|
|
|
|
2005-10-01 20:49:43 +08:00
|
|
|
/* interface for exporting device attributes */
|
|
|
|
struct device_attribute {
|
|
|
|
struct attribute attr;
|
|
|
|
ssize_t (*show)(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf);
|
|
|
|
ssize_t (*store)(struct device *dev, struct device_attribute *attr,
|
|
|
|
const char *buf, size_t count);
|
|
|
|
};
|
|
|
|
|
2011-12-15 06:29:38 +08:00
|
|
|
struct dev_ext_attribute {
|
|
|
|
struct device_attribute attr;
|
|
|
|
void *var;
|
|
|
|
};
|
|
|
|
|
|
|
|
ssize_t device_show_ulong(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf);
|
|
|
|
ssize_t device_store_ulong(struct device *dev, struct device_attribute *attr,
|
|
|
|
const char *buf, size_t count);
|
|
|
|
ssize_t device_show_int(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf);
|
|
|
|
ssize_t device_store_int(struct device *dev, struct device_attribute *attr,
|
|
|
|
const char *buf, size_t count);
|
2012-10-10 01:52:05 +08:00
|
|
|
ssize_t device_show_bool(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf);
|
|
|
|
ssize_t device_store_bool(struct device *dev, struct device_attribute *attr,
|
|
|
|
const char *buf, size_t count);
|
2005-10-01 20:49:43 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
#define DEVICE_ATTR(_name, _mode, _show, _store) \
|
2011-12-15 06:29:38 +08:00
|
|
|
struct device_attribute dev_attr_##_name = __ATTR(_name, _mode, _show, _store)
|
2013-07-15 07:05:54 +08:00
|
|
|
#define DEVICE_ATTR_RW(_name) \
|
|
|
|
struct device_attribute dev_attr_##_name = __ATTR_RW(_name)
|
|
|
|
#define DEVICE_ATTR_RO(_name) \
|
|
|
|
struct device_attribute dev_attr_##_name = __ATTR_RO(_name)
|
2013-08-24 06:02:56 +08:00
|
|
|
#define DEVICE_ATTR_WO(_name) \
|
|
|
|
struct device_attribute dev_attr_##_name = __ATTR_WO(_name)
|
2011-12-15 06:29:38 +08:00
|
|
|
#define DEVICE_ULONG_ATTR(_name, _mode, _var) \
|
|
|
|
struct dev_ext_attribute dev_attr_##_name = \
|
|
|
|
{ __ATTR(_name, _mode, device_show_ulong, device_store_ulong), &(_var) }
|
|
|
|
#define DEVICE_INT_ATTR(_name, _mode, _var) \
|
|
|
|
struct dev_ext_attribute dev_attr_##_name = \
|
2012-05-04 07:19:02 +08:00
|
|
|
{ __ATTR(_name, _mode, device_show_int, device_store_int), &(_var) }
|
2012-10-10 01:52:05 +08:00
|
|
|
#define DEVICE_BOOL_ATTR(_name, _mode, _var) \
|
|
|
|
struct dev_ext_attribute dev_attr_##_name = \
|
|
|
|
{ __ATTR(_name, _mode, device_show_bool, device_store_bool), &(_var) }
|
2012-05-15 01:30:03 +08:00
|
|
|
#define DEVICE_ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store) \
|
|
|
|
struct device_attribute dev_attr_##_name = \
|
|
|
|
__ATTR_IGNORE_LOCKDEP(_name, _mode, _show, _store)
|
2005-10-01 20:49:43 +08:00
|
|
|
|
2012-01-05 07:05:10 +08:00
|
|
|
extern int device_create_file(struct device *device,
|
|
|
|
const struct device_attribute *entry);
|
2008-01-25 13:04:46 +08:00
|
|
|
extern void device_remove_file(struct device *dev,
|
2009-12-18 21:34:19 +08:00
|
|
|
const struct device_attribute *attr);
|
kernfs, sysfs, driver-core: implement kernfs_remove_self() and its wrappers
Sometimes it's necessary to implement a node which wants to delete
nodes including itself. This isn't straightforward because of kernfs
active reference. While a file operation is in progress, an active
reference is held and kernfs_remove() waits for all such references to
drain before completing. For a self-deleting node, this is a deadlock
as kernfs_remove() ends up waiting for an active reference that itself
is sitting on top of.
This currently is worked around in the sysfs layer using
sysfs_schedule_callback() which makes such removals asynchronous.
While it works, it's rather cumbersome and inherently breaks
synchronicity of the operation - the file operation which triggered
the operation may complete before the removal is finished (or even
started) and the removal may fail asynchronously. If a removal
operation is immmediately followed by another operation which expects
the specific name to be available (e.g. removal followed by rename
onto the same name), there's no way to make the latter operation
reliable.
The thing is there's no inherent reason for this to be asynchrnous.
All that's necessary to do this synchronous is a dedicated operation
which drops its own active ref and deactivates self. This patch
implements kernfs_remove_self() and its wrappers in sysfs and driver
core. kernfs_remove_self() is to be called from one of the file
operations, drops the active ref the task is holding, removes the self
node, and restores active ref to the dead node so that the ref is
balanced afterwards. __kernfs_remove() is updated so that it takes an
early exit if the target node is already fully removed so that the
active ref restored by kernfs_remove_self() after removal doesn't
confuse the deactivation path.
This makes implementing self-deleting nodes very easy. The normal
removal path doesn't even need to be changed to use
kernfs_remove_self() for the self-deleting node. The method can
invoke kernfs_remove_self() on itself before proceeding the normal
removal path. kernfs_remove() invoked on the node by the normal
deletion path will simply be ignored.
This will replace sysfs_schedule_callback(). A subtle feature of
sysfs_schedule_callback() is that it collapses multiple invocations -
even if multiple removals are triggered, the removal callback is run
only once. An equivalent effect can be achieved by testing the return
value of kernfs_remove_self() - only the one which gets %true return
value should proceed with actual deletion. All other instances of
kernfs_remove_self() will wait till the enclosing kernfs operation
which invoked the winning instance of kernfs_remove_self() finishes
and then return %false. This trivially makes all users of
kernfs_remove_self() automatically show correct synchronous behavior
even when there are multiple concurrent operations - all "echo 1 >
delete" instances will finish only after the whole operation is
completed by one of the instances.
Note that manipulation of active ref is implemented in separate public
functions - kernfs_[un]break_active_protection().
kernfs_remove_self() is the only user at the moment but this will be
used to cater to more complex cases.
v2: For !CONFIG_SYSFS, dummy version kernfs_remove_self() was missing
and sysfs_remove_file_self() had incorrect return type. Fix it.
Reported by kbuild test bot.
v3: kernfs_[un]break_active_protection() separated out from
kernfs_remove_self() and exposed as public API.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-02-04 03:03:01 +08:00
|
|
|
extern bool device_remove_file_self(struct device *dev,
|
|
|
|
const struct device_attribute *attr);
|
2006-09-20 00:39:19 +08:00
|
|
|
extern int __must_check device_create_bin_file(struct device *dev,
|
2009-12-18 21:34:20 +08:00
|
|
|
const struct bin_attribute *attr);
|
2006-09-20 00:39:19 +08:00
|
|
|
extern void device_remove_bin_file(struct device *dev,
|
2009-12-18 21:34:20 +08:00
|
|
|
const struct bin_attribute *attr);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
|
|
|
|
/* device resource management */
|
|
|
|
typedef void (*dr_release_t)(struct device *dev, void *res);
|
|
|
|
typedef int (*dr_match_t)(struct device *dev, void *res, void *match_data);
|
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_DEVRES
|
2008-01-25 13:04:46 +08:00
|
|
|
extern void *__devres_alloc(dr_release_t release, size_t size, gfp_t gfp,
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
const char *name);
|
|
|
|
#define devres_alloc(release, size, gfp) \
|
|
|
|
__devres_alloc(release, size, gfp, #release)
|
|
|
|
#else
|
2008-01-25 13:04:46 +08:00
|
|
|
extern void *devres_alloc(dr_release_t release, size_t size, gfp_t gfp);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
#endif
|
2012-08-04 12:01:26 +08:00
|
|
|
extern void devres_for_each_res(struct device *dev, dr_release_t release,
|
|
|
|
dr_match_t match, void *match_data,
|
|
|
|
void (*fn)(struct device *, void *, void *),
|
|
|
|
void *data);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
extern void devres_free(void *res);
|
|
|
|
extern void devres_add(struct device *dev, void *res);
|
2008-01-25 13:04:46 +08:00
|
|
|
extern void *devres_find(struct device *dev, dr_release_t release,
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
dr_match_t match, void *match_data);
|
2008-01-25 13:04:46 +08:00
|
|
|
extern void *devres_get(struct device *dev, void *new_res,
|
|
|
|
dr_match_t match, void *match_data);
|
|
|
|
extern void *devres_remove(struct device *dev, dr_release_t release,
|
|
|
|
dr_match_t match, void *match_data);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
extern int devres_destroy(struct device *dev, dr_release_t release,
|
|
|
|
dr_match_t match, void *match_data);
|
2012-05-04 01:15:13 +08:00
|
|
|
extern int devres_release(struct device *dev, dr_release_t release,
|
|
|
|
dr_match_t match, void *match_data);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
|
|
|
|
/* devres group */
|
|
|
|
extern void * __must_check devres_open_group(struct device *dev, void *id,
|
|
|
|
gfp_t gfp);
|
|
|
|
extern void devres_close_group(struct device *dev, void *id);
|
|
|
|
extern void devres_remove_group(struct device *dev, void *id);
|
|
|
|
extern int devres_release_group(struct device *dev, void *id);
|
|
|
|
|
2013-10-12 04:11:38 +08:00
|
|
|
/* managed devm_k.alloc/kfree for device drivers */
|
|
|
|
extern void *devm_kmalloc(struct device *dev, size_t size, gfp_t gfp);
|
|
|
|
static inline void *devm_kzalloc(struct device *dev, size_t size, gfp_t gfp)
|
|
|
|
{
|
|
|
|
return devm_kmalloc(dev, size, gfp | __GFP_ZERO);
|
|
|
|
}
|
|
|
|
static inline void *devm_kmalloc_array(struct device *dev,
|
|
|
|
size_t n, size_t size, gfp_t flags)
|
|
|
|
{
|
|
|
|
if (size != 0 && n > SIZE_MAX / size)
|
|
|
|
return NULL;
|
|
|
|
return devm_kmalloc(dev, n * size, flags);
|
|
|
|
}
|
|
|
|
static inline void *devm_kcalloc(struct device *dev,
|
|
|
|
size_t n, size_t size, gfp_t flags)
|
|
|
|
{
|
|
|
|
return devm_kmalloc_array(dev, n, size, flags | __GFP_ZERO);
|
|
|
|
}
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
extern void devm_kfree(struct device *dev, void *p);
|
2014-01-29 22:57:27 +08:00
|
|
|
extern char *devm_kstrdup(struct device *dev, const char *s, gfp_t gfp);
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
|
2013-01-21 18:08:54 +08:00
|
|
|
void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res);
|
2011-10-25 21:16:47 +08:00
|
|
|
void __iomem *devm_request_and_ioremap(struct device *dev,
|
|
|
|
struct resource *res);
|
|
|
|
|
2013-02-24 05:11:14 +08:00
|
|
|
/* allows to add/remove a custom action to devres stack */
|
|
|
|
int devm_add_action(struct device *dev, void (*action)(void *), void *data);
|
|
|
|
void devm_remove_action(struct device *dev, void (*action)(void *), void *data);
|
|
|
|
|
2008-02-05 14:27:55 +08:00
|
|
|
struct device_dma_parameters {
|
|
|
|
/*
|
|
|
|
* a low level driver may set these to teach IOMMU code about
|
|
|
|
* sg limitations.
|
|
|
|
*/
|
|
|
|
unsigned int max_segment_size;
|
|
|
|
unsigned long segment_boundary_mask;
|
|
|
|
};
|
|
|
|
|
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it. Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.
The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.
First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
2013-11-12 05:41:56 +08:00
|
|
|
struct acpi_device;
|
|
|
|
|
2012-11-21 07:21:50 +08:00
|
|
|
struct acpi_dev_node {
|
|
|
|
#ifdef CONFIG_ACPI
|
ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node
Modify struct acpi_dev_node to contain a pointer to struct acpi_device
associated with the given device object (that is, its ACPI companion
device) instead of an ACPI handle corresponding to it. Introduce two
new macros for manipulating that pointer in a CONFIG_ACPI-safe way,
ACPI_COMPANION() and ACPI_COMPANION_SET(), and rework the
ACPI_HANDLE() macro to take the above changes into account.
Drop the ACPI_HANDLE_SET() macro entirely and rework its users to
use ACPI_COMPANION_SET() instead. For some of them who used to
pass the result of acpi_get_child() directly to ACPI_HANDLE_SET()
introduce a helper routine acpi_preset_companion() doing an
equivalent thing.
The main motivation for doing this is that there are things
represented by struct acpi_device objects that don't have valid
ACPI handles (so called fixed ACPI hardware features, such as
power and sleep buttons) and we would like to create platform
device objects for them and "glue" them to their ACPI companions
in the usual way (which currently is impossible due to the
lack of valid ACPI handles). However, there are more reasons
why it may be useful.
First, struct acpi_device pointers allow of much better type checking
than void pointers which are ACPI handles, so it should be more
difficult to write buggy code using modified struct acpi_dev_node
and the new macros. Second, the change should help to reduce (over
time) the number of places in which the result of ACPI_HANDLE() is
passed to acpi_bus_get_device() in order to obtain a pointer to the
struct acpi_device associated with the given "physical" device,
because now that pointer is returned by ACPI_COMPANION() directly.
Finally, the change should make it easier to write generic code that
will build both for CONFIG_ACPI set and unset without adding explicit
compiler directives to it.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> # on Haswell
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Aaron Lu <aaron.lu@intel.com> # for ATA and SDIO part
2013-11-12 05:41:56 +08:00
|
|
|
struct acpi_device *companion;
|
2012-11-21 07:21:50 +08:00
|
|
|
#endif
|
|
|
|
};
|
|
|
|
|
2011-05-05 07:55:36 +08:00
|
|
|
/**
|
|
|
|
* struct device - The basic device structure
|
|
|
|
* @parent: The device's "parent" device, the device to which it is attached.
|
|
|
|
* In most cases, a parent device is some sort of bus or host
|
|
|
|
* controller. If parent is NULL, the device, is a top-level device,
|
|
|
|
* which is not usually what you want.
|
|
|
|
* @p: Holds the private data of the driver core portions of the device.
|
|
|
|
* See the comment of the struct device_private for detail.
|
|
|
|
* @kobj: A top-level, abstract class from which other classes are derived.
|
|
|
|
* @init_name: Initial name of the device.
|
|
|
|
* @type: The type of device.
|
|
|
|
* This identifies the device type and carries type-specific
|
|
|
|
* information.
|
|
|
|
* @mutex: Mutex to synchronize calls to its driver.
|
|
|
|
* @bus: Type of bus device is on.
|
|
|
|
* @driver: Which driver has allocated this
|
|
|
|
* @platform_data: Platform data specific to the device.
|
|
|
|
* Example: For devices on custom boards, as typical of embedded
|
|
|
|
* and SOC based hardware, Linux often uses platform_data to point
|
|
|
|
* to board-specific structures describing devices and how they
|
|
|
|
* are wired. That can include what ports are available, chip
|
|
|
|
* variants, which GPIO pins act in what additional roles, and so
|
|
|
|
* on. This shrinks the "Board Support Packages" (BSPs) and
|
|
|
|
* minimizes board-specific #ifdefs in drivers.
|
|
|
|
* @power: For device power management.
|
|
|
|
* See Documentation/power/devices.txt for details.
|
2011-06-23 07:52:55 +08:00
|
|
|
* @pm_domain: Provide callbacks that are executed during system suspend,
|
2011-05-05 07:55:36 +08:00
|
|
|
* hibernation, system resume and during runtime PM transitions
|
|
|
|
* along with subsystem-level and driver-level callbacks.
|
drivers/pinctrl: grab default handles from device core
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>
2013-01-23 01:56:14 +08:00
|
|
|
* @pins: For device pin management.
|
|
|
|
* See Documentation/pinctrl.txt for details.
|
2011-05-05 07:55:36 +08:00
|
|
|
* @numa_node: NUMA node this device is close to.
|
|
|
|
* @dma_mask: Dma mask (if dma'ble device).
|
|
|
|
* @coherent_dma_mask: Like dma_mask, but for alloc_coherent mapping as not all
|
|
|
|
* hardware supports 64-bit addresses for consistent allocations
|
|
|
|
* such descriptors.
|
|
|
|
* @dma_parms: A low level driver may set these to teach IOMMU code about
|
|
|
|
* segment limitations.
|
|
|
|
* @dma_pools: Dma pools (if dma'ble device).
|
|
|
|
* @dma_mem: Internal for coherent mem override.
|
2013-06-26 11:57:06 +08:00
|
|
|
* @cma_area: Contiguous memory area for dma allocations
|
2011-05-05 07:55:36 +08:00
|
|
|
* @archdata: For arch-specific additions.
|
|
|
|
* @of_node: Associated device tree node.
|
2012-11-21 07:21:50 +08:00
|
|
|
* @acpi_node: Associated ACPI device node.
|
2011-05-05 07:55:36 +08:00
|
|
|
* @devt: For creating the sysfs "dev".
|
2012-01-22 03:02:51 +08:00
|
|
|
* @id: device instance
|
2011-05-05 07:55:36 +08:00
|
|
|
* @devres_lock: Spinlock to protect the resource of the device.
|
|
|
|
* @devres_head: The resources list of the device.
|
|
|
|
* @knode_class: The node used to add the device to the class list.
|
|
|
|
* @class: The class of the device.
|
|
|
|
* @groups: Optional attribute groups.
|
|
|
|
* @release: Callback to free the device after all references have
|
|
|
|
* gone away. This should be set by the allocator of the
|
|
|
|
* device (i.e. the bus driver that discovered the device).
|
2013-06-26 11:57:06 +08:00
|
|
|
* @iommu_group: IOMMU group the device belongs to.
|
2011-05-05 07:55:36 +08:00
|
|
|
*
|
Driver core: Add offline/online device operations
In some cases, graceful hot-removal of devices is not possible,
although in principle the devices in question support hotplug.
For example, that may happen for the last CPU in the system or
for memory modules holding kernel memory.
In those cases it is nice to be able to check if the given device
can be gracefully hot-removed before triggering a removal procedure
that cannot be aborted or reversed. Unfortunately, however, the
kernel currently doesn't provide any support for that.
To address that deficiency, introduce support for offline and
online operations that can be performed on devices, respectively,
before a hot-removal and in case when it is necessary (or convenient)
to put a device back online after a successful offline (that has not
been followed by removal). The idea is that the offline will fail
whenever the given device cannot be gracefully removed from the
system and it will not be allowed to use the device after a
successful offline (until a subsequent online) in analogy with the
existing CPU offline/online mechanism.
For now, the offline and online operations are introduced at the
bus type level, as that should be sufficient for the most urgent use
cases (CPUs and memory modules). In the future, however, the
approach may be extended to cover some more complicated device
offline/online scenarios involving device drivers etc.
The lock_device_hotplug() and unlock_device_hotplug() functions are
introduced because subsequent patches need to put larger pieces of
code under device_hotplug_lock to prevent race conditions between
device offline and removal from happening.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-03 04:15:29 +08:00
|
|
|
* @offline_disabled: If set, the device is permanently online.
|
|
|
|
* @offline: Set after successful invocation of bus type's .offline().
|
2011-05-05 07:55:36 +08:00
|
|
|
*
|
|
|
|
* At the lowest level, every device in a Linux system is represented by an
|
|
|
|
* instance of struct device. The device structure contains the information
|
|
|
|
* that the device model core needs to model the system. Most subsystems,
|
|
|
|
* however, track additional information about the devices they host. As a
|
|
|
|
* result, it is rare for devices to be represented by bare device structures;
|
|
|
|
* instead, that structure, like kobject structures, is usually embedded within
|
|
|
|
* a higher-level representation of the device.
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
struct device {
|
2007-05-08 15:29:39 +08:00
|
|
|
struct device *parent;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-12-17 04:23:36 +08:00
|
|
|
struct device_private *p;
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
struct kobject kobj;
|
2008-05-31 01:45:12 +08:00
|
|
|
const char *init_name; /* initial name of the device */
|
2011-03-29 00:12:52 +08:00
|
|
|
const struct device_type *type;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-01-30 04:39:02 +08:00
|
|
|
struct mutex mutex; /* mutex to synchronize calls to
|
2005-03-22 02:41:04 +08:00
|
|
|
* its driver.
|
|
|
|
*/
|
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
struct bus_type *bus; /* type of bus device is on */
|
2005-04-17 06:20:36 +08:00
|
|
|
struct device_driver *driver; /* which driver has allocated this
|
|
|
|
device */
|
2009-03-08 23:13:32 +08:00
|
|
|
void *platform_data; /* Platform specific data, device
|
|
|
|
core doesn't touch it */
|
2005-04-17 06:20:36 +08:00
|
|
|
struct dev_pm_info power;
|
2011-06-23 07:52:55 +08:00
|
|
|
struct dev_pm_domain *pm_domain;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
drivers/pinctrl: grab default handles from device core
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>
2013-01-23 01:56:14 +08:00
|
|
|
#ifdef CONFIG_PINCTRL
|
|
|
|
struct dev_pin_info *pins;
|
|
|
|
#endif
|
|
|
|
|
2006-12-07 12:32:33 +08:00
|
|
|
#ifdef CONFIG_NUMA
|
|
|
|
int numa_node; /* NUMA node this device is close to */
|
|
|
|
#endif
|
2005-04-17 06:20:36 +08:00
|
|
|
u64 *dma_mask; /* dma mask (if dma'able device) */
|
|
|
|
u64 coherent_dma_mask;/* Like dma_mask, but for
|
|
|
|
alloc_coherent mappings as
|
|
|
|
not all hardware supports
|
|
|
|
64 bit addresses for consistent
|
|
|
|
allocations such descriptors. */
|
|
|
|
|
2008-02-05 14:27:55 +08:00
|
|
|
struct device_dma_parameters *dma_parms;
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
struct list_head dma_pools; /* dma pools (if dma'ble) */
|
|
|
|
|
|
|
|
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
|
|
|
|
override */
|
2013-07-29 20:31:45 +08:00
|
|
|
#ifdef CONFIG_DMA_CMA
|
2011-12-29 20:09:51 +08:00
|
|
|
struct cma *cma_area; /* contiguous memory area for dma
|
|
|
|
allocations */
|
|
|
|
#endif
|
2006-11-11 14:18:39 +08:00
|
|
|
/* arch specific additions */
|
|
|
|
struct dev_archdata archdata;
|
2011-01-22 00:24:48 +08:00
|
|
|
|
|
|
|
struct device_node *of_node; /* associated device tree node */
|
2012-11-21 07:21:50 +08:00
|
|
|
struct acpi_dev_node acpi_node; /* associated ACPI device node */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-10-17 05:51:35 +08:00
|
|
|
dev_t devt; /* dev_t, creates the sysfs "dev" */
|
2011-12-15 06:29:38 +08:00
|
|
|
u32 id; /* device instance */
|
2008-10-17 05:51:35 +08:00
|
|
|
|
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 15:00:26 +08:00
|
|
|
spinlock_t devres_lock;
|
|
|
|
struct list_head devres_head;
|
|
|
|
|
2008-08-26 01:50:19 +08:00
|
|
|
struct klist_node knode_class;
|
2006-10-08 03:54:55 +08:00
|
|
|
struct class *class;
|
2009-06-25 01:06:31 +08:00
|
|
|
const struct attribute_group **groups; /* optional groups */
|
2006-06-15 03:14:34 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
void (*release)(struct device *dev);
|
2012-05-31 04:18:41 +08:00
|
|
|
struct iommu_group *iommu_group;
|
Driver core: Add offline/online device operations
In some cases, graceful hot-removal of devices is not possible,
although in principle the devices in question support hotplug.
For example, that may happen for the last CPU in the system or
for memory modules holding kernel memory.
In those cases it is nice to be able to check if the given device
can be gracefully hot-removed before triggering a removal procedure
that cannot be aborted or reversed. Unfortunately, however, the
kernel currently doesn't provide any support for that.
To address that deficiency, introduce support for offline and
online operations that can be performed on devices, respectively,
before a hot-removal and in case when it is necessary (or convenient)
to put a device back online after a successful offline (that has not
been followed by removal). The idea is that the offline will fail
whenever the given device cannot be gracefully removed from the
system and it will not be allowed to use the device after a
successful offline (until a subsequent online) in analogy with the
existing CPU offline/online mechanism.
For now, the offline and online operations are introduced at the
bus type level, as that should be sufficient for the most urgent use
cases (CPUs and memory modules). In the future, however, the
approach may be extended to cover some more complicated device
offline/online scenarios involving device drivers etc.
The lock_device_hotplug() and unlock_device_hotplug() functions are
introduced because subsequent patches need to put larger pieces of
code under device_hotplug_lock to prevent race conditions between
device offline and removal from happening.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-03 04:15:29 +08:00
|
|
|
|
|
|
|
bool offline_disabled:1;
|
|
|
|
bool offline:1;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
2012-07-04 00:49:35 +08:00
|
|
|
static inline struct device *kobj_to_dev(struct kobject *kobj)
|
|
|
|
{
|
|
|
|
return container_of(kobj, struct device, kobj);
|
|
|
|
}
|
|
|
|
|
2008-03-20 05:39:13 +08:00
|
|
|
/* Get the wakeup routines, which depend on struct device */
|
|
|
|
#include <linux/pm_wakeup.h>
|
|
|
|
|
2008-07-31 03:29:21 +08:00
|
|
|
static inline const char *dev_name(const struct device *dev)
|
2008-05-02 12:02:41 +08:00
|
|
|
{
|
2010-03-09 14:57:53 +08:00
|
|
|
/* Use the init name until the kobject becomes available */
|
|
|
|
if (dev->init_name)
|
|
|
|
return dev->init_name;
|
|
|
|
|
2009-01-25 22:17:37 +08:00
|
|
|
return kobject_name(&dev->kobj);
|
2008-05-02 12:02:41 +08:00
|
|
|
}
|
|
|
|
|
2011-11-01 08:11:33 +08:00
|
|
|
extern __printf(2, 3)
|
|
|
|
int dev_set_name(struct device *dev, const char *name, ...);
|
2008-05-30 08:16:40 +08:00
|
|
|
|
2006-12-07 12:32:33 +08:00
|
|
|
#ifdef CONFIG_NUMA
|
|
|
|
static inline int dev_to_node(struct device *dev)
|
|
|
|
{
|
|
|
|
return dev->numa_node;
|
|
|
|
}
|
|
|
|
static inline void set_dev_node(struct device *dev, int node)
|
|
|
|
{
|
|
|
|
dev->numa_node = node;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline int dev_to_node(struct device *dev)
|
|
|
|
{
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
static inline void set_dev_node(struct device *dev, int node)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2011-08-25 21:33:50 +08:00
|
|
|
static inline struct pm_subsys_data *dev_to_psd(struct device *dev)
|
|
|
|
{
|
|
|
|
return dev ? dev->power.subsys_data : NULL;
|
|
|
|
}
|
|
|
|
|
2009-03-01 21:10:49 +08:00
|
|
|
static inline unsigned int dev_get_uevent_suppress(const struct device *dev)
|
|
|
|
{
|
|
|
|
return dev->kobj.uevent_suppress;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void dev_set_uevent_suppress(struct device *dev, int val)
|
|
|
|
{
|
|
|
|
dev->kobj.uevent_suppress = val;
|
|
|
|
}
|
|
|
|
|
2005-09-22 15:47:24 +08:00
|
|
|
static inline int device_is_registered(struct device *dev)
|
|
|
|
{
|
2008-03-14 05:07:03 +08:00
|
|
|
return dev->kobj.state_in_sysfs;
|
2005-09-22 15:47:24 +08:00
|
|
|
}
|
|
|
|
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-24 05:23:32 +08:00
|
|
|
static inline void device_enable_async_suspend(struct device *dev)
|
|
|
|
{
|
2011-06-19 02:22:23 +08:00
|
|
|
if (!dev->power.is_prepared)
|
PM: Asynchronous suspend and resume of devices
Theoretically, the total time of system sleep transitions (suspend
to RAM, hibernation) can be reduced by running suspend and resume
callbacks of device drivers in parallel with each other. However,
there are dependencies between devices such that we're not allowed
to suspend the parent of a device before suspending the device
itself. Analogously, we're not allowed to resume a device before
resuming its parent.
The most straightforward way to take these dependencies into accout
is to start the async threads used for suspending and resuming
devices at the core level, so that async_schedule() is called for
each suspend and resume callback supposed to be executed
asynchronously.
For this purpose, introduce a new device flag, power.async_suspend,
used to mark the devices whose suspend and resume callbacks are to be
executed asynchronously (ie. in parallel with the main suspend/resume
thread and possibly in parallel with each other) and helper function
device_enable_async_suspend() allowing one to set power.async_suspend
for given device (power.async_suspend is unset by default for all
devices). For each device with the power.async_suspend flag set the
PM core will use async_schedule() to execute its suspend and resume
callbacks.
The async threads started for different devices as a result of
calling async_schedule() are synchronized with each other and with
the main suspend/resume thread with the help of completions, in the
following way:
(1) There is a completion, power.completion, for each device object.
(2) Each device's completion is reset before calling async_schedule()
for the device or, in the case of devices with the
power.async_suspend flags unset, before executing the device's
suspend and resume callbacks.
(3) During suspend, right before running the bus type, device type
and device class suspend callbacks for the device, the PM core
waits for the completions of all the device's children to be
completed.
(4) During resume, right before running the bus type, device type and
device class resume callbacks for the device, the PM core waits
for the completion of the device's parent to be completed.
(5) The PM core completes power.completion for each device right
after the bus type, device type and device class suspend (or
resume) callbacks executed for the device have returned.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-01-24 05:23:32 +08:00
|
|
|
dev->power.async_suspend = true;
|
|
|
|
}
|
|
|
|
|
2010-01-24 05:25:23 +08:00
|
|
|
static inline void device_disable_async_suspend(struct device *dev)
|
|
|
|
{
|
2011-06-19 02:22:23 +08:00
|
|
|
if (!dev->power.is_prepared)
|
2010-01-24 05:25:23 +08:00
|
|
|
dev->power.async_suspend = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool device_async_suspend_enabled(struct device *dev)
|
|
|
|
{
|
|
|
|
return !!dev->power.async_suspend;
|
|
|
|
}
|
|
|
|
|
2011-11-18 04:39:33 +08:00
|
|
|
static inline void pm_suspend_ignore_children(struct device *dev, bool enable)
|
|
|
|
{
|
|
|
|
dev->power.ignore_children = enable;
|
|
|
|
}
|
|
|
|
|
2012-08-13 20:00:25 +08:00
|
|
|
static inline void dev_pm_syscore_device(struct device *dev, bool val)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_PM_SLEEP
|
|
|
|
dev->power.syscore = val;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2010-02-18 02:57:05 +08:00
|
|
|
static inline void device_lock(struct device *dev)
|
|
|
|
{
|
2010-01-30 04:39:02 +08:00
|
|
|
mutex_lock(&dev->mutex);
|
2010-02-18 02:57:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int device_trylock(struct device *dev)
|
|
|
|
{
|
2010-01-30 04:39:02 +08:00
|
|
|
return mutex_trylock(&dev->mutex);
|
2010-02-18 02:57:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void device_unlock(struct device *dev)
|
|
|
|
{
|
2010-01-30 04:39:02 +08:00
|
|
|
mutex_unlock(&dev->mutex);
|
2010-02-18 02:57:05 +08:00
|
|
|
}
|
|
|
|
|
2006-12-20 05:01:28 +08:00
|
|
|
void driver_init(void);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* High level routines for use by the bus drivers
|
|
|
|
*/
|
2008-01-25 13:04:46 +08:00
|
|
|
extern int __must_check device_register(struct device *dev);
|
|
|
|
extern void device_unregister(struct device *dev);
|
|
|
|
extern void device_initialize(struct device *dev);
|
|
|
|
extern int __must_check device_add(struct device *dev);
|
|
|
|
extern void device_del(struct device *dev);
|
|
|
|
extern int device_for_each_child(struct device *dev, void *data,
|
|
|
|
int (*fn)(struct device *dev, void *data));
|
|
|
|
extern struct device *device_find_child(struct device *dev, void *data,
|
|
|
|
int (*match)(struct device *dev, void *data));
|
2010-08-05 23:38:18 +08:00
|
|
|
extern int device_rename(struct device *dev, const char *new_name);
|
2009-03-04 19:44:00 +08:00
|
|
|
extern int device_move(struct device *dev, struct device *new_parent,
|
|
|
|
enum dpm_order dpm_order);
|
2009-09-19 05:01:12 +08:00
|
|
|
extern const char *device_get_devnode(struct device *dev,
|
2013-04-12 02:43:29 +08:00
|
|
|
umode_t *mode, kuid_t *uid, kgid_t *gid,
|
2013-04-07 00:56:00 +08:00
|
|
|
const char **tmp);
|
2009-05-12 05:16:57 +08:00
|
|
|
extern void *dev_get_drvdata(const struct device *dev);
|
2011-04-20 15:44:46 +08:00
|
|
|
extern int dev_set_drvdata(struct device *dev, void *data);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
Driver core: Add offline/online device operations
In some cases, graceful hot-removal of devices is not possible,
although in principle the devices in question support hotplug.
For example, that may happen for the last CPU in the system or
for memory modules holding kernel memory.
In those cases it is nice to be able to check if the given device
can be gracefully hot-removed before triggering a removal procedure
that cannot be aborted or reversed. Unfortunately, however, the
kernel currently doesn't provide any support for that.
To address that deficiency, introduce support for offline and
online operations that can be performed on devices, respectively,
before a hot-removal and in case when it is necessary (or convenient)
to put a device back online after a successful offline (that has not
been followed by removal). The idea is that the offline will fail
whenever the given device cannot be gracefully removed from the
system and it will not be allowed to use the device after a
successful offline (until a subsequent online) in analogy with the
existing CPU offline/online mechanism.
For now, the offline and online operations are introduced at the
bus type level, as that should be sufficient for the most urgent use
cases (CPUs and memory modules). In the future, however, the
approach may be extended to cover some more complicated device
offline/online scenarios involving device drivers etc.
The lock_device_hotplug() and unlock_device_hotplug() functions are
introduced because subsequent patches need to put larger pieces of
code under device_hotplug_lock to prevent race conditions between
device offline and removal from happening.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-03 04:15:29 +08:00
|
|
|
static inline bool device_supports_offline(struct device *dev)
|
|
|
|
{
|
|
|
|
return dev->bus && dev->bus->offline && dev->bus->online;
|
|
|
|
}
|
|
|
|
|
|
|
|
extern void lock_device_hotplug(void);
|
|
|
|
extern void unlock_device_hotplug(void);
|
driver core / ACPI: Avoid device hot remove locking issues
device_hotplug_lock is held around the acpi_bus_trim() call in
acpi_scan_hot_remove() which generally removes devices (it removes
ACPI device objects at least, but it may also remove "physical"
device objects through .detach() callbacks of ACPI scan handlers).
Thus, potentially, device sysfs attributes are removed under that
lock and to remove those attributes it is necessary to hold the
s_active references of their directory entries for writing.
On the other hand, the execution of a .show() or .store() callback
from a sysfs attribute is carried out with that attribute's s_active
reference held for reading. Consequently, if any device sysfs
attribute that may be removed from within acpi_scan_hot_remove()
through acpi_bus_trim() has a .store() or .show() callback which
acquires device_hotplug_lock, the execution of that callback may
deadlock with the removal of the attribute. [Unfortunately, the
"online" device attribute of CPUs and memory blocks is one of them.]
To avoid such deadlocks, make all of the sysfs attribute callbacks
that need to lock device hotplug, for example store_online(), use
a special function, lock_device_hotplug_sysfs(), to lock device
hotplug and return the result of that function immediately if it is
not zero. This will cause the s_active reference of the directory
entry in question to be released and the syscall to be restarted
if device_hotplug_lock cannot be acquired.
[show_online() actually doesn't need to lock device hotplug, but
it is useful to serialize it with respect to device_offline() and
device_online() for the same device (in case user space attempts to
run them concurrently) which can be done with the help of
device_lock().]
Reported-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reported-and-tested-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Toshi Kani <toshi.kani@hp.com>
2013-08-29 03:41:01 +08:00
|
|
|
extern int lock_device_hotplug_sysfs(void);
|
Driver core: Add offline/online device operations
In some cases, graceful hot-removal of devices is not possible,
although in principle the devices in question support hotplug.
For example, that may happen for the last CPU in the system or
for memory modules holding kernel memory.
In those cases it is nice to be able to check if the given device
can be gracefully hot-removed before triggering a removal procedure
that cannot be aborted or reversed. Unfortunately, however, the
kernel currently doesn't provide any support for that.
To address that deficiency, introduce support for offline and
online operations that can be performed on devices, respectively,
before a hot-removal and in case when it is necessary (or convenient)
to put a device back online after a successful offline (that has not
been followed by removal). The idea is that the offline will fail
whenever the given device cannot be gracefully removed from the
system and it will not be allowed to use the device after a
successful offline (until a subsequent online) in analogy with the
existing CPU offline/online mechanism.
For now, the offline and online operations are introduced at the
bus type level, as that should be sufficient for the most urgent use
cases (CPUs and memory modules). In the future, however, the
approach may be extended to cover some more complicated device
offline/online scenarios involving device drivers etc.
The lock_device_hotplug() and unlock_device_hotplug() functions are
introduced because subsequent patches need to put larger pieces of
code under device_hotplug_lock to prevent race conditions between
device offline and removal from happening.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
2013-05-03 04:15:29 +08:00
|
|
|
extern int device_offline(struct device *dev);
|
|
|
|
extern int device_online(struct device *dev);
|
2008-12-15 20:58:26 +08:00
|
|
|
/*
|
|
|
|
* Root device objects for grouping under /sys/devices
|
|
|
|
*/
|
|
|
|
extern struct device *__root_device_register(const char *name,
|
|
|
|
struct module *owner);
|
2011-05-27 21:02:11 +08:00
|
|
|
|
2014-01-10 21:57:31 +08:00
|
|
|
/* This is a macro to avoid include problems with THIS_MODULE */
|
2011-05-27 21:02:11 +08:00
|
|
|
#define root_device_register(name) \
|
|
|
|
__root_device_register(name, THIS_MODULE)
|
|
|
|
|
2008-12-15 20:58:26 +08:00
|
|
|
extern void root_device_unregister(struct device *root);
|
|
|
|
|
2009-07-17 22:06:08 +08:00
|
|
|
static inline void *dev_get_platdata(const struct device *dev)
|
|
|
|
{
|
|
|
|
return dev->platform_data;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Manual binding of a device to driver. See drivers/base/bus.c
|
|
|
|
* for information on use.
|
|
|
|
*/
|
2006-08-15 13:43:20 +08:00
|
|
|
extern int __must_check device_bind_driver(struct device *dev);
|
2008-01-25 13:04:46 +08:00
|
|
|
extern void device_release_driver(struct device *dev);
|
|
|
|
extern int __must_check device_attach(struct device *dev);
|
2006-08-15 13:43:20 +08:00
|
|
|
extern int __must_check driver_attach(struct device_driver *drv);
|
|
|
|
extern int __must_check device_reprobe(struct device *dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-06-15 03:14:34 +08:00
|
|
|
/*
|
|
|
|
* Easy functions for dynamically creating devices on the fly
|
|
|
|
*/
|
2008-05-16 04:44:08 +08:00
|
|
|
extern struct device *device_create_vargs(struct class *cls,
|
|
|
|
struct device *parent,
|
|
|
|
dev_t devt,
|
|
|
|
void *drvdata,
|
|
|
|
const char *fmt,
|
|
|
|
va_list vargs);
|
2011-11-01 08:11:33 +08:00
|
|
|
extern __printf(5, 6)
|
|
|
|
struct device *device_create(struct class *cls, struct device *parent,
|
|
|
|
dev_t devt, void *drvdata,
|
|
|
|
const char *fmt, ...);
|
2013-07-15 07:05:57 +08:00
|
|
|
extern __printf(6, 7)
|
|
|
|
struct device *device_create_with_groups(struct class *cls,
|
|
|
|
struct device *parent, dev_t devt, void *drvdata,
|
|
|
|
const struct attribute_group **groups,
|
|
|
|
const char *fmt, ...);
|
2006-06-15 03:14:34 +08:00
|
|
|
extern void device_destroy(struct class *cls, dev_t devt);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Platform "fixup" functions - allow the platform to have their say
|
|
|
|
* about devices and actions that the general device layer doesn't
|
|
|
|
* know about.
|
|
|
|
*/
|
|
|
|
/* Notify platform of device discovery */
|
2008-01-25 13:04:46 +08:00
|
|
|
extern int (*platform_notify)(struct device *dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-01-25 13:04:46 +08:00
|
|
|
extern int (*platform_notify_remove)(struct device *dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
2011-05-05 07:55:36 +08:00
|
|
|
/*
|
2005-04-17 06:20:36 +08:00
|
|
|
* get_device - atomically increment the reference count for the device.
|
|
|
|
*
|
|
|
|
*/
|
2008-01-25 13:04:46 +08:00
|
|
|
extern struct device *get_device(struct device *dev);
|
|
|
|
extern void put_device(struct device *dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev
Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
very early at kernel initialization, before any driver-core device
is registered. Every device with a major/minor will provide a
device node in devtmpfs.
Devtmpfs can be changed and altered by userspace at any time,
and in any way needed - just like today's udev-mounted tmpfs.
Unmodified udev versions will run just fine on top of it, and will
recognize an already existing kernel-created device node and use it.
The default node permissions are root:root 0600. Proper permissions
and user/group ownership, meaningful symlinks, all other policy still
needs to be applied by userspace.
If a node is created by devtmps, devtmpfs will remove the device node
when the device goes away. If the device node was created by
userspace, or the devtmpfs created node was replaced by userspace, it
will no longer be removed by devtmpfs.
If it is requested to auto-mount it, it makes init=/bin/sh work
without any further userspace support. /dev will be fully populated
and dynamic, and always reflect the current device state of the kernel.
With the commonly used dynamic device numbers, it solves the problem
where static devices nodes may point to the wrong devices.
It is intended to make the initial bootup logic simpler and more robust,
by de-coupling the creation of the inital environment, to reliably run
userspace processes, from a complex userspace bootstrap logic to provide
a working /dev.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Tested-By: Harald Hoyer <harald@redhat.com>
Tested-By: Scott James Remnant <scott@ubuntu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 21:23:42 +08:00
|
|
|
#ifdef CONFIG_DEVTMPFS
|
|
|
|
extern int devtmpfs_create_node(struct device *dev);
|
|
|
|
extern int devtmpfs_delete_node(struct device *dev);
|
2009-10-29 02:51:17 +08:00
|
|
|
extern int devtmpfs_mount(const char *mntdir);
|
Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev
Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
very early at kernel initialization, before any driver-core device
is registered. Every device with a major/minor will provide a
device node in devtmpfs.
Devtmpfs can be changed and altered by userspace at any time,
and in any way needed - just like today's udev-mounted tmpfs.
Unmodified udev versions will run just fine on top of it, and will
recognize an already existing kernel-created device node and use it.
The default node permissions are root:root 0600. Proper permissions
and user/group ownership, meaningful symlinks, all other policy still
needs to be applied by userspace.
If a node is created by devtmps, devtmpfs will remove the device node
when the device goes away. If the device node was created by
userspace, or the devtmpfs created node was replaced by userspace, it
will no longer be removed by devtmpfs.
If it is requested to auto-mount it, it makes init=/bin/sh work
without any further userspace support. /dev will be fully populated
and dynamic, and always reflect the current device state of the kernel.
With the commonly used dynamic device numbers, it solves the problem
where static devices nodes may point to the wrong devices.
It is intended to make the initial bootup logic simpler and more robust,
by de-coupling the creation of the inital environment, to reliably run
userspace processes, from a complex userspace bootstrap logic to provide
a working /dev.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jan Blunck <jblunck@suse.de>
Tested-By: Harald Hoyer <harald@redhat.com>
Tested-By: Scott James Remnant <scott@ubuntu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2009-04-30 21:23:42 +08:00
|
|
|
#else
|
|
|
|
static inline int devtmpfs_create_node(struct device *dev) { return 0; }
|
|
|
|
static inline int devtmpfs_delete_node(struct device *dev) { return 0; }
|
|
|
|
static inline int devtmpfs_mount(const char *mountpoint) { return 0; }
|
|
|
|
#endif
|
|
|
|
|
2006-03-22 07:58:53 +08:00
|
|
|
/* drivers/base/power/shutdown.c */
|
2005-04-17 06:20:36 +08:00
|
|
|
extern void device_shutdown(void);
|
|
|
|
|
|
|
|
/* debugging and troubleshooting/diagnostic helpers. */
|
2008-07-31 03:29:21 +08:00
|
|
|
extern const char *dev_driver_string(const struct device *dev);
|
2010-06-27 09:02:34 +08:00
|
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_PRINTK
|
|
|
|
|
2012-09-26 09:19:57 +08:00
|
|
|
extern __printf(3, 0)
|
|
|
|
int dev_vprintk_emit(int level, const struct device *dev,
|
|
|
|
const char *fmt, va_list args);
|
2012-09-13 11:13:37 +08:00
|
|
|
extern __printf(3, 4)
|
|
|
|
int dev_printk_emit(int level, const struct device *dev, const char *fmt, ...);
|
2012-09-13 11:11:29 +08:00
|
|
|
|
2011-11-01 08:11:33 +08:00
|
|
|
extern __printf(3, 4)
|
|
|
|
int dev_printk(const char *level, const struct device *dev,
|
2012-09-13 11:11:29 +08:00
|
|
|
const char *fmt, ...);
|
2011-11-01 08:11:33 +08:00
|
|
|
extern __printf(2, 3)
|
|
|
|
int dev_emerg(const struct device *dev, const char *fmt, ...);
|
|
|
|
extern __printf(2, 3)
|
|
|
|
int dev_alert(const struct device *dev, const char *fmt, ...);
|
|
|
|
extern __printf(2, 3)
|
|
|
|
int dev_crit(const struct device *dev, const char *fmt, ...);
|
|
|
|
extern __printf(2, 3)
|
|
|
|
int dev_err(const struct device *dev, const char *fmt, ...);
|
|
|
|
extern __printf(2, 3)
|
|
|
|
int dev_warn(const struct device *dev, const char *fmt, ...);
|
|
|
|
extern __printf(2, 3)
|
|
|
|
int dev_notice(const struct device *dev, const char *fmt, ...);
|
|
|
|
extern __printf(2, 3)
|
|
|
|
int _dev_info(const struct device *dev, const char *fmt, ...);
|
2010-06-27 09:02:34 +08:00
|
|
|
|
|
|
|
#else
|
|
|
|
|
2012-09-26 09:19:57 +08:00
|
|
|
static inline __printf(3, 0)
|
|
|
|
int dev_vprintk_emit(int level, const struct device *dev,
|
|
|
|
const char *fmt, va_list args)
|
2012-09-13 11:13:37 +08:00
|
|
|
{ return 0; }
|
|
|
|
static inline __printf(3, 4)
|
|
|
|
int dev_printk_emit(int level, const struct device *dev, const char *fmt, ...)
|
|
|
|
{ return 0; }
|
|
|
|
|
2011-08-12 02:36:21 +08:00
|
|
|
static inline int __dev_printk(const char *level, const struct device *dev,
|
|
|
|
struct va_format *vaf)
|
2011-11-01 08:11:33 +08:00
|
|
|
{ return 0; }
|
|
|
|
static inline __printf(3, 4)
|
|
|
|
int dev_printk(const char *level, const struct device *dev,
|
|
|
|
const char *fmt, ...)
|
|
|
|
{ return 0; }
|
|
|
|
|
|
|
|
static inline __printf(2, 3)
|
|
|
|
int dev_emerg(const struct device *dev, const char *fmt, ...)
|
|
|
|
{ return 0; }
|
|
|
|
static inline __printf(2, 3)
|
|
|
|
int dev_crit(const struct device *dev, const char *fmt, ...)
|
|
|
|
{ return 0; }
|
|
|
|
static inline __printf(2, 3)
|
|
|
|
int dev_alert(const struct device *dev, const char *fmt, ...)
|
|
|
|
{ return 0; }
|
|
|
|
static inline __printf(2, 3)
|
|
|
|
int dev_err(const struct device *dev, const char *fmt, ...)
|
|
|
|
{ return 0; }
|
|
|
|
static inline __printf(2, 3)
|
|
|
|
int dev_warn(const struct device *dev, const char *fmt, ...)
|
|
|
|
{ return 0; }
|
|
|
|
static inline __printf(2, 3)
|
|
|
|
int dev_notice(const struct device *dev, const char *fmt, ...)
|
|
|
|
{ return 0; }
|
|
|
|
static inline __printf(2, 3)
|
|
|
|
int _dev_info(const struct device *dev, const char *fmt, ...)
|
|
|
|
{ return 0; }
|
2010-06-27 09:02:34 +08:00
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2012-09-04 12:40:40 +08:00
|
|
|
/*
|
|
|
|
* Stupid hackaround for existing uses of non-printk uses dev_info
|
|
|
|
*
|
|
|
|
* Note that the definition of dev_info below is actually _dev_info
|
|
|
|
* and a macro is used to avoid redefining dev_info
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define dev_info(dev, fmt, arg...) _dev_info(dev, fmt, ##arg)
|
|
|
|
|
|
|
|
#if defined(CONFIG_DYNAMIC_DEBUG)
|
|
|
|
#define dev_dbg(dev, format, ...) \
|
|
|
|
do { \
|
|
|
|
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
|
|
|
|
} while (0)
|
|
|
|
#elif defined(DEBUG)
|
|
|
|
#define dev_dbg(dev, format, arg...) \
|
|
|
|
dev_printk(KERN_DEBUG, dev, format, ##arg)
|
|
|
|
#else
|
|
|
|
#define dev_dbg(dev, format, arg...) \
|
|
|
|
({ \
|
|
|
|
if (0) \
|
|
|
|
dev_printk(KERN_DEBUG, dev, format, ##arg); \
|
|
|
|
0; \
|
|
|
|
})
|
|
|
|
#endif
|
|
|
|
|
2012-05-14 15:47:57 +08:00
|
|
|
#define dev_level_ratelimited(dev_level, dev, fmt, ...) \
|
|
|
|
do { \
|
|
|
|
static DEFINE_RATELIMIT_STATE(_rs, \
|
|
|
|
DEFAULT_RATELIMIT_INTERVAL, \
|
|
|
|
DEFAULT_RATELIMIT_BURST); \
|
|
|
|
if (__ratelimit(&_rs)) \
|
|
|
|
dev_level(dev, fmt, ##__VA_ARGS__); \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
#define dev_emerg_ratelimited(dev, fmt, ...) \
|
|
|
|
dev_level_ratelimited(dev_emerg, dev, fmt, ##__VA_ARGS__)
|
|
|
|
#define dev_alert_ratelimited(dev, fmt, ...) \
|
|
|
|
dev_level_ratelimited(dev_alert, dev, fmt, ##__VA_ARGS__)
|
|
|
|
#define dev_crit_ratelimited(dev, fmt, ...) \
|
|
|
|
dev_level_ratelimited(dev_crit, dev, fmt, ##__VA_ARGS__)
|
|
|
|
#define dev_err_ratelimited(dev, fmt, ...) \
|
|
|
|
dev_level_ratelimited(dev_err, dev, fmt, ##__VA_ARGS__)
|
|
|
|
#define dev_warn_ratelimited(dev, fmt, ...) \
|
|
|
|
dev_level_ratelimited(dev_warn, dev, fmt, ##__VA_ARGS__)
|
|
|
|
#define dev_notice_ratelimited(dev, fmt, ...) \
|
|
|
|
dev_level_ratelimited(dev_notice, dev, fmt, ##__VA_ARGS__)
|
|
|
|
#define dev_info_ratelimited(dev, fmt, ...) \
|
|
|
|
dev_level_ratelimited(dev_info, dev, fmt, ##__VA_ARGS__)
|
2013-08-27 22:47:34 +08:00
|
|
|
#if defined(CONFIG_DYNAMIC_DEBUG)
|
|
|
|
/* descriptor check is first to prevent flooding with "callbacks suppressed" */
|
2012-05-14 15:47:57 +08:00
|
|
|
#define dev_dbg_ratelimited(dev, fmt, ...) \
|
2012-09-04 12:40:40 +08:00
|
|
|
do { \
|
|
|
|
static DEFINE_RATELIMIT_STATE(_rs, \
|
|
|
|
DEFAULT_RATELIMIT_INTERVAL, \
|
|
|
|
DEFAULT_RATELIMIT_BURST); \
|
|
|
|
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
|
|
|
|
if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT) && \
|
|
|
|
__ratelimit(&_rs)) \
|
2013-08-27 22:47:34 +08:00
|
|
|
__dynamic_dev_dbg(&descriptor, dev, fmt, \
|
|
|
|
##__VA_ARGS__); \
|
|
|
|
} while (0)
|
|
|
|
#elif defined(DEBUG)
|
|
|
|
#define dev_dbg_ratelimited(dev, fmt, ...) \
|
|
|
|
do { \
|
|
|
|
static DEFINE_RATELIMIT_STATE(_rs, \
|
|
|
|
DEFAULT_RATELIMIT_INTERVAL, \
|
|
|
|
DEFAULT_RATELIMIT_BURST); \
|
|
|
|
if (__ratelimit(&_rs)) \
|
|
|
|
dev_printk(KERN_DEBUG, dev, fmt, ##__VA_ARGS__); \
|
2010-06-27 09:02:34 +08:00
|
|
|
} while (0)
|
2005-04-17 06:20:36 +08:00
|
|
|
#else
|
2012-09-04 12:40:40 +08:00
|
|
|
#define dev_dbg_ratelimited(dev, fmt, ...) \
|
|
|
|
no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif
|
|
|
|
|
2007-07-13 13:08:22 +08:00
|
|
|
#ifdef VERBOSE_DEBUG
|
|
|
|
#define dev_vdbg dev_dbg
|
|
|
|
#else
|
2010-06-27 09:02:34 +08:00
|
|
|
#define dev_vdbg(dev, format, arg...) \
|
|
|
|
({ \
|
|
|
|
if (0) \
|
|
|
|
dev_printk(KERN_DEBUG, dev, format, ##arg); \
|
|
|
|
0; \
|
|
|
|
})
|
2007-07-13 13:08:22 +08:00
|
|
|
#endif
|
|
|
|
|
2008-09-21 10:08:39 +08:00
|
|
|
/*
|
2013-10-25 05:42:33 +08:00
|
|
|
* dev_WARN*() acts like dev_printk(), but with the key difference of
|
|
|
|
* using WARN/WARN_ONCE to include file/line information and a backtrace.
|
2008-09-21 10:08:39 +08:00
|
|
|
*/
|
|
|
|
#define dev_WARN(dev, format, arg...) \
|
2013-10-25 05:42:33 +08:00
|
|
|
WARN(1, "%s %s: " format, dev_driver_string(dev), dev_name(dev), ## arg);
|
2008-09-21 10:08:39 +08:00
|
|
|
|
2011-03-16 21:59:35 +08:00
|
|
|
#define dev_WARN_ONCE(dev, condition, format, arg...) \
|
2013-10-25 05:42:33 +08:00
|
|
|
WARN_ONCE(condition, "%s %s: " format, \
|
|
|
|
dev_driver_string(dev), dev_name(dev), ## arg)
|
2011-03-16 21:59:35 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* Create alias, so I can be autoloaded. */
|
|
|
|
#define MODULE_ALIAS_CHARDEV(major,minor) \
|
|
|
|
MODULE_ALIAS("char-major-" __stringify(major) "-" __stringify(minor))
|
|
|
|
#define MODULE_ALIAS_CHARDEV_MAJOR(major) \
|
|
|
|
MODULE_ALIAS("char-major-" __stringify(major) "-*")
|
2010-09-08 22:54:17 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_SYSFS_DEPRECATED
|
|
|
|
extern long sysfs_deprecated;
|
|
|
|
#else
|
|
|
|
#define sysfs_deprecated 0
|
|
|
|
#endif
|
|
|
|
|
2011-11-16 17:13:35 +08:00
|
|
|
/**
|
|
|
|
* module_driver() - Helper macro for drivers that don't do anything
|
|
|
|
* special in module init/exit. This eliminates a lot of boilerplate.
|
|
|
|
* Each module may only use this macro once, and calling it replaces
|
|
|
|
* module_init() and module_exit().
|
|
|
|
*
|
2012-01-22 03:02:51 +08:00
|
|
|
* @__driver: driver name
|
|
|
|
* @__register: register function for this driver type
|
|
|
|
* @__unregister: unregister function for this driver type
|
2012-02-25 18:25:58 +08:00
|
|
|
* @...: Additional arguments to be passed to __register and __unregister.
|
2012-01-22 03:02:51 +08:00
|
|
|
*
|
2011-11-16 17:13:35 +08:00
|
|
|
* Use this macro to construct bus specific macros for registering
|
|
|
|
* drivers, and do not use it on its own.
|
|
|
|
*/
|
2012-02-25 18:25:58 +08:00
|
|
|
#define module_driver(__driver, __register, __unregister, ...) \
|
2011-11-16 17:13:35 +08:00
|
|
|
static int __init __driver##_init(void) \
|
|
|
|
{ \
|
2012-02-25 18:25:58 +08:00
|
|
|
return __register(&(__driver) , ##__VA_ARGS__); \
|
2011-11-16 17:13:35 +08:00
|
|
|
} \
|
|
|
|
module_init(__driver##_init); \
|
|
|
|
static void __exit __driver##_exit(void) \
|
|
|
|
{ \
|
2012-02-25 18:25:58 +08:00
|
|
|
__unregister(&(__driver) , ##__VA_ARGS__); \
|
2011-11-16 17:13:35 +08:00
|
|
|
} \
|
|
|
|
module_exit(__driver##_exit);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif /* _DEVICE_H_ */
|