Re: [PATCH 0/2] ptp: split non-NIC PHC drivers into the clock/timekeeping maintenance domain

[Wen Gu]

On 2026/3/19 01:05, John Stultz wrote:
> On Wed, Mar 18, 2026 at 12:33 AM Wen Gu <guwen@xxxxxxxxxxxxxxxxx> wrote:
> > - Following the model used by NTP related code, this series lists tip.git
> >    (timers/core) as the integration tree for emulated PTP clocks in the
> >    MAINTAINERS entry. Guidance from clock/timekeeping maintainers
> >    (Thomas Gleixner, John Stultz, Anna-Maria Behnsen, Frederic Weisbecker,
> >    Daniel Lezcano, Stephen Boyd) on whether this is the appropriate workflow
> >    for this class of drivers would be appreciated.
>
> While I'm sure it would be good to continue to CC folks, I'm not sure
> if the timekeeping maintainers would be the right folks for these
> driver/ptp/ changes to flow through.
> Thomas has been doing the heavy lifting for a long while and I'd not
> want to put more on his shoulders.
>
> Richard is listed as the maintainer for drivers/ptp/, is there any
> reason for it not to go through him?
>
> thanks
> -john

Hi John,

Thanks a lot for the feedback.

Richard is indeed listed as the maintainer for the PTP subsystem and
the traditional network-oriented PHC drivers. The intention of this
series is not to bypass that role. I would very much welcome Richard's
thoughts on the proposed split and the appropriate workflow for these
drivers.

Historically the PTP subsystem lived under networking because the
original PHC devices were tightly coupled with NIC hardware and the
IEEE1588 packet timestamping pipeline.

Over time, however, the PTP userspace interface (/dev/ptpX together
with the PTP_* ioctls) has also become a widely used way to expose
high-precision clocks to userspace. Because of the stable interface
and the existing ecosystem (e.g. chrony, phc2sys), many platform or
virtualization-provided clocks have started reusing the same PTP
interface.

As a result, drivers/ptp/ now contains two different classes of
devices: traditional network-oriented PHC drivers and clocks which
are not tied to the IEEE1588 networking pipeline.

The difficulty today is that there is no very clear upstream path for
this class of drivers: they currently live under drivers/ptp/, but
their design and review concerns are often closer to clock/timekeeping
topics than to networking. This series tries to find a clearer
upstream path and review route for this class of drivers.

Regarding the merge path, the suggestion about tip.git was mainly an
attempt to identify a possible integration tree for these drivers, but
I'm open to suggestions if there is a better workflow.

Thanks again for taking a look.

Wen Gu