[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1cfe399-2b4c-790-f648-3ce13736b1eb@linux.intel.com>
Date: Thu, 30 Jun 2022 12:00:42 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Paul Cercueil <paul@...pouillou.net>
cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-serial <linux-serial@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Jiri Slaby <jirislaby@...nel.org>
Subject: Re: [PATCH v1 1/1] serial: 8250_dw: Drop PM ifdeffery
On Thu, 30 Jun 2022, Paul Cercueil wrote:
> Hi Ilpo,
>
> Le jeu., juin 30 2022 at 10:41:40 +0300, Ilpo Järvinen
> <ilpo.jarvinen@...ux.intel.com> a écrit :
> > On Wed, 29 Jun 2022, Andy Shevchenko wrote:
> >
> > > Drop CONFIG_PM and CONFIG_PM_SLEEP ifdeffery while converting
> > > dw8250_pm_ops
> > > to use new PM macros.
> > >
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> >
> > Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
> >
> > Not directily related to the patch itself but do you have any idea why
> > 1a3c7bb08826 ("PM: core: Add new *_PM_OPS macros, deprecate old ones")
> > didn't wrap RUNTIME_PM_OPS() pointers with pm_ptr()? I'm asking this
> > because in SET_RUNTIME_PM_OPS() the callbacks are only created with
> > #ifdef CONFIG_PM so I'd have expected RUNTIME_PM_OPS() to maintain that
> > behavior but it didn't? Was it just an oversight that should be fixed?
>
> The RUNTIME_PM_OPS() does not wrap pointers with pm_ptr(), because the pointer
> to the dev_pm_ops should only ever be used wrapped with pm_ptr() or
> pm_sleep_ptr().
>
> Which is not done here.
Ok, thanks a lot for the explanation. It's really appreciated.
--
i.
> Andy:
> The deference of dw8250_pm_ops should be pm_ptr(&dw8250_pm_ops). If you only
> had system suspend/resume functions, you'd use pm_sleep_ptr() there.
Powered by blists - more mailing lists