All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@kernel.org>
To: Richard Cochran <richardcochran@gmail.com>
Cc: 王擎 <wangqing@vivo.com>, "Jakub Kicinski" <kuba@kernel.org>,
	"Grygorii Strashko" <grygorii.strashko@ti.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Samuel Zou" <zou_wei@huawei.com>,
	"Kurt Kanzenbach" <kurt@linutronix.de>,
	"Ivan Khoronzhuk" <ivan.khoronzhuk@linaro.org>,
	Networking <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Re: [PATCH V4 net-bugfixs] net/ethernet: Update ret when ptp_clock is ERROR
Date: Thu, 12 Nov 2020 22:21:21 +0100	[thread overview]
Message-ID: <CAK8P3a1pHpweXP+2mp7bdg2GvU5kk4NASsu4MQCRPtK-VpuXSA@mail.gmail.com> (raw)
In-Reply-To: <20201112181954.GD21010@hoboy.vegasvil.org>

On Thu, Nov 12, 2020 at 7:19 PM Richard Cochran
<richardcochran@gmail.com> wrote:
>
> On Thu, Nov 12, 2020 at 09:25:12AM +0100, Arnd Bergmann wrote:
> > This is not really getting any better. If Richard is worried about
> > Kconfig getting changed here, I would suggest handling the
> > case of PTP being disabled by returning an error early on in the
> > function, like
> >
> > struct am65_cpts *am65_cpts_create(struct device *dev, void __iomem *regs,
> >                                    struct device_node *node)
> > {
> >         struct am65_cpts *cpts;
> >         int ret, i;
> >
> >         if (!IS_ENABLED(CONFIG_PTP_1588_CLOCK))
> >                  return -ENODEV;
>
> No, please, no.  That only adds confusion.  The NULL return value
> already signals that the compile time support was missing.  That was
> the entire point of this...
>
>  * 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.
>  *
>  * 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.

The problem is that the caller doesn't handle that case gracefully,
but it instead wants to return an error after all. I don't see a good
solution either; as far as I'm concerned we should never be building
code that fails if PTP_1588_CLOCK is disabled when it cannot
do anything sensible in that configuration.

I agree that the 'imply' keyword in Kconfig is what made this a
lot worse, and it would be best to replace that with normal
dependencies.

It would be possible to have a ptp_clock_register_optional()
interface in addition to ptp_clock_register(), which could then
be changed to return an error. Some other subsystems follow
this pattern, but it's not any less confusing either.

     Arnd

  reply	other threads:[~2020-11-12 21:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-11  9:24 [PATCH V4 net-bugfixs] net/ethernet: Update ret when ptp_clock is ERROR Wang Qing
2020-11-11 12:32 ` Richard Cochran
2020-11-11 13:24   ` Grygorii Strashko
2020-11-11 13:55     ` Richard Cochran
2020-11-11 16:00       ` Jakub Kicinski
2020-11-12  1:15         ` 王擎
2020-11-12  1:32           ` Jakub Kicinski
2020-11-12  2:48             ` 王擎
2020-11-12  4:23               ` Jakub Kicinski
2020-11-12  8:25           ` Arnd Bergmann
2020-11-12 10:05             ` Grygorii Strashko
2020-11-12 18:14               ` Richard Cochran
2020-11-12 18:19             ` Richard Cochran
2020-11-12 21:21               ` Arnd Bergmann [this message]
2020-11-12 23:27                 ` Richard Cochran
2020-11-13 16:21                   ` Arnd Bergmann
2020-11-14 15:14                     ` Richard Cochran
2020-11-14 21:16                       ` Arnd Bergmann

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=CAK8P3a1pHpweXP+2mp7bdg2GvU5kk4NASsu4MQCRPtK-VpuXSA@mail.gmail.com \
    --to=arnd@kernel.org \
    --cc=davem@davemloft.net \
    --cc=grygorii.strashko@ti.com \
    --cc=ivan.khoronzhuk@linaro.org \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=wangqing@vivo.com \
    --cc=zou_wei@huawei.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.