Re: [PATCH v2] serial: 8250_uniphier: Use devm_clk_get_enabled()

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Fri, Sep 25, 2026 at 08:32:20PM +0900, Kunihiko Hayashi wrote:
> On 2026/09/24 23:09, Andy Shevchenko wrote:
> > On Thu, Sep 24, 2026 at 06:07:37PM +0900, Kunihiko Hayashi wrote:
> > > On 2026/09/17 13:05, Malathi A wrote:

...

> > > I'm a bit concerned about the error path in uniphier_uart_resume().
> > > The clock may have been disabled in uniphier_uart_suspend(), and
> > > clk_prepare_enable() can fail when trying to enable it again.
> > > 
> > > In that case, wouldn't devres try to disable an already disabled
> > > clock on detach?
> > 
> > Isn't there is a guarantee that the .remove() is called with PM runtime on

After reading a code of driver core I see that this is the opposite actually.
The PM runtime might be off.

> > and get, meaning it's called with the enabled clock? But if not the case,
> > we might use PM runtime force operations (resume and suspend in the
> > respective cases.
> 
> My concern was just the case where clk_prepare_enable() in the system
> resume callback fails, leaving the clock disabled before devres cleanup.
> 
> This driver currently only uses SET_SYSTEM_SLEEP_PM_OPS(), so I wasn't
> considering runtime PM here.

So, in such a case how do you see the scenario when system is resumed (Right?
Otherwise we can't do anything, like detaching driver from the device.) and
clock is disabled?

> I don't have a strong opinion on whether runtime PM should be involved,
> but if it guarantees that the clock is enabled before .remove(),
> that would address my concern.

-- 
With Best Regards,
Andy Shevchenko