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: [email protected]
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-
[email protected]/
[2] https://lore.kernel.org/netdev/[email protected]/
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
