Re: [RFC] Defining a home/maintenance model for non-NIC PHC devices using the /dev/ptpX API

[Imran Shaik <imran.shaik@oss.qualcomm.com>]

On 21-01-2026 07:59 pm, Wen Gu wrote:
> 
> 
> On 2026/1/9 10:56, Wen Gu wrote:
>>
>> #
>> ## Proposal
>> #
>>
>> 1. Reorganize drivers/ptp/ to make the interface/implementation split
>>     explicit,
>>
>>     * drivers/ptp/core      : PTP core infrastructure and API.
>>                               (e.g. ptp_chardev.c, ptp_clock.c,
>>                                ptp_sysfs.c, etc.)
>>
>>     * drivers/ptp/pure      : Non-network ("pure clock") implementation,
>>                               they are typically platform/architecture/
>>                               virtualization-provided time sources.
>>                               (e.g. ptp_kvm, ptp_vmw, ptp_vmclock,
>>                                ptp_s390, etc.)
>>
>>     * drivers/ptp/*         : Network timestamping oriented 
>> implementation,
>>                               they primarily used together with IEEE1588
>>                               over the network.
>>                               (e.g. ptp_qoriq, ptp_pch, ptp_dp83640,
>>                                ptp_idt82p33 etc.)
>>
> 
> Thanks for the feedback so far. It seems we are close to consensus on
> the directory split, as [1] summarized:
> 
> - drivers/ptp/core       : PTP core infrastructure and API
> - drivers/ptp/1588       : network/IEEE 1588 oriented PTP clocks
> - drivers/ptp/emulating  : platform/hardware/hypervisor-provided pure 
> clocks
> 
> For how the existing drivers in `drivers/ptp` are categorized into the
> directories above, please also refer to [1] and the follow-up replies.
> 
>> 2. Transition drivers/ptp/pure from netdev maintainership to
>>     clock/time maintainership (with an appropriate MAINTAINERS entry,
>>     e.g. PURE TIME PHC), since these PHC implementations are primarily
>>     clock devices and not network-oriented. New similar drivers can be
>>     added under drivers/ptp/pure as well.
> 
> 
> Then the open item now is maintainership and the merge path.
> 
> Based on previous guidance[2] and the current MAINTAINERS structure,
> it seems reasonable to have it maintained under the clock/timekeeping
> domain (following the existing timekeeping pull chain), with a
> dedicated MAINTAINERS entry.
> 
> 
> Hi Thomas and clock/timekeeping maintainers,
> 
> Would you agree with this approach? If so, could you please advise on
> the appropriate maintainer/reviewer for this MAINTAINERS entry?
> 
> Below is a strawman MAINTAINERS entry (happy to adjust):
> 
> EMULATING PTP CLOCK SUPPORT
> L:     linux-kernel@vger.kernel.org
> S:     Maintained
> F:     drivers/ptp/emulating/*
> 
> 
> We (Alibaba) are also willing to be the maintainer for this entry as
> a fallback.
> 
> [1] https://lore.kernel.org/netdev/b5a60753-85ed-4d61- 
> a652-568393e0dff3@linux.alibaba.com/
> [2] https://lore.kernel.org/netdev/20251216135848.174e010f@kernel.org/
> 
> Regards.
> 

Hi Wen,

Thanks for driving this discussion.

Is there a patch series posted that reflects the new proposal?

As Manivannan mentioned, some Qcom MHI devices have similar 
requirements. Once the reorganized changes are posted, we will also 
resend our patch series adopting the latest changes.

Thanks,
Imran