* [PATCH 01/14] staging:iio:accel switch select kconfig elements to depends.
2012-04-22 12:13 [PATCH 00/14] IIO: Move from staging to drivers/iio Jonathan Cameron
@ 2012-04-22 12:13 ` Jonathan Cameron
2012-04-22 12:13 ` [PATCH 06/14] staging:iio:impedance-analyzer " Jonathan Cameron
` (5 subsequent siblings)
6 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2012-04-22 12:13 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
As we are moving the IIO core out of staging, we need to
stop drivers in staging controlling whether elements of the
core are built.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/staging/iio/accel/Kconfig | 18 ++++++------------
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/iio/accel/Kconfig b/drivers/staging/iio/accel/Kconfig
index 5ab7167..c445575 100644
--- a/drivers/staging/iio/accel/Kconfig
+++ b/drivers/staging/iio/accel/Kconfig
@@ -6,8 +6,7 @@ menu "Accelerometers"
config ADIS16201
tristate "Analog Devices ADIS16201 Dual-Axis Digital Inclinometer and Accelerometer"
depends on SPI
- select IIO_TRIGGER if IIO_BUFFER
- select IIO_SW_RING if IIO_BUFFER
+ depends on !IIO_BUFFER || (IIO_TRIGGER && IIO_SW_RING)
help
Say yes here to build support for Analog Devices adis16201 dual-axis
digital inclinometer and accelerometer.
@@ -15,8 +14,7 @@ config ADIS16201
config ADIS16203
tristate "Analog Devices ADIS16203 Programmable 360 Degrees Inclinometer"
depends on SPI
- select IIO_TRIGGER if IIO_BUFFER
- select IIO_SW_RING if IIO_BUFFER
+ depends on !IIO_BUFFER || (IIO_TRIGGER && IIO_SW_RING)
help
Say yes here to build support for Analog Devices adis16203 Programmable
360 Degrees Inclinometer.
@@ -24,8 +22,7 @@ config ADIS16203
config ADIS16204
tristate "Analog Devices ADIS16204 Programmable High-g Digital Impact Sensor and Recorder"
depends on SPI
- select IIO_TRIGGER if IIO_BUFFER
- select IIO_SW_RING if IIO_BUFFER
+ depends on !IIO_BUFFER || (IIO_TRIGGER && IIO_SW_RING)
help
Say yes here to build support for Analog Devices adis16204 Programmable
High-g Digital Impact Sensor and Recorder.
@@ -33,8 +30,7 @@ config ADIS16204
config ADIS16209
tristate "Analog Devices ADIS16209 Dual-Axis Digital Inclinometer and Accelerometer"
depends on SPI
- select IIO_TRIGGER if IIO_BUFFER
- select IIO_SW_RING if IIO_BUFFER
+ depends on !IIO_BUFFER || (IIO_TRIGGER && IIO_SW_RING)
help
Say yes here to build support for Analog Devices adis16209 dual-axis digital inclinometer
and accelerometer.
@@ -49,8 +45,7 @@ config ADIS16220
config ADIS16240
tristate "Analog Devices ADIS16240 Programmable Impact Sensor and Recorder"
depends on SPI
- select IIO_TRIGGER if IIO_BUFFER
- select IIO_SW_RING if IIO_BUFFER
+ depends on !IIO_BUFFER || (IIO_TRIGGER && IIO_SW_RING)
help
Say yes here to build support for Analog Devices adis16240 programmable
impact Sensor and recorder.
@@ -65,8 +60,7 @@ config KXSD9
config LIS3L02DQ
tristate "ST Microelectronics LIS3L02DQ Accelerometer Driver"
depends on SPI
- select IIO_TRIGGER if IIO_BUFFER
- depends on !IIO_BUFFER || IIO_KFIFO_BUF || IIO_SW_RING
+ depends on !IIO_BUFFER || ((IIO_KFIFO_BUF || IIO_SW_RING) && IIO_TRIGGER)
depends on GENERIC_GPIO
help
Say yes here to build SPI support for the ST microelectronics
--
1.7.9.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 06/14] staging:iio:impedance-analyzer switch select kconfig elements to depends.
2012-04-22 12:13 [PATCH 00/14] IIO: Move from staging to drivers/iio Jonathan Cameron
2012-04-22 12:13 ` [PATCH 01/14] staging:iio:accel switch select kconfig elements to depends Jonathan Cameron
@ 2012-04-22 12:13 ` Jonathan Cameron
2012-04-22 12:13 ` [PATCH 07/14] staging:iio:imu " Jonathan Cameron
` (4 subsequent siblings)
6 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2012-04-22 12:13 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
As we are moving the IIO core out of staging, we need to
stop drivers in staging controlling whether elements of the
core are built.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/staging/iio/impedance-analyzer/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/iio/impedance-analyzer/Kconfig b/drivers/staging/iio/impedance-analyzer/Kconfig
index ad0ff76..a036e16 100644
--- a/drivers/staging/iio/impedance-analyzer/Kconfig
+++ b/drivers/staging/iio/impedance-analyzer/Kconfig
@@ -6,8 +6,7 @@ menu "Network Analyzer, Impedance Converters"
config AD5933
tristate "Analog Devices AD5933, AD5934 driver"
depends on I2C
- select IIO_BUFFER
- select IIO_SW_RING
+ depends on IIO_BUFFER && IIO_SW_RING
help
Say yes here to build support for Analog Devices Impedance Converter,
Network Analyzer, AD5933/4, provides direct access via sysfs.
--
1.7.9.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 07/14] staging:iio:imu switch select kconfig elements to depends.
2012-04-22 12:13 [PATCH 00/14] IIO: Move from staging to drivers/iio Jonathan Cameron
2012-04-22 12:13 ` [PATCH 01/14] staging:iio:accel switch select kconfig elements to depends Jonathan Cameron
2012-04-22 12:13 ` [PATCH 06/14] staging:iio:impedance-analyzer " Jonathan Cameron
@ 2012-04-22 12:13 ` Jonathan Cameron
2012-04-22 12:13 ` [PATCH 08/14] staging:iio:meter " Jonathan Cameron
` (3 subsequent siblings)
6 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2012-04-22 12:13 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
As we are moving the IIO core out of staging, we need to
stop drivers in staging controlling whether elements of the
core are built.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/staging/iio/imu/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/iio/imu/Kconfig b/drivers/staging/iio/imu/Kconfig
index 2c2f47d..6e693dc 100644
--- a/drivers/staging/iio/imu/Kconfig
+++ b/drivers/staging/iio/imu/Kconfig
@@ -6,8 +6,7 @@ menu "Inertial measurement units"
config ADIS16400
tristate "Analog Devices ADIS16400 and similar IMU SPI driver"
depends on SPI
- select IIO_SW_RING if IIO_BUFFER
- select IIO_TRIGGER if IIO_BUFFER
+ depends on !IIO_BUFFER || (IIO_SW_RING && IIO_TRIGGER)
help
Say yes here to build support for Analog Devices adis16300, adis16344,
adis16350, adis16354, adis16355, adis16360, adis16362, adis16364,
--
1.7.9.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 08/14] staging:iio:meter switch select kconfig elements to depends.
2012-04-22 12:13 [PATCH 00/14] IIO: Move from staging to drivers/iio Jonathan Cameron
` (2 preceding siblings ...)
2012-04-22 12:13 ` [PATCH 07/14] staging:iio:imu " Jonathan Cameron
@ 2012-04-22 12:13 ` Jonathan Cameron
2012-04-22 12:13 ` [PATCH 09/14] staging:iio:buffers " Jonathan Cameron
` (2 subsequent siblings)
6 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2012-04-22 12:13 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
As we are moving the IIO core out of staging, we need to
stop drivers in staging controlling whether elements of the
core are built.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/staging/iio/meter/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/iio/meter/Kconfig b/drivers/staging/iio/meter/Kconfig
index d290d27..ae0e1fd 100644
--- a/drivers/staging/iio/meter/Kconfig
+++ b/drivers/staging/iio/meter/Kconfig
@@ -20,8 +20,7 @@ config ADE7754
config ADE7758
tristate "Analog Devices ADE7758 Poly Phase Multifunction Energy Metering IC Driver"
depends on SPI
- select IIO_TRIGGER if IIO_BUFFER
- select IIO_SW_RING if IIO_BUFFER
+ depends on !IIO_BUFFER || ( IIO_TRIGGER && IIO_SW_RING)
help
Say yes here to build support for Analog Devices ADE7758 Polyphase
Multifunction Energy Metering IC with Per Phase Information Driver.
--
1.7.9.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* [PATCH 09/14] staging:iio:buffers switch select kconfig elements to depends.
2012-04-22 12:13 [PATCH 00/14] IIO: Move from staging to drivers/iio Jonathan Cameron
` (3 preceding siblings ...)
2012-04-22 12:13 ` [PATCH 08/14] staging:iio:meter " Jonathan Cameron
@ 2012-04-22 12:13 ` Jonathan Cameron
2012-04-25 9:02 ` Lars-Peter Clausen
2012-04-22 12:13 ` [PATCH 11/14] staging:iio:Documentation Trivial typo fixes Jonathan Cameron
2012-04-25 9:00 ` [PATCH 00/14] IIO: Move from staging to drivers/iio Lars-Peter Clausen
6 siblings, 1 reply; 13+ messages in thread
From: Jonathan Cameron @ 2012-04-22 12:13 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
As we are moving the IIO core out of staging, we need to
stop drivers in staging controlling whether elements of the
core are built.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/staging/iio/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/iio/Kconfig b/drivers/staging/iio/Kconfig
index fe15867..e644508 100644
--- a/drivers/staging/iio/Kconfig
+++ b/drivers/staging/iio/Kconfig
@@ -28,7 +28,7 @@ config IIO_BUFFER
if IIO_BUFFER
config IIO_SW_RING
- select IIO_TRIGGER
+ depends on IIO_TRIGGER
tristate "Industrial I/O lock free software ring"
help
Example software ring buffer implementation. The design aim
@@ -37,7 +37,7 @@ config IIO_SW_RING
in interrupt context.
config IIO_KFIFO_BUF
- select IIO_TRIGGER
+ depends on IIO_TRIGGER
tristate "Industrial I/O buffering based on kfifo"
help
A simple fifo based on kfifo. Use this if you want a fifo
--
1.7.9.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 09/14] staging:iio:buffers switch select kconfig elements to depends.
2012-04-22 12:13 ` [PATCH 09/14] staging:iio:buffers " Jonathan Cameron
@ 2012-04-25 9:02 ` Lars-Peter Clausen
2012-04-25 15:00 ` Jonathan Cameron
0 siblings, 1 reply; 13+ messages in thread
From: Lars-Peter Clausen @ 2012-04-25 9:02 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: linux-iio
On 04/22/2012 02:13 PM, Jonathan Cameron wrote:
> As we are moving the IIO core out of staging, we need to
> stop drivers in staging controlling whether elements of the
> core are built.
>
> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
> ---
> drivers/staging/iio/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/iio/Kconfig b/drivers/staging/iio/Kconfig
> index fe15867..e644508 100644
> --- a/drivers/staging/iio/Kconfig
> +++ b/drivers/staging/iio/Kconfig
> @@ -28,7 +28,7 @@ config IIO_BUFFER
> if IIO_BUFFER
>
> config IIO_SW_RING
> - select IIO_TRIGGER
> + depends on IIO_TRIGGER
> tristate "Industrial I/O lock free software ring"
> help
> Example software ring buffer implementation. The design aim
> @@ -37,7 +37,7 @@ config IIO_SW_RING
> in interrupt context.
>
> config IIO_KFIFO_BUF
> - select IIO_TRIGGER
> + depends on IIO_TRIGGER
> tristate "Industrial I/O buffering based on kfifo"
> help
> A simple fifo based on kfifo. Use this if you want a fifo
Is there actually anything in the code which gets enabled by these config
symbols that depends on IIO_TRIGGER?
- Lars
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 09/14] staging:iio:buffers switch select kconfig elements to depends.
2012-04-25 9:02 ` Lars-Peter Clausen
@ 2012-04-25 15:00 ` Jonathan Cameron
0 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2012-04-25 15:00 UTC (permalink / raw)
To: Lars-Peter Clausen; +Cc: Jonathan Cameron, linux-iio
On 4/25/2012 10:02 AM, Lars-Peter Clausen wrote:
> On 04/22/2012 02:13 PM, Jonathan Cameron wrote:
>> As we are moving the IIO core out of staging, we need to
>> stop drivers in staging controlling whether elements of the
>> core are built.
>>
>> Signed-off-by: Jonathan Cameron<jic23@kernel.org>
>> ---
>> drivers/staging/iio/Kconfig | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/iio/Kconfig b/drivers/staging/iio/Kconfig
>> index fe15867..e644508 100644
>> --- a/drivers/staging/iio/Kconfig
>> +++ b/drivers/staging/iio/Kconfig
>> @@ -28,7 +28,7 @@ config IIO_BUFFER
>> if IIO_BUFFER
>>
>> config IIO_SW_RING
>> - select IIO_TRIGGER
>> + depends on IIO_TRIGGER
>> tristate "Industrial I/O lock free software ring"
>> help
>> Example software ring buffer implementation. The design aim
>> @@ -37,7 +37,7 @@ config IIO_SW_RING
>> in interrupt context.
>>
>> config IIO_KFIFO_BUF
>> - select IIO_TRIGGER
>> + depends on IIO_TRIGGER
>> tristate "Industrial I/O buffering based on kfifo"
>> help
>> A simple fifo based on kfifo. Use this if you want a fifo
>
> Is there actually anything in the code which gets enabled by these config
> symbols that depends on IIO_TRIGGER?
Not that I can think of.. Would imagine they snuck in to prevent a
build error at somepoint.
Took the view we can fix this up later as I've dropped all these patches.
>
> - Lars
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 11/14] staging:iio:Documentation Trivial typo fixes.
2012-04-22 12:13 [PATCH 00/14] IIO: Move from staging to drivers/iio Jonathan Cameron
` (4 preceding siblings ...)
2012-04-22 12:13 ` [PATCH 09/14] staging:iio:buffers " Jonathan Cameron
@ 2012-04-22 12:13 ` Jonathan Cameron
2012-04-25 9:00 ` [PATCH 00/14] IIO: Move from staging to drivers/iio Lars-Peter Clausen
6 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2012-04-22 12:13 UTC (permalink / raw)
To: linux-iio; +Cc: Jonathan Cameron
Just a couple of things I came across whilst reviewing this file for
moving out of staging. I doubt anyone cares, but seemed sensible to fix
them now!
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
---
drivers/staging/iio/Documentation/sysfs-bus-iio | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/iio/Documentation/sysfs-bus-iio b/drivers/staging/iio/Documentation/sysfs-bus-iio
index acf8698..ab7dfeb 100644
--- a/drivers/staging/iio/Documentation/sysfs-bus-iio
+++ b/drivers/staging/iio/Documentation/sysfs-bus-iio
@@ -108,7 +108,7 @@ Description:
physically equivalent inputs when non differential readings are
separately available. In differential only parts, then all that
is required is a consistent labeling. Units after application
- of scale and offset are nanofarads..
+ of scale and offset are nanofarads.
What: /sys/bus/iio/devices/iio:deviceX/in_temp_raw
What: /sys/bus/iio/devices/iio:deviceX/in_tempX_raw
@@ -119,7 +119,7 @@ KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no bias removal etc) temperature measurement.
- It an axis is specified it generally means that the temperature
+ If an axis is specified it generally means that the temperature
sensor is associated with one part of a compound device (e.g.
a gyroscope axis). Units after application of scale and offset
are milli degrees Celsuis.
@@ -232,7 +232,7 @@ Description:
If known for a device, scale to be applied to <type>Y[_name]_raw
post addition of <type>[Y][_name]_offset in order to obtain the
measured value in <type> units as specified in
- <type>[Y][_name]_raw documentation.. If shared across all in
+ <type>[Y][_name]_raw documentation. If shared across all in
channels then Y and <x|y|z> are not present and the value is
called <type>[Y][_name]_scale. The peak modifier means this
value is applied to <type>Y[_name]_peak_raw values.
--
1.7.9.4
^ permalink raw reply related [flat|nested] 13+ messages in thread* Re: [PATCH 00/14] IIO: Move from staging to drivers/iio
2012-04-22 12:13 [PATCH 00/14] IIO: Move from staging to drivers/iio Jonathan Cameron
` (5 preceding siblings ...)
2012-04-22 12:13 ` [PATCH 11/14] staging:iio:Documentation Trivial typo fixes Jonathan Cameron
@ 2012-04-25 9:00 ` Lars-Peter Clausen
2012-04-25 10:04 ` Jonathan Cameron
6 siblings, 1 reply; 13+ messages in thread
From: Lars-Peter Clausen @ 2012-04-25 9:00 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: linux-iio
On 04/22/2012 02:13 PM, Jonathan Cameron wrote:
> Hi All,
>
> This series is mostly what was discussed in
> IIO: move out of staging plan.
>
> It sits on top of the series
> Staging:iio: Cleanup and refactor pre multibuffer.
> which has gone to Greg already.
>
> However, a few things I'd neglected there came up and occur
> before the final 3 patches that actually do the main movement.
> Basically if we had just done the move we would have introduced
> selection of elements not in staging by driver in staging. This
> breaks the rule that code in staging should not effect any that
> isn't. Hence I've flipped all the selects to the equivalent
> depends on lines.
I think the rule is that non-staging code should not depend on staging code,
but I haven't heard yet that staging code shouldn't select non-staging.
E.g. there is a lot of infrastructure and helper code which is not user
selectable. Not allowing this to be selected by staging drivers would make
those helper functions inaccessible to it. Most of lib/ for example.
And I think at least the buffer implementations falls into this category.
There is no point of including them in the kernel image, if we have no
driver using them. And in fact all except one driver do select them instead
of depending on them. I think the best is to make them non user selectable
and let drivers which need them depend on them.
Triggers are a bit of a different story here. While all drivers select them
instead of depending on them there is also a different group which depends
on the trigger infrastructure. Namely the standalone trigger implementations.
But with a dependency like 'depends on !IIO_BUFFER || IIO_TRIGGER' the
driver will be available without IIO_BUFFER being select or when both
IIO_BUFFER and IIO_TRIGGER are selected, but not if IIO_BUFFER is selected
and not IIO_TRIGGER. This is a bit confusing in my opinion.
One way to solve this would be to make IIO_BUFFER and IIO_TRIGGER more
tightly coupled. In reality we never really use one without the other, so
there is not much gain from making them selectable independently and may
even cause some confusion.
But for now we can just make the buffer implementation of drivers which have
optional buffer support depend on both IIO_BUFFER and IIO_TRIGGER.
i.e. 's/#ifdef CONFIG_IIO_BUFFER/if defined(CONFIG_IIO_BUFFER) &&
defined(CONFIG_IIO_TRIGGER)'
I can take care of this if you want to.
- Lars
>
> Whilst doing this for ADC's I noticed that two had apparent
> configurable elementst that really were not (one of these
> was entirely my fault for being lazy a long time ago!). Anyhow
> I cleaned those up along the way by dropping the 'false' option
> of not having buffers for the max1363 and ad799x drivers.
>
> The other little change I made was to pull two elements,
> ac_excitation_en and bridge_switch_en out of the generic docs
> as they are only used by one driver. They can go back in
> at a later date if appropriate.
>
> Final 3 patches do the actual move.
> For now I've just moved the main sysfs ABI doc. Others should follow
> fairly soon.
>
> I've posted this to the list rather than just getting on with it
> so people can confirm I didn't mess up the non move changes.
> Please look at this asap as we want this to be in linux-next
> for as long as possible before the merge window opens.
> Obviously if I messed up the move changes, please do point that
> out!
>
> Jonathan
>
> Jonathan Cameron (14):
> staging:iio:accel switch select kconfig elements to depends.
> staging:iio:adc:max1363 remove false option to disable ring in
> kconfig.
> staging:iio:ad799x remove false option for ring buffer.
> staging:iio:adc switch select kconfig elements to depends.
> staging:iio:gyro switch select kconfig elements to depends.
> staging:iio:impedance-analyzer switch select kconfig elements to
> depends.
> staging:iio:imu switch select kconfig elements to depends.
> staging:iio:meter switch select kconfig elements to depends.
> staging:iio:buffers switch select kconfig elements to depends.
> staging:iio:documentation pull a few sysfs entries out of main docs.
> staging:iio:Documentation Trivial typo fixes.
> IIO: Move core headers to include/linux/iio
> IIO: Move the core files to drivers/iio
> IIO: Move the core abi documentation from staging
>
> .../ABI/testing}/sysfs-bus-iio | 27 ++---------
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/iio/Kconfig | 51 ++++++++++++++++++++
> drivers/iio/Makefile | 10 ++++
> drivers/{staging => }/iio/iio_core.h | 0
> drivers/{staging => }/iio/iio_core_trigger.h | 0
> drivers/{staging => }/iio/industrialio-buffer.c | 6 +--
> drivers/{staging => }/iio/industrialio-core.c | 6 +--
> drivers/{staging => }/iio/industrialio-event.c | 6 +--
> drivers/{staging => }/iio/industrialio-trigger.c | 6 +--
> drivers/{staging => }/iio/inkern.c | 8 +--
> drivers/{staging => }/iio/kfifo_buf.c | 3 +-
> .../staging/iio/Documentation/iio_event_monitor.c | 2 +-
> .../staging/iio/Documentation/sysfs-bus-iio-ad7192 | 20 ++++++++
> drivers/staging/iio/Kconfig | 46 ++----------------
> drivers/staging/iio/Makefile | 6 ---
> drivers/staging/iio/accel/Kconfig | 18 +++----
> drivers/staging/iio/accel/adis16201_core.c | 6 +--
> drivers/staging/iio/accel/adis16201_ring.c | 4 +-
> drivers/staging/iio/accel/adis16201_trigger.c | 4 +-
> drivers/staging/iio/accel/adis16203_core.c | 6 +--
> drivers/staging/iio/accel/adis16203_ring.c | 4 +-
> drivers/staging/iio/accel/adis16203_trigger.c | 4 +-
> drivers/staging/iio/accel/adis16204_core.c | 6 +--
> drivers/staging/iio/accel/adis16204_ring.c | 4 +-
> drivers/staging/iio/accel/adis16204_trigger.c | 4 +-
> drivers/staging/iio/accel/adis16209_core.c | 6 +--
> drivers/staging/iio/accel/adis16209_ring.c | 4 +-
> drivers/staging/iio/accel/adis16209_trigger.c | 4 +-
> drivers/staging/iio/accel/adis16220_core.c | 4 +-
> drivers/staging/iio/accel/adis16240_core.c | 6 +--
> drivers/staging/iio/accel/adis16240_ring.c | 4 +-
> drivers/staging/iio/accel/adis16240_trigger.c | 4 +-
> drivers/staging/iio/accel/kxsd9.c | 4 +-
> drivers/staging/iio/accel/lis3l02dq_core.c | 8 +--
> drivers/staging/iio/accel/lis3l02dq_ring.c | 8 +--
> drivers/staging/iio/accel/sca3000_core.c | 8 +--
> drivers/staging/iio/accel/sca3000_ring.c | 6 +--
> drivers/staging/iio/adc/Kconfig | 46 +++---------------
> drivers/staging/iio/adc/Makefile | 7 +--
> drivers/staging/iio/adc/ad7192.c | 10 ++--
> drivers/staging/iio/adc/ad7280a.c | 6 +--
> drivers/staging/iio/adc/ad7291.c | 6 +--
> drivers/staging/iio/adc/ad7298_core.c | 6 +--
> drivers/staging/iio/adc/ad7298_ring.c | 6 +--
> drivers/staging/iio/adc/ad7476_core.c | 6 +--
> drivers/staging/iio/adc/ad7476_ring.c | 6 +--
> drivers/staging/iio/adc/ad7606_core.c | 6 +--
> drivers/staging/iio/adc/ad7606_par.c | 2 +-
> drivers/staging/iio/adc/ad7606_ring.c | 6 +--
> drivers/staging/iio/adc/ad7606_spi.c | 2 +-
> drivers/staging/iio/adc/ad7780.c | 4 +-
> drivers/staging/iio/adc/ad7793.c | 10 ++--
> drivers/staging/iio/adc/ad7816.c | 6 +--
> drivers/staging/iio/adc/ad7887_core.c | 6 +--
> drivers/staging/iio/adc/ad7887_ring.c | 6 +--
> drivers/staging/iio/adc/ad799x.h | 14 +-----
> drivers/staging/iio/adc/ad799x_core.c | 8 +--
> drivers/staging/iio/adc/ad799x_ring.c | 6 +--
> drivers/staging/iio/adc/adt7310.c | 6 +--
> drivers/staging/iio/adc/adt7410.c | 6 +--
> drivers/staging/iio/adc/lpc32xx_adc.c | 4 +-
> drivers/staging/iio/adc/max1363.h | 18 -------
> drivers/staging/iio/adc/max1363_core.c | 10 ++--
> drivers/staging/iio/adc/max1363_ring.c | 6 +--
> drivers/staging/iio/adc/spear_adc.c | 4 +-
> drivers/staging/iio/addac/adt7316.c | 6 +--
> drivers/staging/iio/cdc/ad7150.c | 6 +--
> drivers/staging/iio/cdc/ad7152.c | 4 +-
> drivers/staging/iio/cdc/ad7746.c | 4 +-
> drivers/staging/iio/dac/ad5064.c | 4 +-
> drivers/staging/iio/dac/ad5360.c | 4 +-
> drivers/staging/iio/dac/ad5380.c | 4 +-
> drivers/staging/iio/dac/ad5421.c | 6 +--
> drivers/staging/iio/dac/ad5446.c | 4 +-
> drivers/staging/iio/dac/ad5504.c | 6 +--
> drivers/staging/iio/dac/ad5624r_spi.c | 4 +-
> drivers/staging/iio/dac/ad5686.c | 4 +-
> drivers/staging/iio/dac/ad5764.c | 4 +-
> drivers/staging/iio/dac/ad5791.c | 4 +-
> drivers/staging/iio/dac/max517.c | 4 +-
> drivers/staging/iio/dds/ad5930.c | 4 +-
> drivers/staging/iio/dds/ad9832.c | 4 +-
> drivers/staging/iio/dds/ad9834.c | 4 +-
> drivers/staging/iio/dds/ad9850.c | 4 +-
> drivers/staging/iio/dds/ad9852.c | 4 +-
> drivers/staging/iio/dds/ad9910.c | 4 +-
> drivers/staging/iio/dds/ad9951.c | 4 +-
> drivers/staging/iio/gyro/Kconfig | 3 +-
> drivers/staging/iio/gyro/adis16060_core.c | 4 +-
> drivers/staging/iio/gyro/adis16080_core.c | 4 +-
> drivers/staging/iio/gyro/adis16130_core.c | 4 +-
> drivers/staging/iio/gyro/adis16260_core.c | 6 +--
> drivers/staging/iio/gyro/adis16260_ring.c | 4 +-
> drivers/staging/iio/gyro/adis16260_trigger.c | 4 +-
> drivers/staging/iio/gyro/adxrs450_core.c | 4 +-
> drivers/staging/iio/iio_dummy_evgen.c | 4 +-
> drivers/staging/iio/iio_hwmon.c | 4 +-
> drivers/staging/iio/iio_simple_dummy.c | 8 +--
> drivers/staging/iio/iio_simple_dummy_buffer.c | 6 +--
> drivers/staging/iio/iio_simple_dummy_events.c | 6 +--
> drivers/staging/iio/impedance-analyzer/Kconfig | 3 +-
> drivers/staging/iio/impedance-analyzer/ad5933.c | 6 +--
> drivers/staging/iio/imu/Kconfig | 3 +-
> drivers/staging/iio/imu/adis16400_core.c | 6 +--
> drivers/staging/iio/imu/adis16400_ring.c | 4 +-
> drivers/staging/iio/imu/adis16400_trigger.c | 4 +-
> drivers/staging/iio/light/isl29018.c | 4 +-
> drivers/staging/iio/light/isl29028.c | 4 +-
> drivers/staging/iio/light/tsl2563.c | 6 +--
> drivers/staging/iio/light/tsl2583.c | 2 +-
> drivers/staging/iio/magnetometer/ak8975.c | 4 +-
> drivers/staging/iio/magnetometer/hmc5843.c | 4 +-
> drivers/staging/iio/meter/Kconfig | 3 +-
> drivers/staging/iio/meter/ade7753.c | 4 +-
> drivers/staging/iio/meter/ade7754.c | 4 +-
> drivers/staging/iio/meter/ade7758_core.c | 6 +--
> drivers/staging/iio/meter/ade7758_ring.c | 4 +-
> drivers/staging/iio/meter/ade7758_trigger.c | 4 +-
> drivers/staging/iio/meter/ade7759.c | 4 +-
> drivers/staging/iio/meter/ade7854-i2c.c | 2 +-
> drivers/staging/iio/meter/ade7854-spi.c | 2 +-
> drivers/staging/iio/meter/ade7854.c | 4 +-
> drivers/staging/iio/meter/meter.h | 2 +-
> drivers/staging/iio/resolver/ad2s1200.c | 4 +-
> drivers/staging/iio/resolver/ad2s1210.c | 4 +-
> drivers/staging/iio/resolver/ad2s90.c | 4 +-
> drivers/staging/iio/ring_sw.c | 2 +-
> drivers/staging/iio/ring_sw.h | 2 +-
> drivers/staging/iio/trigger/iio-trig-bfin-timer.c | 4 +-
> drivers/staging/iio/trigger/iio-trig-gpio.c | 4 +-
> .../staging/iio/trigger/iio-trig-periodic-rtc.c | 4 +-
> drivers/staging/iio/trigger/iio-trig-sysfs.c | 4 +-
> {drivers/staging => include/linux}/iio/buffer.h | 2 +-
> {drivers/staging => include/linux}/iio/consumer.h | 2 +-
> {drivers/staging => include/linux}/iio/driver.h | 0
> {drivers/staging => include/linux}/iio/events.h | 2 +-
> {drivers/staging => include/linux}/iio/iio.h | 2 +-
> {drivers/staging => include/linux}/iio/kfifo_buf.h | 4 +-
> {drivers/staging => include/linux}/iio/machine.h | 0
> {drivers/staging => include/linux}/iio/sysfs.h | 0
> {drivers/staging => include/linux}/iio/trigger.h | 0
> .../linux}/iio/trigger_consumer.h | 0
> {drivers/staging => include/linux}/iio/types.h | 0
> 145 files changed, 395 insertions(+), 450 deletions(-)
> rename {drivers/staging/iio/Documentation => Documentation/ABI/testing}/sysfs-bus-iio (97%)
> create mode 100644 drivers/iio/Kconfig
> create mode 100644 drivers/iio/Makefile
> rename drivers/{staging => }/iio/iio_core.h (100%)
> rename drivers/{staging => }/iio/iio_core_trigger.h (100%)
> rename drivers/{staging => }/iio/industrialio-buffer.c (99%)
> rename drivers/{staging => }/iio/industrialio-core.c (99%)
> rename drivers/{staging => }/iio/industrialio-event.c (99%)
> rename drivers/{staging => }/iio/industrialio-trigger.c (99%)
> rename drivers/{staging => }/iio/inkern.c (98%)
> rename drivers/{staging => }/iio/kfifo_buf.c (99%)
> create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-ad7192
> rename {drivers/staging => include/linux}/iio/buffer.h (99%)
> rename {drivers/staging => include/linux}/iio/consumer.h (99%)
> rename {drivers/staging => include/linux}/iio/driver.h (100%)
> rename {drivers/staging => include/linux}/iio/events.h (99%)
> rename {drivers/staging => include/linux}/iio/iio.h (99%)
> rename {drivers/staging => include/linux}/iio/kfifo_buf.h (70%)
> rename {drivers/staging => include/linux}/iio/machine.h (100%)
> rename {drivers/staging => include/linux}/iio/sysfs.h (100%)
> rename {drivers/staging => include/linux}/iio/trigger.h (100%)
> rename {drivers/staging => include/linux}/iio/trigger_consumer.h (100%)
> rename {drivers/staging => include/linux}/iio/types.h (100%)
>
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 00/14] IIO: Move from staging to drivers/iio
2012-04-25 9:00 ` [PATCH 00/14] IIO: Move from staging to drivers/iio Lars-Peter Clausen
@ 2012-04-25 10:04 ` Jonathan Cameron
2012-04-25 11:47 ` Lars-Peter Clausen
0 siblings, 1 reply; 13+ messages in thread
From: Jonathan Cameron @ 2012-04-25 10:04 UTC (permalink / raw)
To: Lars-Peter Clausen; +Cc: Jonathan Cameron, linux-iio
On 4/25/2012 10:00 AM, Lars-Peter Clausen wrote:
> On 04/22/2012 02:13 PM, Jonathan Cameron wrote:
>> Hi All,
>>
>> This series is mostly what was discussed in
>> IIO: move out of staging plan.
>>
>> It sits on top of the series
>> Staging:iio: Cleanup and refactor pre multibuffer.
>> which has gone to Greg already.
>>
>> However, a few things I'd neglected there came up and occur
>> before the final 3 patches that actually do the main movement.
>> Basically if we had just done the move we would have introduced
>> selection of elements not in staging by driver in staging. This
>> breaks the rule that code in staging should not effect any that
>> isn't. Hence I've flipped all the selects to the equivalent
>> depends on lines.
> I think the rule is that non-staging code should not depend on staging code,
> but I haven't heard yet that staging code shouldn't select non-staging.
Look around there are quite a few drivers already selecting elements
that aren't
in staging so I guess it's not an issue. Will revert this change.
>
> E.g. there is a lot of infrastructure and helper code which is not user
> selectable. Not allowing this to be selected by staging drivers would make
> those helper functions inaccessible to it. Most of lib/ for example.
>
> And I think at least the buffer implementations falls into this category.
> There is no point of including them in the kernel image, if we have no
> driver using them. And in fact all except one driver do select them instead
> of depending on them. I think the best is to make them non user selectable
> and let drivers which need them depend on them.
Take into account that we don't actually want to go out of our way to stop
people building drivers out of tree. So I'd rather keep these user
selectable if
nothing needs them.
> Triggers are a bit of a different story here. While all drivers select them
> instead of depending on them there is also a different group which depends
> on the trigger infrastructure. Namely the standalone trigger implementations.
>
> But with a dependency like 'depends on !IIO_BUFFER || IIO_TRIGGER' the
> driver will be available without IIO_BUFFER being select or when both
> IIO_BUFFER and IIO_TRIGGER are selected, but not if IIO_BUFFER is selected
> and not IIO_TRIGGER. This is a bit confusing in my opinion.
>
> One way to solve this would be to make IIO_BUFFER and IIO_TRIGGER more
> tightly coupled. In reality we never really use one without the other, so
> there is not much gain from making them selectable independently and may
> even cause some confusion.
We do use the separately in all hardware buffers. There triggers often
don't have
any meaning (or at least we can't get to them so no point in exposing
userspace interfaces).
>
> But for now we can just make the buffer implementation of drivers which have
> optional buffer support depend on both IIO_BUFFER and IIO_TRIGGER.
>
> i.e. 's/#ifdef CONFIG_IIO_BUFFER/if defined(CONFIG_IIO_BUFFER)&&
> defined(CONFIG_IIO_TRIGGER)'
>
> I can take care of this if you want to.
That would indeed be cleaner than the current stack of selects. Would
be great if
you can do this.
So I'll drop my select->depends patches and move on with the rest of the
move.
Clearly the change you suggest can stand separately anyway.
Jonathan
>
> - Lars
>
>
>> Whilst doing this for ADC's I noticed that two had apparent
>> configurable elementst that really were not (one of these
>> was entirely my fault for being lazy a long time ago!). Anyhow
>> I cleaned those up along the way by dropping the 'false' option
>> of not having buffers for the max1363 and ad799x drivers.
>>
>> The other little change I made was to pull two elements,
>> ac_excitation_en and bridge_switch_en out of the generic docs
>> as they are only used by one driver. They can go back in
>> at a later date if appropriate.
>>
>> Final 3 patches do the actual move.
>> For now I've just moved the main sysfs ABI doc. Others should follow
>> fairly soon.
>>
>> I've posted this to the list rather than just getting on with it
>> so people can confirm I didn't mess up the non move changes.
>> Please look at this asap as we want this to be in linux-next
>> for as long as possible before the merge window opens.
>> Obviously if I messed up the move changes, please do point that
>> out!
>>
>> Jonathan
>>
>> Jonathan Cameron (14):
>> staging:iio:accel switch select kconfig elements to depends.
>> staging:iio:adc:max1363 remove false option to disable ring in
>> kconfig.
>> staging:iio:ad799x remove false option for ring buffer.
>> staging:iio:adc switch select kconfig elements to depends.
>> staging:iio:gyro switch select kconfig elements to depends.
>> staging:iio:impedance-analyzer switch select kconfig elements to
>> depends.
>> staging:iio:imu switch select kconfig elements to depends.
>> staging:iio:meter switch select kconfig elements to depends.
>> staging:iio:buffers switch select kconfig elements to depends.
>> staging:iio:documentation pull a few sysfs entries out of main docs.
>> staging:iio:Documentation Trivial typo fixes.
>> IIO: Move core headers to include/linux/iio
>> IIO: Move the core files to drivers/iio
>> IIO: Move the core abi documentation from staging
>>
>> .../ABI/testing}/sysfs-bus-iio | 27 ++---------
>> drivers/Kconfig | 2 +
>> drivers/Makefile | 1 +
>> drivers/iio/Kconfig | 51 ++++++++++++++++++++
>> drivers/iio/Makefile | 10 ++++
>> drivers/{staging => }/iio/iio_core.h | 0
>> drivers/{staging => }/iio/iio_core_trigger.h | 0
>> drivers/{staging => }/iio/industrialio-buffer.c | 6 +--
>> drivers/{staging => }/iio/industrialio-core.c | 6 +--
>> drivers/{staging => }/iio/industrialio-event.c | 6 +--
>> drivers/{staging => }/iio/industrialio-trigger.c | 6 +--
>> drivers/{staging => }/iio/inkern.c | 8 +--
>> drivers/{staging => }/iio/kfifo_buf.c | 3 +-
>> .../staging/iio/Documentation/iio_event_monitor.c | 2 +-
>> .../staging/iio/Documentation/sysfs-bus-iio-ad7192 | 20 ++++++++
>> drivers/staging/iio/Kconfig | 46 ++----------------
>> drivers/staging/iio/Makefile | 6 ---
>> drivers/staging/iio/accel/Kconfig | 18 +++----
>> drivers/staging/iio/accel/adis16201_core.c | 6 +--
>> drivers/staging/iio/accel/adis16201_ring.c | 4 +-
>> drivers/staging/iio/accel/adis16201_trigger.c | 4 +-
>> drivers/staging/iio/accel/adis16203_core.c | 6 +--
>> drivers/staging/iio/accel/adis16203_ring.c | 4 +-
>> drivers/staging/iio/accel/adis16203_trigger.c | 4 +-
>> drivers/staging/iio/accel/adis16204_core.c | 6 +--
>> drivers/staging/iio/accel/adis16204_ring.c | 4 +-
>> drivers/staging/iio/accel/adis16204_trigger.c | 4 +-
>> drivers/staging/iio/accel/adis16209_core.c | 6 +--
>> drivers/staging/iio/accel/adis16209_ring.c | 4 +-
>> drivers/staging/iio/accel/adis16209_trigger.c | 4 +-
>> drivers/staging/iio/accel/adis16220_core.c | 4 +-
>> drivers/staging/iio/accel/adis16240_core.c | 6 +--
>> drivers/staging/iio/accel/adis16240_ring.c | 4 +-
>> drivers/staging/iio/accel/adis16240_trigger.c | 4 +-
>> drivers/staging/iio/accel/kxsd9.c | 4 +-
>> drivers/staging/iio/accel/lis3l02dq_core.c | 8 +--
>> drivers/staging/iio/accel/lis3l02dq_ring.c | 8 +--
>> drivers/staging/iio/accel/sca3000_core.c | 8 +--
>> drivers/staging/iio/accel/sca3000_ring.c | 6 +--
>> drivers/staging/iio/adc/Kconfig | 46 +++---------------
>> drivers/staging/iio/adc/Makefile | 7 +--
>> drivers/staging/iio/adc/ad7192.c | 10 ++--
>> drivers/staging/iio/adc/ad7280a.c | 6 +--
>> drivers/staging/iio/adc/ad7291.c | 6 +--
>> drivers/staging/iio/adc/ad7298_core.c | 6 +--
>> drivers/staging/iio/adc/ad7298_ring.c | 6 +--
>> drivers/staging/iio/adc/ad7476_core.c | 6 +--
>> drivers/staging/iio/adc/ad7476_ring.c | 6 +--
>> drivers/staging/iio/adc/ad7606_core.c | 6 +--
>> drivers/staging/iio/adc/ad7606_par.c | 2 +-
>> drivers/staging/iio/adc/ad7606_ring.c | 6 +--
>> drivers/staging/iio/adc/ad7606_spi.c | 2 +-
>> drivers/staging/iio/adc/ad7780.c | 4 +-
>> drivers/staging/iio/adc/ad7793.c | 10 ++--
>> drivers/staging/iio/adc/ad7816.c | 6 +--
>> drivers/staging/iio/adc/ad7887_core.c | 6 +--
>> drivers/staging/iio/adc/ad7887_ring.c | 6 +--
>> drivers/staging/iio/adc/ad799x.h | 14 +-----
>> drivers/staging/iio/adc/ad799x_core.c | 8 +--
>> drivers/staging/iio/adc/ad799x_ring.c | 6 +--
>> drivers/staging/iio/adc/adt7310.c | 6 +--
>> drivers/staging/iio/adc/adt7410.c | 6 +--
>> drivers/staging/iio/adc/lpc32xx_adc.c | 4 +-
>> drivers/staging/iio/adc/max1363.h | 18 -------
>> drivers/staging/iio/adc/max1363_core.c | 10 ++--
>> drivers/staging/iio/adc/max1363_ring.c | 6 +--
>> drivers/staging/iio/adc/spear_adc.c | 4 +-
>> drivers/staging/iio/addac/adt7316.c | 6 +--
>> drivers/staging/iio/cdc/ad7150.c | 6 +--
>> drivers/staging/iio/cdc/ad7152.c | 4 +-
>> drivers/staging/iio/cdc/ad7746.c | 4 +-
>> drivers/staging/iio/dac/ad5064.c | 4 +-
>> drivers/staging/iio/dac/ad5360.c | 4 +-
>> drivers/staging/iio/dac/ad5380.c | 4 +-
>> drivers/staging/iio/dac/ad5421.c | 6 +--
>> drivers/staging/iio/dac/ad5446.c | 4 +-
>> drivers/staging/iio/dac/ad5504.c | 6 +--
>> drivers/staging/iio/dac/ad5624r_spi.c | 4 +-
>> drivers/staging/iio/dac/ad5686.c | 4 +-
>> drivers/staging/iio/dac/ad5764.c | 4 +-
>> drivers/staging/iio/dac/ad5791.c | 4 +-
>> drivers/staging/iio/dac/max517.c | 4 +-
>> drivers/staging/iio/dds/ad5930.c | 4 +-
>> drivers/staging/iio/dds/ad9832.c | 4 +-
>> drivers/staging/iio/dds/ad9834.c | 4 +-
>> drivers/staging/iio/dds/ad9850.c | 4 +-
>> drivers/staging/iio/dds/ad9852.c | 4 +-
>> drivers/staging/iio/dds/ad9910.c | 4 +-
>> drivers/staging/iio/dds/ad9951.c | 4 +-
>> drivers/staging/iio/gyro/Kconfig | 3 +-
>> drivers/staging/iio/gyro/adis16060_core.c | 4 +-
>> drivers/staging/iio/gyro/adis16080_core.c | 4 +-
>> drivers/staging/iio/gyro/adis16130_core.c | 4 +-
>> drivers/staging/iio/gyro/adis16260_core.c | 6 +--
>> drivers/staging/iio/gyro/adis16260_ring.c | 4 +-
>> drivers/staging/iio/gyro/adis16260_trigger.c | 4 +-
>> drivers/staging/iio/gyro/adxrs450_core.c | 4 +-
>> drivers/staging/iio/iio_dummy_evgen.c | 4 +-
>> drivers/staging/iio/iio_hwmon.c | 4 +-
>> drivers/staging/iio/iio_simple_dummy.c | 8 +--
>> drivers/staging/iio/iio_simple_dummy_buffer.c | 6 +--
>> drivers/staging/iio/iio_simple_dummy_events.c | 6 +--
>> drivers/staging/iio/impedance-analyzer/Kconfig | 3 +-
>> drivers/staging/iio/impedance-analyzer/ad5933.c | 6 +--
>> drivers/staging/iio/imu/Kconfig | 3 +-
>> drivers/staging/iio/imu/adis16400_core.c | 6 +--
>> drivers/staging/iio/imu/adis16400_ring.c | 4 +-
>> drivers/staging/iio/imu/adis16400_trigger.c | 4 +-
>> drivers/staging/iio/light/isl29018.c | 4 +-
>> drivers/staging/iio/light/isl29028.c | 4 +-
>> drivers/staging/iio/light/tsl2563.c | 6 +--
>> drivers/staging/iio/light/tsl2583.c | 2 +-
>> drivers/staging/iio/magnetometer/ak8975.c | 4 +-
>> drivers/staging/iio/magnetometer/hmc5843.c | 4 +-
>> drivers/staging/iio/meter/Kconfig | 3 +-
>> drivers/staging/iio/meter/ade7753.c | 4 +-
>> drivers/staging/iio/meter/ade7754.c | 4 +-
>> drivers/staging/iio/meter/ade7758_core.c | 6 +--
>> drivers/staging/iio/meter/ade7758_ring.c | 4 +-
>> drivers/staging/iio/meter/ade7758_trigger.c | 4 +-
>> drivers/staging/iio/meter/ade7759.c | 4 +-
>> drivers/staging/iio/meter/ade7854-i2c.c | 2 +-
>> drivers/staging/iio/meter/ade7854-spi.c | 2 +-
>> drivers/staging/iio/meter/ade7854.c | 4 +-
>> drivers/staging/iio/meter/meter.h | 2 +-
>> drivers/staging/iio/resolver/ad2s1200.c | 4 +-
>> drivers/staging/iio/resolver/ad2s1210.c | 4 +-
>> drivers/staging/iio/resolver/ad2s90.c | 4 +-
>> drivers/staging/iio/ring_sw.c | 2 +-
>> drivers/staging/iio/ring_sw.h | 2 +-
>> drivers/staging/iio/trigger/iio-trig-bfin-timer.c | 4 +-
>> drivers/staging/iio/trigger/iio-trig-gpio.c | 4 +-
>> .../staging/iio/trigger/iio-trig-periodic-rtc.c | 4 +-
>> drivers/staging/iio/trigger/iio-trig-sysfs.c | 4 +-
>> {drivers/staging => include/linux}/iio/buffer.h | 2 +-
>> {drivers/staging => include/linux}/iio/consumer.h | 2 +-
>> {drivers/staging => include/linux}/iio/driver.h | 0
>> {drivers/staging => include/linux}/iio/events.h | 2 +-
>> {drivers/staging => include/linux}/iio/iio.h | 2 +-
>> {drivers/staging => include/linux}/iio/kfifo_buf.h | 4 +-
>> {drivers/staging => include/linux}/iio/machine.h | 0
>> {drivers/staging => include/linux}/iio/sysfs.h | 0
>> {drivers/staging => include/linux}/iio/trigger.h | 0
>> .../linux}/iio/trigger_consumer.h | 0
>> {drivers/staging => include/linux}/iio/types.h | 0
>> 145 files changed, 395 insertions(+), 450 deletions(-)
>> rename {drivers/staging/iio/Documentation => Documentation/ABI/testing}/sysfs-bus-iio (97%)
>> create mode 100644 drivers/iio/Kconfig
>> create mode 100644 drivers/iio/Makefile
>> rename drivers/{staging => }/iio/iio_core.h (100%)
>> rename drivers/{staging => }/iio/iio_core_trigger.h (100%)
>> rename drivers/{staging => }/iio/industrialio-buffer.c (99%)
>> rename drivers/{staging => }/iio/industrialio-core.c (99%)
>> rename drivers/{staging => }/iio/industrialio-event.c (99%)
>> rename drivers/{staging => }/iio/industrialio-trigger.c (99%)
>> rename drivers/{staging => }/iio/inkern.c (98%)
>> rename drivers/{staging => }/iio/kfifo_buf.c (99%)
>> create mode 100644 drivers/staging/iio/Documentation/sysfs-bus-iio-ad7192
>> rename {drivers/staging => include/linux}/iio/buffer.h (99%)
>> rename {drivers/staging => include/linux}/iio/consumer.h (99%)
>> rename {drivers/staging => include/linux}/iio/driver.h (100%)
>> rename {drivers/staging => include/linux}/iio/events.h (99%)
>> rename {drivers/staging => include/linux}/iio/iio.h (99%)
>> rename {drivers/staging => include/linux}/iio/kfifo_buf.h (70%)
>> rename {drivers/staging => include/linux}/iio/machine.h (100%)
>> rename {drivers/staging => include/linux}/iio/sysfs.h (100%)
>> rename {drivers/staging => include/linux}/iio/trigger.h (100%)
>> rename {drivers/staging => include/linux}/iio/trigger_consumer.h (100%)
>> rename {drivers/staging => include/linux}/iio/types.h (100%)
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: [PATCH 00/14] IIO: Move from staging to drivers/iio
2012-04-25 10:04 ` Jonathan Cameron
@ 2012-04-25 11:47 ` Lars-Peter Clausen
2012-04-25 15:03 ` Jonathan Cameron
0 siblings, 1 reply; 13+ messages in thread
From: Lars-Peter Clausen @ 2012-04-25 11:47 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: Jonathan Cameron, linux-iio
On 04/25/2012 12:04 PM, Jonathan Cameron wrote:
> On 4/25/2012 10:00 AM, Lars-Peter Clausen wrote:
>> On 04/22/2012 02:13 PM, Jonathan Cameron wrote:
>>> Hi All,
>>>
>>> This series is mostly what was discussed in
>>> IIO: move out of staging plan.
>>>
>>> It sits on top of the series
>>> Staging:iio: Cleanup and refactor pre multibuffer.
>>> which has gone to Greg already.
>>>
>>> However, a few things I'd neglected there came up and occur
>>> before the final 3 patches that actually do the main movement.
>>> Basically if we had just done the move we would have introduced
>>> selection of elements not in staging by driver in staging. This
>>> breaks the rule that code in staging should not effect any that
>>> isn't. Hence I've flipped all the selects to the equivalent
>>> depends on lines.
>> I think the rule is that non-staging code should not depend on staging code,
>> but I haven't heard yet that staging code shouldn't select non-staging.
> Look around there are quite a few drivers already selecting elements that
> aren't
> in staging so I guess it's not an issue. Will revert this change.
>>
>> E.g. there is a lot of infrastructure and helper code which is not user
>> selectable. Not allowing this to be selected by staging drivers would make
>> those helper functions inaccessible to it. Most of lib/ for example.
>>
>> And I think at least the buffer implementations falls into this category.
>> There is no point of including them in the kernel image, if we have no
>> driver using them. And in fact all except one driver do select them instead
>> of depending on them. I think the best is to make them non user selectable
>> and let drivers which need them depend on them.
> Take into account that we don't actually want to go out of our way to stop
> people building drivers out of tree. So I'd rather keep these user
> selectable if
> nothing needs them.
In my opinion the rule of thumb should be to either let Kconfig items be
user-selectable and let drivers depend on them or let them be
non-user-selectable and let drivers select them, but ok.
>> Triggers are a bit of a different story here. While all drivers select them
>> instead of depending on them there is also a different group which depends
>> on the trigger infrastructure. Namely the standalone trigger implementations.
>>
>> But with a dependency like 'depends on !IIO_BUFFER || IIO_TRIGGER' the
>> driver will be available without IIO_BUFFER being select or when both
>> IIO_BUFFER and IIO_TRIGGER are selected, but not if IIO_BUFFER is selected
>> and not IIO_TRIGGER. This is a bit confusing in my opinion.
>>
>> One way to solve this would be to make IIO_BUFFER and IIO_TRIGGER more
>> tightly coupled. In reality we never really use one without the other, so
>> there is not much gain from making them selectable independently and may
>> even cause some confusion.
> We do use the separately in all hardware buffers. There triggers often
> don't have
> any meaning (or at least we can't get to them so no point in exposing
> userspace interfaces).
I meant the generic trigger infrastructure (i.e. everything that's pulled in
by IIO_TRIGGER), not the individual trigger implementations. I think there
is only one driver with buffer support which does not depend on IIO_TRIGGER
(or selects it).
>> But for now we can just make the buffer implementation of drivers which have
>> optional buffer support depend on both IIO_BUFFER and IIO_TRIGGER.
>>
>> i.e. 's/#ifdef CONFIG_IIO_BUFFER/if defined(CONFIG_IIO_BUFFER)&&
>> defined(CONFIG_IIO_TRIGGER)'
>>
>> I can take care of this if you want to.
> That would indeed be cleaner than the current stack of selects. Would be
> great if
> you can do this.
>
> So I'll drop my select->depends patches and move on with the rest of the move.
> Clearly the change you suggest can stand separately anyway.
I think it is still worth converting 'select IIO_BUFFER' to 'depends
IIO_BUFFER'.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 00/14] IIO: Move from staging to drivers/iio
2012-04-25 11:47 ` Lars-Peter Clausen
@ 2012-04-25 15:03 ` Jonathan Cameron
0 siblings, 0 replies; 13+ messages in thread
From: Jonathan Cameron @ 2012-04-25 15:03 UTC (permalink / raw)
To: Lars-Peter Clausen; +Cc: Jonathan Cameron, linux-iio
On 4/25/2012 12:47 PM, Lars-Peter Clausen wrote:
> On 04/25/2012 12:04 PM, Jonathan Cameron wrote:
>> On 4/25/2012 10:00 AM, Lars-Peter Clausen wrote:
>>> On 04/22/2012 02:13 PM, Jonathan Cameron wrote:
>>>> Hi All,
>>>>
>>>> This series is mostly what was discussed in
>>>> IIO: move out of staging plan.
>>>>
>>>> It sits on top of the series
>>>> Staging:iio: Cleanup and refactor pre multibuffer.
>>>> which has gone to Greg already.
>>>>
>>>> However, a few things I'd neglected there came up and occur
>>>> before the final 3 patches that actually do the main movement.
>>>> Basically if we had just done the move we would have introduced
>>>> selection of elements not in staging by driver in staging. This
>>>> breaks the rule that code in staging should not effect any that
>>>> isn't. Hence I've flipped all the selects to the equivalent
>>>> depends on lines.
>>> I think the rule is that non-staging code should not depend on staging code,
>>> but I haven't heard yet that staging code shouldn't select non-staging.
>> Look around there are quite a few drivers already selecting elements that
>> aren't
>> in staging so I guess it's not an issue. Will revert this change.
>>> E.g. there is a lot of infrastructure and helper code which is not user
>>> selectable. Not allowing this to be selected by staging drivers would make
>>> those helper functions inaccessible to it. Most of lib/ for example.
>>>
>>> And I think at least the buffer implementations falls into this category.
>>> There is no point of including them in the kernel image, if we have no
>>> driver using them. And in fact all except one driver do select them instead
>>> of depending on them. I think the best is to make them non user selectable
>>> and let drivers which need them depend on them.
>> Take into account that we don't actually want to go out of our way to stop
>> people building drivers out of tree. So I'd rather keep these user
>> selectable if
>> nothing needs them.
> In my opinion the rule of thumb should be to either let Kconfig items be
> user-selectable and let drivers depend on them or let them be
> non-user-selectable and let drivers select them, but ok.
Would be nice... maybe we'll make this decision sometime in the future...
>
>>> Triggers are a bit of a different story here. While all drivers select them
>>> instead of depending on them there is also a different group which depends
>>> on the trigger infrastructure. Namely the standalone trigger implementations.
>>>
>>> But with a dependency like 'depends on !IIO_BUFFER || IIO_TRIGGER' the
>>> driver will be available without IIO_BUFFER being select or when both
>>> IIO_BUFFER and IIO_TRIGGER are selected, but not if IIO_BUFFER is selected
>>> and not IIO_TRIGGER. This is a bit confusing in my opinion.
>>>
>>> One way to solve this would be to make IIO_BUFFER and IIO_TRIGGER more
>>> tightly coupled. In reality we never really use one without the other, so
>>> there is not much gain from making them selectable independently and may
>>> even cause some confusion.
>> We do use the separately in all hardware buffers. There triggers often
>> don't have
>> any meaning (or at least we can't get to them so no point in exposing
>> userspace interfaces).
> I meant the generic trigger infrastructure (i.e. everything that's pulled in
> by IIO_TRIGGER), not the individual trigger implementations. I think there
> is only one driver with buffer support which does not depend on IIO_TRIGGER
> (or selects it).
Probably true, but there are a few drivers that should be in this state
and aren't either
because they don't support buffers or do it horribly wrong (the impact
sensor under
accel for starters with it's horrible binary sysfs files).
>
>
>>> But for now we can just make the buffer implementation of drivers which have
>>> optional buffer support depend on both IIO_BUFFER and IIO_TRIGGER.
>>>
>>> i.e. 's/#ifdef CONFIG_IIO_BUFFER/if defined(CONFIG_IIO_BUFFER)&&
>>> defined(CONFIG_IIO_TRIGGER)'
>>>
>>> I can take care of this if you want to.
>> That would indeed be cleaner than the current stack of selects. Would be
>> great if
>> you can do this.
>>
>> So I'll drop my select->depends patches and move on with the rest of the move.
>> Clearly the change you suggest can stand separately anyway.
> I think it is still worth converting 'select IIO_BUFFER' to 'depends
> IIO_BUFFER'.
Sounds reasonable, but given the stage we are at in the merge cycle I've
left this for
now.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread