[RFC,1/5] Device Power: introduce power controller

Commit Message

Ming Lei Dec. 2, 2012, 3:01 p.m. UTC

Power controller is an abstract on simple power on/off switch.

One power controller can bind to more than one device, which
provides power logically, for example, we can think one usb port
in hub provides power to the usb device attached to the port, even
though the power is supplied actually by other ways, eg. the usb
hub is a self-power device. From hardware view, more than one
device can share one power domain, and power controller can power
on if one of these devices need to provide power, and power off if
all these devices don't need to provide power.

Cc: "Rafael J. Wysocki" <[e-mail]>
Cc: Andy Green <[e-mail]>
Cc: Roger Quadros <[e-mail]>
Cc: Alan Stern <[e-mail]>
Cc: Felipe Balbi <[e-mail]>
Signed-off-by: Ming Lei <[e-mail]>
---
 drivers/base/power/Makefile           |    1 +
 drivers/base/power/power_controller.c |  110 +++++++++++++++++++++++++++++++++
 include/linux/power_controller.h      |   48 ++++++++++++++
 kernel/power/Kconfig                  |    6 ++
 4 files changed, 165 insertions(+)
 create mode 100644 drivers/base/power/power_controller.c
 create mode 100644 include/linux/power_controller.h

Comments

Andy Green Dec. 2, 2012, 4:02 p.m. UTC | #1

On 02/12/12 23:01, the mail apparently from Ming Lei included:
> Power controller is an abstract on simple power on/off switch.
>
> One power controller can bind to more than one device, which
> provides power logically, for example, we can think one usb port
> in hub provides power to the usb device attached to the port, even
> though the power is supplied actually by other ways, eg. the usb
> hub is a self-power device. From hardware view, more than one
> device can share one power domain, and power controller can power
> on if one of these devices need to provide power, and power off if
> all these devices don't need to provide power.

What stops us using struct regulator here?  If you have child regulators 
supplied by a parent supply, isn't that the right semantic already 
without introducing a whole new thing?  Apologies if I missed the point.

-Andy

> Cc: "Rafael J. Wysocki" <[e-mail]>
> Cc: Andy Green <[e-mail]>
> Cc: Roger Quadros <[e-mail]>
> Cc: Alan Stern <[e-mail]>
> Cc: Felipe Balbi <[e-mail]>
> Signed-off-by: Ming Lei <[e-mail]>
> ---
>   drivers/base/power/Makefile           |    1 +
>   drivers/base/power/power_controller.c |  110 +++++++++++++++++++++++++++++++++
>   include/linux/power_controller.h      |   48 ++++++++++++++
>   kernel/power/Kconfig                  |    6 ++
>   4 files changed, 165 insertions(+)
>   create mode 100644 drivers/base/power/power_controller.c
>   create mode 100644 include/linux/power_controller.h
>
> diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
> index 2e58ebb..c08bfc9 100644
> --- a/drivers/base/power/Makefile
> +++ b/drivers/base/power/Makefile
> @@ -5,5 +5,6 @@ obj-$(CONFIG_PM_TRACE_RTC)	+= trace.o
>   obj-$(CONFIG_PM_OPP)	+= opp.o
>   obj-$(CONFIG_PM_GENERIC_DOMAINS)	+=  domain.o domain_governor.o
>   obj-$(CONFIG_HAVE_CLK)	+= clock_ops.o
> +obj-$(CONFIG_POWER_CONTROLLER)	+= power_controller.o
>
>   ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
> diff --git a/drivers/base/power/power_controller.c b/drivers/base/power/power_controller.c
> new file mode 100644
> index 0000000..d7671fb
> --- /dev/null
> +++ b/drivers/base/power/power_controller.c
> @@ -0,0 +1,110 @@
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/power_controller.h>
> +#include <linux/slab.h>
> +#include <linux/err.h>
> +#include <linux/export.h>
> +
> +static DEFINE_MUTEX(pc_lock);
> +
> +static void pc_devm_release(struct device *dev, void *res)
> +{
> +}
> +
> +static int pc_devm_match(struct device *dev, void *res, void *match_data)
> +{
> +	struct pc_dev_data *data = res;
> +
> +	return (data->magic == (unsigned long)pc_devm_release);
> +}
> +
> +static struct pc_dev_data *dev_pc_data(struct device *dev)
> +{
> +	struct pc_dev_data *data;
> +
> +	data = devres_find(dev, pc_devm_release, pc_devm_match, NULL);
> +	return data;
> +}
> +
> +static int pc_add_devm_data(struct device *dev, struct power_controller *pc,
> +			    void *dev_data, int dev_data_size)
> +{
> +	struct pc_dev_data *data;
> +	int ret = 0;
> +
> +	mutex_lock(&pc_lock);
> +
> +	/* each device should only have one power controller resource */
> +	data = dev_pc_data(dev);
> +	if (data) {
> +		ret = 1;
> +		goto exit;
> +	}
> +
> +	data = devres_alloc(pc_devm_release, sizeof(struct pc_dev_data) +
> +			    dev_data_size, GFP_KERNEL);
> +	if (!data) {
> +		ret = -ENOMEM;
> +		goto exit;
> +	}
> +
> +	data->magic = (unsigned long)pc_devm_release;
> +	data->pc = pc;
> +	data->dev_data = &data[1];
> +	memcpy(data->dev_data, dev_data, dev_data_size);
> +	devres_add(dev, data);
> +
> +exit:
> +	mutex_unlock(&pc_lock);
> +	return ret;
> +}
> +
> +static struct power_controller *dev_pc(struct device *dev)
> +{
> +	struct pc_dev_data *data = dev_pc_data(dev);
> +
> +	if (data)
> +		return data->pc;
> +	return NULL;
> +}
> +
> +struct pc_dev_data *dev_pc_get_data(struct device *dev)
> +{
> +	struct pc_dev_data *data = dev_pc_data(dev);
> +	return data;
> +}
> +EXPORT_SYMBOL(dev_pc_get_data);
> +
> +int dev_pc_bind(struct power_controller *pc, struct device *dev,
> +		void *dev_data, int dev_data_size)
> +{
> +	return pc_add_devm_data(dev, pc, dev_data, dev_data_size);
> +}
> +EXPORT_SYMBOL(dev_pc_bind);
> +
> +void dev_pc_unbind(struct power_controller *pc, struct device *dev)
> +{
> +}
> +EXPORT_SYMBOL(dev_pc_unbind);
> +
> +void dev_pc_power_on(struct device *dev)
> +{
> +	struct power_controller *pc = dev_pc(dev);
> +
> +	if (!pc)	return;
> +
> +	if (atomic_inc_return(&pc->count) == 1)
> +		pc->power_on(pc, dev);
> +}
> +EXPORT_SYMBOL(dev_pc_power_on);
> +
> +void dev_pc_power_off(struct device *dev)
> +{
> +	struct power_controller *pc = dev_pc(dev);
> +
> +	if (!pc)	return;
> +
> +	if (!atomic_dec_return(&pc->count))
> +		pc->power_off(pc, dev);
> +}
> +EXPORT_SYMBOL(dev_pc_power_off);
> diff --git a/include/linux/power_controller.h b/include/linux/power_controller.h
> new file mode 100644
> index 0000000..772f6d7
> --- /dev/null
> +++ b/include/linux/power_controller.h
> @@ -0,0 +1,48 @@
> +#ifndef _LINUX_POWER_CONTROLLER_H
> +#define _LINUX_POWER_CONTROLLER_H
> +
> +#include <linux/device.h>
> +
> +/*
> + * One power controller provides simple power on and power off.
> + *
> + * One power controller can bind to more than one device, which
> + * provides power logically, for example, we can think one usb port
> + * in hub provides power to the usb device attached to the port, even
> + * though the power is supplied actually by other ways, eg. the usb
> + * hub is a self-power device. From hardware view, more than one
> + * device can share one power domain, and power controller can power
> + * on if one of these devices need to provide power, and power off if
> + * all these devices don't need to provide power.
> + *
> + * The abstract is introduced to hide the implementation details of
> + * power controller, and only let platform code handle the details.
> + */
> +struct power_controller {
> +	atomic_t count;			/* Number of users with power "on" */
> +	char *name;
> +	void (*power_off)(struct power_controller *pc, struct device *dev);
> +	void (*power_on)(struct power_controller *pc, struct device *dev);
> +};
> +
> +struct pc_dev_data {
> +	unsigned long magic;
> +	struct power_controller *pc;
> +	void	*dev_data;
> +};
> +
> +#ifdef CONFIG_POWER_CONTROLLER
> +extern struct pc_dev_data *dev_pc_get_data(struct device *dev);
> +extern int dev_pc_bind(struct power_controller *pc, struct device *dev, void *dev_data, int dev_data_size);
> +extern void dev_pc_unbind(struct power_controller *pc, struct device *dev);
> +extern void dev_pc_power_on(struct device *dev);
> +extern void dev_pc_power_off(struct device *dev);
> +#else
> +static inline struct pc_dev_data *dev_pc_get_data(struct device *dev){return NULL;}
> +static inline int dev_pc_bind(struct power_controller *pc, struct device *dev, void *dev_data,
> +				int dev_data_size){return 0;}
> +static inline void dev_pc_unbind(struct power_controller *pc, struct device *dev){}
> +static inline void dev_pc_power_on(struct device *dev){}
> +static inline void dev_pc_power_off(struct device *dev){}
> +#endif
> +#endif /* _LINUX_POWER_CONTROLLER_H */
> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
> index 5dfdc9e..51803a9 100644
> --- a/kernel/power/Kconfig
> +++ b/kernel/power/Kconfig
> @@ -255,6 +255,12 @@ config PM_OPP
>   	  implementations a ready to use framework to manage OPPs.
>   	  For more information, read <file:Documentation/power/opp.txt>
>
> +config POWER_CONTROLLER
> +	bool "Power Controller"
> +	---help---
> +	Power Controller is an abstract on power switch which can be
> +	shared by more than more devices.
> +
>   config PM_CLK
>   	def_bool y
>   	depends on PM && HAVE_CLK
>

Ming Lei Dec. 3, 2012, 3 a.m. UTC | #2

On Mon, Dec 3, 2012 at 12:02 AM, Andy Green <[e-mail]> wrote:
> On 02/12/12 23:01, the mail apparently from Ming Lei included:
>
>> Power controller is an abstract on simple power on/off switch.
>>
>> One power controller can bind to more than one device, which
>> provides power logically, for example, we can think one usb port
>> in hub provides power to the usb device attached to the port, even
>> though the power is supplied actually by other ways, eg. the usb
>> hub is a self-power device. From hardware view, more than one
>> device can share one power domain, and power controller can power
>> on if one of these devices need to provide power, and power off if
>> all these devices don't need to provide power.
>
>
> What stops us using struct regulator here?  If you have child regulators
> supplied by a parent supply, isn't that the right semantic already without
> introducing a whole new thing?  Apologies if I missed the point.

There are two purposes:

One is to hide the implementation details of the power controller because
the user doesn't care how it is implemented, maybe clock, regulator, gpio
and other platform dependent stuffs involved, so the patch simplify the usage
from the view of users.

Another is that several users may share one power controller, and the
introduced power controller can help users to use it.

Also the power controller is stored as device resource, not any new
stuff added into 'struct device', and all users of the power controller
needn't write code to operate device resource things too.

Thanks,

Roger Quadros Dec. 5, 2012, 4:49 p.m. UTC | #3

On 12/03/2012 05:00 AM, Ming Lei wrote:
> On Mon, Dec 3, 2012 at 12:02 AM, Andy Green <[e-mail]> wrote:
>> On 02/12/12 23:01, the mail apparently from Ming Lei included:
>>
>>> Power controller is an abstract on simple power on/off switch.
>>>
>>> One power controller can bind to more than one device, which
>>> provides power logically, for example, we can think one usb port
>>> in hub provides power to the usb device attached to the port, even
>>> though the power is supplied actually by other ways, eg. the usb
>>> hub is a self-power device. From hardware view, more than one
>>> device can share one power domain, and power controller can power
>>> on if one of these devices need to provide power, and power off if
>>> all these devices don't need to provide power.
>>
>>
>> What stops us using struct regulator here?  If you have child regulators
>> supplied by a parent supply, isn't that the right semantic already without
>> introducing a whole new thing?  Apologies if I missed the point.
> 
> There are two purposes:
> 
> One is to hide the implementation details of the power controller because
> the user doesn't care how it is implemented, maybe clock, regulator, gpio
> and other platform dependent stuffs involved, so the patch simplify the usage
> from the view of users.
> 

Which user are you talking about?

AFAIK for Panda we only need a regulator and a clock for each root port.
IMHO we should just use the existing regulator and clock frameworks.

> Another is that several users may share one power controller, and the
> introduced power controller can help users to use it.
> 

True. e.g. the same regulator could be used to power 3 root hub ports in
a ganged setup. But the regulator framework is sufficient to deal with
that. Each port will call regulator_get() and regulator_enable() and the
physical regulator won't be disabled till all of them have called
regulator_disable().

regards,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ming Lei Dec. 6, 2012, 1:27 a.m. UTC | #4

On Thu, Dec 6, 2012 at 12:49 AM, Roger Quadros <[e-mail]> wrote:
> On 12/03/2012 05:00 AM, Ming Lei wrote:
>> On Mon, Dec 3, 2012 at 12:02 AM, Andy Green <[e-mail]> wrote:
>>> On 02/12/12 23:01, the mail apparently from Ming Lei included:
>>>
>>>> Power controller is an abstract on simple power on/off switch.
>>>>
>>>> One power controller can bind to more than one device, which
>>>> provides power logically, for example, we can think one usb port
>>>> in hub provides power to the usb device attached to the port, even
>>>> though the power is supplied actually by other ways, eg. the usb
>>>> hub is a self-power device. From hardware view, more than one
>>>> device can share one power domain, and power controller can power
>>>> on if one of these devices need to provide power, and power off if
>>>> all these devices don't need to provide power.
>>>
>>>
>>> What stops us using struct regulator here?  If you have child regulators
>>> supplied by a parent supply, isn't that the right semantic already without
>>> introducing a whole new thing?  Apologies if I missed the point.
>>
>> There are two purposes:
>>
>> One is to hide the implementation details of the power controller because
>> the user doesn't care how it is implemented, maybe clock, regulator, gpio
>> and other platform dependent stuffs involved, so the patch simplify the usage
>> from the view of users.
>>
>
> Which user are you talking about?

Here it is the usb port device.

At least, there are many boards which have hardwired and self-powered usb
devices, so in theory they can benefits from the power controller.  Maybe
only regulator and clock can't be covered completely for other boards.

The patch can make usb port deal with the 'power controller' only, and make it
avoid to deal with regulators/clocks/... directly.


Thanks,

Jassi Brar Dec. 6, 2012, 3:46 a.m. UTC | #5

On 6 December 2012 06:57, Ming Lei <[e-mail]> wrote:
> On Thu, Dec 6, 2012 at 12:49 AM, Roger Quadros <[e-mail]> wrote:
>> On 12/03/2012 05:00 AM, Ming Lei wrote:
>>> On Mon, Dec 3, 2012 at 12:02 AM, Andy Green <[e-mail]> wrote:
>>>> On 02/12/12 23:01, the mail apparently from Ming Lei included:
>>>>
>>>>> Power controller is an abstract on simple power on/off switch.
>>>>>
>>>>> One power controller can bind to more than one device, which
>>>>> provides power logically, for example, we can think one usb port
>>>>> in hub provides power to the usb device attached to the port, even
>>>>> though the power is supplied actually by other ways, eg. the usb
>>>>> hub is a self-power device. From hardware view, more than one
>>>>> device can share one power domain, and power controller can power
>>>>> on if one of these devices need to provide power, and power off if
>>>>> all these devices don't need to provide power.
>>>>
>>>>
>>>> What stops us using struct regulator here?  If you have child regulators
>>>> supplied by a parent supply, isn't that the right semantic already without
>>>> introducing a whole new thing?  Apologies if I missed the point.
>>>
>>> There are two purposes:
>>>
>>> One is to hide the implementation details of the power controller because
>>> the user doesn't care how it is implemented, maybe clock, regulator, gpio
>>> and other platform dependent stuffs involved, so the patch simplify the usage
>>> from the view of users.
>>>
>>
>> Which user are you talking about?
>
> Here it is the usb port device.
>
> At least, there are many boards which have hardwired and self-powered usb
> devices, so in theory they can benefits from the power controller.  Maybe
> only regulator and clock can't be covered completely for other boards.
>
> The patch can make usb port deal with the 'power controller' only, and make it
> avoid to deal with regulators/clocks/... directly.
>
I am curious too, except for clocks and voltage supplies (regulators),
what other external resources does a chip need ?
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ming Lei Dec. 6, 2012, 1:18 p.m. UTC | #6

On Thu, Dec 6, 2012 at 11:46 AM, Jassi Brar <[e-mail]> wrote:
>> The patch can make usb port deal with the 'power controller' only, and make it
>> avoid to deal with regulators/clocks/... directly.
>>
> I am curious too, except for clocks and voltage supplies (regulators),
> what other external resources does a chip need ?

For example, one indicator LED which doesn't connect to the same power
domain might need to be triggered after the power switch state is changed.

Thanks,

Jassi Brar Dec. 6, 2012, 2:50 p.m. UTC | #7

On 6 December 2012 18:48, Ming Lei <[e-mail]> wrote:
> On Thu, Dec 6, 2012 at 11:46 AM, Jassi Brar <[e-mail]> wrote:
>>> The patch can make usb port deal with the 'power controller' only, and make it
>>> avoid to deal with regulators/clocks/... directly.
>>>
>> I am curious too, except for clocks and voltage supplies (regulators),
>> what other external resources does a chip need ?
>
> For example, one indicator LED which doesn't connect to the same power
> domain might need to be triggered after the power switch state is changed.
>
Hmm.. I am not sure if we could call an indicator LED a resource that
a chip needs to be functional. Isn't how mmc core manages the
indicator led, a better way?

cheers.
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
index 2e58ebb..c08bfc9 100644
--- a/drivers/base/power/Makefile
+++ b/drivers/base/power/Makefile
@@ -5,5 +5,6 @@  obj-$(CONFIG_PM_TRACE_RTC)	+= trace.o
 obj-$(CONFIG_PM_OPP)	+= opp.o
 obj-$(CONFIG_PM_GENERIC_DOMAINS)	+=  domain.o domain_governor.o
 obj-$(CONFIG_HAVE_CLK)	+= clock_ops.o
+obj-$(CONFIG_POWER_CONTROLLER)	+= power_controller.o
 
 ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
diff --git a/drivers/base/power/power_controller.c b/drivers/base/power/power_controller.c
new file mode 100644
index 0000000..d7671fb
--- /dev/null
+++ b/drivers/base/power/power_controller.c
@@ -0,0 +1,110 @@ 
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/power_controller.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/export.h>
+
+static DEFINE_MUTEX(pc_lock);
+
+static void pc_devm_release(struct device *dev, void *res)
+{
+}
+
+static int pc_devm_match(struct device *dev, void *res, void *match_data)
+{
+	struct pc_dev_data *data = res;
+
+	return (data->magic == (unsigned long)pc_devm_release);
+}
+
+static struct pc_dev_data *dev_pc_data(struct device *dev)
+{
+	struct pc_dev_data *data;
+
+	data = devres_find(dev, pc_devm_release, pc_devm_match, NULL);
+	return data;
+}
+
+static int pc_add_devm_data(struct device *dev, struct power_controller *pc,
+			    void *dev_data, int dev_data_size)
+{
+	struct pc_dev_data *data;
+	int ret = 0;
+
+	mutex_lock(&pc_lock);
+
+	/* each device should only have one power controller resource */
+	data = dev_pc_data(dev);
+	if (data) {
+		ret = 1;
+		goto exit;
+	}
+
+	data = devres_alloc(pc_devm_release, sizeof(struct pc_dev_data) +
+			    dev_data_size, GFP_KERNEL);
+	if (!data) {
+		ret = -ENOMEM;
+		goto exit;
+	}
+
+	data->magic = (unsigned long)pc_devm_release;
+	data->pc = pc;
+	data->dev_data = &data[1];
+	memcpy(data->dev_data, dev_data, dev_data_size);
+	devres_add(dev, data);
+
+exit:
+	mutex_unlock(&pc_lock);
+	return ret;
+}
+
+static struct power_controller *dev_pc(struct device *dev)
+{
+	struct pc_dev_data *data = dev_pc_data(dev);
+
+	if (data)
+		return data->pc;
+	return NULL;
+}
+
+struct pc_dev_data *dev_pc_get_data(struct device *dev)
+{
+	struct pc_dev_data *data = dev_pc_data(dev);
+	return data;
+}
+EXPORT_SYMBOL(dev_pc_get_data);
+
+int dev_pc_bind(struct power_controller *pc, struct device *dev,
+		void *dev_data, int dev_data_size)
+{
+	return pc_add_devm_data(dev, pc, dev_data, dev_data_size);
+}
+EXPORT_SYMBOL(dev_pc_bind);
+
+void dev_pc_unbind(struct power_controller *pc, struct device *dev)
+{
+}
+EXPORT_SYMBOL(dev_pc_unbind);
+
+void dev_pc_power_on(struct device *dev)
+{
+	struct power_controller *pc = dev_pc(dev);
+
+	if (!pc)	return;
+
+	if (atomic_inc_return(&pc->count) == 1)
+		pc->power_on(pc, dev);
+}
+EXPORT_SYMBOL(dev_pc_power_on);
+
+void dev_pc_power_off(struct device *dev)
+{
+	struct power_controller *pc = dev_pc(dev);
+
+	if (!pc)	return;
+
+	if (!atomic_dec_return(&pc->count))
+		pc->power_off(pc, dev);
+}
+EXPORT_SYMBOL(dev_pc_power_off);
diff --git a/include/linux/power_controller.h b/include/linux/power_controller.h
new file mode 100644
index 0000000..772f6d7
--- /dev/null
+++ b/include/linux/power_controller.h
@@ -0,0 +1,48 @@ 
+#ifndef _LINUX_POWER_CONTROLLER_H
+#define _LINUX_POWER_CONTROLLER_H
+
+#include <linux/device.h>
+
+/*
+ * One power controller provides simple power on and power off.
+ *
+ * One power controller can bind to more than one device, which
+ * provides power logically, for example, we can think one usb port
+ * in hub provides power to the usb device attached to the port, even
+ * though the power is supplied actually by other ways, eg. the usb
+ * hub is a self-power device. From hardware view, more than one
+ * device can share one power domain, and power controller can power
+ * on if one of these devices need to provide power, and power off if
+ * all these devices don't need to provide power.
+ *
+ * The abstract is introduced to hide the implementation details of
+ * power controller, and only let platform code handle the details.
+ */
+struct power_controller {
+	atomic_t count;			/* Number of users with power "on" */
+	char *name;
+	void (*power_off)(struct power_controller *pc, struct device *dev);
+	void (*power_on)(struct power_controller *pc, struct device *dev);
+};
+
+struct pc_dev_data {
+	unsigned long magic;
+	struct power_controller *pc;
+	void	*dev_data;
+};
+
+#ifdef CONFIG_POWER_CONTROLLER
+extern struct pc_dev_data *dev_pc_get_data(struct device *dev);
+extern int dev_pc_bind(struct power_controller *pc, struct device *dev, void *dev_data, int dev_data_size);
+extern void dev_pc_unbind(struct power_controller *pc, struct device *dev);
+extern void dev_pc_power_on(struct device *dev);
+extern void dev_pc_power_off(struct device *dev);
+#else
+static inline struct pc_dev_data *dev_pc_get_data(struct device *dev){return NULL;}
+static inline int dev_pc_bind(struct power_controller *pc, struct device *dev, void *dev_data,
+				int dev_data_size){return 0;}
+static inline void dev_pc_unbind(struct power_controller *pc, struct device *dev){}
+static inline void dev_pc_power_on(struct device *dev){}
+static inline void dev_pc_power_off(struct device *dev){}
+#endif
+#endif /* _LINUX_POWER_CONTROLLER_H */
diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig
index 5dfdc9e..51803a9 100644
--- a/kernel/power/Kconfig
+++ b/kernel/power/Kconfig
@@ -255,6 +255,12 @@  config PM_OPP
 	  implementations a ready to use framework to manage OPPs.
 	  For more information, read <file:Documentation/power/opp.txt>
 
+config POWER_CONTROLLER
+	bool "Power Controller"
+	---help---
+	Power Controller is an abstract on power switch which can be
+	shared by more than more devices.
+
 config PM_CLK
 	def_bool y
 	depends on PM && HAVE_CLK