lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250723095125.GR11056@google.com>
Date: Wed, 23 Jul 2025 10:51:25 +0100
From: Lee Jones <lee@...nel.org>
To: Alex Elder <elder@...cstar.com>
Cc: lgirdwood@...il.com, broonie@...nel.org, alexandre.belloni@...tlin.com,
	robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
	mat.jonczyk@...pl, dlan@...too.org, paul.walmsley@...ive.com,
	palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr,
	troymitchell988@...il.com, guodong@...cstar.com,
	linux-rtc@...r.kernel.org, devicetree@...r.kernel.org,
	linux-riscv@...ts.infradead.org, spacemit@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 2/8] mfd: simple-mfd-i2c: specify max_register

On Thu, 10 Jul 2025, Alex Elder wrote:

> All devices supported by simple MFD use the same 8-bit register 8-bit
> value regmap configuration.  There is an option available for a device
> to specify a custom configuration, but no existing device uses it.
> 
> Rather than specify a "full" regmap configuration to change only
> the max_register value, Lee Jones suggested allowing max_register
> to be specified in the simple_mfd_data structure.  If regmap_config
> and max_register are both supplied, the max_register field is ignored.
> 
> Signed-off-by: Alex Elder <elder@...cstar.com>
> Suggested-by: Lee Jones <lee@...nel.org>
> ---
> v8: - Use regmap_config_8r_8v, modifying it if max_register supplied
> 
>  drivers/mfd/simple-mfd-i2c.c | 8 ++++++--
>  drivers/mfd/simple-mfd-i2c.h | 3 ++-
>  2 files changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mfd/simple-mfd-i2c.c b/drivers/mfd/simple-mfd-i2c.c
> index 22159913bea03..5138aa72140b5 100644
> --- a/drivers/mfd/simple-mfd-i2c.c
> +++ b/drivers/mfd/simple-mfd-i2c.c
> @@ -24,15 +24,16 @@
>  
>  #include "simple-mfd-i2c.h"
>  
> -static const struct regmap_config regmap_config_8r_8v = {
> +static struct regmap_config regmap_config_8r_8v = {
>  	.reg_bits = 8,
>  	.val_bits = 8,
> +	/* .max_register can be specified in simple_mfd_data */

Drop this comment please.

>  };
>  
>  static int simple_mfd_i2c_probe(struct i2c_client *i2c)
>  {
>  	const struct simple_mfd_data *simple_mfd_data;
> -	const struct regmap_config *regmap_config;
> +	struct regmap_config *regmap_config;
>  	struct regmap *regmap;
>  	int ret;
>  
> @@ -43,8 +44,11 @@ static int simple_mfd_i2c_probe(struct i2c_client *i2c)
>  		regmap_config = &regmap_config_8r_8v;
>  	else
>  		regmap_config = simple_mfd_data->regmap_config;
> +	if (simple_mfd_data && !simple_mfd_data->regmap_config)
> +		regmap_config->max_register = simple_mfd_data->max_register;

If max_register is set in simple_mfd_data, it should take precedence.

if (simple_mfd_data && simple_mfd_data->max_register)
	regmap_config->max_register = simple_mfd_data->max_register;

>  	regmap = devm_regmap_init_i2c(i2c, regmap_config);
> +	regmap_config->max_register = 0;

Does max_register definitely have persistence over subsequent calls?

>  	if (IS_ERR(regmap))
>  		return PTR_ERR(regmap);
>  
> diff --git a/drivers/mfd/simple-mfd-i2c.h b/drivers/mfd/simple-mfd-i2c.h
> index 7cb2bdd347d97..ea2a96af8bce4 100644
> --- a/drivers/mfd/simple-mfd-i2c.h
> +++ b/drivers/mfd/simple-mfd-i2c.h
> @@ -24,7 +24,8 @@
>  #include <linux/regmap.h>
>  
>  struct simple_mfd_data {
> -	const struct regmap_config *regmap_config;
> +	struct regmap_config *regmap_config;
> +	unsigned int max_register;	/* Ignored if regmap_config supplied */
>  	const struct mfd_cell *mfd_cell;
>  	size_t mfd_cell_size;
>  };
> -- 
> 2.45.2
> 

-- 
Lee Jones [李琼斯]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ