[01/15] iio: accel: remove unnecessary CONFIG_PM_SLEEP
diff mbox series

Message ID 20201029074910.227859-1-coiby.xu@gmail.com
State New, archived
Headers show
Series
  • [01/15] iio: accel: remove unnecessary CONFIG_PM_SLEEP
Related show

Commit Message

Coiby Xu Oct. 29, 2020, 7:48 a.m. UTC
SIMPLE_DEV_PM_OPS has already took good care of CONFIG_PM_CONFIG.

Signed-off-by: Coiby Xu <coiby.xu@gmail.com>
---
 drivers/iio/accel/da311.c | 2 --
 1 file changed, 2 deletions(-)

Comments

Jonathan Cameron Oct. 29, 2020, 2:40 p.m. UTC | #1
On Thu, 29 Oct 2020 15:48:56 +0800
Coiby Xu <coiby.xu@gmail.com> wrote:

> SIMPLE_DEV_PM_OPS has already took good care of CONFIG_PM_CONFIG.
> 
> Signed-off-by: Coiby Xu <coiby.xu@gmail.com>
Hi Coiby, 

Please put a cover letter on your next series explaining the context.
In this particular case some of the replies you have gotten are
general at it is a lot easier to find these sorts of things via
replying to the cover letter.

Jonathan

> ---
>  drivers/iio/accel/da311.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/iio/accel/da311.c b/drivers/iio/accel/da311.c
> index 3b3df620ba27..55d4891556ca 100644
> --- a/drivers/iio/accel/da311.c
> +++ b/drivers/iio/accel/da311.c
> @@ -263,7 +263,6 @@ static int da311_remove(struct i2c_client *client)
>  	return da311_enable(client, false);
>  }
>  
> -#ifdef CONFIG_PM_SLEEP
>  static int da311_suspend(struct device *dev)
>  {
>  	return da311_enable(to_i2c_client(dev), false);
> @@ -273,7 +272,6 @@ static int da311_resume(struct device *dev)
>  {
>  	return da311_enable(to_i2c_client(dev), true);
>  }
> -#endif
>  
>  static SIMPLE_DEV_PM_OPS(da311_pm_ops, da311_suspend, da311_resume);
>
Coiby Xu Oct. 29, 2020, 2:43 p.m. UTC | #2
HI Jonathan,

On Thu, Oct 29, 2020 at 02:40:07PM +0000, Jonathan Cameron wrote:
>On Thu, 29 Oct 2020 15:48:56 +0800
>Coiby Xu <coiby.xu@gmail.com> wrote:
>
>> SIMPLE_DEV_PM_OPS has already took good care of CONFIG_PM_CONFIG.
>>
>> Signed-off-by: Coiby Xu <coiby.xu@gmail.com>
>Hi Coiby,
>
>Please put a cover letter on your next series explaining the context.
>In this particular case some of the replies you have gotten are
>general at it is a lot easier to find these sorts of things via
>replying to the cover letter.
>

I will do it in v2. Thank you for the suggestion!

>Jonathan
>
>> ---
>>  drivers/iio/accel/da311.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/iio/accel/da311.c b/drivers/iio/accel/da311.c
>> index 3b3df620ba27..55d4891556ca 100644
>> --- a/drivers/iio/accel/da311.c
>> +++ b/drivers/iio/accel/da311.c
>> @@ -263,7 +263,6 @@ static int da311_remove(struct i2c_client *client)
>>  	return da311_enable(client, false);
>>  }
>>
>> -#ifdef CONFIG_PM_SLEEP
>>  static int da311_suspend(struct device *dev)
>>  {
>>  	return da311_enable(to_i2c_client(dev), false);
>> @@ -273,7 +272,6 @@ static int da311_resume(struct device *dev)
>>  {
>>  	return da311_enable(to_i2c_client(dev), true);
>>  }
>> -#endif
>>
>>  static SIMPLE_DEV_PM_OPS(da311_pm_ops, da311_suspend, da311_resume);
>>
>

--
Best regards,
Coiby
Andy Shevchenko Oct. 29, 2020, 5:06 p.m. UTC | #3
On Thu, Oct 29, 2020 at 4:42 PM Jonathan Cameron <jic23@kernel.org> wrote:
> On Thu, 29 Oct 2020 15:48:56 +0800
> Coiby Xu <coiby.xu@gmail.com> wrote:

> Please put a cover letter on your next series explaining the context.
> In this particular case some of the replies you have gotten are
> general at it is a lot easier to find these sorts of things via
> replying to the cover letter.

Looking at the number of duplicate messages I would suggest that one
needs to go through documentation on how to use git format-patch and
git send-email.
Coiby Xu Oct. 30, 2020, 2:34 p.m. UTC | #4
On Thu, Oct 29, 2020 at 07:06:40PM +0200, Andy Shevchenko wrote:
>On Thu, Oct 29, 2020 at 4:42 PM Jonathan Cameron <jic23@kernel.org> wrote:
>> On Thu, 29 Oct 2020 15:48:56 +0800
>> Coiby Xu <coiby.xu@gmail.com> wrote:
>
>> Please put a cover letter on your next series explaining the context.
>> In this particular case some of the replies you have gotten are
>> general at it is a lot easier to find these sorts of things via
>> replying to the cover letter.
>
>Looking at the number of duplicate messages I would suggest that one
>needs to go through documentation on how to use git format-patch and
>git send-email.
>

Thank you for the suggestion! Actually it's a tree-wide change and it
seems the kernel community prefer individual patches or series for
subsystems having the same maintainer over a huge patch set so I wrote
some scripts to automate the process. That's why you see ~50 emails
with almost the same commit message. The only difference of these
commit messages is the name of PM macro.

>--
>With Best Regards,
>Andy Shevchenko

--
Best regards,
Coiby
Jonathan Cameron Oct. 31, 2020, 11:05 a.m. UTC | #5
On Fri, 30 Oct 2020 22:34:10 +0800
Coiby Xu <coiby.xu@gmail.com> wrote:

> On Thu, Oct 29, 2020 at 07:06:40PM +0200, Andy Shevchenko wrote:
> >On Thu, Oct 29, 2020 at 4:42 PM Jonathan Cameron <jic23@kernel.org> wrote:  
> >> On Thu, 29 Oct 2020 15:48:56 +0800
> >> Coiby Xu <coiby.xu@gmail.com> wrote:  
> >  
> >> Please put a cover letter on your next series explaining the context.
> >> In this particular case some of the replies you have gotten are
> >> general at it is a lot easier to find these sorts of things via
> >> replying to the cover letter.  
> >
> >Looking at the number of duplicate messages I would suggest that one
> >needs to go through documentation on how to use git format-patch and
> >git send-email.
> >  
> 
> Thank you for the suggestion! Actually it's a tree-wide change and it
> seems the kernel community prefer individual patches or series for
> subsystems having the same maintainer over a huge patch set so I wrote
> some scripts to automate the process. That's why you see ~50 emails
> with almost the same commit message. The only difference of these
> commit messages is the name of PM macro.

When doing a bit set like this, it's worth sending out a small subset
first to shake out issue like those seen here.

Once those get merged then send out out the reset.

Thanks,

Jonathan

> 
> >--
> >With Best Regards,
> >Andy Shevchenko  
> 
> --
> Best regards,
> Coiby
Coiby Xu Oct. 31, 2020, 10:47 p.m. UTC | #6
On Sat, Oct 31, 2020 at 11:05:11AM +0000, Jonathan Cameron wrote:
>On Fri, 30 Oct 2020 22:34:10 +0800
>Coiby Xu <coiby.xu@gmail.com> wrote:
>
>> On Thu, Oct 29, 2020 at 07:06:40PM +0200, Andy Shevchenko wrote:
>> >On Thu, Oct 29, 2020 at 4:42 PM Jonathan Cameron <jic23@kernel.org> wrote:
>> >> On Thu, 29 Oct 2020 15:48:56 +0800
>> >> Coiby Xu <coiby.xu@gmail.com> wrote:
>> >
>> >> Please put a cover letter on your next series explaining the context.
>> >> In this particular case some of the replies you have gotten are
>> >> general at it is a lot easier to find these sorts of things via
>> >> replying to the cover letter.
>> >
>> >Looking at the number of duplicate messages I would suggest that one
>> >needs to go through documentation on how to use git format-patch and
>> >git send-email.
>> >
>>
>> Thank you for the suggestion! Actually it's a tree-wide change and it
>> seems the kernel community prefer individual patches or series for
>> subsystems having the same maintainer over a huge patch set so I wrote
>> some scripts to automate the process. That's why you see ~50 emails
>> with almost the same commit message. The only difference of these
>> commit messages is the name of PM macro.
>
>When doing a bit set like this, it's worth sending out a small subset
>first to shake out issue like those seen here.
>
>Once those get merged then send out out the reset.
>
Thank you for the suggestion! Actually I've held off another ~150
emails and these ~200 emails were only part of work. I thought it's
better to reach 4 or 5 subsystem to collect sufficient feedbacks
considering some subsystems may respond slow. But I didn't realize a
better way is to cut down the size of patch set sent to a subsystem.
>Thanks,
>
>Jonathan
>
>>
>> >--
>> >With Best Regards,
>> >Andy Shevchenko
>>
>> --
>> Best regards,
>> Coiby
>

--
Best regards,
Coiby
Jonathan Cameron Nov. 1, 2020, 5:20 p.m. UTC | #7
On Sun, 1 Nov 2020 06:47:35 +0800
Coiby Xu <coiby.xu@gmail.com> wrote:

> On Sat, Oct 31, 2020 at 11:05:11AM +0000, Jonathan Cameron wrote:
> >On Fri, 30 Oct 2020 22:34:10 +0800
> >Coiby Xu <coiby.xu@gmail.com> wrote:
> >  
> >> On Thu, Oct 29, 2020 at 07:06:40PM +0200, Andy Shevchenko wrote:  
> >> >On Thu, Oct 29, 2020 at 4:42 PM Jonathan Cameron <jic23@kernel.org> wrote:  
> >> >> On Thu, 29 Oct 2020 15:48:56 +0800
> >> >> Coiby Xu <coiby.xu@gmail.com> wrote:  
> >> >  
> >> >> Please put a cover letter on your next series explaining the context.
> >> >> In this particular case some of the replies you have gotten are
> >> >> general at it is a lot easier to find these sorts of things via
> >> >> replying to the cover letter.  
> >> >
> >> >Looking at the number of duplicate messages I would suggest that one
> >> >needs to go through documentation on how to use git format-patch and
> >> >git send-email.
> >> >  
> >>
> >> Thank you for the suggestion! Actually it's a tree-wide change and it
> >> seems the kernel community prefer individual patches or series for
> >> subsystems having the same maintainer over a huge patch set so I wrote
> >> some scripts to automate the process. That's why you see ~50 emails
> >> with almost the same commit message. The only difference of these
> >> commit messages is the name of PM macro.  
> >
> >When doing a bit set like this, it's worth sending out a small subset
> >first to shake out issue like those seen here.
> >
> >Once those get merged then send out out the reset.
> >  
> Thank you for the suggestion! Actually I've held off another ~150
> emails and these ~200 emails were only part of work. I thought it's
> better to reach 4 or 5 subsystem to collect sufficient feedbacks
> considering some subsystems may respond slow. But I didn't realize a
> better way is to cut down the size of patch set sent to a subsystem.

Keep it sub 20 per subsystem and it shouldn't matter too much, but perhaps
always send to just one subsystem first as you may get very fast responses!

Then if it looks good after a few days, your approach of targeting a few
more subsystems would make sense.

Jonathan

> >Thanks,
> >
> >Jonathan
> >  
> >>  
> >> >--
> >> >With Best Regards,
> >> >Andy Shevchenko  
> >>
> >> --
> >> Best regards,
> >> Coiby  
> >  
> 
> --
> Best regards,
> Coiby

Patch
diff mbox series

diff --git a/drivers/iio/accel/da311.c b/drivers/iio/accel/da311.c
index 3b3df620ba27..55d4891556ca 100644
--- a/drivers/iio/accel/da311.c
+++ b/drivers/iio/accel/da311.c
@@ -263,7 +263,6 @@  static int da311_remove(struct i2c_client *client)
 	return da311_enable(client, false);
 }
 
-#ifdef CONFIG_PM_SLEEP
 static int da311_suspend(struct device *dev)
 {
 	return da311_enable(to_i2c_client(dev), false);
@@ -273,7 +272,6 @@  static int da311_resume(struct device *dev)
 {
 	return da311_enable(to_i2c_client(dev), true);
 }
-#endif
 
 static SIMPLE_DEV_PM_OPS(da311_pm_ops, da311_suspend, da311_resume);