linux-kernel - Re: [PATCH 2/2] iio: mxs-lradc: add ADC channel 9 as a copy of channel 8

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]

Date:	Wed, 11 Jun 2014 00:51:34 +0200
From:	Marek Vasut <marex@...x.de>
To:	Robert Hodaszi <robert.hodaszi@...i.com>
Cc:	jic23@...nel.org, linux-iio@...r.kernel.org,
	linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
	alexandre.belloni@...e-electrons.com, jbe@...gutronix.de,
	hector.palacios@...i.com, fabio.estevam@...escale.com,
	lars@...afoo.de
Subject: Re: [PATCH 2/2] iio: mxs-lradc: add ADC channel 9 as a copy of channel 8

On Tuesday, June 10, 2014 at 03:41:35 PM, Robert Hodaszi wrote:
> Commit c8231a9af8147f8a401fc55931ec44abfb937660 ("iio: mxs-lradc: compute
> temperature from channel 8 and 9") merged channel 8 and channel 9 to create
> an IIO_TEMP channel. It changed the number of LRADC channels, which could
> cause incompatibility with previous device-tree declarations, and also
> makes it illogical (e.g. channel 15 is <&lradc 14>).
> 
> Add channel 9 as a copy of channel 8. Reading channel 9 has the same output
> as reading channel 8.
> 
> Signed-off-by: Robert Hodaszi <robert.hodaszi@...i.com>
> ---

[...]

>  static const struct iio_chan_spec mxs_lradc_chan_spec[] = {
> -	MXS_ADC_CHAN(0, IIO_VOLTAGE),
> -	MXS_ADC_CHAN(1, IIO_VOLTAGE),
> -	MXS_ADC_CHAN(2, IIO_VOLTAGE),
> -	MXS_ADC_CHAN(3, IIO_VOLTAGE),
> -	MXS_ADC_CHAN(4, IIO_VOLTAGE),
> -	MXS_ADC_CHAN(5, IIO_VOLTAGE),
> -	MXS_ADC_CHAN(6, IIO_VOLTAGE),
> -	MXS_ADC_CHAN(7, IIO_VOLTAGE),	/* VBATT */
> +	MXS_ADC_VOLTAGE_CHAN(0),
> +	MXS_ADC_VOLTAGE_CHAN(1),
> +	MXS_ADC_VOLTAGE_CHAN(2),
> +	MXS_ADC_VOLTAGE_CHAN(3),
> +	MXS_ADC_VOLTAGE_CHAN(4),
> +	MXS_ADC_VOLTAGE_CHAN(5),
> +	MXS_ADC_VOLTAGE_CHAN(6),
> +	MXS_ADC_VOLTAGE_CHAN(7),	/* VBATT */
>  	/* Combined Temperature sensors */
> -	{
> -		.type = IIO_TEMP,
> -		.indexed = 1,
> -		.scan_index = 8,
> -		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> -				      BIT(IIO_CHAN_INFO_OFFSET) |
> -				      BIT(IIO_CHAN_INFO_SCALE),
> -		.channel = 8,
> -		.scan_type = {.sign = 'u', .realbits = 18, .storagebits = 32,},
> -	},

I wonder, shouldn't the IIO framework handle this kind of a "hole" in the 
iio_chan_spec structure, where one entry has .channel = N and the subsequent one 
has .channel = N + 2 somehow ?

> -	MXS_ADC_CHAN(10, IIO_VOLTAGE),	/* VDDIO */
> -	MXS_ADC_CHAN(11, IIO_VOLTAGE),	/* VTH */
> -	MXS_ADC_CHAN(12, IIO_VOLTAGE),	/* VDDA */
> -	MXS_ADC_CHAN(13, IIO_VOLTAGE),	/* VDDD */
> -	MXS_ADC_CHAN(14, IIO_VOLTAGE),	/* VBG */
> -	MXS_ADC_CHAN(15, IIO_VOLTAGE),	/* VDD5V */

[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/