From: Jakub Kicinski <kuba@kernel.org>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Richard Cochran <richardcochran@gmail.com>,
Wen Gu <guwen@linux.alibaba.com>,
tglx@kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, pabeni@redhat.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
jstultz@google.com, anna-maria@linutronix.de,
frederic@kernel.org, daniel.lezcano@kernel.org, sboyd@kernel.org,
vladimir.oltean@nxp.com, wei.fang@nxp.com, xiaoning.wang@nxp.com,
jonathan.lemon@gmail.com, vadim.fedorenko@linux.dev,
yangbo.lu@nxp.com, svens@linux.ibm.com, nick.shi@broadcom.com,
ajay.kaher@broadcom.com, alexey.makhalov@broadcom.com,
bcm-kernel-feedback-list@broadcom.com,
linux-fpga@vger.kernel.org, imx@lists.linux.dev,
linux-s390@vger.kernel.org, dust.li@linux.alibaba.com,
xuanzhuo@linux.alibaba.com, mani@kernel.org,
imran.shaik@oss.qualcomm.com, taniya.das@oss.qualcomm.com
Subject: Re: [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split
Date: Mon, 1 Jun 2026 18:52:26 -0700 [thread overview]
Message-ID: <20260601185226.7f43fa75@kernel.org> (raw)
In-Reply-To: <0e023f951c102fe2ee7070e490c579783b2817d5.camel@infradead.org>
On Mon, 01 Jun 2026 17:53:49 +0100 David Woodhouse wrote:
> On Mon, 2026-06-01 at 08:20 -0700, Richard Cochran wrote:
> > On Mon, Jun 01, 2026 at 08:03:26AM +0100, David Woodhouse wrote:
> > > If we move all the plain non-network PHC drivers (which, as noted,
> > > is
> > > basically *all* of them) into a drivers/ subdirectory, then perhaps
> > > we
> >
> > Sorry, just catching up here, so the idea is to have
> >
> > linux/drivers/ptp/drivers ?
>
> That is my current suggestion.
>
> It stems from Jakub's response in
> https://lore.kernel.org/all/20250815113814.5e135318@kernel.org/ that "I
> really wish someone stepped up and created a separate subsystem for all
> these cloud / vm clocks. They have nothing to do with PTP."
>
> There was some further bikeshedding in
> https://lore.kernel.org/netdev/0afe19db-9c7f-4228-9fc2-f7b34c4bc227@linux.alibaba.com/
> around how to split 'emulated' from other hardware drivers, but I don't
> much like that taxonomy. Some of these "virtual" clocks could just as
> easily exist in hardware with PTM too.
Not sure I fully understand what you mean. Practically the distinction
is very clear - the virt devices are implemented by a hypervisor and/or
IPU which may have some HW gadgets and PTM support but beyond that are
software-defined. We don't need help maintaining drivers for
fixed-ASIC (?) clocks, atomic clocks etc. Those are usually time
counter + misc. They are not "devices" which know the wall clock time
better than the host :\
IOW the "does it have a NIC" is not a great distinction.
A better oneliner would be "does it purport to know real time better
than the host"
> My observation is that with the sole exception of ptp_inet.c, *all* of
> the actual PHC drivers that live in drivers/ptp instead of drivers/net
> are "pure clock" drivers, so perhaps we split those all out into
> drivers/ptp/drivers/ and exclude them from the netdev maintenance?
>
> I'm reluctantly prepared to host and help maintain a drivers tree if
> it's necessary, but equally as happy to let you own it.
No strong feelings here, but atomic clocks will start spilling into
DPLL and SyncE pretty quickly.
next prev parent reply other threads:[~2026-06-02 1:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 10:48 [PATCH v2 0/2] ptp: split non-NIC PHC drivers into the clock/timekeeping maintenance domain Wen Gu
2026-04-07 10:48 ` [PATCH v2 1/2] ptp: move emulated/virtual clock drivers into a dedicated subdirectory Wen Gu
2026-04-07 10:48 ` [PATCH v2 2/2] MAINTAINERS: update PTP maintainer entries after directory split Wen Gu
2026-04-12 15:47 ` Jakub Kicinski
2026-04-12 16:32 ` David Woodhouse
2026-04-12 16:53 ` Jakub Kicinski
2026-04-13 9:00 ` Wen Gu
2026-04-29 8:28 ` Wen Gu
2026-05-28 17:06 ` David Woodhouse
2026-06-01 0:20 ` Richard Cochran
2026-06-01 7:03 ` David Woodhouse
2026-06-01 15:20 ` Richard Cochran
2026-06-01 16:53 ` David Woodhouse
2026-06-02 1:52 ` Jakub Kicinski [this message]
2026-06-02 4:20 ` Richard Cochran
2026-06-02 8:04 ` David Woodhouse
2026-06-02 8:51 ` Wen Gu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260601185226.7f43fa75@kernel.org \
--to=kuba@kernel.org \
--cc=ajay.kaher@broadcom.com \
--cc=alexey.makhalov@broadcom.com \
--cc=andrew+netdev@lunn.ch \
--cc=anna-maria@linutronix.de \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=daniel.lezcano@kernel.org \
--cc=davem@davemloft.net \
--cc=dust.li@linux.alibaba.com \
--cc=dwmw2@infradead.org \
--cc=edumazet@google.com \
--cc=frederic@kernel.org \
--cc=guwen@linux.alibaba.com \
--cc=imran.shaik@oss.qualcomm.com \
--cc=imx@lists.linux.dev \
--cc=jonathan.lemon@gmail.com \
--cc=jstultz@google.com \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mani@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nick.shi@broadcom.com \
--cc=pabeni@redhat.com \
--cc=richardcochran@gmail.com \
--cc=sboyd@kernel.org \
--cc=svens@linux.ibm.com \
--cc=taniya.das@oss.qualcomm.com \
--cc=tglx@kernel.org \
--cc=vadim.fedorenko@linux.dev \
--cc=vladimir.oltean@nxp.com \
--cc=wei.fang@nxp.com \
--cc=xiaoning.wang@nxp.com \
--cc=xuanzhuo@linux.alibaba.com \
--cc=yangbo.lu@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox