summaryrefslogtreecommitdiff
path: root/drivers/staging/iio/resolver/ad2s1210.c
AgeCommit message (Collapse)AuthorFilesLines
2023-10-12iio: resolver: ad2s1210: move out of stagingDavid Lechner1-1522/+0
This moves the ad2s1210 resolver driver out of staging. The driver has been fixed up and is ready to graduate. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231010-ad2s1210-mainline-v5-4-35a0f6ffa04a@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-12staging: iio: resolver: ad2s1210: simplify code with guard(mutex)David Lechner1-104/+49
We can simplify the code and get rid of most of the gotos by using guard(mutex) from cleanup.h. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231010-ad2s1210-mainline-v5-3-35a0f6ffa04a@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-12staging: iio: resolver: ad2s1210: clear faults after soft resetDavid Lechner1-1/+24
When a software reset is performed on the AD2S1210 to make the selected excitation frequency take effect, it always triggers faults on the input signals because the output signal is interrupted momentarily. So we need to clear the faults after the software reset to avoid triggering fault events the next time a sample is read. The datasheet specifies a time t[track] in Table 27 that specifies the settle time in milliseconds after a reset depending on the selected resolution. This is used in the driver to add an appropriate delay. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231010-ad2s1210-mainline-v5-2-35a0f6ffa04a@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-12staging: iio: resolver: ad2s1210: refactor sample toggleDavid Lechner1-8/+22
This refactors the sample line toggle in the ad2s1210 resolver driver to a separate function. The sample has some timing requirements, so this ensures that it is always done the same way, both in the existing call sites and any future usage. Previously, the sample line was kept on for the duration of the read, but this is not necessary. Data is latched in on the rising edge and after the specified delay the state of the sample line does not matter. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231010-ad2s1210-mainline-v5-1-35a0f6ffa04a@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: remove fault attributeDavid Lechner1-57/+0
Faults have been converted to events and we are now polling the fault register each time we read a sample, so we no longer need the fault attribute. This attribute was not suitable for promotion out of staging anyway since it was returning multiple values in a single attribute. The fault clearing feature should not be needed unless we need to support the fault output pins on the chip which is not currently supported. So we can add this feature back in if we need it later. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-16-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: add label attribute supportDavid Lechner1-0/+29
The ad2s1210 resolver driver has quite a few channels, mostly for internal signals for event support. This makes it difficult to know which channel is which. This patch adds a label attribute to the channels to make it easier to identify them. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-15-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: add register/fault support summaryDavid Lechner1-0/+40
The ad2s1210 driver shoe-horns the register and fault support into IIO events. The mapping between the registers/faults and the events is not obvious. To save users from having to read the entire driver to figure out how to use it, add a summary of the register/fault support to the top of the file. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-14-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: implement fault eventsDavid Lechner1-14/+197
When reading the position and velocity on the AD2S1210, there is also a 3rd byte following the two data bytes that contains the fault flag bits. This patch adds support for reading this byte and generating events when faults occur. The faults are mapped to various channels and event type in order to have a unique event for each fault. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-13-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: rename DOS reset min/max attrsDavid Lechner1-44/+55
The AD2S1210 has a programmable threshold for the degradation of signal (DOS) mismatch fault. This fault is triggered when the difference in amplitude between the sine and cosine inputs exceeds the threshold. The DOS reset min/max registers on the chip provide initial values for internal tracking of the min/max of the monitor signal after the fault register is cleared. This patch converts the custom device DOS reset min/max threshold attributes custom event attributes on the monitor signal channel. The attributes now use millivolts instead of the raw register value in accordance with the IIO ABI. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-11-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: convert DOS mismatch threshold to event attrDavid Lechner1-4/+15
The AD2S1210 has a programmable threshold for the degradation of signal (DOS) mismatch fault. This fault is triggered when the difference in voltage between the sine and cosine inputs exceeds the threshold. In other words, when the magnitude of sine and cosine inputs are equal, the AC component of the monitor signal is zero and when the magnitudes of the sine and cosine inputs are not equal, the AC component of the monitor signal is the difference between the sine and cosine inputs. So the fault occurs when the magnitude of the AC component of the monitor signal exceeds the DOS mismatch threshold voltage. This patch converts the custom device DOS mismatch threshold attribute to an event magnitude attribute on the monitor signal channel. The attribute now uses millivolts instead of the raw register value in accordance with the IIO ABI. Emitting the event will be implemented in a later patch. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-10-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: convert DOS overrange threshold to event attrDavid Lechner1-4/+16
The AD2S1210 has a programmable threshold for the degradation of signal (DOS) overrange fault. This fault is triggered when either the sine or cosine input rises above the threshold voltage. This patch converts the custom device DOS overrange threshold attribute to an event rising edge threshold attribute on the monitor signal channel. The attribute now uses millivolts instead of the raw register value in accordance with the IIO ABI. Emitting the event will be implemented in a later patch. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-9-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: convert LOS threshold to event attrDavid Lechner1-4/+72
The AD2S1210 has a programmable threshold for the loss of signal (LOS) fault. This fault is triggered when either the sine or cosine input falls below the threshold voltage. This patch converts the custom device LOS threshold attribute to an event falling edge threshold attribute on a new monitor signal channel. The monitor signal is an internal signal that combines the amplitudes of the sine and cosine inputs as well as the current angle and position output. This signal is used to detect faults in the input signals. The attribute now uses millivolts instead of the raw register value in accordance with the IIO ABI. Emitting the event will be implemented in a later patch. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-8-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: convert LOT threshold attrs to event attrsDavid Lechner1-8/+183
The AD2S1210 monitors the internal error signal (difference between estimated angle and measured angle) to determine a loss of position tracking (LOT) condition. When the error value exceeds a threshold, a fault is triggered. This threshold is user-configurable. This patch converts the custom lot_high_thrd and lot_low_thrd attributes in the ad2s1210 driver to standard event attributes. This will allow tooling to be able to expose these in a generic way. Since the low threshold determines the hysteresis, it requires some special handling to expose the difference between the high and low register values as the hysteresis instead of exposing the low register value directly. The attributes also return the values in radians now as required by the ABI. Actually emitting the fault event will be done in a later patch. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-7-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: add triggered buffer supportDavid Lechner1-1/+82
This adds support for triggered buffers to the AD2S1210 resolver driver. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-6-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: add phase lock range supportDavid Lechner1-0/+125
The AD2S1210 chip has a phase lock range feature that allows selecting the allowable phase difference between the excitation output and the sine and cosine inputs. This can be set to either 44 degrees (default) or 360 degrees. This patch adds a new phase channel with a phase0_mag_rising event that can be used to configure the phase lock range. Actually emitting the event will be added in a subsequent patch. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-5-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: convert resolution to devicetree propertyDavid Lechner1-79/+71
Selecting the resolution was implemented as the `bits` sysfs attribute. However, the selection of the resolution depends on how the hardware is wired and the specific application, so this is rather a job for devicetree to describe. A new devicetree property `assigned-resolution-bits` to specify the resolution required for each chip is added and the `bits` sysfs attribute is removed. Since the resolution is now supplied by a devicetree property, the resolution-gpios are now optional and we can allow for the case where the resolution pins on the AD2S1210 are hard-wired instead of requiring them to be connected to gpios. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-4-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: convert fexcit to channel attributeDavid Lechner1-52/+71
The ad2s1210 driver has a device-specific attribute `fexcit` for setting the frequency of the excitation output. This converts it to a channel in order to use standard IIO ABI. The excitation frequency is an analog output that generates a sine wave. Only the frequency is configurable. According to the datasheet, the specified range of the excitation frequency is from 2 kHz to 20 kHz and can be set in increments of 250 Hz. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-3-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: implement hysteresis as channel attrDavid Lechner1-3/+88
The AD2S1210 resolver has a hysteresis feature that can be used to prevent flicker in the LSB of the position register. This can be either enabled or disabled. Disabling hysteresis is useful for increasing precision by oversampling. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-2-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-11staging: iio: resolver: ad2s1210: do not use fault register for dummy readDavid Lechner1-2/+3
When reading registers on the AD2S1210 chip, we have to supply a "dummy" address for the second SPI tx byte so that we don't accidentally write to a register. This register will be read and the value discarded on the next regmap read or write call. Reading the fault register has a side-effect of clearing the faults so we should not use this register for the dummy read. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20231005-ad2s1210-mainline-v4-1-ec00746840fc@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-05staging: iio: resolver: ad2s1210: read excitation frequency from control ↵David Lechner1-4/+15
register This modifies the ad2s1210_show_fexcit() function to read the excitation frequency from the control register. This way we don't have to keep track of the value and don't risk returning a stale value. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-16-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-05staging: iio: resolver: ad2s1210: refactor setting excitation frequencyDavid Lechner1-32/+34
This combines the ad2s1210_update_frequency_control_word() and ad2s1210_soft_reset() functions into a single function since they both have to be called together. (The software reset does not reset any configuration registers, it only updates the excitation output and resets the tracking loop.) Also clean up a few things while touching this: - move AD2S1210_DEF_EXCIT macro with similar macros - remove unnecessary dev_err() calls Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-15-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-10-05staging: iio: resolver: ad2s1210: rework gpiosDavid Lechner1-79/+85
- Remove "adi," prefix from gpio names. - Sample gpio is now expected to be active low. - Convert A0 and A1 gpios to "mode-gpios" gpio array. - Convert RES0 and RES1 gpios to "resolution-gpios" gpio array. - Remove extraneous lookup tables. - Remove unused mode field from state struct. - Swap argument order of ad2s1210_set_mode() while we are touching this. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-13-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-30staging: iio: resolver: ad2s1210: remove config attributeDavid Lechner1-47/+0
This removes the config register sysfs attribute. Writing to the config register directly can be dangerous and userspace should not need to have to know the register layout. This register can still be accessed though debugfs if needed. We can add new attributes to set specific flags in the config register in the future if needed (e.g. `enable_hysterisis` and `phase_lock_range`). Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-12-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-30staging: iio: resolver: ad2s1210: add debugfs reg accessDavid Lechner1-0/+20
This add an implementation of debugfs_reg_access for the AD2S1210 driver. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-11-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-30staging: iio: resolver: ad2s1210: use regmap for config registersDavid Lechner1-104/+155
This makes use of the regmap API to read and write the configuration registers. This simplifies code quite a bit and makes it safer (previously, it was easy to write a bad value to the config registers which causes the chip to lock up and need to be reset). This chip has multiple modes of operation. In normal mode, we do not use regmap since there is no addressing - data is just bitshifted out during the SPI read. In config mode, we use regmap since it requires writing the address (with read/write flag) before reading and writing. We don't use the lock provided by the regmap because we need to also synchronize with the normal mode SPI reads and with the various GPIOs. There is also a quirk when reading registers (other than the fault register). If the address/data bit is set in the value read, then it indicates there is a configuration parity error and the data is not valid. Previously, this was checked in a few places, but not consistently. Now, we always check it in the regmap read function. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-10-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-30staging: iio: resolver: ad2s1210: use devicetree to get CLKIN rateDavid Lechner1-52/+29
This removes the fclkin sysfs attribute and replaces it with getting the CLKIN clock rate using the clk subsystem (i.e. from the devicetree). CLKIN comes from an external oscillator that is connected directly to the AD2S1210 chip, so users of the sysfs attributes should not need to be concerned with this. The fclkin field (the datasheet name) is renamed to clkin_hz to be more obvious that it is a frequency in Hz. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-9-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-30staging: iio: resolver: ad2s1210: implement IIO_CHAN_INFO_SCALEDavid Lechner1-8/+45
This adds an implementation of IIO_CHAN_INFO_SCALE to the ad2s1210 resolver driver. This allows userspace to get the scale factor for the raw values. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-8-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-30staging: iio: resolver: ad2s1210: always use 16-bit value for raw readDavid Lechner1-16/+8
This removes the special handling for resolutions lower than 16 bits. This will allow us to use a fixed scale independent of the resolution. A new sample field is added to store the raw data instead of reusing the config mode rx buffer so that we don't have to do a cast or worry about unaligned access. Also, for the record, according to the datasheet, the logic for the special handling based on hysteresis that was removed was incorrect. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-7-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-30staging: iio: resolver: ad2s1210: sort importsDavid Lechner1-6/+6
There are quite a few imports and we will be adding more so it will make it easier to read if they are sorted. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-6-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-30staging: iio: resolver: ad2s1210: remove spi_set_drvdata()David Lechner1-2/+0
Since we never call spi_get_drvdata(), we can remove spi_set_drvdata(). Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-5-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-30staging: iio: resolver: ad2s1210: check return of ad2s1210_initial()David Lechner1-1/+4
This adds a check to the return value of ad2s1210_initial() since it can fail. The call is also moved before devm_iio_device_register() so that we don't have to unregister the device if it fails. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-4-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-30staging: iio: resolver: ad2s1210: remove call to spi_setup()David Lechner1-2/+0
This removes the call to spi_setup() in the ad2s1210 driver. Setting MODE_3 was incorrect. It should be MODE_1 but we can let the device tree select this and avoid the need to call spi_setup(). Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-3-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-30staging: iio: resolver: ad2s1210: fix use before initializationDavid Lechner1-3/+4
This fixes a use before initialization in ad2s1210_probe(). The ad2s1210_setup_gpios() function uses st->sdev but it was being called before this field was initialized. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-2-fa4364281745@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-24staging: iio: resolver: ad2s1210: fix not restoring sample gpio in channel readDavid Lechner1-2/+2
In theory, this code path should not be reachable because of the previous switch statement. But just in case we should make sure we are restoring the SAMPLE gpio to its original state before returning in addition to releasing the mutex lock. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230921144400.62380-5-dlechner@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-09-24staging: iio: resolver: ad2s1210: fix ad2s1210_show_faultDavid Lechner1-1/+1
When reading the fault attribute, an empty string was printed if the fault register value was non-zero. This is fixed by checking that the return value is less than zero instead of not zero. Also always print two hex digits while we are touching this line. Signed-off-by: David Lechner <dlechner@baylibre.com> Link: https://lore.kernel.org/r/20230921144400.62380-4-dlechner@baylibre.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2023-04-27Merge tag 'staging-6.4-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver updates from Greg KH: "Here is the large set of staging driver updates for 6.4-rc1. Once again, we removed more code than was added, a nice trend. It was a calm cycle, mostly all just small coding style cleanups, included in here are: - removal of the greybus loopback testing tools, userspace code that didn't belong in a driver subdirectory and was causing problems for some build systems - platform remove callback cleanups - rtl8192e huge cleanups - other small staging driver cleanups. All of these have been in linux-next for a while with no reported problems" * tag 'staging-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (185 commits) staging: rtl8192e: Fix W_DISABLE# does not work after stop/start staging: rtl8192e: Remove unchanged variables bfsync_processing and more staging: rtl8192e: Remove unchanged variable frame_sync_monitor staging: rtl8192e: Remove unchanged variable chan_forced staging: rtl8192e: Remove set to true while true of bfirst_after_down staging: rtl8192e: Remove second initialization of bActuallySet staging: rtl8192e: Remove unused macro RT_SET_PS_LEVEL staging: rtl8192e: Remove unused function rtl92e_disable_nic staging: rtl8192e: Remove unchanged variable RegRfPsLevel staging: rtl8172: Add blank lines after declarations staging: rtl8192e: Remove unused variable RF_Type staging: rtl8192e: Remove one of two checks for hardware RTL8192SE staging: rtl8192e: Remove unused function _rtl92e_dm_init_wa_broadcom_iot staging: rtl8192e: Remove macro IS_HARDWARE_TYPE_8192SE staging: greybus: drop loopback test files staging: rtl8192e: Add blank lines after declarations staging: rtl8192e: avoid CamelCase <dot11RSNAStatsCCMPDecryptErrors> staging: rtl8192e: avoid CamelCase <dot11RSNAStatsCCMPReplays> staging: rtl8192e: avoid CamelCase <dot11RSNAStatsCCMPFormatErrors> staging: rtl8192e: fix alignment to match open parenthesis ...
2023-04-06staging: iio: resolver: ad2s1210: Add explicit include for of.hRob Herring1-0/+1
With linux/acpi.h no longer implicitly including of.h, add an explicit include of of.h to fix the following error: drivers/staging/iio/resolver/ad2s1210.c:706:21: error: implicit declaration of function 'of_match_ptr' is invalid in C99 [-Werror,-Wimplicit-function-declaration] Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-03-28staging: iio: resolver: ads1210: fix config modeNuno Sá1-1/+1
As stated in the device datasheet [1], bits a0 and a1 have to be set to 1 for the configuration mode. [1]: https://www.analog.com/media/en/technical-documentation/data-sheets/ad2s1210.pdf Fixes: b19e9ad5e2cb9 ("staging:iio:resolver:ad2s1210 general driver cleanup") Cc: stable <stable@kernel.org> Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20230327145414.1505537-1-nuno.sa@analog.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-08-16staging: iio: resolver: ad2s1210: Fix alignment for DMA safetyJonathan Cameron1-2/+2
____cacheline_aligned is an insufficient guarantee for non-coherent DMA on platforms with 128 byte cachelines above L1. Switch to the updated IIO_DMA_MINALIGN definition. As the tx[] an rx[] buffers are only used in the same SPI exchanges, we should be safe with them on the same cacheline. Hence only mark the first one __aligned(IIO_DMA_MINALIGN). Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220807151218.656881-5-jic23@kernel.org
2022-04-20staging: iio: ad2s1210: remove redundant assignment to variable negativeColin Ian King1-1/+0
Variable negative is being assigned a value that is never read, it is being re-assigned later. The assignment is redundant and can be removed. Cleans up clang scan build warning: drivers/staging/iio/resolver/ad2s1210.c:502:3: warning: Value stored to 'negative' is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20220418134603.81336-1-colin.i.king@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-06-14iio: remove explicit IIO device parent assignmentAlexandru Ardelean1-1/+0
This patch applies the semantic patch: @@ expression I, P, SP; @@ I = devm_iio_device_alloc(P, SP); ... - I->dev.parent = P; It updates 302 files and does 307 deletions. This semantic patch also removes some comments like '/* Establish that the iio_dev is a child of the i2c device */' But this is is only done in case where the block is left empty. The patch does not seem to cover all cases. It looks like in some cases a different variable is used in some cases to assign the parent, but it points to the same reference. In other cases, the block covered by ... may be just too big to be covered by the semantic patch. However, this looks pretty good as well, as it does cover a big bulk of the drivers that should remove the parent assignment. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2020-05-03staging: iio: ad2s1210: Fix SPI readingDragos Bogdan1-5/+12
If the serial interface is used, the 8-bit address should be latched using the rising edge of the WR/FSYNC signal. This basically means that a CS change is required between the first byte sent, and the second one. This change splits the single-transfer transfer of 2 bytes into 2 transfers with a single byte, and CS change in-between. Note fixes tag is not accurate, but reflects a point beyond which there are too many refactors to make backporting straight forward. Fixes: b19e9ad5e2cb ("staging:iio:resolver:ad2s1210 general driver cleanup.") Signed-off-by: Dragos Bogdan <dragos.bogdan@analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-07-28staging: iio: ad2s1210: Use device-managed APIChuhong Yuan1-11/+1
Use device-managed API to simplify the code. The remove function is redundant now and can be deleted. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-06-17staging: iio: ad2s1210: Remove platform data NULL check in probeAlexandru Ardelean1-3/+0
The driver only needs to access GPIOs via GPIOLIB. And SPI can be configured via device-tree or ACPI. The platform data is a remnant from another time, and should not cause the driver to error out during probing if it is NULL. Also, it's not used. Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2019-04-03staging: iio: add proper SPDX identifiers to remaining driver filesGreg Kroah-Hartman1-5/+1
There are a number of IIO staging drivers that do not have a proper SPDX identifier on it. So fix that up and at the same time, remove the "free form" license text, as that's pretty much impossible for any tool to parse. Cc: Lars-Peter Clausen <lars@metafoo.de> Cc: Michael Hennerich <Michael.Hennerich@analog.com> Cc: Jonathan Cameron <jic23@kernel.org> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-11staging: iio: ad2s1210: Add device tree table.Nishad Kamdar1-0/+7
Add device tree table for matching vendor ID. Note that as the driver is still heavily in flux and there are some non obvious aspects to a comprehensive binding, that binding will be submitted at a later date (before leaving staging!) Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-11-11staging: iio: ad2s1210: Drop the gpioin flag.Nishad Kamdar1-44/+8
Drop gpioin flag which decides how the GPIOs are controlled as the GPIOs must be outputs for the host as per the datasheet. Removes need for platform data so that is dropped as well. Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-11-11staging: iio: ad2s1210: Switch to the gpio descriptor interfaceNishad Kamdar1-44/+63
Use the gpiod interface instead of the deprecated old non-descriptor interface. Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-10-08staging: iio: ad2s1210: fix 'assignment operator' style checksMatheus Tavares1-4/+4
This patch fixes all "Assignment operator '=' should be on the previous line" checks found in ad2s1210.c with checkpatch.pl. Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2018-03-10staging:iio:ad2s1210: Remove old_data from ad2s1210_stateRodrigo Siqueira1-3/+0
The variable old_data is a bool type, which only receives the value 'true' in the function ad2s1210_config_write and ad2s1210_config_read. There is no other use for this variable. This patch removes old_data from the ad2s1210_state and from all the function that use it. Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>