Re: [PATCH V3 1/2] net: phylink: add a function to resume phy alone to fix resume issue with WoL enabled
From: Alexis Lothoré
Date: Thu Aug 10 2023 - 12:10:33 EST
Hello Clark, Russell,
On 2/23/23 12:06, Russell King (Oracle) wrote:
> On Thu, Feb 23, 2023 at 10:27:06AM +0000, Clark Wang wrote:
>> Hi Russel,
>>
>> I have sent the V4 patch set yesterday.
>> You can check it from: https://lore.kernel.org/linux-arm-kernel/20230222092636.1984847-2-xiaoning.wang@xxxxxxx/T/
>>
>
> Ah yes, sent while net-next is closed.
>
> Have you had any contact with Clément Léger ? If not, please can you
> reach out to Clément, because he has virtually the same problem. I
> don't want to end up with a load of different fixes in the mainline
> kernel for the same "we need the PHY clock enabled on stmmac" problem
> from different people.
I am resuming Clement's initial efforts on RZN1 GMAC interface, which indeed is
in need of an early PCS initialization mechanism too ([1]).
> Please try to come up with one patch set between you both to fix this.
>
> (effectively, that's a temporary NAK on your series.)>
I would like to know if this series is still ongoing/alive ? I have checked for
follow-ups after V4 sent by Clark ([2]), but did not find anything. Clement
handed me over the topic right when Russell suggested to discuss this shared
need, so I am not sure if any mutualization discussion has happened yet ?
If not, what would be the next steps ? Based on my understanding and comments on
the [2] v3, I feel that Clark's series would be a good starting point. In order
to be able to use it in both series, we could possibly make it less specific to
the "resume" mechanism (basically, phylink_phy_resume() =>
phylink_phy_early_start() ) ? It would then prevent [1] from moving the whole
phylink_start() in stmmac_main too early (see issue raised by Russell) and allow
to just call phylink_phy_early_start() early enough, while still being usable in
the resume scenario raised by Clark. Or am I missing bigger issues with current
series ?
Regards,
Alexis
[1]
https://lore.kernel.org/linux-arm-kernel/20230116103926.276869-1-clement.leger@xxxxxxxxxxx/
[2] https://lore.kernel.org/all/20230222092636.1984847-1-xiaoning.wang@xxxxxxx/
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com