[PATCH 0/3] some objtool warnings fixes

[PATCH 0/3] some objtool warnings fixes

[Josh Poimboeuf]

Some fixes for objtool warnings reported by Arnd.

Josh Poimboeuf (3):
  objtool: Fix Clang jump table detection
  ASoC: codecs: wcd9335: Remove potential undefined behavior in
    wcd9335_slimbus_irq()
  iio: imu: bmi160: Remove potential undefined behavior in
    bmi160_config_pin()

 drivers/iio/imu/bmi160/bmi160_core.c | 2 ++
 sound/soc/codecs/wcd9335.c           | 2 +-
 tools/objtool/check.c                | 5 ++---
 3 files changed, 5 insertions(+), 4 deletions(-)

-- 
2.53.0

[PATCH 1/3] objtool: Fix Clang jump table detection

[Josh Poimboeuf]

With Clang, there can be a conditional forward jump between the load of
the jump table address and the indirect branch.

Fixes the following warning:

  vmlinux.o: warning: objtool: ___bpf_prog_run+0x1c5: sibling call from callable instruction with modified stack frame

Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 tools/objtool/check.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 91b3ff4803cf..b6765e876507 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2184,12 +2184,11 @@ static void mark_func_jump_tables(struct objtool_file *file,
 			last = insn;
 
 		/*
-		 * Store back-pointers for unconditional forward jumps such
+		 * Store back-pointers for forward jumps such
 		 * that find_jump_table() can back-track using those and
 		 * avoid some potentially confusing code.
 		 */
-		if (insn->type == INSN_JUMP_UNCONDITIONAL && insn->jump_dest &&
-		    insn->offset > last->offset &&
+		if (insn->jump_dest &&
 		    insn->jump_dest->offset > insn->offset &&
 		    !insn->jump_dest->first_jump_src) {
 
-- 
2.53.0

[tip: objtool/urgent] objtool: Fix Clang jump table detection

[tip-bot2 for Josh Poimboeuf]

The following commit has been merged into the objtool/urgent branch of tip:

Commit-ID:     4e5019216402ad0b4a84cff457b662d26803f103
Gitweb:        https://git.kernel.org/tip/4e5019216402ad0b4a84cff457b662d26803f103
Author:        Josh Poimboeuf <jpoimboe@kernel.org>
AuthorDate:    Mon, 09 Mar 2026 09:03:05 -07:00
Committer:     Josh Poimboeuf <jpoimboe@kernel.org>
CommitterDate: Mon, 16 Mar 2026 15:31:25 -07:00

objtool: Fix Clang jump table detection

With Clang, there can be a conditional forward jump between the load of
the jump table address and the indirect branch.

Fixes the following warning:

  vmlinux.o: warning: objtool: ___bpf_prog_run+0x1c5: sibling call from callable instruction with modified stack frame

Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
Link: https://patch.msgid.link/7d8600caed08901b6679767488acd639f6df9688.1773071992.git.jpoimboe@kernel.org
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 tools/objtool/check.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 91b3ff4..b6765e8 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2184,12 +2184,11 @@ static void mark_func_jump_tables(struct objtool_file *file,
 			last = insn;
 
 		/*
-		 * Store back-pointers for unconditional forward jumps such
+		 * Store back-pointers for forward jumps such
 		 * that find_jump_table() can back-track using those and
 		 * avoid some potentially confusing code.
 		 */
-		if (insn->type == INSN_JUMP_UNCONDITIONAL && insn->jump_dest &&
-		    insn->offset > last->offset &&
+		if (insn->jump_dest &&
 		    insn->jump_dest->offset > insn->offset &&
 		    !insn->jump_dest->first_jump_src) {
 

[PATCH 2/3] ASoC: codecs: wcd9335: Remove potential undefined behavior in wcd9335_slimbus_irq()

[Josh Poimboeuf]

If 'port_id' is negative, the shift counts in wcd9335_slimbus_irq() also
become negative, resulting in undefined behavior due to shift out of
bounds.

That appears to be not possible, but with UBSAN enabled, Clang's range
analysis isn't always able to determine that and generates undefined
behavior.

As a result the code generation isn't optimal, and undefined behavior
should be avoided regardless.  Improve code generation and remove the
undefined behavior by converting the signed variables to unsigned.

Fixes the following warning:

  sound/soc/codecs/wcd9335.o: warning: objtool: wcd9335_slimbus_irq() falls through to next function __cfi_wcd9335_set_channel_map()

This is very similar to a previous fix to wcd934x with commit
060aed9c0093 ("objtool, ASoC: codecs: wcd934x: Remove potential
undefined behavior in wcd934x_slim_irq_handler()").

Cc: Srinivas Kandagatla <srini@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 sound/soc/codecs/wcd9335.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wcd9335.c b/sound/soc/codecs/wcd9335.c
index 640e43ee1975..e3ca5ca6de3d 100644
--- a/sound/soc/codecs/wcd9335.c
+++ b/sound/soc/codecs/wcd9335.c
@@ -3907,7 +3907,7 @@ static irqreturn_t wcd9335_slimbus_irq(int irq, void *data)
 {
 	struct wcd9335_codec *wcd = data;
 	unsigned long status = 0;
-	int i, j, port_id;
+	unsigned int i, j, port_id;
 	unsigned int val, int_val = 0;
 	irqreturn_t ret = IRQ_NONE;
 	bool tx;
-- 
2.53.0

Re: [PATCH 2/3] ASoC: codecs: wcd9335: Remove potential undefined behavior in wcd9335_slimbus_irq()

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 772 bytes --]

On Mon, Mar 09, 2026 at 09:03:06AM -0700, Josh Poimboeuf wrote:
> If 'port_id' is negative, the shift counts in wcd9335_slimbus_irq() also
> become negative, resulting in undefined behavior due to shift out of
> bounds.

You've not copied me on the rest of the series so I don't know what's
going on with dependencies.  When sending a patch series it is important
to ensure that all the various maintainers understand what the
relationship between the patches as the expecation is that there will be
interdependencies.  Either copy everyone on the whole series or at least
copy them on the cover letter and explain what's going on.  If there are
no strong interdependencies then it's generally simplest to just send
the patches separately to avoid any possible confusion.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 2/3] ASoC: codecs: wcd9335: Remove potential undefined behavior in wcd9335_slimbus_irq()

[Josh Poimboeuf]

On Mon, Mar 09, 2026 at 04:05:06PM +0000, Mark Brown wrote:
> On Mon, Mar 09, 2026 at 09:03:06AM -0700, Josh Poimboeuf wrote:
> > If 'port_id' is negative, the shift counts in wcd9335_slimbus_irq() also
> > become negative, resulting in undefined behavior due to shift out of
> > bounds.
> 
> You've not copied me on the rest of the series so I don't know what's
> going on with dependencies.  When sending a patch series it is important
> to ensure that all the various maintainers understand what the
> relationship between the patches as the expecation is that there will be
> interdependencies.  Either copy everyone on the whole series or at least
> copy them on the cover letter and explain what's going on.  If there are
> no strong interdependencies then it's generally simplest to just send
> the patches separately to avoid any possible confusion.

Sorry about that.  This is just a collection of objtool warnings fixes
and there are no interdependencies.

-- 
Josh

Re: [PATCH 2/3] ASoC: codecs: wcd9335: Remove potential undefined behavior in wcd9335_slimbus_irq()

[Srinivas Kandagatla]

On 3/9/26 4:03 PM, Josh Poimboeuf wrote:
> If 'port_id' is negative, the shift counts in wcd9335_slimbus_irq() also
> become negative, resulting in undefined behavior due to shift out of
> bounds.
> 
> That appears to be not possible, but with UBSAN enabled, Clang's range
> analysis isn't always able to determine that and generates undefined
> behavior.
> 
> As a result the code generation isn't optimal, and undefined behavior
> should be avoided regardless.  Improve code generation and remove the
> undefined behavior by converting the signed variables to unsigned.
> 
> Fixes the following warning:
> 
>   sound/soc/codecs/wcd9335.o: warning: objtool: wcd9335_slimbus_irq() falls through to next function __cfi_wcd9335_set_channel_map()
> 
> This is very similar to a previous fix to wcd934x with commit
> 060aed9c0093 ("objtool, ASoC: codecs: wcd934x: Remove potential
> undefined behavior in wcd934x_slim_irq_handler()").
> 
> Cc: Srinivas Kandagatla <srini@kernel.org>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> ---

Am not sure if port_id will be ever negative. but the change itself
looks harmless,

Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>

--srini

>  sound/soc/codecs/wcd9335.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/soc/codecs/wcd9335.c b/sound/soc/codecs/wcd9335.c
> index 640e43ee1975..e3ca5ca6de3d 100644
> --- a/sound/soc/codecs/wcd9335.c
> +++ b/sound/soc/codecs/wcd9335.c
> @@ -3907,7 +3907,7 @@ static irqreturn_t wcd9335_slimbus_irq(int irq, void *data)
>  {
>  	struct wcd9335_codec *wcd = data;
>  	unsigned long status = 0;
> -	int i, j, port_id;
> +	unsigned int i, j, port_id;
>  	unsigned int val, int_val = 0;
>  	irqreturn_t ret = IRQ_NONE;
>  	bool tx;

[PATCH 3/3] iio: imu: bmi160: Remove potential undefined behavior in bmi160_config_pin()

[Josh Poimboeuf]

If 'pin' is not one of its expected values, the value of
'int_out_ctrl_shift' is undefined.  With UBSAN enabled, this causes
Clang to generate undefined behavior, resulting in the following
warning:

  drivers/iio/imu/bmi160/bmi160_core.o: warning: objtool: bmi160_setup_irq() falls through to next function __cfi_bmi160_core_runtime_resume()

Prevent the UB and improve error handling by adding a BUG() if 'pin' has
an unexpected value.

Cc: Jonathan Cameron <jic23@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>
CC: Nuno Sá <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Fixes: 895bf81e6bbf ("iio:bmi160: add drdy interrupt support")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
 drivers/iio/imu/bmi160/bmi160_core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iio/imu/bmi160/bmi160_core.c b/drivers/iio/imu/bmi160/bmi160_core.c
index 5f47708b4c5d..e5326df75e49 100644
--- a/drivers/iio/imu/bmi160/bmi160_core.c
+++ b/drivers/iio/imu/bmi160/bmi160_core.c
@@ -579,6 +579,8 @@ static int bmi160_config_pin(struct regmap *regmap, enum bmi160_int_pin pin,
 		int_latch_mask = BMI160_INT2_LATCH_MASK;
 		int_map_mask = BMI160_INT2_MAP_DRDY_EN;
 		break;
+	default:
+		BUG();
 	}
 	int_out_ctrl_mask = BMI160_INT_OUT_CTRL_MASK << int_out_ctrl_shift;
 
-- 
2.53.0

Re: [PATCH 3/3] iio: imu: bmi160: Remove potential undefined behavior in bmi160_config_pin()

[Nuno Sá]

On Mon, 2026-03-09 at 09:03 -0700, Josh Poimboeuf wrote:
> If 'pin' is not one of its expected values, the value of
> 'int_out_ctrl_shift' is undefined.  With UBSAN enabled, this causes
> Clang to generate undefined behavior, resulting in the following
> warning:
> 
>   drivers/iio/imu/bmi160/bmi160_core.o: warning: objtool: bmi160_setup_irq() falls through to next
> function __cfi_bmi160_core_runtime_resume()
> 
> Prevent the UB and improve error handling by adding a BUG() if 'pin' has
> an unexpected value.
> 
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> CC: Nuno Sá <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Fixes: 895bf81e6bbf ("iio:bmi160: add drdy interrupt support")
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> ---
>  drivers/iio/imu/bmi160/bmi160_core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iio/imu/bmi160/bmi160_core.c b/drivers/iio/imu/bmi160/bmi160_core.c
> index 5f47708b4c5d..e5326df75e49 100644
> --- a/drivers/iio/imu/bmi160/bmi160_core.c
> +++ b/drivers/iio/imu/bmi160/bmi160_core.c
> @@ -579,6 +579,8 @@ static int bmi160_config_pin(struct regmap *regmap, enum bmi160_int_pin pin,
>  		int_latch_mask = BMI160_INT2_LATCH_MASK;
>  		int_map_mask = BMI160_INT2_MAP_DRDY_EN;
>  		break;
> +	default:
> +		BUG();
>  	}
>  	int_out_ctrl_mask = BMI160_INT_OUT_CTRL_MASK << int_out_ctrl_shift;
>  

AFAIK, BUG() is not something we should use lightly so I wonder why having it rather that a normal
'return -EINVAL'?

At the very least, it could be WARN but I still think that's too much for a device .probe(). Any
special reason using BUG()?

Also seems like:

https://elixir.bootlin.com/linux/v7.0-rc2/source/drivers/iio/imu/bmi160/bmi160_core.c#L624

could be improved? Like setting 'pin_name' in the first switch() case.

- Nuno Sá

Re: [PATCH 3/3] iio: imu: bmi160: Remove potential undefined behavior in bmi160_config_pin()

[Josh Poimboeuf]

On Mon, Mar 09, 2026 at 04:16:16PM +0000, Nuno Sá wrote:
> On Mon, 2026-03-09 at 09:03 -0700, Josh Poimboeuf wrote:
> > If 'pin' is not one of its expected values, the value of
> > 'int_out_ctrl_shift' is undefined.  With UBSAN enabled, this causes
> > Clang to generate undefined behavior, resulting in the following
> > warning:
> > 
> >   drivers/iio/imu/bmi160/bmi160_core.o: warning: objtool: bmi160_setup_irq() falls through to next
> > function __cfi_bmi160_core_runtime_resume()
> > 
> > Prevent the UB and improve error handling by adding a BUG() if 'pin' has
> > an unexpected value.
> > 
> > Cc: Jonathan Cameron <jic23@kernel.org>
> > Cc: David Lechner <dlechner@baylibre.com>
> > CC: Nuno Sá <nuno.sa@analog.com>
> > Cc: Andy Shevchenko <andy@kernel.org>
> > Fixes: 895bf81e6bbf ("iio:bmi160: add drdy interrupt support")
> > Reported-by: Arnd Bergmann <arnd@arndb.de>
> > Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
> > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> > ---
> >  drivers/iio/imu/bmi160/bmi160_core.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/iio/imu/bmi160/bmi160_core.c b/drivers/iio/imu/bmi160/bmi160_core.c
> > index 5f47708b4c5d..e5326df75e49 100644
> > --- a/drivers/iio/imu/bmi160/bmi160_core.c
> > +++ b/drivers/iio/imu/bmi160/bmi160_core.c
> > @@ -579,6 +579,8 @@ static int bmi160_config_pin(struct regmap *regmap, enum bmi160_int_pin pin,
> >  		int_latch_mask = BMI160_INT2_LATCH_MASK;
> >  		int_map_mask = BMI160_INT2_MAP_DRDY_EN;
> >  		break;
> > +	default:
> > +		BUG();
> >  	}
> >  	int_out_ctrl_mask = BMI160_INT_OUT_CTRL_MASK << int_out_ctrl_shift;
> >  
> 
> AFAIK, BUG() is not something we should use lightly so I wonder why having it rather that a normal
> 'return -EINVAL'?
> 
> At the very least, it could be WARN but I still think that's too much for a device .probe(). Any
> special reason using BUG()?

Using BUG() for a default "invalid enum" is a common pattern, but indeed
returning an error would also be valid here.  I can change that to
return -EINVAL.

> Also seems like:
> 
> https://elixir.bootlin.com/linux/v7.0-rc2/source/drivers/iio/imu/bmi160/bmi160_core.c#L624
> 
> could be improved? Like setting 'pin_name' in the first switch() case.

Yeah, I assume you mean setting 'pin_name' to something like "invalid"
for the default case?

-- 
Josh

Re: [PATCH 3/3] iio: imu: bmi160: Remove potential undefined behavior in bmi160_config_pin()

[Nuno Sá]

On Mon, 2026-03-09 at 09:27 -0700, Josh Poimboeuf wrote:
> On Mon, Mar 09, 2026 at 04:16:16PM +0000, Nuno Sá wrote:
> > On Mon, 2026-03-09 at 09:03 -0700, Josh Poimboeuf wrote:
> > > If 'pin' is not one of its expected values, the value of
> > > 'int_out_ctrl_shift' is undefined.  With UBSAN enabled, this causes
> > > Clang to generate undefined behavior, resulting in the following
> > > warning:
> > > 
> > >   drivers/iio/imu/bmi160/bmi160_core.o: warning: objtool: bmi160_setup_irq() falls through to
> > > next
> > > function __cfi_bmi160_core_runtime_resume()
> > > 
> > > Prevent the UB and improve error handling by adding a BUG() if 'pin' has
> > > an unexpected value.
> > > 
> > > Cc: Jonathan Cameron <jic23@kernel.org>
> > > Cc: David Lechner <dlechner@baylibre.com>
> > > CC: Nuno Sá <nuno.sa@analog.com>
> > > Cc: Andy Shevchenko <andy@kernel.org>
> > > Fixes: 895bf81e6bbf ("iio:bmi160: add drdy interrupt support")
> > > Reported-by: Arnd Bergmann <arnd@arndb.de>
> > > Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
> > > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> > > ---
> > >  drivers/iio/imu/bmi160/bmi160_core.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > > 
> > > diff --git a/drivers/iio/imu/bmi160/bmi160_core.c b/drivers/iio/imu/bmi160/bmi160_core.c
> > > index 5f47708b4c5d..e5326df75e49 100644
> > > --- a/drivers/iio/imu/bmi160/bmi160_core.c
> > > +++ b/drivers/iio/imu/bmi160/bmi160_core.c
> > > @@ -579,6 +579,8 @@ static int bmi160_config_pin(struct regmap *regmap, enum bmi160_int_pin
> > > pin,
> > >  		int_latch_mask = BMI160_INT2_LATCH_MASK;
> > >  		int_map_mask = BMI160_INT2_MAP_DRDY_EN;
> > >  		break;
> > > +	default:
> > > +		BUG();
> > >  	}
> > >  	int_out_ctrl_mask = BMI160_INT_OUT_CTRL_MASK << int_out_ctrl_shift;
> > >  
> > 
> > AFAIK, BUG() is not something we should use lightly so I wonder why having it rather that a
> > normal
> > 'return -EINVAL'?
> > 
> > At the very least, it could be WARN but I still think that's too much for a device .probe(). Any
> > special reason using BUG()?
> 
> Using BUG() for a default "invalid enum" is a common pattern, but indeed
> returning an error would also be valid here.  I can change that to
> return -EINVAL.
> 
> > Also seems like:
> > 
> > https://elixir.bootlin.com/linux/v7.0-rc2/source/drivers/iio/imu/bmi160/bmi160_core.c#L624
> > 
> > could be improved? Like setting 'pin_name' in the first switch() case.
> 
> Yeah, I assume you mean setting 'pin_name' to something like "invalid"
> for the default case?

Nope, I meant not duplicating the switch() case. The default should return an error so I would say
no need to bother in setting the name for that case.

- Nuno Sá

Re: [PATCH 3/3] iio: imu: bmi160: Remove potential undefined behavior in bmi160_config_pin()

[Josh Poimboeuf]

On Mon, Mar 09, 2026 at 04:31:49PM +0000, Nuno Sá wrote:
> On Mon, 2026-03-09 at 09:27 -0700, Josh Poimboeuf wrote:
> > On Mon, Mar 09, 2026 at 04:16:16PM +0000, Nuno Sá wrote:
> > > On Mon, 2026-03-09 at 09:03 -0700, Josh Poimboeuf wrote:
> > > > If 'pin' is not one of its expected values, the value of
> > > > 'int_out_ctrl_shift' is undefined.  With UBSAN enabled, this causes
> > > > Clang to generate undefined behavior, resulting in the following
> > > > warning:
> > > > 
> > > >   drivers/iio/imu/bmi160/bmi160_core.o: warning: objtool: bmi160_setup_irq() falls through to
> > > > next
> > > > function __cfi_bmi160_core_runtime_resume()
> > > > 
> > > > Prevent the UB and improve error handling by adding a BUG() if 'pin' has
> > > > an unexpected value.
> > > > 
> > > > Cc: Jonathan Cameron <jic23@kernel.org>
> > > > Cc: David Lechner <dlechner@baylibre.com>
> > > > CC: Nuno Sá <nuno.sa@analog.com>
> > > > Cc: Andy Shevchenko <andy@kernel.org>
> > > > Fixes: 895bf81e6bbf ("iio:bmi160: add drdy interrupt support")
> > > > Reported-by: Arnd Bergmann <arnd@arndb.de>
> > > > Closes: https://lore.kernel.org/a426d669-58bb-4be1-9eaa-6f3d83109e2d@app.fastmail.com
> > > > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> > > > ---
> > > >  drivers/iio/imu/bmi160/bmi160_core.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/iio/imu/bmi160/bmi160_core.c b/drivers/iio/imu/bmi160/bmi160_core.c
> > > > index 5f47708b4c5d..e5326df75e49 100644
> > > > --- a/drivers/iio/imu/bmi160/bmi160_core.c
> > > > +++ b/drivers/iio/imu/bmi160/bmi160_core.c
> > > > @@ -579,6 +579,8 @@ static int bmi160_config_pin(struct regmap *regmap, enum bmi160_int_pin
> > > > pin,
> > > >  		int_latch_mask = BMI160_INT2_LATCH_MASK;
> > > >  		int_map_mask = BMI160_INT2_MAP_DRDY_EN;
> > > >  		break;
> > > > +	default:
> > > > +		BUG();
> > > >  	}
> > > >  	int_out_ctrl_mask = BMI160_INT_OUT_CTRL_MASK << int_out_ctrl_shift;
> > > >  
> > > 
> > > AFAIK, BUG() is not something we should use lightly so I wonder why having it rather that a
> > > normal
> > > 'return -EINVAL'?
> > > 
> > > At the very least, it could be WARN but I still think that's too much for a device .probe(). Any
> > > special reason using BUG()?
> > 
> > Using BUG() for a default "invalid enum" is a common pattern, but indeed
> > returning an error would also be valid here.  I can change that to
> > return -EINVAL.
> > 
> > > Also seems like:
> > > 
> > > https://elixir.bootlin.com/linux/v7.0-rc2/source/drivers/iio/imu/bmi160/bmi160_core.c#L624
> > > 
> > > could be improved? Like setting 'pin_name' in the first switch() case.
> > 
> > Yeah, I assume you mean setting 'pin_name' to something like "invalid"
> > for the default case?
> 
> Nope, I meant not duplicating the switch() case. The default should return an error so I would say
> no need to bother in setting the name for that case.

Ah, you mean combining the switch() statements into one.  Ok, I'll do
that.

-- 
Josh

Re: [PATCH 3/3] iio: imu: bmi160: Remove potential undefined behavior in bmi160_config_pin()

[Andy Shevchenko]

On Mon, Mar 9, 2026 at 6:03 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> If 'pin' is not one of its expected values, the value of
> 'int_out_ctrl_shift' is undefined.  With UBSAN enabled, this causes
> Clang to generate undefined behavior, resulting in the following
> warning:
>
>   drivers/iio/imu/bmi160/bmi160_core.o: warning: objtool: bmi160_setup_irq() falls through to next function __cfi_bmi160_core_runtime_resume()
>
> Prevent the UB and improve error handling by adding a BUG() if 'pin' has
> an unexpected value.

> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> CC: Nuno Sá <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>

Please, reduce the noise in the commit message by moving Cc list to be
below the '---' line. This will have the same effect on email (Git
tools work fine) and if anybody needs this information it will be
preserved in lore.kernel.org archive. In case you have questions about
handling this locally, there is a subthread (patch 18) of this series:
https://lore.kernel.org/lkml/20260123113708.416727-19-bigeasy@linutronix.de/

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/3] iio: imu: bmi160: Remove potential undefined behavior in bmi160_config_pin()

[David Lechner]

On 3/9/26 11:40 AM, Andy Shevchenko wrote:
> On Mon, Mar 9, 2026 at 6:03 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>>
>> If 'pin' is not one of its expected values, the value of
>> 'int_out_ctrl_shift' is undefined.  With UBSAN enabled, this causes
>> Clang to generate undefined behavior, resulting in the following
>> warning:
>>
>>   drivers/iio/imu/bmi160/bmi160_core.o: warning: objtool: bmi160_setup_irq() falls through to next function __cfi_bmi160_core_runtime_resume()
>>
>> Prevent the UB and improve error handling by adding a BUG() if 'pin' has
>> an unexpected value.
> 
>> Cc: Jonathan Cameron <jic23@kernel.org>
>> Cc: David Lechner <dlechner@baylibre.com>
>> CC: Nuno Sá <nuno.sa@analog.com>
>> Cc: Andy Shevchenko <andy@kernel.org>
> 
> Please, reduce the noise in the commit message by moving Cc list to be
> below the '---' line. This will have the same effect on email (Git
> tools work fine) and if anybody needs this information it will be
> preserved in lore.kernel.org archive. In case you have questions about
> handling this locally, there is a subthread (patch 18) of this series:
> https://lore.kernel.org/lkml/20260123113708.416727-19-bigeasy@linutronix.de/
> 

And be sure to include the IIO mailing list too, not just the maintainers/
reviewers. Omitting it breaks some workflows.

Re: [PATCH 3/3] iio: imu: bmi160: Remove potential undefined behavior in bmi160_config_pin()

[Josh Poimboeuf]

On Mon, Mar 09, 2026 at 06:40:26PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 9, 2026 at 6:03 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > If 'pin' is not one of its expected values, the value of
> > 'int_out_ctrl_shift' is undefined.  With UBSAN enabled, this causes
> > Clang to generate undefined behavior, resulting in the following
> > warning:
> >
> >   drivers/iio/imu/bmi160/bmi160_core.o: warning: objtool: bmi160_setup_irq() falls through to next function __cfi_bmi160_core_runtime_resume()
> >
> > Prevent the UB and improve error handling by adding a BUG() if 'pin' has
> > an unexpected value.
> 
> > Cc: Jonathan Cameron <jic23@kernel.org>
> > Cc: David Lechner <dlechner@baylibre.com>
> > CC: Nuno Sá <nuno.sa@analog.com>
> > Cc: Andy Shevchenko <andy@kernel.org>
> 
> Please, reduce the noise in the commit message by moving Cc list to be
> below the '---' line. This will have the same effect on email (Git
> tools work fine) and if anybody needs this information it will be
> preserved in lore.kernel.org archive. In case you have questions about
> handling this locally, there is a subthread (patch 18) of this series:
> https://lore.kernel.org/lkml/20260123113708.416727-19-bigeasy@linutronix.de/

Will do, thanks.

-- 
Josh

Re: (subset) [PATCH 0/3] some objtool warnings fixes

[Mark Brown]

On Mon, 09 Mar 2026 09:03:04 -0700, Josh Poimboeuf wrote:
> Some fixes for objtool warnings reported by Arnd.
> 
> Josh Poimboeuf (3):
>   objtool: Fix Clang jump table detection
>   ASoC: codecs: wcd9335: Remove potential undefined behavior in
>     wcd9335_slimbus_irq()
>   iio: imu: bmi160: Remove potential undefined behavior in
>     bmi160_config_pin()
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[2/3] ASoC: codecs: wcd9335: Remove potential undefined behavior in wcd9335_slimbus_irq()
      commit: ed0313223ce6514dbd39c049e25f702980d7e3cc

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark