From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Jonathan Cameron <jic23@kernel.org>
Cc: linux-input@vger.kernel.org,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Hans de Goede <hdegoede@redhat.com>,
Caleb Connolly <caleb@connolly.tech>,
Andi Shyti <andi@etezian.org>,
Matthias Schiffer <matthias.schiffer@ew.tq-group.com>,
Lyude Paul <lyude@redhat.com>,
Andrew Duggan <aduggan@synaptics.com>,
Michael Hennerich <michael.hennerich@analog.com>,
Javier Martinez Canillas <javier@dowhile0.org>,
Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH 00/16] Input: Switch to new PM macros set 3
Date: Fri, 27 Jan 2023 14:50:58 -0800 [thread overview]
Message-ID: <Y9RVUuRvtIRSUD4A@google.com> (raw)
In-Reply-To: <20230114171620.42891-1-jic23@kernel.org>
On Sat, Jan 14, 2023 at 05:16:04PM +0000, Jonathan Cameron wrote:
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> Continuation of
> https://lore.kernel.org/all/20230102181842.718010-1-jic23@kernel.org/
>
> This time we have most of the remaining drivers where the changes needed
> are more complex than the earlier straight conversions.
>
> A separate series will deal with pm80x as the cleanup for that will
> extend to MFD and RTC trees and cannot easily be broken up due to
> some changes in exports.
>
> There is a general mixture of cases in here:
> 1) More complex direct conversions - typically drivers with separate
> sleep and runtime pm ops.
> 2) Cases where the callbacks or struct dev_pm_ops is exported to
> multiple modules.
> 3) Refactors that avoid duplication of callbacks or exports.
> 4) A tweak to the core input handling to use the new macros - this
> is different from the driver changes, but seemed sensible.
>
> Note there are a few cases in here where I a much more minimal
> set of callbacks is provided than DEFINE_SIMPLE_DEV_PM_OPS() and
> friends would set. I don't know the history behind those so whilst
> they might well be fine converted to the generic macros, I've
> left them alone.
Applied the lot, thank you.
--
Dmitry
prev parent reply other threads:[~2023-01-27 22:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-14 17:16 [PATCH 00/16] Input: Switch to new PM macros set 3 Jonathan Cameron
2023-01-14 17:16 ` [PATCH 01/16] Input: cyapa - switch to SYSTEM_SLEEP/RUNTIME_PM_OPS() and pm_ptr() Jonathan Cameron
2023-01-14 17:16 ` [PATCH 02/16] Input: axp20x-pek - switch to SYSTEM_SLEEP_PM_OPS() and pm_sleep_ptr() Jonathan Cameron
2023-01-14 17:16 ` [PATCH 03/16] Input: samsung-keypad - switch to pm_ptr() and SYSTEM_SLEEP/RUNTIME_PM_OPS() Jonathan Cameron
2023-01-14 17:16 ` [PATCH 04/16] Input: s6sy761 - switch to SYSTEM_SLEEP_/RUNTIME_PM_OPS() and pm_ptr() Jonathan Cameron
2023-01-16 14:20 ` Caleb Connolly
2023-01-14 17:16 ` [PATCH 05/16] Input: rmi4 - switch to SYSTEM_SLEEP/RUNTIME_PM_OPS() " Jonathan Cameron
2023-01-14 17:16 ` [PATCH 06/16] Input: stmfts - switch to SYSTEM_SLEEP_/RUNTIME_PM_OPS() " Jonathan Cameron
2023-01-14 17:16 ` [PATCH 07/16] Input: ad714x - unify dev_pm_ops using EXPORT_SIMPLE_DEV_PM_OPS() Jonathan Cameron
2023-01-14 17:16 ` [PATCH 08/16] Input: adxl34x " Jonathan Cameron
2023-01-14 17:16 ` [PATCH 09/16] Input: tsc200x - use EXPORT_GPL_SIMPLE_DEV_PM_OPS() Jonathan Cameron
2023-01-14 17:16 ` [PATCH 10/16] Input: cyttsp4 - use EXPORT_GPL_RUNTIME_DEV_PM_OPS() Jonathan Cameron
2023-01-14 17:16 ` [PATCH 11/16] Input: cyttsp - use EXPORT_GPL_SIMPLE_DEV_PM_OPS() Jonathan Cameron
2023-01-14 17:16 ` [PATCH 12/16] Input: applespi - use pm_sleep_ptr() and SYSTEM_SLEEP_PM_OPS() Jonathan Cameron
2023-01-14 17:16 ` [PATCH 13/16] Input: omap4-keyad - use pm_ptr() and RUNTIME_DEV_PM_OPS() Jonathan Cameron
2023-01-14 17:16 ` [PATCH 14/16] Input: Use pm_sleep_ptr() to avoid need for ifdef CONFIG_PM_SLEEP Jonathan Cameron
2023-01-14 17:16 ` [PATCH 15/16] Input: cma3000 - use pm_sleep_ptr() to allow removal of ifdef CONFIG_PM guards Jonathan Cameron
2023-01-14 17:16 ` [PATCH 16/16] Input: wistron_btns " Jonathan Cameron
2023-01-27 22:50 ` Dmitry Torokhov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9RVUuRvtIRSUD4A@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=aduggan@synaptics.com \
--cc=andi@etezian.org \
--cc=caleb@connolly.tech \
--cc=hdegoede@redhat.com \
--cc=javier@dowhile0.org \
--cc=jic23@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-input@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=matthias.schiffer@ew.tq-group.com \
--cc=michael.hennerich@analog.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).