[PATCH] mfd: cros_ec_spi: set wakeup capability

[PATCH] mfd: cros_ec_spi: set wakeup capability

[Doug Anderson]

From: Prathyush K <prathyush.k@samsung.com>

Set the device as wakeup capable and register the wakeup source.

Note: Though it makes more sense to have the SPI framework do this,
(either via device tree or by board_info)
this change is as per an existing mail chain:
https://lkml.org/lkml/2009/8/27/291

Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
---
Note that I don't have suspend/resume actually working upstream, but I
see that /sys/bus/spi/drivers/cros-ec-spi/spi2.0/power/wakeup exists
with this patch and doesn't exist without it.

 drivers/mfd/cros_ec_spi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 0b8d328..ef22dd5 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -385,6 +385,8 @@ static int cros_ec_spi_probe(struct spi_device *spi)
 		return err;
 	}
 
+	device_init_wakeup(&spi->dev, true);
+
 	return 0;
 }
 
-- 
2.0.0.526.g5318336

Re: [PATCH] mfd: cros_ec_spi: set wakeup capability

[Lee Jones]

> From: Prathyush K <prathyush.k@samsung.com>
> 
> Set the device as wakeup capable and register the wakeup source.
> 
> Note: Though it makes more sense to have the SPI framework do this,
> (either via device tree or by board_info)
> this change is as per an existing mail chain:
> https://lkml.org/lkml/2009/8/27/291
> 
> Signed-off-by: Prathyush K <prathyush.k@samsung.com>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> ---
> Note that I don't have suspend/resume actually working upstream, but I
> see that /sys/bus/spi/drivers/cros-ec-spi/spi2.0/power/wakeup exists
> with this patch and doesn't exist without it.

Very well.  Applied, thanks.

>  drivers/mfd/cros_ec_spi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index 0b8d328..ef22dd5 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -385,6 +385,8 @@ static int cros_ec_spi_probe(struct spi_device *spi)
>  		return err;
>  	}
>  
> +	device_init_wakeup(&spi->dev, true);
> +
>  	return 0;
>  }
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] mfd: cros_ec_spi: set wakeup capability

[Lee Jones]

> Lee (-others),

Re-CC'ing the list.

> On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> From: Prathyush K <prathyush.k@samsung.com>
> >>
> >> Set the device as wakeup capable and register the wakeup source.
> >>
> >> Note: Though it makes more sense to have the SPI framework do this,
> >> (either via device tree or by board_info)
> >> this change is as per an existing mail chain:
> >> https://lkml.org/lkml/2009/8/27/291
> >>
> >> Signed-off-by: Prathyush K <prathyush.k@samsung.com>
> >> Signed-off-by: Doug Anderson <dianders@chromium.org>
> >> ---
> >> Note that I don't have suspend/resume actually working upstream, but I
> >> see that /sys/bus/spi/drivers/cros-ec-spi/spi2.0/power/wakeup exists
> >> with this patch and doesn't exist without it.
> >
> > Very well.  Applied, thanks.
> 
> Thanks for applying!  ...did this go in some non-standard branch?  I
> see another of my patches got committed to your "for-mfd-next" tree on
> the 19th but I don't see this one...

Patience Grasshopper.  When I say that it's applied, it means that I
have done so locally only.  After I've collected a few local patches
I'll usually then fix them all with with my SoB and push them out to
the public MFD tree.

BTW, it's always best to leave the ML in as CC, so others can see the
answer to these types of questions.  It may save a few emails a year,
but every little helps. :)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] mfd: cros_ec_spi: set wakeup capability

[Doug Anderson]

Lee,

On Mon, Jun 23, 2014 at 2:26 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> Lee (-others),
>
> Re-CC'ing the list.
>
>> On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> From: Prathyush K <prathyush.k@samsung.com>
>> >>
>> >> Set the device as wakeup capable and register the wakeup source.
>> >>
>> >> Note: Though it makes more sense to have the SPI framework do this,
>> >> (either via device tree or by board_info)
>> >> this change is as per an existing mail chain:
>> >> https://lkml.org/lkml/2009/8/27/291
>> >>
>> >> Signed-off-by: Prathyush K <prathyush.k@samsung.com>
>> >> Signed-off-by: Doug Anderson <dianders@chromium.org>
>> >> ---
>> >> Note that I don't have suspend/resume actually working upstream, but I
>> >> see that /sys/bus/spi/drivers/cros-ec-spi/spi2.0/power/wakeup exists
>> >> with this patch and doesn't exist without it.
>> >
>> > Very well.  Applied, thanks.
>>
>> Thanks for applying!  ...did this go in some non-standard branch?  I
>> see another of my patches got committed to your "for-mfd-next" tree on
>> the 19th but I don't see this one...
>
> Patience Grasshopper.  When I say that it's applied, it means that I
> have done so locally only.  After I've collected a few local patches
> I'll usually then fix them all with with my SoB and push them out to
> the public MFD tree.
>
> BTW, it's always best to leave the ML in as CC, so others can see the
> answer to these types of questions.  It may save a few emails a year,
> but every little helps. :)

Thanks!  I know it's super hard to keep track of everything, so I
figure that it's part of my job as a submitter to help maintainers
keep track of my patches.  I've definitely had many-a-time where
someone has said "oops, I forgot about that" or where people were not
on the same page about what the next steps ought to be.  Sounds like I
should perhaps tone back and wait a bit longer before I ping about
things.

Note: if there's any way you can provide more info to submitters like
me then it would certainly be appreciated!  In this case I was trying
hard not to be a noob.  I checked your public git tree and saw patches
applied that were after the date you sent your last email and didn't
see this patch.  I definitely don't know your personal workflow, but
it's good to know that didn't mean the patch was lost.

A few things that would have kept me from sending an email:

* If your email had read: "Applied to low priority fixes" and the
other email had read "Applied to high priority fixes" then I would
have understood that there were two queues and wouldn't have been
concerned.

* If you are able to publish (by pushing) your WIP collection to
patches to git.kernel.org then I would be able to confirm myself that
the patch wasn't lost.  If your queue was named something like "WIP"
then I would also have a good idea that inclusion in that queue isn't
a guarantee that my patch would land in mainline and I would also be
able to guess that git hashes were probably not stable there.


...anyway, as I said I will try to follow up less often and only ping
if I see silence for > 2 weeks.

:)


-Doug

Re: [PATCH] mfd: cros_ec_spi: set wakeup capability

[Olof Johansson]

On Mon, Jun 23, 2014 at 2:26 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> Lee (-others),
>
> Re-CC'ing the list.
>
>> On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> >> From: Prathyush K <prathyush.k@samsung.com>
>> >>
>> >> Set the device as wakeup capable and register the wakeup source.
>> >>
>> >> Note: Though it makes more sense to have the SPI framework do this,
>> >> (either via device tree or by board_info)
>> >> this change is as per an existing mail chain:
>> >> https://lkml.org/lkml/2009/8/27/291
>> >>
>> >> Signed-off-by: Prathyush K <prathyush.k@samsung.com>
>> >> Signed-off-by: Doug Anderson <dianders@chromium.org>
>> >> ---
>> >> Note that I don't have suspend/resume actually working upstream, but I
>> >> see that /sys/bus/spi/drivers/cros-ec-spi/spi2.0/power/wakeup exists
>> >> with this patch and doesn't exist without it.
>> >
>> > Very well.  Applied, thanks.
>>
>> Thanks for applying!  ...did this go in some non-standard branch?  I
>> see another of my patches got committed to your "for-mfd-next" tree on
>> the 19th but I don't see this one...
>
> Patience Grasshopper.  When I say that it's applied, it means that I
> have done so locally only.  After I've collected a few local patches
> I'll usually then fix them all with with my SoB and push them out to
> the public MFD tree.
>
> BTW, it's always best to leave the ML in as CC, so others can see the
> answer to these types of questions.  It may save a few emails a year,
> but every little helps. :)

It's great to see this on the list, because I find your workflow as a
maintainer to be hard to follow as a developer.

You applying patches but taking several days to push out makes it
completely opaque for someone to know if you just accidentally missed
to apply the patch after all (it happens, I've done that myself). It's
pretty common to expect a "thanks, applied" patch to show up in
linux-next within one day or so depending on timing.

The fact that you had already pushed out a patch that you had replied
to even later makes for extra confusion. So I'm sorry Lee, but I don't
think Doug was unreasonable in asking for status here. Sometimes
maintainers forget to push, which is why it's a good idea to ping a
few days later if the patch hasn't showed up in -next.


-Olof

Re: [PATCH] mfd: cros_ec_spi: set wakeup capability

[Lee Jones]

On Thu, 26 Jun 2014, Olof Johansson wrote:

> On Mon, Jun 23, 2014 at 2:26 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> Lee (-others),
> >
> > Re-CC'ing the list.
> >
> >> On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones <lee.jones@linaro.org> wrote:
> >> >> From: Prathyush K <prathyush.k@samsung.com>
> >> >>
> >> >> Set the device as wakeup capable and register the wakeup source.
> >> >>
> >> >> Note: Though it makes more sense to have the SPI framework do this,
> >> >> (either via device tree or by board_info)
> >> >> this change is as per an existing mail chain:
> >> >> https://lkml.org/lkml/2009/8/27/291
> >> >>
> >> >> Signed-off-by: Prathyush K <prathyush.k@samsung.com>
> >> >> Signed-off-by: Doug Anderson <dianders@chromium.org>
> >> >> ---
> >> >> Note that I don't have suspend/resume actually working upstream, but I
> >> >> see that /sys/bus/spi/drivers/cros-ec-spi/spi2.0/power/wakeup exists
> >> >> with this patch and doesn't exist without it.
> >> >
> >> > Very well.  Applied, thanks.
> >>
> >> Thanks for applying!  ...did this go in some non-standard branch?  I
> >> see another of my patches got committed to your "for-mfd-next" tree on
> >> the 19th but I don't see this one...
> >
> > Patience Grasshopper.  When I say that it's applied, it means that I
> > have done so locally only.  After I've collected a few local patches
> > I'll usually then fix them all with with my SoB and push them out to
> > the public MFD tree.
> >
> > BTW, it's always best to leave the ML in as CC, so others can see the
> > answer to these types of questions.  It may save a few emails a year,
> > but every little helps. :)
> 
> It's great to see this on the list, because I find your workflow as a
> maintainer to be hard to follow as a developer.
> 
> You applying patches but taking several days to push out makes it
> completely opaque for someone to know if you just accidentally missed
> to apply the patch after all (it happens, I've done that myself). It's
> pretty common to expect a "thanks, applied" patch to show up in
> linux-next within one day or so depending on timing.
> 
> The fact that you had already pushed out a patch that you had replied
> to even later makes for extra confusion. So I'm sorry Lee, but I don't
> think Doug was unreasonable in asking for status here. Sometimes
> maintainers forget to push, which is why it's a good idea to ping a
> few days later if the patch hasn't showed up in -next.

I completely understand and even empathise with the predicament of a
diligent developer.  What you see above isn't me being cantankerous,
but rather an explanation how things are handed in the MFD tree.

Taking into consideration my current workload and time constraints,
the work-flow used is the best I can muster currently.  Lest we forget,
this isn't the role for what I'm employed, I do this on-top of my
daily tasks using time accumulated by starting early and finishing
late _every day_.

Building, testing and pushing after every patch, hell even on a daily
basis would be difficult to sustain without it impacting my _proper_
work.  What I need to do is write some more scripts which will help to
relieve some of the burden, but again time is notable factor here.

>From a personal point of view, I prefer to be on top of the patches
as they come in and have some lead time from when they are applied
locally to finding their way into -next (bearing in mind that this
lead time is seldom more than 24-48hrs), rather than do what others do
and leave patches hanging on the list for weeks, then gather enough
time to review, collect, test and push all in one session. 

A quick aside; given the state of maintainership in some of the other
subsystems, I'm surprised that we're even having this conversation
considering how responsive we are in MFD.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH] mfd: cros_ec_spi: set wakeup capability

[Doug Anderson]

Lee,

On Fri, Jun 27, 2014 at 1:16 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> It's great to see this on the list, because I find your workflow as a
>> maintainer to be hard to follow as a developer.
>>
>> You applying patches but taking several days to push out makes it
>> completely opaque for someone to know if you just accidentally missed
>> to apply the patch after all (it happens, I've done that myself). It's
>> pretty common to expect a "thanks, applied" patch to show up in
>> linux-next within one day or so depending on timing.
>>
>> The fact that you had already pushed out a patch that you had replied
>> to even later makes for extra confusion. So I'm sorry Lee, but I don't
>> think Doug was unreasonable in asking for status here. Sometimes
>> maintainers forget to push, which is why it's a good idea to ping a
>> few days later if the patch hasn't showed up in -next.
>
> I completely understand and even empathise with the predicament of a
> diligent developer.  What you see above isn't me being cantankerous,
> but rather an explanation how things are handed in the MFD tree.

Yup, it's reasonable.  I will say that when I first read your response
it felt a little bit like you were lecturing me, which I didn't feel
like I deserved.  ...but I also know how easy it is to misconstrue
things over email and how hard it is to convey just the right tone
when there are so many emails and so much to do.

As I said in my earlier response I think that perhaps changing the
wording just a little from "Applied, thanks" would have made me wait
longer before querying.


> Taking into consideration my current workload and time constraints,
> the work-flow used is the best I can muster currently.  Lest we forget,
> this isn't the role for what I'm employed, I do this on-top of my
> daily tasks using time accumulated by starting early and finishing
> late _every day_.
>
> Building, testing and pushing after every patch, hell even on a daily
> basis would be difficult to sustain without it impacting my _proper_
> work.  What I need to do is write some more scripts which will help to
> relieve some of the burden, but again time is notable factor here.
>
> From a personal point of view, I prefer to be on top of the patches
> as they come in and have some lead time from when they are applied
> locally to finding their way into -next (bearing in mind that this
> lead time is seldom more than 24-48hrs), rather than do what others do
> and leave patches hanging on the list for weeks, then gather enough
> time to review, collect, test and push all in one session.
>
> A quick aside; given the state of maintainership in some of the other
> subsystems, I'm surprised that we're even having this conversation
> considering how responsive we are in MFD.

Just a quick note that I am certainly very appreciative of your
responsiveness to patches.  It is very rare that a MFD patch sits
around stagnating on the list without a review and that most
definitely helps with efficiency.  It also helps keep developers like
me motivated.  There's nothing more discouraging than spending a whole
bunch of time on the patch only to have it met with absolute silence.

-Doug