# SPDX-License-Identifier: GPL-2.0-only
#
# Industrial I/O subsystem configuration
#

menuconfig IIO
	tristate "Industrial I/O support"
	help
	  The industrial I/O subsystem provides a unified framework for
	  drivers for many different types of embedded sensors using a
	  number of different physical interfaces (i2c, spi, etc).

if IIO

config IIO_BUFFER
	bool "Enable buffer support within IIO"
	help
	  Provide core support for various buffer based data
	  acquisition methods.

if IIO_BUFFER
	source "drivers/iio/buffer/Kconfig"
endif # IIO_BUFFER

config IIO_CONFIGFS
	tristate "Enable IIO configuration via configfs"
	select CONFIGFS_FS
	help
	  This allows configuring various IIO bits through configfs
	  (e.g. software triggers). For more info see
	  Documentation/iio/iio_configfs.rst.

config IIO_GTS_HELPER
	tristate

config IIO_TRIGGER
	bool "Enable triggered sampling support"
	help
	  Provides IIO core support for triggers.  Currently these
	  are used to initialize capture of samples to push into
	  buffers.  The triggers are effectively a 'capture
	  data now' interrupt.

config IIO_CONSUMERS_PER_TRIGGER
	int "Maximum number of consumers per trigger"
	depends on IIO_TRIGGER
	default "2"
	help
	  This value controls the maximum number of consumers that a
	  given trigger may handle. Default is 2.

config IIO_SW_DEVICE
	tristate "Enable software IIO device support"
	select IIO_CONFIGFS
	help
	  Provides IIO core support for software devices. A software
	  device can be created via configfs or directly by a driver
	  using the API provided.

config IIO_SW_TRIGGER
	tristate "Enable software triggers support"
	select IIO_CONFIGFS
	help
	  Provides IIO core support for software triggers. A software
	  trigger can be created via configfs or directly by a driver
	  using the API provided.

config IIO_TRIGGERED_EVENT
	tristate "Enable triggered events support"
	select IIO_TRIGGER
	help
	  Provides helper functions for setting up triggered events.

config IIO_BACKEND
	tristate
	help
	  Framework to handle complex IIO aggregate devices. The typical
	  architecture that can make use of this framework is to have one
	  device as the frontend device which can be "linked" against one or
	  multiple backend devices. The framework then makes it easy to get
	  and control such backend devices.

source "drivers/iio/accel/Kconfig"
source "drivers/iio/adc/Kconfig"
source "drivers/iio/addac/Kconfig"
source "drivers/iio/afe/Kconfig"
source "drivers/iio/amplifiers/Kconfig"
source "drivers/iio/cdc/Kconfig"
source "drivers/iio/chemical/Kconfig"
source "drivers/iio/common/Kconfig"
source "drivers/iio/dac/Kconfig"
source "drivers/iio/dummy/Kconfig"
source "drivers/iio/filter/Kconfig"
source "drivers/iio/frequency/Kconfig"
source "drivers/iio/gyro/Kconfig"
source "drivers/iio/health/Kconfig"
source "drivers/iio/humidity/Kconfig"
source "drivers/iio/imu/Kconfig"
source "drivers/iio/light/Kconfig"
source "drivers/iio/magnetometer/Kconfig"
source "drivers/iio/multiplexer/Kconfig"
source "drivers/iio/orientation/Kconfig"
source "drivers/iio/test/Kconfig"
if IIO_TRIGGER
   source "drivers/iio/trigger/Kconfig"
endif #IIO_TRIGGER
source "drivers/iio/position/Kconfig"
source "drivers/iio/potentiometer/Kconfig"
source "drivers/iio/potentiostat/Kconfig"
source "drivers/iio/pressure/Kconfig"
source "drivers/iio/proximity/Kconfig"
source "drivers/iio/resolver/Kconfig"
source "drivers/iio/temperature/Kconfig"

endif # IIO