Re: [PATCH v2] serial: 8250_uniphier: Use devm_clk_get_enabled()
From: Kunihiko Hayashi
Date: Mon Oct 05 2026 - 02:55:29 EST
On 2026/09/28 18:05, Andy Shevchenko wrote:
On Mon, Sep 28, 2026 at 03:51:09PM +0900, Kunihiko Hayashi wrote:Sorry for the delayed reply.
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:
...
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.
I'm not sure, I don't know if I was right. Can you confirm that this scenario
is not possible? So, it might look like CPU is resumed, some of the devices
were resumed, but this particular UART failed to resume, and now we want to
detach it. If this case is possible, I believe tons of the device drivers as
of today may be affected by the same issue (it doesn't mean that the issue
is impossible to happen, one needs to investigate deeper)
Unfortunately, I can't confirm whether this scenario is impossible.
I don't currently have an environment where I can reproduce this system
suspend/resume case either.
I agree that if a device can later be detached after its system resume callback
has failed, this may affect other drivers using the same pattern as well,
and determining that seems to require a deeper look into the PM core behavior.
If that sequence cannot happen after a failed system resume, then my concern
doesn't apply.
As pointed out I'm not sure. Last time I experimented with failed resume > long time ago.
So I don't have a definitive answer here either, and can only point out this
as a potential issue for now.
Thank you,
---
Best Regards
Kunihiko Hayashi