Re: [PATCH] iio: core: Avoid BUG() on invalid clock types

On Mon, Aug 24, 2026 at 05:06:24PM +0200, Joshua Crofts wrote:
> On Mon, 24 Aug 2026 at 16:48, Andy Shevchenko
> <[email protected]> wrote:
> > On Mon, Aug 24, 2026 at 12:05:03PM +0200, Joshua Crofts wrote:
> > > On Mon, 24 Aug 2026 12:55:47 +0300
> > > Andy Shevchenko <[email protected]> wrote:
> > > > On Sun, Aug 23, 2026 at 10:25:02PM +0000, Rishab Madhugiri wrote:
> > > > > Replace deprecated use of BUG() in default switch cases of
> > > > > iio_get_time_ns() and current_timestamp_clock_show() with
> > > > > WARN_ONCE() and return correct fallback or error codes.
> > > >
> > > > Why?!
> > >
> > > Because BUG() and BUG_ON() shouldn't be used anymore, no? Linus himself
> > > said that he hates the macros.
> >
> > Why? Please, study the case. As for the above change, there are two questions
> > (at least):
> > - Why BUG() is deprecated? Where is it stated?
> 
> https://docs.kernel.org/process/deprecated.html?hl=en-GB#bug-and-bug-on

Thanks for sharing! So, this is a missing point in the commit message.

> > - What will WARN*() gain us here? (Note some specific kernel command line
> >   parameter that may convert WARN to BUG)
> 
> As Jonathan mentioned earlier, the original BUG() was there to prevent the
> compiler from complaining that all possible values weren't handled. So BUG()
> or WARN*() here is a placeholder. Just removing the BUG() call should be
> valid since it's impossible to hit(?)

Yeah, I was participated in several cases where the compiler made something
strange when BUG() was absent (basically no reachable point which BUG()
represents). Do we have no issues (anymore?) with the compiler with WARN*()?

-- 
With Best Regards,
Andy Shevchenko