All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: Yangbo Lu <yangbo.lu@nxp.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, mptcp@lists.linux.dev,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Mat Martineau <mathew.j.martineau@linux.intel.com>,
	Matthieu Baerts <matthieu.baerts@tessares.net>,
	Shuah Khan <shuah@kernel.org>, Michal Kubecek <mkubecek@suse.cz>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>, Rui Sousa <rui.sousa@nxp.com>,
	Sebastien Laveze <sebastien.laveze@nxp.com>
Subject: Re: [net-next, v5, 08/11] net: sock: extend SO_TIMESTAMPING for PHC binding
Date: Sun, 4 Jul 2021 06:33:31 -0700	[thread overview]
Message-ID: <20210704133331.GA4268@hoboy.vegasvil.org> (raw)
In-Reply-To: <20210630081202.4423-9-yangbo.lu@nxp.com>

On Wed, Jun 30, 2021 at 04:11:59PM +0800, Yangbo Lu wrote:
> Since PTP virtual clock support is added, there can be
> several PTP virtual clocks based on one PTP physical
> clock for timestamping.
> 
> This patch is to extend SO_TIMESTAMPING API to support
> PHC (PTP Hardware Clock) binding by adding a new flag
> SOF_TIMESTAMPING_BIND_PHC. When PTP virtual clocks are
> in use, user space can configure to bind one for
> timestamping, but PTP physical clock is not supported
> and not needed to bind.

Would it not be better to simply bind automatically?

Like this pseudo code:

	if (hw_timestamping_requested() && interface_is_vclock()) {
		bind_vclock();
	}

It would be great to avoid forcing user space to use a new option.

Especially because NOT setting the option makes no sense.  Or maybe
there is a use case for omitting the option?


Thoughts?

Thanks,
Richard

  reply	other threads:[~2021-07-04 13:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-30  8:11 [net-next, v5, 00/11] ptp: support virtual clocks and timestamping Yangbo Lu
2021-06-30  8:11 ` [net-next, v5, 01/11] ptp: add ptp virtual clock driver framework Yangbo Lu
2021-06-30  8:11 ` [net-next, v5, 02/11] ptp: support ptp physical/virtual clocks conversion Yangbo Lu
2021-07-04 10:25   ` [ptp] becdd56786: BUG:kernel_NULL_pointer_dereference,address kernel test robot
2021-07-04 10:25     ` kernel test robot
2021-08-07  1:15   ` [net-next, v5, 02/11] ptp: support ptp physical/virtual clocks conversion Vinicius Costa Gomes
2021-08-07 14:22     ` Richard Cochran
2021-08-07 14:43       ` Vladimir Oltean
2021-08-07 20:56         ` Richard Cochran
2021-06-30  8:11 ` [net-next, v5, 03/11] ptp: track available ptp vclocks information Yangbo Lu
2021-06-30  8:11 ` [net-next, v5, 04/11] ptp: add kernel API ptp_get_vclocks_index() Yangbo Lu
2021-06-30  8:11 ` [net-next, v5, 05/11] ethtool: add a new command for getting PHC virtual clocks Yangbo Lu
2021-06-30  8:11 ` [net-next, v5, 06/11] ptp: add kernel API ptp_convert_timestamp() Yangbo Lu
2021-06-30  8:11 ` [net-next, v5, 07/11] mptcp: setsockopt: convert to mptcp_setsockopt_sol_socket_timestamping() Yangbo Lu
2021-06-30  8:11 ` [net-next, v5, 08/11] net: sock: extend SO_TIMESTAMPING for PHC binding Yangbo Lu
2021-07-04 13:33   ` Richard Cochran [this message]
2021-07-05  8:19     ` Y.b. Lu
2021-07-05 18:44       ` Richard Cochran
2021-06-30  8:12 ` [net-next, v5, 09/11] net: socket: support hardware timestamp conversion to PHC bound Yangbo Lu
2021-06-30  8:12 ` [net-next, v5, 10/11] selftests/net: timestamping: support binding PHC Yangbo Lu
2021-06-30  8:12 ` [net-next, v5, 11/11] MAINTAINERS: add entry for PTP virtual clock driver Yangbo Lu
2021-07-01 20:20 ` [net-next, v5, 00/11] ptp: support virtual clocks and timestamping patchwork-bot+netdevbpf

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=20210704133331.GA4268@hoboy.vegasvil.org \
    --to=richardcochran@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mathew.j.martineau@linux.intel.com \
    --cc=matthieu.baerts@tessares.net \
    --cc=mkubecek@suse.cz \
    --cc=mptcp@lists.linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=rui.sousa@nxp.com \
    --cc=sebastien.laveze@nxp.com \
    --cc=shuah@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.