netdev - Re: [PATCH net-next 0/2] ptp: Introduce .getfine callback to ptp_clock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8ea1fe78-c957-1ffd-f4e9-8740c451a40f@intel.com>
Date:   Fri, 2 Dec 2022 14:11:38 -0800
From:   Jacob Keller <jacob.e.keller@...el.com>
To:     Richard Cochran <richardcochran@...il.com>,
        Rahul Rameshbabu <rrameshbabu@...dia.com>
CC:     Saeed Mahameed <saeedm@...dia.com>,
        Leon Romanovsky <leon@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Aya Levin <ayal@...dia.com>,
        Gal Pressman <gal@...dia.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 0/2] ptp: Introduce .getfine callback to
 ptp_clock_info



On 12/2/2022 12:45 PM, Richard Cochran wrote:
> On Fri, Dec 02, 2022 at 12:15:27PM -0800, Rahul Rameshbabu wrote:
>> The current state of the ptp driver provides the ability to query the frequency
>> of the ptp clock device by caching the frequency values used in previous
>> adjustments done through the ptp driver. This works great when the ptp driver is
>> the only means for changing the clock frequency. However, some devices support
>> ways to adjust the frequency outside the ptp driver stack.
> 
> The kernel provides no other way to adjust the frequency.
> 
> So NAK on this series.
> 
> Thanks,
> Richard
> 

Agreed. Just because your driver does something silly such as modifying 
the frequency out of band of PTP stack doesn't mean we need to support it.

As for running multiple ptp4l instances on the same PTP clock, we 
already have the ability to report the frequency out to user space. The 
ptp4l application checks this at init but then begins assuming that it 
is the only software controlling the clock. That seems like a reasonable 
assumption to me. If you want to write your own user space software 
which handles this, you already have the mechanism to do so.

Thanks,
Jake