[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dd6e3a60-cb5f-9c3c-2608-637ceb8de09c@prolan.hu>
Date: Thu, 11 Aug 2022 10:07:17 +0200
From: Csókás Bence <csokas.bence@...lan.hu>
To: Andrew Lunn <andrew@...n.ch>,
Richard Cochran <richardcochran@...il.com>
CC: <netdev@...r.kernel.org>, Fugang Duan <fugang.duan@....com>
Subject: Re: [PATCH] fec: Restart PPS after link state change
On 2022. 08. 11. 4:05, Andrew Lunn wrote:
> On Wed, Aug 10, 2022 at 06:37:19PM -0700, Richard Cochran wrote:
>> On Thu, Aug 11, 2022 at 02:05:39AM +0200, Andrew Lunn wrote:
>>>> Yes. We use PPS to synchronize devices on a common backplane. We use PTP to
>>>> sync this PPS to a master clock. But if PTP sync drops out, we wouldn't want
>>>> the backplane-level synchronization to fail. The PPS needs to stay on as
>>>> long as userspace *explicitly* disables it, regardless of what happens to
>>>> the link.
>>>
>>> We need the PTP Maintainers view on that. I don't know if that is
>>> normal or not.
>>
>> IMO the least surprising behavior is that once enabled, a feature
>> stays on until explicitly disabled.
>
> O.K, thanks for the response.
>
> Your answer is a bit surprising to me. To me, an interface which is
> administratively down is completely inactive. The action to down it
> should disable everything.
I think you are confusing two states here. This patch addresses the bug
thatcauses the PPS to drop when the Ethernet link goes away. The
interface remainsUP the whole time.
>
> So your answer also implies PPS can be used before the interface is
> set administratively up?
The PPS can already be used before the first link-up, but once it has
acquired a link once, PPS no longer works without a link.
>
> Andrew
Powered by blists - more mailing lists