Re: [PATCH] net: pcs: xpcs-plat: fix runtime PM initialization

[Coia Prant]

On July 21, 2026 11:00:23 PM GMT+08:00, Maxime Chevallier <maxime.chevallier@xxxxxxxxxxx> wrote:
>
>>> 3. Should we add a .remove callback to force suspend the device on
>>>    unbind? Otherwise the clock might remain enabled if the driver is
>>>    removed while active.
>> 
>> Embedded experts would have to chime in on this one. AFAIK this is a bit
>> of a gray area. Some users may want the link to stay up, eg to allow
>> WoL or avoid link training, maybe?
>
>Avoiding link flaps/training is mostly a concern at boot time if the
>bootloader set everything up beforehand, but I'd say for unbinding,
>this should be OK and would mirror the probe.
>
>Maxime

Hi Maxime,

Thanks for the feedback on the .remove callback — I'll include it in
the next version.

One more question regarding PM dependency: the current pcs-xpcs-plat
driver uses runtime PM to manage the CSR clock, but the driver works
fine without PM only if the platform doesn't have a CSR clock at all.

On Rockchip, the CSR clock (PCLK_XPCS) is required for register access,
and without PM enabled, the clock is never prepared/enabled, so the
driver simply won't work.

That said, I think in practice, almost no one disables CONFIG_PM in
their kernel builds these days — it's enabled by default on most
architectures. So forcing the dependency (e.g., `select PM` or
`depends on PM`) wouldn't really hurt anyone, and it would ensure
the driver works correctly on platforms that do need the clock.

Do you think it's worth adding `select PM` in Kconfig for
pcs-xpcs-plat, or should we just leave it as-is since PM is almost
always already enabled anyway?

Thanks,
Coia