[PATCH] soundwire: Correct ifdef for stub functions

[PATCH] soundwire: Correct ifdef for stub functions

[Charles Keepax]

Currently the stubs for SoundWire functions are enabled using
IS_ENABLED(). The trouble is if a driver intends to use the stubs
it by definition also does not depend on SOUNDWIRE. This means a
state can arise where SOUNDWIRE=m and DRIVER_CALLING_STUBS=y,
leading to a link time failure. Update the stubs to use
IS_REACHABLE such that the stubs will still be used in the
above situation.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202606151303.Erj5lfRD-lkp@intel.com/
Fixes: 6726b47a2a60 ("soundwire: Provide build stubs for common functions")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
---
 include/linux/soundwire/sdw.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
index 6147eb1fb210d..b96f0310da7c0 100644
--- a/include/linux/soundwire/sdw.h
+++ b/include/linux/soundwire/sdw.h
@@ -1077,7 +1077,7 @@ int sdw_bpt_send_async(struct sdw_bus *bus, struct sdw_slave *slave, struct sdw_
 int sdw_bpt_wait(struct sdw_bus *bus, struct sdw_slave *slave, struct sdw_bpt_msg *msg);
 int sdw_bpt_send_sync(struct sdw_bus *bus, struct sdw_slave *slave, struct sdw_bpt_msg *msg);
 
-#if IS_ENABLED(CONFIG_SOUNDWIRE)
+#if IS_REACHABLE(CONFIG_SOUNDWIRE)
 
 int sdw_stream_add_slave(struct sdw_slave *slave,
 			 struct sdw_stream_config *stream_config,
-- 
2.47.3

Re: [PATCH] soundwire: Correct ifdef for stub functions

[Charles Keepax]

On Mon, Jun 15, 2026 at 04:05:22PM +0100, Charles Keepax wrote:
> Currently the stubs for SoundWire functions are enabled using
> IS_ENABLED(). The trouble is if a driver intends to use the stubs
> it by definition also does not depend on SOUNDWIRE. This means a
> state can arise where SOUNDWIRE=m and DRIVER_CALLING_STUBS=y,
> leading to a link time failure. Update the stubs to use
> IS_REACHABLE such that the stubs will still be used in the
> above situation.

Feels like maybe I should have noted this can happen say for a
driver that has two control interfaces. For example the rt5682
(in the test robot report) has both an I2C and a SDW. If only the
I2C is selected but the driver calls stubbed functions from
common code. Typically these are gated in some way so they arn't
actually called in the non-soundwire case.

An alternative would be to add a dependency onto the driver to
ensure the two modules are compatible, but this felt like it
would cover more cases.

Thanks,
Charles

Re: [PATCH] soundwire: Correct ifdef for stub functions

[Charles Keepax]

On Mon, Jun 15, 2026 at 04:49:04PM +0100, Charles Keepax wrote:
> On Mon, Jun 15, 2026 at 04:05:22PM +0100, Charles Keepax wrote:
> > Currently the stubs for SoundWire functions are enabled using
> > IS_ENABLED(). The trouble is if a driver intends to use the stubs
> > it by definition also does not depend on SOUNDWIRE. This means a
> > state can arise where SOUNDWIRE=m and DRIVER_CALLING_STUBS=y,
> > leading to a link time failure. Update the stubs to use
> > IS_REACHABLE such that the stubs will still be used in the
> > above situation.
> 
> Feels like maybe I should have noted this can happen say for a
> driver that has two control interfaces. For example the rt5682
> (in the test robot report) has both an I2C and a SDW. If only the
> I2C is selected but the driver calls stubbed functions from
> common code. Typically these are gated in some way so they arn't
> actually called in the non-soundwire case.
> 
> An alternative would be to add a dependency onto the driver to
> ensure the two modules are compatible, but this felt like it
> would cover more cases.

Having this weight on my mind for a few days, think I am going to
switch to just adding the dependencies on the affected drivers.
So please disregard this patch.

Thanks,
Charles