From: Jonathan Cameron <jic23@kernel.org>
To: Rishab M <rishab.madhugiri@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@intel.com>,
dlechner@baylibre.com, nuno.sa@analog.com, andy@kernel.org,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] iio: core: Replace BUG() with WARN_ON_ONCE() and error return
Date: Mon, 31 Aug 2026 00:35:09 +0100 [thread overview]
Message-ID: <20260831003509.4fb38052@jic23-huawei> (raw)
In-Reply-To: <CANc32tPtHyJdg-PJa0iZHcqX4WDtMFikZFD+4aO96B1+zmf0_Q@mail.gmail.com>
On Thu, 27 Aug 2026 15:24:52 -0700
Rishab M <rishab.madhugiri@gmail.com> wrote:
> Thanks for the feedback. I totally understand the perspective on code churn
> versus making tree wide cleanups, and I will let Jonathan make the final call
> on whether this is suitable. I've also noted the wrapping width feedback for
> commit messages in the future.
>
Please comment inline.
Anyhow, I have applied this but mostly because it is easier for cases like
this to do so than to reply to a series of folk proposing the change.
Slightly rubbish reason, but meh, too many patches floating around and this
is a harmless way to potentially cut that down a little in the longer term.
Thanks,
Jonathan
> Best,
> Rishab
>
> On Wed, Aug 26, 2026 at 11:41 PM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> >
> > On Wed, Aug 26, 2026 at 09:31:40PM +0000, Rishab Madhugiri wrote:
> > > As documented in Documentation/process/deprecated.rst, the
> > > use of BUG() and BUG_ON() should be avoided as they could
> > > cause a complete system crash, preventing further debugging.
> >
> > Right, but deprecation doesn't mean the _old_ existing code must be immediately
> > changed. I leave it to Jonathan, but I see no value in this change except
> > the unneeded churn. If we ever want to drop BUG(), it should be done tree wide.
> > Hence no tag given.
> >
> > > In iio_get_time_ns() and current_timestamp_clock_show(), the
> > > clock type is already validated against supported clock
> > > types prior to these calls, making the default switch
> > > branches expected to be unreachable. Replace these with
> > > WARN_ON_ONCE(1) followed by an error return to avoid a
> > > crash and to log the highly unexpected condition.
> >
> > There is like 10+ character space on each line, the commit message shouldn't
> > be that condensed.
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >
prev parent reply other threads:[~2026-08-30 23:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 21:31 [PATCH v2] iio: core: Replace BUG() with WARN_ON_ONCE() and error return Rishab Madhugiri
2026-08-27 6:41 ` Andy Shevchenko
2026-08-27 22:24 ` Rishab M
2026-08-30 23:35 ` Jonathan Cameron [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=20260831003509.4fb38052@jic23-huawei \
--to=jic23@kernel.org \
--cc=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=rishab.madhugiri@gmail.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.