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

[Kunihiko Hayashi]

On 2026/09/25 22:37, Andy Shevchenko wrote:
> 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?

Ah, I understand your point. I was assuming that the driver could later
be detached after uniphier_uart_resume() failed, leaving the clock disabled.

If that sequence cannot happen after a failed system resume, then my concern
doesn't apply. Thanks for pointing this out.

In that case, I have no further concerns about the use of
devm_clk_get_enabled() here.

Thank you,

---
Best Regards
Kunihiko Hayashi