All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Josh Triplett <josh@joshtriplett.org>,
	John Stultz <john.stultz@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3) posix-timers: make it configurable
Date: Sun, 18 Sep 2016 16:35:29 +0200	[thread overview]
Message-ID: <20160918143529.GA4651@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.20.1609162251160.9883@knanqh.ubzr>

On Fri, Sep 16, 2016 at 10:57:58PM -0400, Nicolas Pitre wrote:
> Subject: [PATCH] ptp_clock: allow for it to be optional
> 
> In order to break the hard dependency between the PTP clock subsystem and
> ethernet drivers capable of being clock providers, this patch provides
> simple PTP stub functions to allow linkage of those drivers into the
> kernel even when the PTP subsystem is configured out.
> 
> And to make it possible for PTP to be configured out, the select statement
> in the Kconfig entry for those ethernet drivers is changed from selecting
> PTP_1588_CLOCK to PTP_1588_CLOCK_DEFAULT whose purpose is to indicate the
> default Kconfig value for the PTP subsystem.
> 
> This way the PTP subsystem may have Kconfig dependencies of its own, such
> as POSIX_TIMERS, without making those ethernet drivers unavailable if
> POSIX timers are cconfigured out. And when support for POSIX timers is
> selected again then PTP clock support will also be selected accordingly.
> 
> Drivers must be ready to accept NULL from ptp_clock_register().
> The pch_gbe driver is a bit special as it relies on extra code in
> drivers/ptp/ptp_pch.c. Therefore we let the make process descend into
> drivers/ptp/ even if PTP_1588_CLOCK is unselected.

Thanks for the detailed description.

> diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
> index 00e6098e9a..c36c018f0f 100644
> --- a/drivers/ptp/Kconfig
> +++ b/drivers/ptp/Kconfig
> @@ -4,8 +4,12 @@
>  
>  menu "PTP clock support"
>  
> +config PTP_1588_CLOCK_DEFAULT
> +	tristate

I see what this option is doing, but I wonder about the name
"DEFAULT".  In what sense is this a default?

> +/**
> + * ptp_clock_register() - register a PTP hardware clock driver
> + *
> + * @info:   Structure describing the new clock.
> + * @parent: Pointer to the parent device of the new clock.

Here we should finally explain the return value for authors of new
drivers.  Something like this:

 * Returns a valid pointer on success or PTR_ERR on failure.  If PHC
 * support is missing at the configuration level, this function
 * returns NULL, and drivers are expected to gracefully handle that
 * case separately.

> + */
> +
> +extern struct ptp_clock *ptp_clock_register(struct ptp_clock_info *info,
> +					    struct device *parent);

Thanks,
Richard

  reply	other threads:[~2016-09-18 14:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-15  3:47 [PATCH v3) posix-timers: make it configurable Nicolas Pitre
2016-09-15 17:48 ` John Stultz
2016-09-15 17:56   ` Nicolas Pitre
2016-09-15 18:13 ` John Stultz
2016-09-15 18:28   ` Nicolas Pitre
2016-09-15 18:35     ` John Stultz
2016-09-15 18:37       ` Nicolas Pitre
2016-09-15 18:46         ` John Stultz
2016-09-15 19:31           ` Nicolas Pitre
2016-09-15 19:58             ` John Stultz
2016-09-15 21:07               ` Richard Cochran
2016-09-15 21:15                 ` Josh Triplett
2016-09-15 21:35                   ` Nicolas Pitre
2016-09-15 21:56                     ` Josh Triplett
2016-09-16  7:24                       ` Richard Cochran
2016-09-17  2:57                         ` Nicolas Pitre
2016-09-18 14:35                           ` Richard Cochran [this message]
2016-09-18 16:54                             ` Nicolas Pitre
2016-09-18 18:20                               ` Richard Cochran
2016-09-18 18:49                                 ` Nicolas Pitre
2016-09-18 20:22                                   ` Richard Cochran
2016-09-18 20:30                                     ` Nicolas Pitre
2016-09-18 21:11                                       ` Richard Cochran
2016-09-15 21:23               ` Richard Cochran
2016-09-16 14:31 ` kbuild test robot

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=20160918143529.GA4651@localhost.localdomain \
    --to=richardcochran@gmail.com \
    --cc=john.stultz@linaro.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolas.pitre@linaro.org \
    --cc=tglx@linutronix.de \
    /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.