All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfgang Denk <wd@denx.de>
To: Tom Rini <trini@konsulko.com>
Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>,
	u-boot@lists.denx.de, Simon Glass <sjg@chromium.org>,
	Stefan Roese <sr@denx.de>
Subject: Re: [PATCH v6 10/12] watchdog: add gpio watchdog driver
Date: Thu, 19 Aug 2021 16:16:12 +0200	[thread overview]
Message-ID: <66367.1629382572@gemini.denx.de> (raw)
In-Reply-To: <20210819130806.GW858@bill-the-cat>

Dear Tom,

In message <20210819130806.GW858@bill-the-cat> you wrote:
> 
> > So we have now a policy to wave through code, and ask others to
> > clean it up later?  That's ... sad.
>
> No, we continue to have the policy of expecting reviewers to follow the
> whole discussion and relevant subsystems.

Once upon a time there has also been a policy that if a function
might return error codes, these need to be checked and handled.

> Changing _every_ caller of dev_get_priv to check for NULL and
> then, what? is clearly not the right answer.

Then what is the right answer in your opinion?

I mean, look at the implementation of dev_get_priv():

 628 void *dev_get_priv(const struct udevice *dev)
 629 {
 630         if (!dev) {
 631                 dm_warn("%s: null device\n", __func__);
 632                 return NULL;
 633         }
 634
 635         return dm_priv_to_rw(dev->priv_);
 636 }

If there is guaranteed no way that dev_get_priv() can return a NULL
pointer, that means that it must be guaranteed that the "dev"
argument can never be a NULL pointer, either.  So why do we check it
at all?

The same applies for all functions in "drivers/core/device.c" - they
all check for valid input parameters, like any code should do.

> If you think you see a problem here please go audit the DM code
> itself more and propose some changes.

I can see that the DM code itself implements proper error checking
and reporting; it's the callers where negligent code prevails.


If you are consequent, you must decide what you want:

- Either we want robust and reliable code - then we have to handle
  the error codes which functions like dev_get_priv() etc. return.

- Or you don't care about software quality, then we can omit such
  handling, but then it would also be consequent to remove all the
  error checking from "drivers/core/device.c" etc. - hey, that would
  even save a few hundred bytes of code size.


Sugarcoating code which fails to handle error codes because "these
errors can never happen" does not seem to be a clever approach to
software engineering to me.


I stop here.  You know my opinion.  You are the maintainer.


Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A witty saying proves nothing, but saying  something  pointless  gets
people's attention.

  reply	other threads:[~2021-08-19 14:16 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-19  9:56 [PATCH v6 00/12] handling all DM watchdogs in watchdog_reset() Rasmus Villemoes
2021-08-19  9:56 ` [PATCH v6 01/12] watchdog: wdt-uclass.c: use wdt_start() in wdt_expire_now() Rasmus Villemoes
2021-08-19  9:56 ` [PATCH v6 02/12] watchdog: wdt-uclass.c: introduce struct wdt_priv Rasmus Villemoes
2021-08-19  9:56 ` [PATCH v6 03/12] watchdog: wdt-uclass.c: neaten UCLASS_DRIVER definition Rasmus Villemoes
2021-08-19  9:56 ` [PATCH v6 04/12] watchdog: wdt-uclass.c: refactor initr_watchdog() Rasmus Villemoes
2021-08-19  9:56 ` [PATCH v6 05/12] watchdog: wdt-uclass.c: keep track of each device's running state Rasmus Villemoes
2021-08-19 11:35   ` Wolfgang Denk
2021-08-19  9:57 ` [PATCH v6 06/12] sandbox: disable CONFIG_WATCHDOG_AUTOSTART Rasmus Villemoes
2021-08-19  9:57 ` [PATCH v6 07/12] watchdog: wdt-uclass.c: add wdt_stop_all() helper Rasmus Villemoes
2021-08-19 11:37   ` Wolfgang Denk
2021-08-19  9:57 ` [PATCH v6 08/12] board: x530: switch to wdt_stop_all() Rasmus Villemoes
2021-08-19  9:57 ` [PATCH v6 09/12] watchdog: wdt-uclass.c: handle all DM watchdogs in watchdog_reset() Rasmus Villemoes
2021-08-19 11:43   ` Wolfgang Denk
2021-08-19  9:57 ` [PATCH v6 10/12] watchdog: add gpio watchdog driver Rasmus Villemoes
2021-08-19 11:46   ` Wolfgang Denk
2021-08-19 12:09     ` Rasmus Villemoes
2021-08-19 12:32       ` Wolfgang Denk
2021-08-19 12:35         ` Tom Rini
2021-08-19 13:03           ` Wolfgang Denk
2021-08-19 13:08             ` Tom Rini
2021-08-19 14:16               ` Wolfgang Denk [this message]
2021-08-19 14:44                 ` Simon Glass
2021-08-19 14:57                   ` Wolfgang Denk
2021-08-20 15:02                     ` Simon Glass
2021-08-23 11:07                       ` Wolfgang Denk
2021-08-23 17:25                         ` Simon Glass
2021-08-20  6:22         ` Rasmus Villemoes
2021-08-20 18:22           ` Simon Glass
2021-08-19  9:57 ` [PATCH v6 11/12] sandbox: add test of wdt_gpio driver Rasmus Villemoes
2021-08-19  9:57 ` [PATCH v6 12/12] sandbox: add test of wdt-uclass' watchdog_reset() Rasmus Villemoes
2021-08-31  8:17   ` Stefan Roese
2021-08-31  9:29     ` Rasmus Villemoes
2021-08-31 12:44       ` Tom Rini
2021-08-31 15:03       ` Stefan Roese

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=66367.1629382572@gemini.denx.de \
    --to=wd@denx.de \
    --cc=rasmus.villemoes@prevas.dk \
    --cc=sjg@chromium.org \
    --cc=sr@denx.de \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.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.