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: <20240727133352.549f48df@jic23-huawei>
Date: Sat, 27 Jul 2024 13:33:52 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Antoniu Miclaus <antoniu.miclaus@...log.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich
 <Michael.Hennerich@...log.com>, Rob Herring <robh@...nel.org>, "Krzysztof
 Kozlowski" <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 "Dragos Bogdan" <dragos.bogdan@...log.com>, <linux-iio@...r.kernel.org>,
 <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] iio: frequency: adf4377: add adf4378 support

On Mon, 22 Jul 2024 16:45:06 +0300
Antoniu Miclaus <antoniu.miclaus@...log.com> wrote:

> Add separate handling for adf4378 within the driver.
> 
> The main difference between adf4377 and adf4378 is that adf4378 has only
> one output which is handled by only one gpio.
> 
> Signed-off-by: Antoniu Miclaus <antoniu.miclaus@...log.com>

Follow up comments on the v2 changes inline.

For future series, please always use a cover letter 
--cover-letter in git format-patch as it provides somewhere for general
comments and gives the series a nice name etc in patchwork.

Jonathan

> ---
> changes in v2:
>  - use chip_info structure to handle new added part (adf4378)
>  - use spi_get_device_match_data
>  - drop redundant check in if statement.
>  drivers/iio/frequency/adf4377.c | 36 ++++++++++++++++++++++++++-------
>  1 file changed, 29 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/frequency/adf4377.c b/drivers/iio/frequency/adf4377.c
> index 9284c13f1abb..82374f5d2695 100644
> --- a/drivers/iio/frequency/adf4377.c
> +++ b/drivers/iio/frequency/adf4377.c
> @@ -400,7 +400,13 @@ enum muxout_select_mode {
>  	ADF4377_MUXOUT_HIGH = 0x8,
>  };
>  
> +struct adf4377_chip_info {
> +	const char *name;
> +	bool has_gpio_enclk2;
> +};
> +
>  struct adf4377_state {
> +	const struct adf4377_chip_info	*chip_info;
>  	struct spi_device	*spi;
>  	struct regmap		*regmap;
>  	struct clk		*clkin;
> @@ -889,11 +895,13 @@ static int adf4377_properties_parse(struct adf4377_state *st)
>  		return dev_err_probe(&spi->dev, PTR_ERR(st->gpio_enclk1),
>  				     "failed to get the CE GPIO\n");
>  
> -	st->gpio_enclk2 = devm_gpiod_get_optional(&st->spi->dev, "clk2-enable",
> -						  GPIOD_OUT_LOW);
> -	if (IS_ERR(st->gpio_enclk2))
> -		return dev_err_probe(&spi->dev, PTR_ERR(st->gpio_enclk2),
> -				     "failed to get the CE GPIO\n");
> +	if (st->chip_info->has_gpio_enclk2) {
> +		st->gpio_enclk2 = devm_gpiod_get_optional(&st->spi->dev, "clk2-enable",
> +							  GPIOD_OUT_LOW);
> +		if (IS_ERR(st->gpio_enclk2))
> +			return dev_err_probe(&spi->dev, PTR_ERR(st->gpio_enclk2),
> +					"failed to get the CE GPIO\n");
> +	}
>  
>  	ret = device_property_match_property_string(&spi->dev, "adi,muxout-select",
>  						    adf4377_muxout_modes,
> @@ -921,6 +929,17 @@ static int adf4377_freq_change(struct notifier_block *nb, unsigned long action,
>  	return NOTIFY_OK;
>  }
>  
> +static const struct adf4377_chip_info adf4377_chip_info_tbl[] = {
See below on why an array is not useful here.

> +	{
> +		.name = "adf4377",
> +		.has_gpio_enclk2 = true,
> +	},
> +	{
> +		.name = "adf4378",
> +		.has_gpio_enclk2 = false,
> +	},
> +};
> +
>  static int adf4377_probe(struct spi_device *spi)
>  {
>  	struct iio_dev *indio_dev;
> @@ -945,6 +964,7 @@ static int adf4377_probe(struct spi_device *spi)
>  
>  	st->regmap = regmap;
>  	st->spi = spi;
> +	st->chip_info = spi_get_device_match_data(spi);
>  	mutex_init(&st->lock);
>  
>  	ret = adf4377_properties_parse(st);
> @@ -964,13 +984,15 @@ static int adf4377_probe(struct spi_device *spi)
>  }
>  
>  static const struct spi_device_id adf4377_id[] = {
> -	{ "adf4377", 0 },
> +	{ "adf4377", (kernel_ulong_t)&adf4377_chip_info_tbl[0] },
> +	{ "adf4378", (kernel_ulong_t)&adf4377_chip_info_tbl[1] },
>  	{}
>  };
>  MODULE_DEVICE_TABLE(spi, adf4377_id);
>  
>  static const struct of_device_id adf4377_of_match[] = {
> -	{ .compatible = "adi,adf4377" },
> +	{ .compatible = "adi,adf4377", .data = &adf4377_chip_info_tbl[0] },
> +	{ .compatible = "adi,adf4378", .data = &adf4377_chip_info_tbl[1]},
We've been moving away from this use of an array because it means you then need
an enum to say which is which.  Better to just have two named structures
as then it's obvious which one is which.

adf4377_chip_info and adf4378_chip_info

>  	{}
>  };
>  MODULE_DEVICE_TABLE(of, adf4377_of_match);


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ