From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: linux-sound@vger.kernel.org
Subject: Re: [PATCH 01/12] ALSA: hda: intel: Reduce CONFIG_PM dependencies
Date: Fri, 10 May 2024 17:30:07 +0300 [thread overview]
Message-ID: <Zj4vb33uz2rgX3tQ@smile.fi.intel.com> (raw)
In-Reply-To: <87edabbh2h.wl-tiwai@suse.de>
On Thu, May 09, 2024 at 09:05:58AM +0200, Takashi Iwai wrote:
> On Wed, 08 May 2024 19:45:42 +0200,
> Andy Shevchenko wrote:
> > On Mon, May 06, 2024 at 06:13:44PM +0200, Takashi Iwai wrote:
> > > snd-hda-intel contains lots of CONFIG_PM dependent code although
> > > CONFIG_PM is almost mandatory nowadays, and it makes the code
> > > unnecessarily complex.
> > >
> > > Let's reduce the dependencies of CONFIG_PM in snd-hda-intel driver
> > > code. I left a few module options to be dependent on CONFIG_PM (which
> > > are visible to users), but other places are either enabled or
> > > optimized by compiler automatically.
...
> > > +static int __maybe_unused azx_resume(struct device *dev)
> >
> > __maybe)unused is discouraged nowadays.
> > We have new PM macros (w/o SET_ prefix) along with pm_ptr() / pm_sleep_ptr()
> > macros. They are preferred. In complicated cases the PTR_IF() can be used
> > directly.
>
> Yeah, it was a dilemma there. There seems no standard macro to use
> pm_ptr() for runtime_suspend (there is only RUNTIME_PM_OPS()), so for
> avoiding __maybe_unused, I'd have to expand them manually instead.
I'm not sure I got the use case. If we have runtime PM, we use pm_ptr(),
otherwise pm_sleep_ptr().
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-05-10 14:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 16:13 [PATCH 00/12] ALSA: hda: Reduce CONFIG_PM dependencies Takashi Iwai
2024-05-06 16:13 ` [PATCH 01/12] ALSA: hda: intel: " Takashi Iwai
2024-05-08 17:45 ` Andy Shevchenko
2024-05-09 7:05 ` Takashi Iwai
2024-05-10 14:30 ` Andy Shevchenko [this message]
2024-05-06 16:13 ` [PATCH 02/12] ALSA: hda: codec: " Takashi Iwai
2024-05-06 16:13 ` [PATCH 03/12] ALSA: hda: generic: " Takashi Iwai
2024-05-06 16:13 ` [PATCH 04/12] ALSA: hda: analog: " Takashi Iwai
2024-05-06 16:13 ` [PATCH 05/12] ALSA: hda: ca0132: " Takashi Iwai
2024-05-06 16:13 ` [PATCH 06/12] ALSA: hda: cirrus: " Takashi Iwai
2024-05-06 16:13 ` [PATCH 07/12] ALSA: hda: conexant: " Takashi Iwai
2024-05-06 16:13 ` [PATCH 08/12] ALSA: hda: cs4809: " Takashi Iwai
2024-05-06 16:13 ` [PATCH 09/12] ALSA: hda: hdmi: " Takashi Iwai
2024-05-06 16:13 ` [PATCH 10/12] ALSA: hda: realtek: " Takashi Iwai
2024-05-06 16:13 ` [PATCH 11/12] ALSA: hda: sigmantel: " Takashi Iwai
2024-05-06 16:13 ` [PATCH 12/12] ALSA: hda: via: " Takashi Iwai
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=Zj4vb33uz2rgX3tQ@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=linux-sound@vger.kernel.org \
--cc=tiwai@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.