Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH 1/1] extcon: gpio: Add power resume support

5 views
Skip to first unread message

rjying

unread,
Dec 20, 2013, 3:20:02 AM12/20/13
to
From: Rongjun Ying <rongju...@csr.com>

After system resume, need send extcon uevent to userspace

Change-Id: I32a9e1c6646035f95765bba79a7acaccb8ce45a7

Signed-off-by: Rongjun Ying <rongju...@csr.com>
---
drivers/extcon/extcon-gpio.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 7e0dff5..d916522 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -159,12 +159,29 @@ static int gpio_extcon_remove(struct platform_device *pdev)
return 0;
}

+#ifdef CONFIG_PM_SLEEP
+static int gpio_extcon_resume(struct device *dev)
+{
+ struct gpio_extcon_data *extcon_data;
+
+ extcon_data = dev_get_drvdata(dev);
+ queue_delayed_work(system_power_efficient_wq, &extcon_data->work,
+ extcon_data->debounce_jiffies);
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops gpio_extcon_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(NULL, gpio_extcon_resume)
+};
+
static struct platform_driver gpio_extcon_driver = {
.probe = gpio_extcon_probe,
.remove = gpio_extcon_remove,
.driver = {
.name = "extcon-gpio",
.owner = THIS_MODULE,
+ .pm = &gpio_extcon_pm_ops,
},
};

--
1.7.5.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Chanwoo Choi

unread,
Dec 22, 2013, 11:30:02 PM12/22/13
to
On 12/20/2013 05:09 PM, rjying wrote:
> From: Rongjun Ying <rongju...@csr.com>
>
> After system resume, need send extcon uevent to userspace

Why did extcon send uevent after wakeup from suspend?

If extcon cable is attatched or detached on suspend state,
Kernel can detect the interrupt about changed state of extcon.
So, kernel would execute proper operation about interrupt
after wakeup from suspend state.

I think it isn't necessary.

Thanks,
Chanwoo Choi

Barry Song

unread,
Dec 23, 2013, 1:20:02 AM12/23/13
to
2013/12/23 Chanwoo Choi <cw00...@samsung.com>:
> On 12/20/2013 05:09 PM, rjying wrote:
>> From: Rongjun Ying <rongju...@csr.com>
>>
>> After system resume, need send extcon uevent to userspace
>
> Why did extcon send uevent after wakeup from suspend?
>
> If extcon cable is attatched or detached on suspend state,
> Kernel can detect the interrupt about changed state of extcon.

irq controller has lost power in suspend, so there is no pending interrupt.
and HW will not pend any interrupt when we hotplug cable during sleep.

> So, kernel would execute proper operation about interrupt
> after wakeup from suspend state.

kernel only save/restore the register status of gpio, how could it
know whether there is a pending interrupt if the HW doesn't do it?
-barry

Chanwoo Choi

unread,
Dec 23, 2013, 1:40:01 AM12/23/13
to
On 12/23/2013 03:10 PM, Barry Song wrote:
> 2013/12/23 Chanwoo Choi <cw00...@samsung.com>:
>> On 12/20/2013 05:09 PM, rjying wrote:
>>> From: Rongjun Ying <rongju...@csr.com>
>>>
>>> After system resume, need send extcon uevent to userspace
>>
>> Why did extcon send uevent after wakeup from suspend?
>>
>> If extcon cable is attatched or detached on suspend state,
>> Kernel can detect the interrupt about changed state of extcon.
>
> irq controller has lost power in suspend, so there is no pending interrupt.
> and HW will not pend any interrupt when we hotplug cable during sleep.

No, SoC in suspend state must maintain the minimum power under 1mA
if completed the power-optimization on suspend state.

If user insert USB cable to target, the external interrupt connected to
USB port is happened. And kernel would be waked up from suspend state
to operate proper interrupt handler of external interrupt.

Also,
Input subsystem used gpio-keys driver for power button..
If user press power button in suspend state, target would be waked up from suspend state.
It is same case both extcon gpio and gpio-keys of input subsystem.

Barry Song

unread,
Dec 23, 2013, 2:40:02 AM12/23/13
to
2013/12/23 Chanwoo Choi <cw00...@samsung.com>:
> On 12/23/2013 03:10 PM, Barry Song wrote:
>> 2013/12/23 Chanwoo Choi <cw00...@samsung.com>:
>>> On 12/20/2013 05:09 PM, rjying wrote:
>>>> From: Rongjun Ying <rongju...@csr.com>
>>>>
>>>> After system resume, need send extcon uevent to userspace
>>>
>>> Why did extcon send uevent after wakeup from suspend?
>>>
>>> If extcon cable is attatched or detached on suspend state,
>>> Kernel can detect the interrupt about changed state of extcon.
>>
>> irq controller has lost power in suspend, so there is no pending interrupt.
>> and HW will not pend any interrupt when we hotplug cable during sleep.
>
> No, SoC in suspend state must maintain the minimum power under 1mA
> if completed the power-optimization on suspend state.
>
> If user insert USB cable to target, the external interrupt connected to
> USB port is happened. And kernel would be waked up from suspend state
> to operate proper interrupt handler of external interrupt.

no. not every USB supports that. that depends on the power domain design of SoC.

>
> Also,
> Input subsystem used gpio-keys driver for power button..
> If user press power button in suspend state, target would be waked up from suspend state.
> It is same case both extcon gpio and gpio-keys of input subsystem.

no. it depends on the SoC design. many SoC only support 1 special key
which can work as ON-KEY as wakeup source. and this kind of keys might
not be GPIO at all.
there is a special power domain which is still open for it.

Chanwoo Choi

unread,
Dec 23, 2013, 3:00:02 AM12/23/13
to
On 12/23/2013 04:36 PM, Barry Song wrote:
> 2013/12/23 Chanwoo Choi <cw00...@samsung.com>:
>> On 12/23/2013 03:10 PM, Barry Song wrote:
>>> 2013/12/23 Chanwoo Choi <cw00...@samsung.com>:
>>>> On 12/20/2013 05:09 PM, rjying wrote:
>>>>> From: Rongjun Ying <rongju...@csr.com>
>>>>>
>>>>> After system resume, need send extcon uevent to userspace
>>>>
>>>> Why did extcon send uevent after wakeup from suspend?
>>>>
>>>> If extcon cable is attatched or detached on suspend state,
>>>> Kernel can detect the interrupt about changed state of extcon.
>>>
>>> irq controller has lost power in suspend, so there is no pending interrupt.
>>> and HW will not pend any interrupt when we hotplug cable during sleep.
>>
>> No, SoC in suspend state must maintain the minimum power under 1mA
>> if completed the power-optimization on suspend state.
>>
>> If user insert USB cable to target, the external interrupt connected to
>> USB port is happened. And kernel would be waked up from suspend state
>> to operate proper interrupt handler of external interrupt.
>
> no. not every USB supports that. that depends on the power domain design of SoC.

USB is only example for gpio control in suspend state.

>
>>
>> Also,
>> Input subsystem used gpio-keys driver for power button..
>> If user press power button in suspend state, target would be waked up from suspend state.
>> It is same case both extcon gpio and gpio-keys of input subsystem.
>
> no. it depends on the SoC design. many SoC only support 1 special key
> which can work as ON-KEY as wakeup source. and this kind of keys might
> not be GPIO at all.
> there is a special power domain which is still open for it.

many SoC?

As I knew, most SoC has supported various wakeup source.
As you comment, if specific SoC support only one special key
for wakeup from suspend state, I think it isn't common.

Also,
This patch isn't necessary on SoCs which support various wakeup source (e.g., external interrupt).
As you comment, this issue has dependecy on specific SoC. Why did you think this common code?

Barry Song

unread,
Dec 23, 2013, 3:20:02 AM12/23/13
to
i am not thinking this patch must be common codes but i think the
extcon should provide common codes to support all chips. that is what
a framework should consider.

if there is no this or things similar with this, how could extcon
support the chips which don't support receiving sleep gpio interrupts?

Chanwoo Choi

unread,
Dec 23, 2013, 3:30:02 AM12/23/13
to
Sure, subsystem should support all cases related to this issue.

I'd like to send common patch to support all cases as we discussed.
If some patch support all case, I would review and apply it.

Chanwoo Choi

Barry Song

unread,
Dec 23, 2013, 3:40:01 AM12/23/13
to
well. agree.

then, will you give comments about how to make this one common?
will it be useful to differentiate two different kinds of chips and
branch to two different code paths?

>
> Chanwoo Choi
>
>

-barry

MyungJoo Ham

unread,
Dec 23, 2013, 4:10:02 AM12/23/13
to
> Chanwoo Choi

Dear Barry and Chanwoo,


What about having a flag in extcon platform data that describes
whether this extcon-gpio requires status double checking at resume
or not?


Cheers,
MyungJoo

Barry Song

unread,
Dec 23, 2013, 4:30:02 AM12/23/13
to
2013/12/23 MyungJoo Ham <myungj...@samsung.com>:
MyungJoo,

Thanks!
i am ok. what about naming it as "bool lost_sleep_irq"? default, it is
0, for chips that will lose sleeping IRQ, set it to 1?

Chanwoo, how do you think?

>
>
> Cheers,
> MyungJoo

rjying

unread,
Dec 27, 2013, 12:50:02 AM12/27/13
to
From: Rongjun Ying <rongju...@csr.com>

When system on the suspend state, Some SoC can't get gpio interrupt.
After system resume, need send extcon uevent to userspace.

Signed-off-by: Rongjun Ying <rongju...@csr.com>
---
-v2: Add lost_sleep_irq flags.

drivers/extcon/extcon-gpio.c | 20 ++++++++++++++++++++
include/linux/extcon/extcon-gpio.h | 1 +
2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 7e0dff5..fde52c1 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -40,6 +40,7 @@ struct gpio_extcon_data {
int irq;
struct delayed_work work;
unsigned long debounce_jiffies;
+ bool lost_sleep_irq;
};

static void gpio_extcon_work(struct work_struct *work)
@@ -103,6 +104,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
extcon_data->gpio_active_low = pdata->gpio_active_low;
extcon_data->state_on = pdata->state_on;
extcon_data->state_off = pdata->state_off;
+ extcon_data->lost_sleep_irq = pdata->lost_sleep_irq;
if (pdata->state_on && pdata->state_off)
extcon_data->edev.print_state = extcon_gpio_print_state;
if (pdata->debounce) {
@@ -159,12 +161,30 @@ static int gpio_extcon_remove(struct platform_device *pdev)
return 0;
}

+#ifdef CONFIG_PM_SLEEP
+static int gpio_extcon_resume(struct device *dev)
+{
+ struct gpio_extcon_data *extcon_data;
+
+ extcon_data = dev_get_drvdata(dev);
+ if (extcon_data->lost_sleep_irq)
+ queue_delayed_work(system_power_efficient_wq,
+ &extcon_data->work, extcon_data->debounce_jiffies);
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops gpio_extcon_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(NULL, gpio_extcon_resume)
+};
+
static struct platform_driver gpio_extcon_driver = {
.probe = gpio_extcon_probe,
.remove = gpio_extcon_remove,
.driver = {
.name = "extcon-gpio",
.owner = THIS_MODULE,
+ .pm = &gpio_extcon_pm_ops,
},
};

diff --git a/include/linux/extcon/extcon-gpio.h b/include/linux/extcon/extcon-gpio.h
index 4195810..c7f0c3e 100644
--- a/include/linux/extcon/extcon-gpio.h
+++ b/include/linux/extcon/extcon-gpio.h
@@ -51,6 +51,7 @@ struct gpio_extcon_platform_data {
/* if NULL, "0" or "1" will be printed */
const char *state_on;
const char *state_off;
+ bool lost_sleep_irq;
};

#endif /* __EXTCON_GPIO_H__ */
--
1.7.5.4

Barry Song

unread,
Jan 6, 2014, 9:30:02 PM1/6/14
to
2013/12/27 rjying <rjy...@gmail.com>:
> From: Rongjun Ying <rongju...@csr.com>
>
> When system on the suspend state, Some SoC can't get gpio interrupt.
> After system resume, need send extcon uevent to userspace.
>
> Signed-off-by: Rongjun Ying <rongju...@csr.com>

Reviewed-by: Barry Song <Baohu...@csr.com>

for CSR SiRFSoC, we need similar patch in extcon to make the lost
plug/unplug event during sleeping to be resent.
-barry

Chanwoo Choi

unread,
Jan 6, 2014, 10:00:01 PM1/6/14
to
On 12/27/2013 02:40 PM, rjying wrote:
> From: Rongjun Ying <rongju...@csr.com>
>
> When system on the suspend state, Some SoC can't get gpio interrupt.
> After system resume, need send extcon uevent to userspace.
>
> Signed-off-by: Rongjun Ying <rongju...@csr.com>
> ---
> -v2: Add lost_sleep_irq flags.
>
> drivers/extcon/extcon-gpio.c | 20 ++++++++++++++++++++
> include/linux/extcon/extcon-gpio.h | 1 +
> 2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index 7e0dff5..fde52c1 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -40,6 +40,7 @@ struct gpio_extcon_data {
> int irq;
> struct delayed_work work;
> unsigned long debounce_jiffies;
> + bool lost_sleep_irq;

I prefer 'check_on_resume' instead of 'load_sleep_irq'.

> };
>
> static void gpio_extcon_work(struct work_struct *work)
> @@ -103,6 +104,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
> extcon_data->gpio_active_low = pdata->gpio_active_low;
> extcon_data->state_on = pdata->state_on;
> extcon_data->state_off = pdata->state_off;
> + extcon_data->lost_sleep_irq = pdata->lost_sleep_irq;

ditto.

> if (pdata->state_on && pdata->state_off)
> extcon_data->edev.print_state = extcon_gpio_print_state;
> if (pdata->debounce) {
> @@ -159,12 +161,30 @@ static int gpio_extcon_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int gpio_extcon_resume(struct device *dev)
> +{
> + struct gpio_extcon_data *extcon_data;
> +
> + extcon_data = dev_get_drvdata(dev);
> + if (extcon_data->lost_sleep_irq)

ditto.
ditto.

> };
>
> #endif /* __EXTCON_GPIO_H__ */
>

Thanks,
Chanwoo Choi

RongJun Ying

unread,
Jan 7, 2014, 12:00:01 AM1/7/14
to
From: Rongjun Ying <rongju...@csr.com>

When system on the suspend state, Some SoC can't get gpio interrupt.
After system resume, need send extcon uevent to userspace.

Signed-off-by: Rongjun Ying <rongju...@csr.com>
Reviewed-by: Barry Song <Baohu...@csr.com>
---
-v3:
'check_on_resume' instead of 'load_sleep_irq' as Chanwoo Choi's proposal.

drivers/extcon/extcon-gpio.c | 20 ++++++++++++++++++++
include/linux/extcon/extcon-gpio.h | 1 +
2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 7e0dff5..fde52c1 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -40,6 +40,7 @@ struct gpio_extcon_data {
int irq;
struct delayed_work work;
unsigned long debounce_jiffies;
+ bool check_on_resume;
};

static void gpio_extcon_work(struct work_struct *work)
@@ -103,6 +104,7 @@ static int gpio_extcon_probe(struct platform_device *pdev)
extcon_data->gpio_active_low = pdata->gpio_active_low;
extcon_data->state_on = pdata->state_on;
extcon_data->state_off = pdata->state_off;
+ extcon_data->check_on_resume = pdata->check_on_resume;
if (pdata->state_on && pdata->state_off)
extcon_data->edev.print_state = extcon_gpio_print_state;
if (pdata->debounce) {
@@ -159,12 +161,30 @@ static int gpio_extcon_remove(struct platform_device *pdev)
return 0;
}

+#ifdef CONFIG_PM_SLEEP
+static int gpio_extcon_resume(struct device *dev)
+{
+ struct gpio_extcon_data *extcon_data;
+
+ extcon_data = dev_get_drvdata(dev);
+ if (extcon_data->check_on_resume)
+ bool check_on_resume;
};

#endif /* __EXTCON_GPIO_H__ */
--
1.7.5.4

MyungJoo Ham

unread,
Jan 7, 2014, 1:00:01 AM1/7/14
to
> From: Rongjun Ying <rongju...@csr.com>
>
> When system on the suspend state, Some SoC can't get gpio interrupt.
> After system resume, need send extcon uevent to userspace.
>
> Signed-off-by: Rongjun Ying <rongju...@csr.com>
> Reviewed-by: Barry Song <Baohu...@csr.com>

Acked-by: MyungJoo Ham <myungj...@samsung.com>

Thanks!

Chanwoo Choi

unread,
Jan 7, 2014, 1:10:02 AM1/7/14
to
Hi RongJun,
If CONFIG_PM_SLEEP is undefined, gpio_extcon_pm_ops cannot find gpio_extcon_resume function.
You should define dummy function for gpio_extcon_resume function.

Chanwoo Choi

unread,
Jan 7, 2014, 1:10:02 AM1/7/14
to
This patch has conflict as following:
You have to implement extcon patch based mainline extcon-next branch.

Applying: extcon: gpio: Add power resume support
error: patch failed: drivers/extcon/extcon-gpio.c:103
error: drivers/extcon/extcon-gpio.c: patch does not apply
Patch failed at 0001 extcon: gpio: Add power resume support
The copy of the patch that failed is found in:
/home/cwchoi00/kernel/git.kernel/extcon/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

This time, I will manually apply this patch on extcon branch.

Thanks,
Chanwoo Choi

On 01/07/2014 01:56 PM, RongJun Ying wrote:

Rongjun Ying

unread,
Jan 7, 2014, 4:50:02 AM1/7/14
to


> -----Original Message-----
> From: Chanwoo Choi [mailto:cw00...@samsung.com]
> Sent: Tuesday, January 07, 2014 2:07 PM
> To: RongJun Ying
> Cc: MyungJoo Ham; Barry Song; linux-ar...@lists.infradead.org;
> linux-...@vger.kernel.org; DL-SHA-WorkGroupLinux; Rongjun Ying
> Subject: Re: [PATCH v3] extcon: gpio: Add power resume support
>
> This patch has conflict as following:
> You have to implement extcon patch based mainline extcon-next branch.
>
> Applying: extcon: gpio: Add power resume support
> error: patch failed: drivers/extcon/extcon-gpio.c:103
> error: drivers/extcon/extcon-gpio.c: patch does not apply Patch failed
> at 0001 extcon: gpio: Add power resume support The copy of the patch
> that failed is found in:
> /home/cwchoi00/kernel/git.kernel/extcon/.git/rebase-apply/patch
> When you have resolved this problem, run "git am --resolved".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
> This time, I will manually apply this patch on extcon branch.
>
> Thanks,
> Chanwoo Choi
>
Thank you.

RongJun Ying
> > + struct gpio_extcon_data *extcon_data;
> > +
> > + extcon_data = dev_get_drvdata(dev);
> > + if (extcon_data->check_on_resume)
> > + queue_delayed_work(system_power_efficient_wq,
> > + &extcon_data->work, extcon_data->debounce_jiffies);
> > + return 0;
> > +}
> > +#endif
> > +
> > +static const struct dev_pm_ops gpio_extcon_pm_ops = {
> > + SET_SYSTEM_SLEEP_PM_OPS(NULL, gpio_extcon_resume) };
> > +
> > static struct platform_driver gpio_extcon_driver = {
> > .probe = gpio_extcon_probe,
> > .remove = gpio_extcon_remove,
> > .driver = {
> > .name = "extcon-gpio",
> > .owner = THIS_MODULE,
> > + .pm = &gpio_extcon_pm_ops,
> > },
> > };
> >
> > diff --git a/include/linux/extcon/extcon-gpio.h
> > b/include/linux/extcon/extcon-gpio.h
> > index 4195810..c7f0c3e 100644
> > --- a/include/linux/extcon/extcon-gpio.h
> > +++ b/include/linux/extcon/extcon-gpio.h
> > @@ -51,6 +51,7 @@ struct gpio_extcon_platform_data {
> > /* if NULL, "0" or "1" will be printed */
> > const char *state_on;
> > const char *state_off;
> > + bool check_on_resume;
> > };
> >
> > #endif /* __EXTCON_GPIO_H__ */
> > --
> > 1.7.5.4
> >
> >
>
>
>
> To report this email as spam click
> https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==
> BhEym36W00netVd8YYrcUQrAnqreWejYcysfmF8UmgH1OQ== .


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.

Rongjun Ying

unread,
Jan 7, 2014, 5:20:02 AM1/7/14
to


> -----Original Message-----
> From: Chanwoo Choi [mailto:cw00...@samsung.com]
> Sent: Tuesday, January 07, 2014 2:09 PM
> To: RongJun Ying
> Cc: MyungJoo Ham; Barry Song; linux-ar...@lists.infradead.org;
> linux-...@vger.kernel.org; DL-SHA-WorkGroupLinux; Rongjun Ying
> Subject: Re: [PATCH v3] extcon: gpio: Add power resume support
>
> > + struct gpio_extcon_data *extcon_data;
> > +
> > + extcon_data = dev_get_drvdata(dev);
> > + if (extcon_data->check_on_resume)
> > + queue_delayed_work(system_power_efficient_wq,
> > + &extcon_data->work, extcon_data->debounce_jiffies);
> > + return 0;
> > +}
> > +#endif
> > +
> > +static const struct dev_pm_ops gpio_extcon_pm_ops = {
> > + SET_SYSTEM_SLEEP_PM_OPS(NULL, gpio_extcon_resume)
>
> If CONFIG_PM_SLEEP is undefined, gpio_extcon_pm_ops cannot find
> gpio_extcon_resume function.
> You should define dummy function for gpio_extcon_resume function.
>
>
In the include/Linux/pm.h
If CONFIG_PM_SLEEP is undefined, the SET_SYSTEM_SLEEP_PM_OPS macro is bypassed.

#ifdef CONFIG_PM_SLEEP
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
.suspend = suspend_fn, \
.resume = resume_fn, \
.freeze = suspend_fn, \
.thaw = resume_fn, \
.poweroff = suspend_fn, \
.restore = resume_fn,
#else
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
#endif
>
>
> To report this email as spam click
> https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==
> UfkIuR0P8QH1DW7C+lVo3569nqreWejYcysfmF8UmgH1OQ== .


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.

Chanwoo Choi

unread,
Jan 8, 2014, 8:00:02 PM1/8/14
to
Hi Rongjun,

OK, I applied this patch on extcon-next branch.

Thannks,
Chanwoo Choi
0 new messages