Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
Lee, On Fri, Jun 27, 2014 at 1:16 AM, Lee Jones 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
On Thu, 26 Jun 2014, Olof Johansson wrote: > On Mon, Jun 23, 2014 at 2:26 AM, Lee Jones wrote: > >> Lee (-others), > > > > Re-CC'ing the list. > > > >> On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones wrote: > >> >> From: Prathyush K > >> >> > >> >> 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 > >> >> Signed-off-by: Doug Anderson > >> >> --- > >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
On Thu, 26 Jun 2014, Olof Johansson wrote: On Mon, Jun 23, 2014 at 2:26 AM, Lee Jones lee.jo...@linaro.org wrote: Lee (-others), Re-CC'ing the list. On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones lee.jo...@linaro.org wrote: From: Prathyush K prathyus...@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 prathyus...@samsung.com Signed-off-by: Doug Anderson diand...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
Lee, On Fri, Jun 27, 2014 at 1:16 AM, Lee Jones lee.jo...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
On Mon, Jun 23, 2014 at 2:26 AM, Lee Jones wrote: >> Lee (-others), > > Re-CC'ing the list. > >> On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones wrote: >> >> From: Prathyush K >> >> >> >> 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 >> >> Signed-off-by: Doug Anderson >> >> --- >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
On Mon, Jun 23, 2014 at 2:26 AM, Lee Jones lee.jo...@linaro.org wrote: Lee (-others), Re-CC'ing the list. On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones lee.jo...@linaro.org wrote: From: Prathyush K prathyus...@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 prathyus...@samsung.com Signed-off-by: Doug Anderson diand...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
Lee, On Mon, Jun 23, 2014 at 2:26 AM, Lee Jones wrote: >> Lee (-others), > > Re-CC'ing the list. > >> On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones wrote: >> >> From: Prathyush K >> >> >> >> 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 >> >> Signed-off-by: Doug Anderson >> >> --- >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
> Lee (-others), Re-CC'ing the list. > On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones wrote: > >> From: Prathyush K > >> > >> 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 > >> Signed-off-by: Doug Anderson > >> --- > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
Lee, On Mon, Jun 23, 2014 at 2:26 AM, Lee Jones lee.jo...@linaro.org wrote: Lee (-others), Re-CC'ing the list. On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones lee.jo...@linaro.org wrote: From: Prathyush K prathyus...@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 prathyus...@samsung.com Signed-off-by: Doug Anderson diand...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
Lee (-others), Re-CC'ing the list. On Wed, Jun 18, 2014 at 2:20 AM, Lee Jones lee.jo...@linaro.org wrote: From: Prathyush K prathyus...@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 prathyus...@samsung.com Signed-off-by: Doug Anderson diand...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
> From: Prathyush K > > 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 > Signed-off-by: Doug Anderson > --- > 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(>dev, true); > + > return 0; > } > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: cros_ec_spi: set wakeup capability
From: Prathyush K prathyus...@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 prathyus...@samsung.com Signed-off-by: Doug Anderson diand...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: cros_ec_spi: set wakeup capability
From: Prathyush K 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 Signed-off-by: Doug Anderson --- 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(>dev, true); + return 0; } -- 2.0.0.526.g5318336 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: cros_ec_spi: set wakeup capability
From: Prathyush K prathyus...@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 prathyus...@samsung.com Signed-off-by: Doug Anderson diand...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/