[PATCH 0/2] iio: magn: mmc5633: Fix two build issues

[PATCH 0/2] iio: magn: mmc5633: Fix two build issues

[Jonathan Cameron]

From: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The Kconfig  issue was one I came across whilst testing the second fix
which has been being reported by the bots for some time. Frank posted the
full fix for the undefined symbols a while back, but it is merged in
the middle i3c/for-next making it hard to merge into IIO as well.
So work around this to get the build issue resolved.

That workaround can be reverted next cycle.

I'll queue these up now but they can have brief 0-day exposure
before I push them out on the togreg branch to be picked up by
linux-next. Even after that comments on these ones welcome.

Thanks,

Jonathan


Jonathan Cameron (2):
  iio: magn: mmc5633: Ensure REGMAP_I2C / I3C not build if I2C / I3C is
    not.
  iio: magn: mmc5633: Add some ifdef / __maybe_unused until stubs
    available

 drivers/iio/magnetometer/Kconfig   |  4 ++--
 drivers/iio/magnetometer/mmc5633.c | 25 +++++++++++++++++++++----
 2 files changed, 23 insertions(+), 6 deletions(-)

-- 
2.52.0

[PATCH 1/2] iio: magn: mmc5633: Ensure REGMAP_I2C / I3C not build if I2C / I3C is not.

[Jonathan Cameron]

From: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Fixes the following build warning (and equivalent I2C one)
WARNING: unmet direct dependencies detected for REGMAP_I3C
  Depends on [n]: I3C [=n]
  Selected by [m]:
  - MMC5633 [=m] && IIO [=y] && (I2C [=y] || I3C [=n])

Fixes: 6e5f6bf2e3f0 ("iio: magnetometer: Add mmc5633 sensor")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/iio/magnetometer/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index cfb74a4a0836..2b81b22c9550 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -141,8 +141,8 @@ config MMC35240
 
 config MMC5633
 	tristate "MEMSIC MMC5633 3-axis magnetic sensor"
-	select REGMAP_I2C
-	select REGMAP_I3C
+	select REGMAP_I2C if I2C
+	select REGMAP_I3C if I3C
 	depends on I2C || I3C
 	help
 	  Say yes here to build support for the MEMSIC MMC5633 3-axis
-- 
2.52.0

[PATCH 2/2] iio: magn: mmc5633: Add some ifdef / __maybe_unused until stubs available

[Jonathan Cameron]

From: Jonathan Cameron <Jonathan.Cameron@huawei.com>

The I3C tree has Frank Li's fix for the case of I3C not being built
https://lore.kernel.org/all/20251230145718.4088694-1-Frank.Li@nxp.com/
Given those will only be available upstream at the next merge window
and the ordering of merge of I3C vs IIO is uncertain, apply some temporary
stubs in the driver to avoid build issues.

This can be reverted next cycle.

Fixes: 6e5f6bf2e3f0 ("iio: magnetometer: Add mmc5633 sensor")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202512280443.lOhY75Df-lkp@intel.com/
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/iio/magnetometer/mmc5633.c | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/magnetometer/mmc5633.c b/drivers/iio/magnetometer/mmc5633.c
index 9d8e27486963..37f46fe5e9e4 100644
--- a/drivers/iio/magnetometer/mmc5633.c
+++ b/drivers/iio/magnetometer/mmc5633.c
@@ -190,32 +190,37 @@ static bool mmc5633_is_support_hdr(struct mmc5633_data *data)
 	if (!data->i3cdev)
 		return false;
 
+#ifdef CONFIG_I3C
 	return i3c_device_get_supported_xfer_mode(data->i3cdev) & BIT(I3C_HDR_DDR);
+#else
+	return false;
+#endif
 }
 
 static int mmc5633_read_measurement(struct mmc5633_data *data, int address, void *buf, size_t sz)
 {
 	struct device *dev = regmap_get_device(data->regmap);
 	u8 data_cmd[2], status[2];
-	unsigned int val, ready;
+	unsigned int val;
+	unsigned int ready __maybe_unused;
 	int ret;
 
 	if (mmc5633_is_support_hdr(data)) {
-		struct i3c_xfer xfers_wr_cmd[] = {
+		struct i3c_xfer xfers_wr_cmd[] __maybe_unused = {
 			{
 				.cmd = 0x3b,
 				.len = 2,
 				.data.out = data_cmd,
 			}
 		};
-		struct i3c_xfer xfers_rd_sta_cmd[] = {
+		struct i3c_xfer xfers_rd_sta_cmd[] __maybe_unused = {
 			{
 				.cmd = 0x23 | BIT(7), /* RDSTA CMD */
 				.len = 2,
 				.data.in = status,
 			},
 		};
-		struct i3c_xfer xfers_rd_data_cmd[] = {
+		struct i3c_xfer xfers_rd_data_cmd[] __maybe_unused = {
 			{
 				.cmd = 0x22 | BIT(7), /* RDLONG CMD */
 				.len = sz,
@@ -227,19 +232,27 @@ static int mmc5633_read_measurement(struct mmc5633_data *data, int address, void
 		data_cmd[1] = (address == MMC5633_TEMPERATURE) ?
 			      MMC5633_HDR_CTRL0_MEAS_T : MMC5633_HDR_CTRL0_MEAS_M;
 
+#ifdef CONFIG_I3C
 		ret = i3c_device_do_xfers(data->i3cdev, xfers_wr_cmd,
 					  ARRAY_SIZE(xfers_wr_cmd), I3C_HDR_DDR);
+#else
+		return -EOPNOTSUPP;
+#endif
 		if (ret < 0)
 			return ret;
 
 		ready = (address == MMC5633_TEMPERATURE) ?
 			MMC5633_STATUS1_MEAS_T_DONE_BIT : MMC5633_STATUS1_MEAS_M_DONE_BIT;
+#ifdef CONFIG_I3C
 		ret = read_poll_timeout(i3c_device_do_xfers, val,
 					val || (status[0] & ready),
 					10 * USEC_PER_MSEC,
 					100 * 10 * USEC_PER_MSEC, 0,
 					data->i3cdev, xfers_rd_sta_cmd,
 					ARRAY_SIZE(xfers_rd_sta_cmd), I3C_HDR_DDR);
+#else
+		ret = -EOPNOTSUPP;
+#endif
 		if (ret) {
 			dev_err(dev, "data not ready\n");
 			return ret;
@@ -248,8 +261,12 @@ static int mmc5633_read_measurement(struct mmc5633_data *data, int address, void
 			dev_err(dev, "i3c transfer error\n");
 			return val;
 		}
+#ifdef CONFIG_I3C
 		return i3c_device_do_xfers(data->i3cdev, xfers_rd_data_cmd,
 					   ARRAY_SIZE(xfers_rd_data_cmd), I3C_HDR_DDR);
+#else
+		return -EOPNOTSUPP;
+#endif
 	}
 
 	/* Fallback to use SDR/I2C mode */
-- 
2.52.0

Re: [PATCH 0/2] iio: magn: mmc5633: Fix two build issues

[Frank Li]

On Mon, Jan 19, 2026 at 10:17:34PM +0000, Jonathan Cameron wrote:
> From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
> The Kconfig  issue was one I came across whilst testing the second fix
> which has been being reported by the bots for some time. Frank posted the
> full fix for the undefined symbols a while back, but it is merged in
> the middle i3c/for-next making it hard to merge into IIO as well.
> So work around this to get the build issue resolved.
>
> That workaround can be reverted next cycle.
>
> I'll queue these up now but they can have brief 0-day exposure
> before I push them out on the togreg branch to be picked up by
> linux-next. Even after that comments on these ones welcome.
>
> Thanks,
>
> Jonathan
>

Reviewed-by: Frank Li <Frank.Li@nxp.com>

>
> Jonathan Cameron (2):
>   iio: magn: mmc5633: Ensure REGMAP_I2C / I3C not build if I2C / I3C is
>     not.
>   iio: magn: mmc5633: Add some ifdef / __maybe_unused until stubs
>     available
>
>  drivers/iio/magnetometer/Kconfig   |  4 ++--
>  drivers/iio/magnetometer/mmc5633.c | 25 +++++++++++++++++++++----
>  2 files changed, 23 insertions(+), 6 deletions(-)
>
> --
> 2.52.0
>

Re: [PATCH 2/2] iio: magn: mmc5633: Add some ifdef / __maybe_unused until stubs available

[Andy Shevchenko]

On Mon, Jan 19, 2026 at 10:17:36PM +0000, Jonathan Cameron wrote:

> The I3C tree has Frank Li's fix for the case of I3C not being built

> https://lore.kernel.org/all/20251230145718.4088694-1-Frank.Li@nxp.com/

Make it a Link tag

> Given those will only be available upstream at the next merge window
> and the ordering of merge of I3C vs IIO is uncertain, apply some temporary
> stubs in the driver to avoid build issues.
> 
> This can be reverted next cycle.

Link: ... [1]

> Fixes: 6e5f6bf2e3f0 ("iio: magnetometer: Add mmc5633 sensor")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202512280443.lOhY75Df-lkp@intel.com/
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

...

>  static int mmc5633_read_measurement(struct mmc5633_data *data, int address, void *buf, size_t sz)
>  {
>  	struct device *dev = regmap_get_device(data->regmap);
>  	u8 data_cmd[2], status[2];
> -	unsigned int val, ready;
> +	unsigned int val;
> +	unsigned int ready __maybe_unused;
>  	int ret;

Reversed xmas tree ordering?

...

> +#ifdef CONFIG_I3C
>  		ret = i3c_device_do_xfers(data->i3cdev, xfers_wr_cmd,
>  					  ARRAY_SIZE(xfers_wr_cmd), I3C_HDR_DDR);
> +#else

> +		return -EOPNOTSUPP;

I would do one point of return, id est

		ret = -EOPNOTSUPP;

> +#endif
>  		if (ret < 0)
>  			return ret;

...

> +#ifdef CONFIG_I3C
>  		ret = read_poll_timeout(i3c_device_do_xfers, val,
>  					val || (status[0] & ready),
>  					10 * USEC_PER_MSEC,
>  					100 * 10 * USEC_PER_MSEC, 0,
>  					data->i3cdev, xfers_rd_sta_cmd,
>  					ARRAY_SIZE(xfers_rd_sta_cmd), I3C_HDR_DDR);
> +#else
> +		ret = -EOPNOTSUPP;
> +#endif
>  		if (ret) {
>  			dev_err(dev, "data not ready\n");
>  			return ret;
>  		}

Ditto.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/2] iio: magn: mmc5633: Ensure REGMAP_I2C / I3C not build if I2C / I3C is not.

[Andy Shevchenko]

On Mon, Jan 19, 2026 at 10:17:35PM +0000, Jonathan Cameron wrote:

> Fixes the following build warning (and equivalent I2C one)
> WARNING: unmet direct dependencies detected for REGMAP_I3C
>   Depends on [n]: I3C [=n]
>   Selected by [m]:
>   - MMC5633 [=m] && IIO [=y] && (I2C [=y] || I3C [=n])

Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/2] iio: magn: mmc5633: Add some ifdef / __maybe_unused until stubs available

[Jonathan Cameron]

On Tue, 20 Jan 2026 09:23:04 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Mon, Jan 19, 2026 at 10:17:36PM +0000, Jonathan Cameron wrote:
> 
> > The I3C tree has Frank Li's fix for the case of I3C not being built  
> 
> > https://lore.kernel.org/all/20251230145718.4088694-1-Frank.Li@nxp.com/  
> 
> Make it a Link tag
> 
> > Given those will only be available upstream at the next merge window
> > and the ordering of merge of I3C vs IIO is uncertain, apply some temporary
> > stubs in the driver to avoid build issues.
> > 
> > This can be reverted next cycle.  
> 
> Link: ... [1]
> 
> > Fixes: 6e5f6bf2e3f0 ("iio: magnetometer: Add mmc5633 sensor")
> > Reported-by: kernel test robot <lkp@intel.com>
> > Closes: https://lore.kernel.org/oe-kbuild-all/202512280443.lOhY75Df-lkp@intel.com/
> > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>  
> 
> ...
> 
> >  static int mmc5633_read_measurement(struct mmc5633_data *data, int address, void *buf, size_t sz)
> >  {
> >  	struct device *dev = regmap_get_device(data->regmap);
> >  	u8 data_cmd[2], status[2];
> > -	unsigned int val, ready;
> > +	unsigned int val;
> > +	unsigned int ready __maybe_unused;
> >  	int ret;  
> 
> Reversed xmas tree ordering?

I'm reverting this in a couple of weeks and want to keep things
as tightly organized as possible.  I swapped val and ready but
no more than that.

> 
> ...
> 
> > +#ifdef CONFIG_I3C
> >  		ret = i3c_device_do_xfers(data->i3cdev, xfers_wr_cmd,
> >  					  ARRAY_SIZE(xfers_wr_cmd), I3C_HDR_DDR);
> > +#else  
> 
> > +		return -EOPNOTSUPP;  
> 
> I would do one point of return, id est
> 
> 		ret = -EOPNOTSUPP;
> 
> > +#endif
> >  		if (ret < 0)
> >  			return ret;  
Ok for this one.
> 
> ...
> 
> > +#ifdef CONFIG_I3C
> >  		ret = read_poll_timeout(i3c_device_do_xfers, val,
> >  					val || (status[0] & ready),
> >  					10 * USEC_PER_MSEC,
> >  					100 * 10 * USEC_PER_MSEC, 0,
> >  					data->i3cdev, xfers_rd_sta_cmd,
> >  					ARRAY_SIZE(xfers_rd_sta_cmd), I3C_HDR_DDR);
> > +#else
> > +		ret = -EOPNOTSUPP;
> > +#endif
> >  		if (ret) {
> >  			dev_err(dev, "data not ready\n");
> >  			return ret;
> >  		}  
> 
> Ditto.
I'm confused this one already does one point of return.

The final one (which was in the cropped bit) I'm leaving alone as
it would be more churn.

J
> 

Re: [PATCH 2/2] iio: magn: mmc5633: Add some ifdef / __maybe_unused until stubs available

[Jonathan Cameron]

On Tue, 20 Jan 2026 21:56:27 +0000
Jonathan Cameron <jic23@kernel.org> wrote:

> On Tue, 20 Jan 2026 09:23:04 +0200
> Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> 
> > On Mon, Jan 19, 2026 at 10:17:36PM +0000, Jonathan Cameron wrote:
> >   
> > > The I3C tree has Frank Li's fix for the case of I3C not being built    
> >   
> > > https://lore.kernel.org/all/20251230145718.4088694-1-Frank.Li@nxp.com/    
> > 
> > Make it a Link tag
> >   
> > > Given those will only be available upstream at the next merge window
> > > and the ordering of merge of I3C vs IIO is uncertain, apply some temporary
> > > stubs in the driver to avoid build issues.
> > > 
> > > This can be reverted next cycle.    
> > 
> > Link: ... [1]
> >   
> > > Fixes: 6e5f6bf2e3f0 ("iio: magnetometer: Add mmc5633 sensor")
> > > Reported-by: kernel test robot <lkp@intel.com>
> > > Closes: https://lore.kernel.org/oe-kbuild-all/202512280443.lOhY75Df-lkp@intel.com/
> > > Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>    
> > 
> > ...
> >   
> > >  static int mmc5633_read_measurement(struct mmc5633_data *data, int address, void *buf, size_t sz)
> > >  {
> > >  	struct device *dev = regmap_get_device(data->regmap);
> > >  	u8 data_cmd[2], status[2];
> > > -	unsigned int val, ready;
> > > +	unsigned int val;
> > > +	unsigned int ready __maybe_unused;
> > >  	int ret;    
> > 
> > Reversed xmas tree ordering?  
> 
> I'm reverting this in a couple of weeks and want to keep things
> as tightly organized as possible.  I swapped val and ready but
> no more than that.
> 
> > 
> > ...
> >   
> > > +#ifdef CONFIG_I3C
> > >  		ret = i3c_device_do_xfers(data->i3cdev, xfers_wr_cmd,
> > >  					  ARRAY_SIZE(xfers_wr_cmd), I3C_HDR_DDR);
> > > +#else    
> >   
> > > +		return -EOPNOTSUPP;    
> > 
> > I would do one point of return, id est
> > 
> > 		ret = -EOPNOTSUPP;
> >   
> > > +#endif
> > >  		if (ret < 0)
> > >  			return ret;    
> Ok for this one.
Or not.  Amazingly enough if I touch this the compiler suddenly decides
val is not initialised.

drivers/iio/magnetometer/mmc5633.c:260:7: warning: variable 'val' is uninitialized when used here [-Wuninitialized]
  260 |                 if (val) {
      |                     ^~~
drivers/iio/magnetometer/mmc5633.c:205:18: note: initialize the variable 'val' to silence this warning
  205 |         unsigned int val;
      |                         ^
      |             

 Why does that happen?  Answers on a post card, but I need 'a fix' in place
for this. Given I plan to revert it shortly anyway, I'll play a little fast
and lose this time!

> > 
> > ...
> >   
> > > +#ifdef CONFIG_I3C
> > >  		ret = read_poll_timeout(i3c_device_do_xfers, val,
> > >  					val || (status[0] & ready),
> > >  					10 * USEC_PER_MSEC,
> > >  					100 * 10 * USEC_PER_MSEC, 0,
> > >  					data->i3cdev, xfers_rd_sta_cmd,
> > >  					ARRAY_SIZE(xfers_rd_sta_cmd), I3C_HDR_DDR);
> > > +#else
> > > +		ret = -EOPNOTSUPP;
> > > +#endif
> > >  		if (ret) {
> > >  			dev_err(dev, "data not ready\n");
> > >  			return ret;
> > >  		}    
> > 
> > Ditto.  
> I'm confused this one already does one point of return.
> 
> The final one (which was in the cropped bit) I'm leaving alone as
> it would be more churn.
> 
> J
> >   
> 

Re: [PATCH 2/2] iio: magn: mmc5633: Add some ifdef / __maybe_unused until stubs available

[Jonathan Cameron]

On Tue, 20 Jan 2026 22:03:28 +0000
Jonathan Cameron <jic23@kernel.org> wrote:

> On Tue, 20 Jan 2026 21:56:27 +0000
> Jonathan Cameron <jic23@kernel.org> wrote:
> 
> > On Tue, 20 Jan 2026 09:23:04 +0200
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> >   
> > > On Mon, Jan 19, 2026 at 10:17:36PM +0000, Jonathan Cameron wrote:
> > >     
> > > > The I3C tree has Frank Li's fix for the case of I3C not being built      
> > >     
> > > > https://lore.kernel.org/all/20251230145718.4088694-1-Frank.Li@nxp.com/      
> > > 
> > > Make it a Link tag
> > >     
> > > > Given those will only be available upstream at the next merge window
> > > > and the ordering of merge of I3C vs IIO is uncertain, apply some temporary
> > > > stubs in the driver to avoid build issues.
> > > > 
> > > > This can be reverted next cycle.      
Dropped this patch in favour of the immutable branch Alexandre pushed out.

Much nicer than this hack.

Jonathan

Re: [PATCH 1/2] iio: magn: mmc5633: Ensure REGMAP_I2C / I3C not build if I2C / I3C is not.

[Jonathan Cameron]

On Tue, 20 Jan 2026 09:23:35 +0200
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:

> On Mon, Jan 19, 2026 at 10:17:35PM +0000, Jonathan Cameron wrote:
> 
> > Fixes the following build warning (and equivalent I2C one)
> > WARNING: unmet direct dependencies detected for REGMAP_I3C
> >   Depends on [n]: I3C [=n]
> >   Selected by [m]:
> >   - MMC5633 [=m] && IIO [=y] && (I2C [=y] || I3C [=n])  
> 
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> 

Unfotunately this isn't sufficient because we get issues
if MMC5633 is built in and I3C is a module.

Not sure why the didn't turn up in 0-day tests until this hit next
(and due to some forgetfulness that was rather late).

Seems this is a common problem as there are some unusual constructs
in tree. I'm going to switch this to

depends on I2C
select REGMAP_I2C
select REGMAP_I3C if I3C
depends on I3C || !I3C

Similar to Guenter did for:
83b645ee43f7 ("hwmon: tmp108: fix I3C dependency)

It is ugly but I'm going to do this as a fix on top of the current tree
as I don't want to rebase just before sending out the pull request.

Jonathan