netdev - Re: [PATCH net-next v5 1/4] net: wangxun: Add support for 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: <4fc53607-c0e4-42fc-a0df-0ad0d0c7a26c@intel.com>
Date: Fri, 17 Jan 2025 14:39:14 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>, Richard Cochran
	<richardcochran@...il.com>
CC: Jiawen Wu <jiawenwu@...stnetic.com>, <andrew+netdev@...n.ch>,
	<davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<pabeni@...hat.com>, <linux@...linux.org.uk>, <horms@...nel.org>,
	<netdev@...r.kernel.org>, <mengyuanlou@...-swift.com>
Subject: Re: [PATCH net-next v5 1/4] net: wangxun: Add support for PTP clock



On 1/17/2025 8:03 AM, Vadim Fedorenko wrote:
> On 17/01/2025 15:51, Richard Cochran wrote:
>> On Fri, Jan 17, 2025 at 02:15:01PM +0000, Vadim Fedorenko wrote:
>>
>>> there is no way ptp_clock_register() will return NULL,
>>
>> Really?
>>
>> include/linux/ptp_clock_kernel.h:
>>
>>   400 static inline struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
>>   401                                                    struct device *parent)
>>   402 { return NULL; }
>>
>> Also, sometimes the kernelDoc comments are correct, like in this case:
>>
>>   304 /**
>>   305  * ptp_clock_register() - register a PTP hardware clock driver
>>   306  *
>>   307  * @info:   Structure describing the new clock.
>>   308  * @parent: Pointer to the parent device of the new clock.
>>   309  *
>>   310  * Returns a valid pointer on success or PTR_ERR on failure.  If PHC
>>   311  * support is missing at the configuration level, this function
>>   312  * returns NULL, and drivers are expected to gracefully handle that
>>   313  * case separately.
>>   314  */
>>
>>
>> Thanks,
>> Richard
> 
> Well, yes, this case is a special one. Then maybe it's better to adjust
> Kconfig and Makefile to avoid it?

Seems simple enough to just have the driver disable the PTP support when
the kernel doesn't support it, especially if its not a core piece of
functionality for the device. In cases where the device would be
functionally useless without PTP support, Kconfig can be used to ensure
the device driver won't be built without PTP support.