[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tuv77a83.fsf@kurt>
Date: Tue, 06 Oct 2020 15:30:36 +0200
From: Kurt Kanzenbach <kurt@...utronix.de>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Richard Cochran <richardcochran@...il.com>,
Kamil Alkhouri <kamil.alkhouri@...offenburg.de>,
ilias.apalodimas@...aro.org
Subject: Re: [PATCH net-next v6 4/7] net: dsa: hellcreek: Add support for hardware timestamping
On Tue Oct 06 2020, Vladimir Oltean wrote:
> On Tue, Oct 06, 2020 at 08:27:42AM +0200, Kurt Kanzenbach wrote:
>> On Sun Oct 04 2020, Vladimir Oltean wrote:
>> > On Sun, Oct 04, 2020 at 01:29:08PM +0200, Kurt Kanzenbach wrote:
>> >> +/* Enabling/disabling TX and RX HW timestamping for different PTP messages is
>> >> + * not available in the switch. Thus, this function only serves as a check if
>> >> + * the user requested what is actually available or not
>> >> + */
>> >
>> > Correct me if I'm wrong, but to the user it makes zero difference
>> > whether the hardware takes timestamps or not.
>>
>> Why not? I think it makes a difference to the user b/o the precision.
>>
>> > What matters is whether the skb will be delivered to the stack with a
>> > hardware timestamp or not, so you should definitely accept a
>> > hwtstamp_config with TX and RX timestamping disabled.
>> >
>>
>> Sorry, I cannot follow you here.
>
> What I meant to say is that there is no reason you should refuse the
> disabling of hardware timestamping. Even if that operation does not
> really prevent the hardware from taking the timestamps, you simply
> ignore the timestamps in the driver.
That's the point. The user (or anybody else) cannot disable hardware
stamping, because it is always performed. So, why should it be allowed
to disable it even when it cannot be disabled?
Thanks,
Kurt
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists