summaryrefslogtreecommitdiff
path: root/drivers/iio/dac
AgeCommit message (Collapse)AuthorFilesLines
2018-06-13treewide: devm_kzalloc() -> devm_kcalloc()Kees Cook1-2/+3
The devm_kzalloc() function has a 2-factor argument form, devm_kcalloc(). This patch replaces cases of: devm_kzalloc(handle, a * b, gfp) with: devm_kcalloc(handle, a * b, gfp) as well as handling cases of: devm_kzalloc(handle, a * b * c, gfp) with: devm_kzalloc(handle, array3_size(a, b, c), gfp) as it's slightly less ugly than: devm_kcalloc(handle, array_size(a, b), c, gfp) This does, however, attempt to ignore constant size factors like: devm_kzalloc(handle, 4 * 1024, gfp) though any constants defined via macros get caught up in the conversion. Any factors with a sizeof() of "unsigned char", "char", and "u8" were dropped, since they're redundant. Some manual whitespace fixes were needed in this patch, as Coccinelle really liked to write "=devm_kcalloc..." instead of "= devm_kcalloc...". The Coccinelle script used for this was: // Fix redundant parens around sizeof(). @@ expression HANDLE; type TYPE; expression THING, E; @@ ( devm_kzalloc(HANDLE, - (sizeof(TYPE)) * E + sizeof(TYPE) * E , ...) | devm_kzalloc(HANDLE, - (sizeof(THING)) * E + sizeof(THING) * E , ...) ) // Drop single-byte sizes and redundant parens. @@ expression HANDLE; expression COUNT; typedef u8; typedef __u8; @@ ( devm_kzalloc(HANDLE, - sizeof(u8) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(__u8) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(char) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(unsigned char) * (COUNT) + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(u8) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(__u8) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(char) * COUNT + COUNT , ...) | devm_kzalloc(HANDLE, - sizeof(unsigned char) * COUNT + COUNT , ...) ) // 2-factor product with sizeof(type/expression) and identifier or constant. @@ expression HANDLE; type TYPE; expression THING; identifier COUNT_ID; constant COUNT_CONST; @@ ( - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (COUNT_ID) + COUNT_ID, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * COUNT_ID + COUNT_ID, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (COUNT_CONST) + COUNT_CONST, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * COUNT_CONST + COUNT_CONST, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (COUNT_ID) + COUNT_ID, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * COUNT_ID + COUNT_ID, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (COUNT_CONST) + COUNT_CONST, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * COUNT_CONST + COUNT_CONST, sizeof(THING) , ...) ) // 2-factor product, only identifiers. @@ expression HANDLE; identifier SIZE, COUNT; @@ - devm_kzalloc + devm_kcalloc (HANDLE, - SIZE * COUNT + COUNT, SIZE , ...) // 3-factor product with 1 sizeof(type) or sizeof(expression), with // redundant parens removed. @@ expression HANDLE; expression THING; identifier STRIDE, COUNT; type TYPE; @@ ( devm_kzalloc(HANDLE, - sizeof(TYPE) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(TYPE)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * (COUNT) * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * (COUNT) * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * COUNT * (STRIDE) + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING) * COUNT * STRIDE + array3_size(COUNT, STRIDE, sizeof(THING)) , ...) ) // 3-factor product with 2 sizeof(variable), with redundant parens removed. @@ expression HANDLE; expression THING1, THING2; identifier COUNT; type TYPE1, TYPE2; @@ ( devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(TYPE2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(THING1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(THING1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * COUNT + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) | devm_kzalloc(HANDLE, - sizeof(TYPE1) * sizeof(THING2) * (COUNT) + array3_size(COUNT, sizeof(TYPE1), sizeof(THING2)) , ...) ) // 3-factor product, only identifiers, with redundant parens removed. @@ expression HANDLE; identifier STRIDE, SIZE, COUNT; @@ ( devm_kzalloc(HANDLE, - (COUNT) * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * (STRIDE) * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * STRIDE * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - (COUNT) * (STRIDE) * (SIZE) + array3_size(COUNT, STRIDE, SIZE) , ...) | devm_kzalloc(HANDLE, - COUNT * STRIDE * SIZE + array3_size(COUNT, STRIDE, SIZE) , ...) ) // Any remaining multi-factor products, first at least 3-factor products, // when they're not all constants... @@ expression HANDLE; expression E1, E2, E3; constant C1, C2, C3; @@ ( devm_kzalloc(HANDLE, C1 * C2 * C3, ...) | devm_kzalloc(HANDLE, - (E1) * E2 * E3 + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - (E1) * (E2) * E3 + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - (E1) * (E2) * (E3) + array3_size(E1, E2, E3) , ...) | devm_kzalloc(HANDLE, - E1 * E2 * E3 + array3_size(E1, E2, E3) , ...) ) // And then all remaining 2 factors products when they're not all constants, // keeping sizeof() as the second factor argument. @@ expression HANDLE; expression THING, E1, E2; type TYPE; constant C1, C2, C3; @@ ( devm_kzalloc(HANDLE, sizeof(THING) * C2, ...) | devm_kzalloc(HANDLE, sizeof(TYPE) * C2, ...) | devm_kzalloc(HANDLE, C1 * C2 * C3, ...) | devm_kzalloc(HANDLE, C1 * C2, ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * (E2) + E2, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(TYPE) * E2 + E2, sizeof(TYPE) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * (E2) + E2, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - sizeof(THING) * E2 + E2, sizeof(THING) , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - (E1) * E2 + E1, E2 , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - (E1) * (E2) + E1, E2 , ...) | - devm_kzalloc + devm_kcalloc (HANDLE, - E1 * E2 + E1, E2 , ...) ) Signed-off-by: Kees Cook <keescook@chromium.org>
2018-05-22iio: dac: Add support for external reference voltage through the regulator ↵Silvan Murer1-9/+61
framework. Signed-off-by: Silvan Murer <silvan.murer@gmail.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-05-22iio: dac: fix missing of_match_table assignment in the LTC 2632 deviceSilvan Murer1-9/+10
Signed-off-by: Silvan Murer <silvan.murer@gmail.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-05-20iio:dac:ad5686: Add AD5681R/AD5682R/AD5683/AD5683R supportStefan Popa3-8/+74
The AD5681R/AD5682R/AD5683/AD5683R are a family of one channel DACs with 12-bit, 14-bit and 16-bit precision respectively. The devices have either no built-in reference, or built-in 2.5V reference. These devices are similar to AD5691R/AD5692R/AD5693/AD5693R except with a few notable differences: * they use the SPI interface instead of I2C * in the write control register, DB18 and DB17 are used for setting the power mode, while DB16 is the REF bit. This is why a new regmap type was defined and checked accordingly. * the shift register is 24 bits wide, the first four bits are the command bits followed by the data bits. As the data comprises of 20-bit, 18-bit or 16-bit input code, this means that 4 LSB bits are don't care. This is why the data needs to be shifted on the left with four bits. Therefore, AD5683_REGMAP is checked inside a switch case in the ad5686_spi_write() function. On the other hand, similar devices such as AD5693R family, have the 4 MSB command bits followed by 4 don't care bits. Datasheet: http://www.analog.com/media/en/technical-documentation/data-sheets/AD5683R_5682R_5681R_5683.pdf Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-05-20iio:dac:ad5686: Add AD5691R/AD5692R/AD5693/AD5693R supportStefan Popa3-7/+109
The AD5691R/AD5692R/AD5693/AD5693R are a family of one channel DACs with 12-bit, 14-bit and 16-bit precision respectively. The devices have either no built-in reference, or built-in 2.5V reference. These devices are pretty similar to AD5671R/AD5675R and AD5694/AD5694R/AD5695R/AD5696/AD5696R, except that they have one channel. Another difference is that they use a write control register(addr 0x04) for setting the power down modes and the internal reference instead of separate registers for each function. Datasheet: http://www.analog.com/media/en/technical-documentation/data-sheets/AD5693R_5692R_5691R_5693.pdf Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-05-11Merge tag 'iio-for-4.18a' of ↵Greg Kroah-Hartman7-185/+912
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: 1st round of IIO new device support, features and cleanup for the 4.18 cycle A nice mix this time of excellent cleanups (many to send drivers speeding toward staging graduations) and new drivers / device support. A good part of this is Brian Masney's never ending task on the tsl2x7x driver. The end is in sight so hopefully we'll get that one out of staging very soon! New device support * AD5686 - Support AD5685R (was wrongly present as AD5685) - Support AD5672R, AD5676, AD5676, AD5684R and AD5686R 4 and 8 channel SPI DACs with various precisions. - Support AD5671R, AD5675R, AD5694, AD5694R, AD5695R, AD5696 and AD5696R I2C DACs with various percisions and numbers of channels. * Analog front end rescale driver - New driver. - Support current sensing usings a shunt resistor. - Support simple voltage dividers. - support simple current sense amplifiers. * TI dac5571 - New driver and device bindings supporting: dac5571, dac6571, dac7571, dac5574, dac6574, dac7574, dac5573, dac6573 and dac7573 * Meson-adc - Support for Meson AXG with DT bindings. * mpu6050 - Support the mpu9255 which only requires additional WHOAMI entry and compatible string. * st_lsm6dsx - Support for lsm330dlc combinded accelerometer and gyro sensors with DT bindings. * stm32_adc - Add support for STM32MP1 with bindings. Staging graduations * adis16201 after some excelent cleanup by Himanshu Jha. * adis16029 after some excelent cleanup by Shreeya Patel. New features: * ABI docs - Add core ABI docs for angle channels. * inv_mpu6050 - Provide support for the full range of interrupts the device supports. * st_accel - Add SMO8840 ACPI ID seen in the wild on some Lenovo machines. * stx104 - Provide a multiple gpio get function. Cleanups / Minor fixes * core - Use new nested structure support to improve kernel-doc. * ad2s1200 - Use be16_to_cpup instead of opencoding. * ad5686 - Indentation tidy up. - Switch to SPDX - Refactor to allow various numbers of channels. - Refactor to separate core and SPI specific support, prior to addition of i2c equivalent devices. * ad7606 - Use drvdata directly from device rather than boucing via the platform_device structure. * ad7746 - Replace opencoded byte swapped i2c calls with _swapped variants. - White space and line break readability improvements. - Reorder includes and variable declarations where appropriate. * ad7791 - Changes to the AD ADC library used by this driver took in the sampling frequency. This lead to be the wrong path being the one tied to the resulting attribute, so it didn't work, and a warning to be printed. * ad7780 - Remove apparent support for sampling frequency control on devices that don't support changing the sampling attributes. * ade7854 - Fix a read of the wrong number of bits. - Improve error handling on i2c read/write errors. - Rework i2c and spi code to reduce duplication. * adis16201 (staging) - Improve meaning inherent in some macro names by adding units etc where relevant. - Adjust comments to improve detail and drop the irrelevant. - Rename register address definitions definitions to add a _REG postfix, clearly separating them from field definitions. Reorganize the definitions to group register address and fields. - Use sign_extend32 rather than open coding. - Reverse Xmas tree ordering where appropriate and align function args. - Remove unused headers. - Use GENMASK where appropriate instead of open coding. * adis16209 (staging) - Indent field definitions to visually separate them from register address definitions. - Use reverse xmas tree ordering where appropriate. - Add some whitespace where it will help readability. - Drop some unused headers. - Use GENMASK where appropriate. * ad2s1200 - Drop unnecessary includes and reorder alphabetically. - Reverse xmas tree and blank line cleanups. * atlas-ph-sensor - Use msleep instead of usleep_range where the precise value doesn't matter and the delays are long. * bcm150 - Drop transaction splitting as core now handles it. * cros_ec - Move the shared header to the include/iio/common directory. This brings it inline with the other multiple type devices. - Use drvdata directly from device rather than boucing via the platform_device structure. * hid-sensors - Use drvdata directly from device rather than boucing via the platform_device structure. * inv_mpu6050 - Clear out a second function definition for the same function. - Don't flush fifo when the iio buffer is full but just drop excess data. - Tidy up set_power_itg and ensure it is used in the right places. - Use set_power_itg rather than opencoding it again in the i2c mux control. - Make sure error paths disable the power if undoing power on. - Used managed devm_ functions during probe. Delete remove function. - Refactor to pull raw data read out of read_raw function. - Simplify data reading error paths. - Only enable the i2c mux for chips with the i2c aux bus (not icm20608) - Fix a potential deadlock due to varying lock ordering. - Fix an issue where first sample from gyro after enabling is unstable by dropping the first sample. - Fix an issue where the user_ctrl register is incorrectly overwritten. - Tidy up some grammar and spelling minor issus. * mcp320x - Use vendor compatible strings. * mcp4018 - Switch to using i2c .probe_new. * mcp4351 - switch to using i2c .probe_new. * meson-adc - rework handing on common ADC platform data so it can be shared across multiple families of SoCs. * sca3000 - Fix an error handling path if the ring configure fails. * st_lsm6dsx - Fix a wrong fifo threshold mask (no actual effect) * stm32-dfsdm - Style fixes and cleanups. - Check filter ID is in range and check spi-max-frequency. * tsl2x7x (staging) - Drop some unnecessary function calls, unused variables and unnecessary local variables. - Fix wrong interrupt type. - Avoid unnecessary double clear of interrupt. - Simplify proximity calibration call which did various things unrelated to actually calibrating. - Separate control of the proximity and ALS interrupts. - Improve consistency of logging. - Separate ALS and proximity persistence settings as they have separate hardware controls. - Tidy up variable ordering. - Add Brian to copyright notice given consider work on this driver. - Take advantage of hardware support for I2C address auto increment. - Combine individuaal enable and period attributes for the two directions on the threshold events into a single value as the hardware doesn't separate them. - Move integration_time* attributes from light channel to intensity value as they effect the intensity readings directly and the light reading only indirectly. Hence this better reflects reality. Also move the calibscale_available. - Avoid returning an error in the IRQ handler. - Hard code the reg value in _clear_interrupts as it only takes one value in the code. Result is the function has little purpose so opencode the two remaining i2c_smbus_write_byte calls. - Drop some unnecessary checking of the chip status register. - Tidy up return path in _write_interrupt_config. - Tidy up the ID verification code. - Move the power and diode settings defines into the header as these are needed for platform data configuration. - Various renames and comment cleanups for consistency and clarity. - Use actual device defaults for default startup settings. - SPDX - Add some range sanity checking to sysfs attribute writes. - Don't provide event interfaces if the interrupt line isn't available. - Use IIO_CONST_ATTR macro for calibscale_available as it's a constant string. - Fix the integration time and lux equations. - Make device IDs explicit index values in the device_channel_config array.
2018-05-06iio: dac: add TI DAC5571 family supportSean Nyekjaer3-0/+450
This patch adds support for the Texas Intruments DAC5571 Family. Signed-off-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-04-15iio:dac:ad5686: Add AD5671R/75R/94/94R/95R/96/96R supportStefan Popa5-0/+143
The AD5694/AD5694R/AD5695R/AD5696/AD5696R are a family of 4 channel DACs with 12-bit, 14-bit and 16-bit precision respectively. The devices have either no built-in reference, or built-in 2.5V reference. The AD5671R/AD5675R are similar, except that they have 8 instead of 4 channels. These devices are similar to AD5672R/AD5676/AD5676R and AD5684/AD5684R/AD5684/AD5685R/AD5686/AD5686R, except that they use i2c instead of spi. Datasheets: http://www.analog.com/media/en/technical-documentation/data-sheets/AD5671R_5675R.pdf http://www.analog.com/media/en/technical-documentation/data-sheets/AD5696R_5695R_5694R.pdf Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-04-15iio:dac:ad5686: Refactor the driverStefan Popa5-166/+246
In this patch restructures the existing ad5686 driver by adding a module for SPI and a header file, while the baseline module deals with the chip-logic. This is a necessary step, as this driver should support in the future similar devices which differ only in the type of interface used (I2C instead of SPI). Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-04-15iio:dac:ad5686: Add AD5672R/76/76R/84R/86R supportStefan Popa1-0/+46
The AD5684R/AD5686R are a family of 4 channel DACs with 12-bit, 14-bit and 16-bit precision respectively. The devices come either with a built-in reference or no built-in reference. The AD5672R/AD5676/AD5676R are similar, except that they have 8 channels instead of 4. Datasheets: http://www.analog.com/media/en/technical-documentation/data-sheets/AD5672R_5676R.pdf http://www.analog.com/media/en/technical-documentation/data-sheets/AD5686R_5685R_5684R.pdf Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-04-15iio:dac:ad5686: Add support for AD5685RStefan Popa1-3/+4
This driver acctually supports the AD5685R device and NOT the AD5685, which does not exist. Maintain old id entry in case we have devicetrees out there which are using the wrong name. More information can be found in the datasheet: http://www.analog.com/media/en/technical-documentation/data-sheets/AD5686_5684.pdf Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-04-15iio:dac:ad5686: Add support for various number of channelsStefan Popa1-20/+25
This patch adds a new num_channels attribute as part of the ad5686_chip_info struct which replaces the AD5686_DAC_CHANNELS define. This is a necessary step, since this driver should support similar devices which differ only in the number of channels. Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-04-15iio:dac:ad5686: Change license descriptionStefan Popa1-2/+1
Add GPLv2+ SPDX identifier and remove license notice to keep the whole purpose of using an SPDx id. Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-04-15iio:dac:ad5686: Style fixes no functional changesStefan Popa1-11/+14
This patch fixes some indentation issues and does not modify the functionality of the driver. Signed-off-by: Stefan Popa <stefan.popa@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-04-05Merge tag 'gpio-v4.17-1' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio Pull GPIO updates from Linus Walleij: "This is the bulk of GPIO changes for the v4.17 kernel cycle: New drivers: - Nintendo Wii GameCube GPIO, known as "Hollywood" - Raspberry Pi mailbox service GPIO expander - Spreadtrum main SC9860 SoC and IEC GPIO controllers. Improvements: - Implemented .get_multiple() callback for most of the high-performance industrial GPIO cards for the ISA bus. - ISA GPIO drivers now select the ISA_BUS_API instead of depending on it. This is merged with the same pattern for all the ISA drivers and some other Kconfig cleanups related to this. Cleanup: - Delete the TZ1090 GPIO drivers following the deletion of this SoC from the ARM tree. - Move the documentation over to driver-api to conform with the rest of the kernel documentation build. - Continue to make the GPIO drivers include only <linux/gpio/driver.h> and not the too broad <linux/gpio.h> that we want to get rid of. - Managed to remove VLA allocation from two drivers pending more fixes in this area for the next merge window. - Misc janitorial fixes" * tag 'gpio-v4.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (77 commits) gpio: Add Spreadtrum PMIC EIC driver support gpio: Add Spreadtrum EIC driver support dt-bindings: gpio: Add Spreadtrum EIC controller documentation gpio: ath79: Fix potential NULL dereference in ath79_gpio_probe() pinctrl: qcom: Don't allow protected pins to be requested gpiolib: Support 'gpio-reserved-ranges' property gpiolib: Change bitmap allocation to kmalloc_array gpiolib: Extract mask allocation into subroutine dt-bindings: gpio: Add a gpio-reserved-ranges property gpio: mockup: fix a potential crash when creating debugfs entries gpio: pca953x: add compatibility for pcal6524 and pcal9555a gpio: dwapb: Add support for a bus clock gpio: Remove VLA from xra1403 driver gpio: Remove VLA from MAX3191X driver gpio: ws16c48: Implement get_multiple callback gpio: gpio-mm: Implement get_multiple callback gpio: 104-idi-48: Implement get_multiple callback gpio: 104-dio-48e: Implement get_multiple callback gpio: pcie-idio-24: Implement get_multiple/set_multiple callbacks gpio: pci-idio-16: Implement get_multiple callback ...
2018-03-07iio: Replace occurrences of magic number 0 by IIO_CHAN_INFO_RAWRodrigo Siqueira2-2/+2
Usually, functions responsible for reading raw data typically relies on values from iio_chan_info_enum to correctly identify the type of data to be read. There is a set of a device driver that uses the magic number 0 instead of IIO_CHAN_INFO_RAW. This patch improves the readability by replaces the magic number 0 for the appropriate IIO_CHAN_INFO_RAW in six devices driver in the IIO subsystem. Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-02-22iio: Change ISA_BUS_API dependency to selectionWilliam Breathitt Gray1-1/+2
The ISA_BUS_API Kconfig option enables the compilation of the ISA bus driver. The ISA bus driver does not perform any hardware interaction, and is instead just a thin layer of software abstraction to eliminate boilerplate code common to ISA-style device drivers. Since ISA_BUS_API has no dependencies and does not jeopardize the integrity of the system when enabled, drivers should select it when the ISA bus driver functionality is needed. Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2018-01-08iio: dac: mcp4725: Remove unneeded conversions to boolAndrew F. Davis1-1/+1
Found with scripts/coccinelle/misc/boolconv.cocci. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-01-08iio: stm32: Adopt SPDX identifierBenjamin Gaignard3-41/+3
Add SPDX identifier in stm32's files in IIO directory Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com> Acked-by: Fabrice Gasnier <fabrice.gasnier@st.com> Acked-by: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-14Merge tag 'staging-4.15-rc1' of ↵Linus Torvalds31-28/+745
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging and IIO updates from Greg KH: "Here is the "big" staging and IIO driver update for 4.15-rc1. Lots and lots of little changes, almost all minor code cleanups as the Outreachy application process happened during this development cycle. Also happened was a lot of IIO driver activity, and the typec USB code moving out of staging to drivers/usb (same commits are in the USB tree on a persistent branch to not cause merge issues.) Overall, it's a wash, I think we added a few hundred more lines than removed, but really only a few thousand were modified at all. All of these have been in linux-next for a while. There might be a merge issue with Al's vfs tree in the pi433 driver (take his changes, they are always better), and the media tree with some of the odd atomisp cleanups (take the media tree's version)" * tag 'staging-4.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (507 commits) staging: lustre: add SPDX identifiers to all lustre files staging: greybus: Remove redundant license text staging: greybus: add SPDX identifiers to all greybus driver files staging: ccree: simplify ioread/iowrite staging: ccree: simplify registers access staging: ccree: simplify error handling logic staging: ccree: remove dead code staging: ccree: handle limiting of DMA masks staging: ccree: copy IV to DMAable memory staging: fbtft: remove redundant initialization of buf staging: sm750fb: Fix parameter mistake in poke32 staging: wilc1000: Fix bssid buffer offset in Txq staging: fbtft: fb_ssd1331: fix mirrored display staging: android: Fix checkpatch.pl error staging: greybus: loopback: convert loopback to use generic async operations staging: greybus: operation: add private data with get/set accessors staging: greybus: loopback: Fix iteration count on async path staging: greybus: loopback: Hold per-connection mutex across operations staging: greybus/loopback: use ktime_get() for time intervals staging: fsl-dpaa2/eth: Extra headroom in RX buffers ...
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-21iio: dac: ti-dac082s085: Read chip spec from device tableLukas Wunner1-9/+26
The two properties unique to each supported chip, resolution and number of channels, are currently gleaned from the chip's name. E.g. dac102s085 is a dual channel 10-bit DAC. ^^^ This was deemed unmaintainable by the subsystem maintainer once the driver is extended to support further chips, hence it was requested to add an explicit table for chip-specific information and use an enum to reference into it. This adds 17 LoC without any immediate gain, so make the change in a separate commit which can be reverted if we determine in 10 years that it was unnecessary. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-10-21iio: dac: Add Texas Instruments 8/10/12-bit 2/4-channel DAC driverLukas Wunner3-0/+362
The DACrrcS085 (rr = 08/10/12, c = 2/4) family of SPI DACs was inherited by TI when they acquired National Semiconductor in 2011. This driver was developed for and tested with the DAC082S085 built into the Revolution Pi by KUNBUS, but should work with any of the other chips as they share the same programming interface. There is also a family of I2C DACs with just a single channel called DACrr1C08x (rr = 08/10/12, x = 1/5). Their programming interface is very similar and it should be possible to extend the driver for these chips with moderate effort. Alternatively they could be integrated into ad5446.c. (The AD5301/AD5311/AD5321 use different power-down modes but otherwise appear to be comparable.) Furthermore there is a family of 8-channel DACs called DACrr8S085 (rr = 08/10/12) as well as two 16-bit DACs called DAC161Sxxx (xxx = 055/997). These are more complicated devices with support for daisy-chaining and the ability to power down each channel separately. They could either be handled by a separate driver or integrated into the present driver with a larger effort. Cc: Mathias Duckeck <m.duckeck@kunbus.de> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-10-09iio: dac: ds4422/ds4424 dac driverIsmail H. Kose3-0/+351
This patch provides an iio device driver for DS4422/DS4424 chips that support two/four channel 7-bit Sink/Source Current DAC. Signed-off-by: Ismail H. Kose <Ismail.Kose@maximintegrated.com> Signed-off-by: Ismail H. Kose <ihkose@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-09-13drivers: misc: ti_dac7512: Remove duplicate driverLukas Wunner1-0/+10
The Texas Instruments DAC7512 has the exact same pinout, programming interface and power-down modes as the Texas Instruments DAC121S101 and Analog Devices AD5320, which are already supported by the IIO driver ad5446.c. Remove the duplicate misc driver. This requires user space to migrate to the standardized IIO sysfs ABI. (In other words, it needs to change a filename.) The IIO driver supports the chip's features more fully, e.g. the ability to power down the output or choose one of the available powerdown modes. There is an oddity with the misc driver in that it initializes the SPI slave to SPI_MODE_0, in contradiction to the datasheet which specifies that data is latched in on the falling edge, implying that SPI_MODE_1 or SPI_MODE_2 must be used. Another oddity is that Kconfig and the MODULE_DESCRIPTION() claim the chip has 16-bit resolution although it actually has 12-bit. Datasheets: http://www.ti.com/lit/ds/symlink/dac7512.pdf http://www.ti.com/lit/ds/symlink/dac121s101.pdf http://www.analog.com/media/en/technical-documentation/data-sheets/AD5320.pdf Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Daniel Mack <daniel@zonque.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-09-13iio: dac: ad5446: Add IDs of compatible Texas Instruments chipsLukas Wunner2-1/+5
The Texas Instruments DAC081S101, DAC101S101 and DAC121S101 have the exact same pinout, programming interface and power-down modes as the AD5300, AD5310 and AD5320, respectively, and their datasheets declare them "a direct replacement" for the Analog Devices chips. This may not be immediately obvious to a casual observer, so add them to the supported modalias strings. Datasheets: http://www.ti.com/lit/ds/symlink/dac081s101.pdf http://www.ti.com/lit/ds/symlink/dac101s101.pdf http://www.ti.com/lit/ds/symlink/dac121s101.pdf http://www.analog.com/media/en/technical-documentation/data-sheets/AD5300.pdf http://www.analog.com/media/en/technical-documentation/data-sheets/AD5310.pdf http://www.analog.com/media/en/technical-documentation/data-sheets/AD5320.pdf Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-08-22iio:dac: drop assignment of iio_info.driver_moduleJonathan Cameron27-27/+0
The equivalent of this is now done via macro magic when the relevant register call is made. The actual structure element will shortly go away. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
2017-08-20iio: dac: stm32-dac-core: explicitly request exclusive reset controlPhilipp Zabel1-1/+1
Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting reset lines") started to transition the reset control request API calls to explicitly state whether the driver needs exclusive or shared reset control behavior. Convert all drivers requesting exclusive resets to the explicit API call so the temporary transition helpers can be removed. No functional changes. Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: linux-iio@vger.kernel.org Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-07-15iio: dac: stm32: add support for stm32f4Fabrice Gasnier1-7/+31
This adds support for STM32F4 Digital-To-Analog converter. Add compatible configuration data to handle hfsel (not present in stm32f4). Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-07-15iio: dac: stm32: fix error messageFabrice Gasnier1-1/+1
Fix error message, there's no 'st,dac-channel' property, but 'reg' (see https://lkml.org/lkml/2017/4/3/567). Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2017-05-29Merge tag 'iio-for-4.13a' of ↵Greg Kroah-Hartman2-3/+71
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: First set of new device support, features and cleanups for IIO in the 4.13 cycle Two entirely new drivers in here plus the usual range of cleanups and features. New device support * ad5064 - add ltc2631, ltc2633 and ltc2635 support. * bma180 - trivial support for bma250e (new id) * hid-sensor-rotation - add relative orientation and geometric orientation support. * isl29028 - add isl29030 support (its effectively the same part from a driver point of view) * maxim_thermocouple - add max31856 id. * meson-saradc - add meson8b SoC adc support. * ti-adc084s021 - new driver and bindings. * ti-adc108s102 - new driver and bindings. Staging graduations * isl29028 Features * bma180 - ACPI enumeration for BMA250E which is used in various x86 tablets. * hi8453 - add raw access rather than only events. * hid-sensor-hub - Implement batch mode in which we can set a threshold on the amount of time between data coming from the fifos. This is the first device to do this rather than use a watershed on the number of samples. * hts221 - power management support * lsm6dsx - add system power management support. * rpr0521 - sampling frequency read / write * stm32-trigger - add support for TRG02 triggers. * tsl2583 - runtime power management support. Cleanups * core - inkern: fix a double unlock in iio_read_available_channel_raw when raw value doesn't appear to be raw (error path). - fixup accidental sizeof pointer in iio_device_add_mask_type. * docs - fix an accidental duplicated line in sysfs-bus-iio-meas-spec. * tools - use local include/uapi headers to ensure always up to date. - increase length of allowed trigger names. * ad9834 - symbolic to octal permissions. * ade7753 - symbolic to octal permissions. - fix indentation * ade7754 - symbolic to octal permissions. * ade7758 - symbolic to octal permissions. - ade7854 - symbolic to octal permissions. * as3935 - move out of storm check to given consistent results for raw and processed values. * bmp280 - fix bme280 naming in Kconfig help. * hi8435 - avoid garbage on event after enable. - add missing in_voltage_sensing_mode_available to list possible enum options. - handle the reset gpio with the obvious polarity rather than relying on DT to provide it correctly. * hid-sensors - fix a wrong error path scrubbing of return values. * hid-sensors-accel - drop static on a local variable * hid-sensors-rotation - Add missing scale and offset property parsing support. * ina2xx - Fix a bad use of GENMASK and some typos and whitespace issues. * isl29018 - only declare the ACPI table when ACPI is enabled. * isl29028 - fix proximity sleep times. * lsm6dsx - replace ifdef CONFIG_PM with __maybe_unused to avoid the complexity of dealing with the various PM config variables. * meson-saradc - mark meson_sar_adc_data static and const. * rcar-gyroadc - derive the interface clock speed from the fck clock on the basis they are the same actual clock. - drop the now unused if clock from the bindings. * rpr0521 - disable sensor when marked as such rather than always enabling it. - poweroff if probe fails and we can talk to device. - make sure device powered off when it doesn't need to be on. - use sizeof rather than hardcoded size on value read. - whitespace fixup. - reorder channel numbers ready for buffered support which didn't quite make this pull request. * st-accel - fix platform data initialization to allow remove and reprobe. * st-pressure - fix platform data initialization to allow remove and reprobe. * tsl2x7x - S_IRUGO, S_IWUSR to octal values - rename driver for consistency with more recent drivers - drop FSF mailing address - replace DEVICE_ATTR macros with the shorter DEVICE_ATTR_RW form and relevant function renames. * zpa2326 - report an error for consistency with other error paths.
2017-05-14iio:ad5064: Add support for ltc2633 and similar devicesMike Looijmans2-3/+71
The Linear Technology LTC2631, LTC2633 and LTC2635 are very similar to the AD5064 device, in particular the LTC2627. This patch adds support for those devices. Only the LTC2633 has been tested, which is the 2-channel variant. The LTC2631 is the 1-channel, and the LTC2635 the 4-channel version. The actual DAC resolution depends on the exact chip type and can be 12, 10 or 8 bits, using the upper bits so this has no effect on the register map. The internal reference is set to 2.5V on "L" versions, and it's 4.096V for "H" versions. Datasheets: LTC2631: http://www.linear.com/docs/26553 LTC2633: http://www.linear.com/docs/39529 LTC2635: http://www.linear.com/docs/28754 Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-05-11Merge tag 'hwparam-20170420' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs Pull hw lockdown support from David Howells: "Annotation of module parameters that configure hardware resources including ioports, iomem addresses, irq lines and dma channels. This allows a future patch to prohibit the use of such module parameters to prevent that hardware from being abused to gain access to the running kernel image as part of locking the kernel down under UEFI secure boot conditions. Annotations are made by changing: module_param(n, t, p) module_param_named(n, v, t, p) module_param_array(n, t, m, p) to: module_param_hw(n, t, hwtype, p) module_param_hw_named(n, v, t, hwtype, p) module_param_hw_array(n, t, hwtype, m, p) where the module parameter refers to a hardware setting hwtype specifies the type of the resource being configured. This can be one of: ioport Module parameter configures an I/O port iomem Module parameter configures an I/O mem address ioport_or_iomem Module parameter could be either (runtime set) irq Module parameter configures an I/O port dma Module parameter configures a DMA channel dma_addr Module parameter configures a DMA buffer address other Module parameter configures some other value Note that the hwtype is compile checked, but not currently stored (the lockdown code probably won't require it). It is, however, there for future use. A bonus is that the hwtype can also be used for grepping. The intention is for the kernel to ignore or reject attempts to set annotated module parameters if lockdown is enabled. This applies to options passed on the boot command line, passed to insmod/modprobe or direct twiddling in /sys/module/ parameter files. The module initialisation then needs to handle the parameter not being set, by (1) giving an error, (2) probing for a value or (3) using a reasonable default. What I can't do is just reject a module out of hand because it may take a hardware setting in the module parameters. Some important modules, some ipmi stuff for instance, both probe for hardware and allow hardware to be manually specified; if the driver is aborts with any error, you don't get any ipmi hardware. Further, trying to do this entirely in the module initialisation code doesn't protect against sysfs twiddling. [!] Note that in and of itself, this series of patches should have no effect on the the size of the kernel or code execution - that is left to a patch in the next series to effect. It does mark annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in an already existing field" * tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits) Annotate hardware config module parameters in sound/pci/ Annotate hardware config module parameters in sound/oss/ Annotate hardware config module parameters in sound/isa/ Annotate hardware config module parameters in sound/drivers/ Annotate hardware config module parameters in fs/pstore/ Annotate hardware config module parameters in drivers/watchdog/ Annotate hardware config module parameters in drivers/video/ Annotate hardware config module parameters in drivers/tty/ Annotate hardware config module parameters in drivers/staging/vme/ Annotate hardware config module parameters in drivers/staging/speakup/ Annotate hardware config module parameters in drivers/staging/media/ Annotate hardware config module parameters in drivers/scsi/ Annotate hardware config module parameters in drivers/pcmcia/ Annotate hardware config module parameters in drivers/pci/hotplug/ Annotate hardware config module parameters in drivers/parport/ Annotate hardware config module parameters in drivers/net/wireless/ Annotate hardware config module parameters in drivers/net/wan/ Annotate hardware config module parameters in drivers/net/irda/ Annotate hardware config module parameters in drivers/net/hamradio/ Annotate hardware config module parameters in drivers/net/ethernet/ ...
2017-04-20Annotate hardware config module parameters in drivers/iio/David Howells1-1/+1
When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/iio/. Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk> Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Acked-by: Jonathan Cameron <jic23@kernel.org> cc: linux-iio@vger.kernel.org
2017-04-18Merge tag 'iio-fixes-for-4.11e' of ↵Greg Kroah-Hartman1-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: Fifth set of IIO fixes for the 4.11 cycle. As these are rather late in the cycle, they may sneak over into 4.12. There is a fix for a regression caused by another fix (hid sensors hardware seems to vary a lot in how various corner cases are handled). * ad7303 - fix channel description. Numeric values were being passed as characters presumably leading to garbage from the userspace interface. * as3935 - the write data macro was wrong so fix it. * bmp280 - incorrect handling of negative values as being unsigned broke humidity calculation. * hid-sensor - Restore the poll and hysteresis values after resume as some hardware doesn't do it. * stm32-trigger - buglet in reading the sampling frequency
2017-04-14iio: dac: add support for stm32 DACFabrice Gasnier5-0/+582
Add support for STMicroelectronics STM32 DAC. It's a 12-bit, voltage output digital-to-analog converter. It has two output channels, each with its own converter. It supports 8 bits or 12bits left/right aligned data format. Only 12bits right-aligned is used here. It has built-in noise or triangle waveform generator, and supports external triggers for conversions. Each channel can be used independently, with separate trigger, then separate IIO devices are used to handle this. Core driver is intended to share common resources such as clock, reset, reference voltage and registers. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-04-14iio: dac: ad7303: fix channel descriptionPavel Roskin1-3/+3
realbits, storagebits and shift should be numbers, not ASCII characters. Signed-off-by: Pavel Roskin <plroskin@gmail.com> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-04-02iio: dac: ad5504: Remove unnecessary cast on void pointersimran singhal1-1/+1
The following Coccinelle script was used to detect this: @r@ expression x; void* e; type T; identifier f; @@ ( *((T *)e) | ((T *)x)[...] | ((T*)x)->f | - (T*) e ) Signed-off-by: simran singhal <singhalsimran0@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-03-30iio: dac: ad5504: constify attribute_group structuressimran singhal1-1/+1
Check for attribute_group structures that are only stored in the event_attrs filed of iio_info structure. As the event_attrs field of iio_info structures is constant, so these attribute_group structures can also be declared constant. Done using coccinelle: @r1 disable optional_qualifier @ identifier i; position p; @@ static struct attribute_group i@p = {...}; @ok1@ identifier r1.i; position p; struct iio_info x; @@ x.event_attrs=&i@p; @bad@ position p!={r1.p,ok1.p}; identifier r1.i; @@ i@p @depends on !bad disable optional_qualifier@ identifier r1.i; @@ static +const struct attribute_group i={...}; @depends on !bad disable optional_qualifier@ identifier r1.i; @@ +const struct attribute_group i; File size before: text data bss dec hex filename 3046 360 0 3406 d4e drivers/iio/dac/ad5504.o File size after: text data bss dec hex filename 3110 296 0 3406 d4e drivers/iio/dac/ad5504.o Signed-off-by: simran singhal <singhalsimran0@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-03-21iio: dac: Add support for ltc2632 DACsMaxime Roussin-Belanger3-0/+325
Add support for Linear Technology LTC2632 (SPI) family of· dual 12- 10-, and 8-bits output DACs. Signed-off-by: Maxime Roussin-Belanger <maxime.roussinbelanger@gmail.com> Signed-off-by: Jean-Francois Dagenais <jeff.dagenais@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-03-19iio: dac: max5821: Set .of_match_table to OF device ID tableJavier Martinez Canillas1-0/+1
The driver has a OF device ID table but the struct i2c_driver .of_match_table field is not set. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-03-19iio: dac: mcp4725: Add OF device ID tableJavier Martinez Canillas1-2/+22
The driver doesn't have a struct of_device_id table but supported devices are registered via Device Trees. This is working on the assumption that a I2C device registered via OF will always match a legacy I2C device ID and that the MODALIAS reported will always be of the form i2c:<device>. But this could change in the future so the correct approach is to have an OF device ID table if the devices are registered via OF. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2017-02-19iio: cio-dac: Set parent deviceLars-Peter Clausen1-0/+1
Initialize the parent of the IIO device to the device that registered it. This makes sure that the IIO device appears the right level in the device hierarchy. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-12-30iio: dac: ad5593r: Add ACPI supportMichael Hennerich1-0/+8
This patch adds the ACPI/PNP ID. The AD5592/3 driver core is already designed around the unified device property API. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-12-30iio: dac: ad5592r: Add ACPI supportMichael Hennerich1-0/+8
This patch adds the ACPI/PNP ID. The AD5592/3 driver core is already designed around the unified device property API. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-11-13iio: dpot-dac: DAC driver based on a digital potentiometerPeter Rosin3-0/+277
It is assumed that the dpot is used as a voltage divider between the current dpot wiper setting and the maximum resistance of the dpot. The divided voltage is provided by a vref regulator. .------. .-----------. | | | vref |--' .---. | regulator |--. | | '-----------' | | d | | | p | | | o | wiper | | t |<---------+ | | | | '---' dac output voltage | | '------+------------+ Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-10-23iio: dac: mcp4725: fix odd_ptr_err.cocci warningsJulia Lawall1-1/+1
PTR_ERR should access the value just tested by IS_ERR Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci CC: Tomas Novotny <tomas@novotny.cz> Signed-off-by: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-10-23iio: dac: mcp4725: add devicetree supportTomas Novotny1-6/+37
Signed-off-by: Tomas Novotny <tomas@novotny.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-10-23iio: dac: mcp4725: support voltage reference selectionTomas Novotny1-7/+92
MCP47x6 chip supports selection of a voltage reference (VDD, VREF buffered or unbuffered). MCP4725 doesn't have this feature thus the eventual setting is ignored and user is warned. The setting is stored only in the volatile memory of the chip. You need to manually store it to the EEPROM of the chip via 'store_eeprom' sysfs entry. Signed-off-by: Tomas Novotny <tomas@novotny.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
2016-10-23iio: dac: mcp4725: fix incorrect commentTomas Novotny1-1/+1
Number 2 is referencing to the settings with the largest available resistor. No functional change. Signed-off-by: Tomas Novotny <tomas@novotny.cz> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-27 05:26:52 +0300