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] [day] [month] [year] [list]
Message-ID: <20250629182822.0d572b17@jic23-huawei>
Date: Sun, 29 Jun 2025 18:28:22 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Nuno Sá <nuno.sa@...log.com>, Andy Shevchenko
 <andy@...nel.org>, linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] iio: adc: ti-adc081c: drop use of model array

On Sat, 28 Jun 2025 11:47:53 -0500
David Lechner <dlechner@...libre.com> wrote:

> Change the ti-adc081c driver to use individual model structures instead
> of an array. This reduces the verbosity of the code. Also, the data is
> now const as it should have been in the first place.
> 
> Signed-off-by: David Lechner <dlechner@...libre.com>
> ---
>  drivers/iio/adc/ti-adc081c.c | 29 ++++++++++-------------------
>  1 file changed, 10 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/iio/adc/ti-adc081c.c b/drivers/iio/adc/ti-adc081c.c
> index 4f514db5c26ea803660087ae02b2cf8ec71911e4..c09f41e8867c45a44a98f4409946c3256d34280f 100644
> --- a/drivers/iio/adc/ti-adc081c.c
> +++ b/drivers/iio/adc/ti-adc081c.c
> @@ -112,18 +112,9 @@ DEFINE_ADCxx1C_CHANNELS(adc081c,  8);
>  DEFINE_ADCxx1C_CHANNELS(adc101c, 10);
>  DEFINE_ADCxx1C_CHANNELS(adc121c, 12);
>  
> -/* Model ids are indexes in _models array */
> -enum adcxx1c_model_id {
> -	ADC081C = 0,
> -	ADC101C = 1,
> -	ADC121C = 2,
> -};
> -
> -static struct adcxx1c_model adcxx1c_models[] = {
> -	ADCxx1C_MODEL(adc081c,  8),
> -	ADCxx1C_MODEL(adc101c, 10),
> -	ADCxx1C_MODEL(adc121c, 12),
> -};
> +static const struct adcxx1c_model adc081c_model = ADCxx1C_MODEL(adc081c,  8);
> +static const struct adcxx1c_model adc101c_model = ADCxx1C_MODEL(adc101c, 10);
> +static const struct adcxx1c_model adc121c_model = ADCxx1C_MODEL(adc121c, 12);

Is the macro actually worth while to just set two named elements?

static const struct adcxx1c_model adc081c_model = {
	.channels = adc081c_channels,
	.bits = 8,
};

static const struct adcxx1c_model adc101c_model = {
	.channels = adc101c_channels,
	.bits = 10,
};
etc are more readable to my eyes.


>  
>  static const struct iio_info adc081c_info = {
>  	.read_raw = adc081c_read_raw,
> @@ -203,24 +194,24 @@ static int adc081c_probe(struct i2c_client *client)
>  }
>  
>  static const struct i2c_device_id adc081c_id[] = {
> -	{ "adc081c", (kernel_ulong_t)&adcxx1c_models[ADC081C] },
> -	{ "adc101c", (kernel_ulong_t)&adcxx1c_models[ADC101C] },
> -	{ "adc121c", (kernel_ulong_t)&adcxx1c_models[ADC121C] },
> +	{ "adc081c", (kernel_ulong_t)&adc081c_model },
> +	{ "adc101c", (kernel_ulong_t)&adc101c_model },
> +	{ "adc121c", (kernel_ulong_t)&adc121c_model },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(i2c, adc081c_id);
>  
>  static const struct acpi_device_id adc081c_acpi_match[] = {
>  	/* Used on some AAEON boards */
> -	{ "ADC081C", (kernel_ulong_t)&adcxx1c_models[ADC081C] },
> +	{ "ADC081C", (kernel_ulong_t)&adc081c_model },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(acpi, adc081c_acpi_match);
>  
>  static const struct of_device_id adc081c_of_match[] = {
> -	{ .compatible = "ti,adc081c", .data = &adcxx1c_models[ADC081C] },
> -	{ .compatible = "ti,adc101c", .data = &adcxx1c_models[ADC101C] },
> -	{ .compatible = "ti,adc121c", .data = &adcxx1c_models[ADC121C] },
> +	{ .compatible = "ti,adc081c", .data = &adc081c_model },
> +	{ .compatible = "ti,adc101c", .data = &adc101c_model },
> +	{ .compatible = "ti,adc121c", .data = &adc121c_model },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, adc081c_of_match);
> 
> ---
> base-commit: 14071b9cf2d751ff9bc8b5e43fa94fbf08aceea1
> change-id: 20250628-iio-const-data-11-1c6b9e28aded
> 
> Best regards,


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ