From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: tanure@linux.com
Cc: Alison Schofield <alison.schofield@intel.com>,
Anton Gusev <aagusev@ispras.ru>,
kernelnewbies@kernelnewbies.org
Subject: Re: Need help determining if the change is warranted.
Date: Sun, 28 May 2023 00:18:37 -0400 [thread overview]
Message-ID: <1264347.1685247517@turing-police> (raw)
In-Reply-To: <CAJX_Q+3jWRM1JdRV0EnJa24hEt-PgyHE=DqtJyriDWypWMBxug@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1186 bytes --]
On Sat, 27 May 2023 07:05:40 +0100, Lucas Tanure said:
> It's unusual for an I2C bus would suddenly stop working, so just one
> check at the beginning of the function is enough.
> I would remove all ret assignments apart from the first one for every
> function on that driver.
By the same token, it's somewhat unusual for an I2C bus to stop working
once it's been probed and initialized, so maybe the first one is superfluous
as well :) (Just playing devil's advocate here - after 4 decades of this stuff,
I've hit enough systems that have gotten wedged on unusual situations. The worst
one was an 18 month chase for why on occasion a petabyte-scale disk array
hanging off a bunch of FiberChannel connections would read from the wrong LUN.
We finally figured out it was actually a firmware bug in the 10Gig ethernet card.
But probably the best advice is this one variously attributed to Tom Duff
at Bell Labs (yeah the guy who came up with the Duff Device) or Henry Spencer:
Never test for an error condition you don't know how to handle....
(And that 10gig issue probably needed Casey Schaufler of SGI's suggested
error code:
-EGADS - Violates the principle of least surprise.
[-- Attachment #1.2: Type: application/pgp-signature, Size: 494 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
prev parent reply other threads:[~2023-05-28 4:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-27 11:34 Need help determining if the change is warranted Anton Gusev
2023-05-27 0:36 ` Alison Schofield
2023-05-27 6:05 ` Lucas Tanure
2023-05-28 4:18 ` Valdis Klētnieks [this message]
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=1264347.1685247517@turing-police \
--to=valdis.kletnieks@vt.edu \
--cc=aagusev@ispras.ru \
--cc=alison.schofield@intel.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=tanure@linux.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;
as well as URLs for NNTP newsgroup(s).