From: Jonathan Cameron <jic23@cam.ac.uk>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: linux-iio@vger.kernel.org, Michael.Hennerich@analog.com,
Robin.Getz@analog.com, manuel.stahl@iis.fraunhofer.de
Subject: Re: [PATCH 5/6] staging:iio:adis16300 merge into adis16350 driver
Date: Sat, 18 Sep 2010 17:06:36 +0100 [thread overview]
Message-ID: <4C94E38C.7040007@cam.ac.uk> (raw)
In-Reply-To: <1284217100-2469-6-git-send-email-jic23@cam.ac.uk>
...
> +static struct attribute *adis16300_attributes[] = {
> + &iio_dev_attr_gyro_x_calibbias.dev_attr.attr,
> + &iio_dev_attr_accel_x_calibbias.dev_attr.attr,
> + &iio_dev_attr_accel_y_calibbias.dev_attr.attr,
> + &iio_dev_attr_accel_z_calibbias.dev_attr.attr,
> + &iio_dev_attr_in_supply_raw.dev_attr.attr,
> + &iio_const_attr_in_supply_scale.dev_attr.attr,
> + &iio_dev_attr_gyro_z_raw.dev_attr.attr,
> + &iio_dev_attr_gyro_scale.dev_attr.attr,
> + &iio_dev_attr_accel_x_raw.dev_attr.attr,
> + &iio_dev_attr_accel_y_raw.dev_attr.attr,
> + &iio_dev_attr_accel_z_raw.dev_attr.attr,
> + &iio_dev_attr_accel_scale.dev_attr.attr,
> + &iio_dev_attr_incli_x_raw.dev_attr.attr,
> + &iio_dev_attr_incli_y_raw.dev_attr.attr,
> + &iio_const_attr_incli_scale.dev_attr.attr,
> + &iio_dev_attr_temp_raw.dev_attr.attr,
> + &iio_const_attr_temp_offset.dev_attr.attr,
> + &iio_const_attr_temp_scale.dev_attr.attr,
> + &iio_dev_attr_in0_raw.dev_attr.attr,
> + &iio_const_attr_in0_scale.dev_attr.attr,
> + &iio_dev_attr_sampling_frequency.dev_attr.attr,
> + &iio_const_attr_sampling_frequency_available.dev_attr.attr,
> + &iio_dev_attr_reset.dev_attr.attr,
> + &iio_dev_attr_name.dev_attr.attr,
> + NULL
> +};
> +
> +static const struct attribute_group adis16300_attribute_group = {
> + .attrs = adis16300_attributes,
> +};
> +
> +static struct adis16350_chip_info adis16350_variants[] = {
> + [adis16300] = {
> + .attribute_group = &adis16300_attribute_group,
The complexity with building is here. If we aren't building with
CONFIG_IIO_RING_BUFFER then the right had side of this statement
does not exist. Updated patch puts an ifdef around here.
It's not pretty but I can't work out any other way of doing it.
Jonathan
> + .scan_el_group = &adis16300_scan_el_group,
> + .burst_available = 1,
> + .gyro_scale = "0.000872664",
> + .accel_scale = "0.00588399",
> + .burst_length = 18,
> + .all_mask =
> + BIT(ADIS16350_SCAN_IN_SUPPLY) |
> + BIT(ADIS16350_SCAN_GYRO_Z) |
> + BIT(ADIS16350_SCAN_ACCEL_X) |
> + BIT(ADIS16350_SCAN_ACCEL_Y) |
> + BIT(ADIS16350_SCAN_ACCEL_Z) |
> + BIT(ADIS16300_SCAN_TEMP) |
> + BIT(ADIS16300_SCAN_INCLI_X) |
> + BIT(ADIS16300_SCAN_INCLI_Y) |
> + BIT(ADIS16350_SCAN_IN0),
> + },
> + [adis16350] = {
> + .attribute_group = &adis16350_attribute_group,
> + .scan_el_group = &adis16350_scan_el_group,
> + .burst_available = 0,
> + .gyro_scale = "0.00127862821",
> + .accel_scale = "0.0247323713",
> + .all_mask =
> + BIT(ADIS16350_SCAN_IN_SUPPLY) |
> + BIT(ADIS16350_SCAN_GYRO_X) |
> + BIT(ADIS16350_SCAN_GYRO_Y) |
> + BIT(ADIS16350_SCAN_GYRO_Z) |
> + BIT(ADIS16350_SCAN_ACCEL_X) |
> + BIT(ADIS16350_SCAN_ACCEL_Y) |
> + BIT(ADIS16350_SCAN_ACCEL_Z) |
> + BIT(ADIS16350_SCAN_TEMP_X) |
> + BIT(ADIS16350_SCAN_TEMP_Y) |
> + BIT(ADIS16350_SCAN_TEMP_Z) |
> + BIT(ADIS16350_SCAN_IN0),
> + },
> + [adis16360] = {
> + .attribute_group = &adis16350_attribute_group,
> + .scan_el_group = &adis16350_scan_el_group,
> + .burst_available = 1,
> + .gyro_scale = "0.00127862821",
> + .accel_scale = "0.0247323713",
> + .burst_length = 22,
> + .all_mask =
> + BIT(ADIS16350_SCAN_IN_SUPPLY) |
> + BIT(ADIS16350_SCAN_GYRO_X) |
> + BIT(ADIS16350_SCAN_GYRO_Y) |
> + BIT(ADIS16350_SCAN_GYRO_Z) |
> + BIT(ADIS16350_SCAN_ACCEL_X) |
> + BIT(ADIS16350_SCAN_ACCEL_Y) |
> + BIT(ADIS16350_SCAN_ACCEL_Z) |
> + BIT(ADIS16350_SCAN_TEMP_X) |
> + BIT(ADIS16350_SCAN_TEMP_Y) |
> + BIT(ADIS16350_SCAN_TEMP_Z) |
> + BIT(ADIS16350_SCAN_IN0),
> + },
> +};
next prev parent reply other threads:[~2010-09-18 16:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-11 14:58 [RFC PATCH 0/6] staging:iio:imu driver merges, fixes and new features Jonathan Cameron
2010-09-11 14:58 ` [PATCH 1/6] staging:iio:adis16350 add non burst buffer fill and fix burst logic Jonathan Cameron
2010-09-11 14:58 ` [PATCH 2/6] staging:iio:adis16350 move datardy trigger to straight interrupt Jonathan Cameron
2010-09-11 14:58 ` [PATCH 3/6] staging:iio:adis16350 Add optional event support Jonathan Cameron
2010-09-11 14:58 ` [PATCH 4/6] staging:iio:adis16350 add missing registration of temp_offset attr Jonathan Cameron
2010-09-11 14:58 ` [PATCH 5/6] staging:iio:adis16300 merge into adis16350 driver Jonathan Cameron
2010-09-18 16:06 ` Jonathan Cameron [this message]
2010-09-11 14:58 ` [PATCH 6/6] staging:iio:adis16400 " Jonathan Cameron
2010-09-11 15:05 ` Jonathan Cameron
2010-09-22 8:47 ` [RFC PATCH 0/6] staging:iio:imu driver merges, fixes and new features Manuel Stahl
2010-09-22 10:12 ` Jonathan Cameron
2010-09-22 10:17 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C94E38C.7040007@cam.ac.uk \
--to=jic23@cam.ac.uk \
--cc=Michael.Hennerich@analog.com \
--cc=Robin.Getz@analog.com \
--cc=linux-iio@vger.kernel.org \
--cc=manuel.stahl@iis.fraunhofer.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox