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

[Kunihiko Hayashi <hayashi.kunihiko@socionext.com>]

On 2026/09/28 18:05, Andy Shevchenko wrote:
> On Mon, Sep 28, 2026 at 03:51:09PM +0900, Kunihiko Hayashi wrote:
>> 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)
Sorry for the delayed reply.

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