Re: [PATCH v5 08/10] iio: dac: mcp47feb02: refactor MCP47FEB02 I2C driver into two modules

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Renaming the visible Kconfig symbol breaks existing configurations by silently dropping the driver from user builds.
--

commit 528e4c3512ab81e838d441fdb1209303ed961a7f
Author: Ariana Lazar <ariana.lazar@microchip.com>

iio: dac: mcp47feb02: refactor MCP47FEB02 I2C driver into two modules

This patch prepares the MCP47FEB02 driver for bus-specific code by splitting
the existing implementation into separate core and I2C modules. It introduces a
new I2C-specific Kconfig option to support this separation.

> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index 657c68e75542e..cc10d43ffd1e8 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
[ ... ]
> @@ -550,8 +550,13 @@ config MCP4728
>  	  will be called mcp4728.
>  
>  config MCP47FEB02
> -	tristate "MCP47F(E/V)B01/02/04/08/11/12/14/18/21/22/24/28 DAC driver"
> +	tristate
> +
> +config MCP47FEB02_I2C
> +	tristate "MCP47F(E/V)B01/02/04/08/11/12/14/18/21/22/24/28 I2C DAC driver"

[Severity: Medium]
Does removing the prompt from CONFIG_MCP47FEB02 break existing configurations?

Users upgrading their kernels with an existing .config where
CONFIG_MCP47FEB02=y or m will silently lose support for this DAC. When they
run make oldconfig, the module will be dropped because the new visible symbol,
CONFIG_MCP47FEB02_I2C, defaults to 'n' and nothing automatically selects it.

Could a transition path be provided to prevent this regression, perhaps by
defaulting the new I2C driver to the value of the old configuration, or by
using a configuration scheme that automatically enables the I2C driver if the
old symbol was previously selected?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260909-mcp47feb02_refactor-v5-0-8b67bcab93d1@microchip.com?part=8