- 05 Oct, 2023 18 commits
-
-
David Lechner authored
This adds new DeviceTree bindings for the Analog Devices, Inc. AD2S1210 resolver-to-digital converter. Co-developed-by: Apelete Seketeli <aseketeli@baylibre.com> Signed-off-by: Apelete Seketeli <aseketeli@baylibre.com> Signed-off-by: David Lechner <dlechner@baylibre.com> Acked-by: Michael Hennerich <michael.hennerich@analog.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230929-ad2s1210-mainline-v3-1-fa4364281745@baylibre.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Justin Stitt authored
strncpy() is deprecated for use on NUL-terminated destination strings [1]. We should prefer more robust and less ambiguous string interfaces. We expect adc->chan_name[val] to be NUL-terminated based on ch_name's use within functions that expect NUL-terminated strings like strncmp and printf-likes: | if (!strncmp(stm32_adc_ic[i].name, ch_name, STM32_ADC_CH_SZ)) { | /* Check internal channel availability */ | switch (i) { | case STM32_ADC_INT_CH_VDDCORE: | if (!adc->cfg->regs->or_vddcore.reg) | dev_warn(&indio_dev->dev, | "%s channel not available\n", ch_name); ... There is no evidence that NUL-padding is needed either. Considering the above, a suitable replacement is strscpy() [2] due to the fact that it guarantees NUL-termination on the destination buffer without unnecessarily NUL-padding. If, for any reason, NUL-padding _is_ required we should go for `strscpy_pad`. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230921-strncpy-drivers-iio-adc-stm32-adc-c-v1-1-c50eca098597@google.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
George Stark authored
Add log messages for errors that may occur at the probe stage Signed-off-by: George Stark <gnstark@sberdevices.ru> Link: https://lore.kernel.org/r/20230721102413.255726-3-gnstark@sberdevices.ruSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Matti Vaittinen authored
dt-bindings: iio: Add KX132ACR-LBZ accelerometer ROHM KX132ACR-LBZ is an accelerometer for industrial applications. It has a subset of KX022A functionalities, dropping support for tap, free fall and tilt detection engines. Also, the register interface is an exact subset of what is found on KX022A (except the WHO_AM_I register value). Add support for KX132ACR-LBZ. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/272065b9f35b817aff86b7760ff1aaaaaaa969f5.1695879676.git.mazziesaccount@gmail.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Matti Vaittinen authored
ROHM KX132ACR-LBZ is an accelerometer for industrial applications. It has a subset of KX022A functionalities, dropping support for tap, free fall and tilt detection engines. Also, the register interface is an exact subset of what is found on KX022A. Extend the kionix,kx022a.yaml file to support the KX132ACR-LBZ device Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/5c9e03ffad5e6e5970d6e71fb02eab4b652e109f.1695879676.git.mazziesaccount@gmail.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alisa-Dariana Roman authored
Instead of using the f_order member of ad7192_state, a function that computes the f_order coefficient makes more sense. This coefficient is a function of the sinc filter and chop filter states. Remove f_order member of ad7192_state structure. Instead use ad7192_compute_f_order function to compute the f_order coefficient according to the sinc filter and chop filter states passed as parameters. Add ad7192_get_f_order function that returns the current f_order coefficient of the device. Add ad7192_compute_f_adc function that computes the f_adc value according to the sinc filter and chop filter states passed as parameters. Add ad7192_get_f_adc function that returns the current f_adc value of the device. Signed-off-by: Alisa-Dariana Roman <alisa.roman@analog.com> Link: https://lore.kernel.org/r/20230924215148.102491-3-alisadariana@gmail.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Alisa-Dariana Roman authored
Include bitfield.h and update driver to use bitfield access macros GENMASK, FIELD_PREP and FIELD_GET. Remove old macros in favor of using FIELD_PREP and masks. Change %d to %ld to match the type of FIELD_GET(). Signed-off-by: Alisa-Dariana Roman <alisa.roman@analog.com> Link: https://lore.kernel.org/r/20230924215148.102491-2-alisadariana@gmail.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Matti Vaittinen authored
Add myself as a maintainer for ROHM BM1390 pressure sensor driver. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/fb19d3027ac19663789e18d4dc972a5dac0fde74.1695727471.git.mazziesaccount@gmail.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Matti Vaittinen authored
Support for the ROHM BM1390 pressure sensor. The BM1390GLV-Z can measure pressures ranging from 300 hPa to 1300 hPa with configurable measurement averaging and internal FIFO. The sensor does also provide temperature measurements. Sensor does also contain IIR filter implemented in HW. The data-sheet says the IIR filter can be configured to be "weak", "middle" or "strong". Some RMS noise figures are provided in data sheet but no accurate maths for the filter configurations is provided. Hence, the IIR filter configuration is not supported by this driver and the filter is configured to the "middle" setting (at least not for now). The FIFO measurement mode is only measuring the pressure and not the temperature. The driver measures temperature when FIFO is flushed and simply uses the same measured temperature value to all reported temperatures. This should not be a problem when temperature is not changing very rapidly (several degrees C / second) but allows users to get the temperature measurements from sensor without any additional logic. This driver allows the sensor to be used in two muitually exclusive ways, 1. With trigger (data-ready IRQ). In this case the FIFO is not used as we get data ready for each collected sample. Instead, for each data-ready IRQ we read the sample from sensor and push it to the IIO buffer. 2. With hardware FIFO and watermark IRQ. In this case the data-ready is not used but we enable watermark IRQ. At each watermark IRQ we go and read all samples in FIFO and push them to the IIO buffer. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/4f23211e3cf248f9f48ddb2a752387bb00e9c2c4.1695727471.git.mazziesaccount@gmail.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Matti Vaittinen authored
BM1390GLV-Z is a pressure sensor which performs internal temperature compensation for the MEMS. Pressure range is from 300 hPa to 1300 hPa and sample averaging and IIR filtering is built in sensor. Temperature measurement is also supported. Add dt-bindings for the sensor. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/08796e6b28d2c67933b1a1a5eca0f43da322a597.1695727471.git.mazziesaccount@gmail.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Matti Vaittinen authored
The available_scan_mask is an array of bitmaps representing the channels which can be simultaneously enabled by the driver. In many cases, the hardware can offer more channels than what the user is interested in obtaining. In such cases, it may be preferred that only a subset of channels are enabled, and the driver reads only a subset of the channels from the hardware. Some devices can't support all channel combinations. For example, the BM1390 pressure sensor must always read the pressure data in order to acknowledge the watermark IRQ, while reading temperature can be omitted. So, the available scan masks would be 'pressure and temperature' and 'pressure only'. When IIO searches for the scan mask it asks the driver to use, it will pick the first suitable one from the 'available_scan_mask' array. Hence, ordering the masks in the array makes a difference. We should 'prefer' reading just the pressure from the hardware (as it is a cheaper operation than reading both pressure and temperature) over reading both pressure and temperature. Hence, we should set the 'only pressure' as the first scan mask in available_scan_mask array. If we set the 'pressure and temperature' as first in the array, then the 'only temperature' will never get used as 'pressure and temperature' can always serve the user's needs. Add (minimal) kerneldoc to the 'available_scan_mask' to hint the user that the ordering of masks matters. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/4e43bf0186df5c8a56b470318b4827605f9cad6c.1695727471.git.mazziesaccount@gmail.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andreas Kemnade authored
Some boards fail in magnetometer probe if level shifter flag is not set, definition was found in the vendor Linux kernel v3.0. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20230927173245.2151083-3-andreas@kemnade.infoSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Andreas Kemnade authored
Add a level shifter flag as found in ancient platform data struct: level_shifter: 0: VLogic, 1: VDD Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20230927173245.2151083-2-andreas@kemnade.infoSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Antoniu Miclaus authored
The http://ez.analog.com/community/linux-device-drivers link is broken. Update website link to the new available one: https://ez.analog.com/linux-software-driversSigned-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com> Link: https://lore.kernel.org/r/20230926100149.4611-1-antoniu.miclaus@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Ramona Gradinariu authored
The temperature channel has 16-bit storage size. We need to perform the padding to have the buffer elements naturally aligned in case the temperature channel is enabled and there are any 32-bit storage size channels enabled which have a scan index higher than the temperature channel scan index. Fixes: 8f6bc87d ("iio: imu: adis16475.c: Add delta angle and delta velocity channels") Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20230926085721.645687-2-ramona.gradinariu@analog.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
- 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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 30 Sep, 2023 11 commits
-
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
- 24 Sep, 2023 11 commits
-
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
David Lechner authored
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.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Marius Cristea authored
The patch 33ec3e5f: "iio: adc: adding support for MCP3564 ADC" from Aug 29, 2023 (linux-next), leads to the following Smatch static checker warning: drivers/iio/adc/mcp3564.c:1426 mcp3564_probe() warn: address of NULL pointer 'indio_dev' drivers/iio/adc/mcp3564.c 1421 struct iio_dev *indio_dev; 1422 struct mcp3564_state *adc; 1423 1424 indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*adc)); 1425 if (!indio_dev) { --> 1426 dev_err_probe(&indio_dev->dev, PTR_ERR(indio_dev), ^^^^^^^^^^^^^^^ Fixes: 33ec3e5f (iio: adc: adding support for MCP3564 ADC) Signed-off-by: Marius Cristea <marius.cristea@microchip.com> Link: https://lore.kernel.org/r/20230918075633.1884-1-marius.cristea@microchip.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Jonathan Cameron authored
The deta angle and deta velocity channels were added in parallel with color temperature and chromacity so this merge had to assign a consistent order. I put the color related ones second. Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support the x and y light colors, which represent the coordinates on the CIE 1931 chromaticity diagram. Thus, add light chromaticity x and y for SFH1.1. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by: Jiri Kosina <jkosina@suse.cz> Link: https://lore.kernel.org/r/20230919081054.2050714-10-Basavaraj.Natikar@amd.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support the x and y light colors, which represent the coordinates on the CIE 1931 chromaticity diagram. Thus, add light chromaticity x and y. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by: Jiri Kosina <jkosina@suse.cz> Link: https://lore.kernel.org/r/20230919081054.2050714-9-Basavaraj.Natikar@amd.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support the x and y light colors, which represent the coordinates on the CIE 1931 chromaticity diagram. Thus, add light chromaticity x and y. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by: Srinivas Pandruvada<srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20230919081054.2050714-8-Basavaraj.Natikar@amd.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support the x and y light colors, which represent the coordinates on the CIE 1931 chromaticity diagram. Thus, add channel type for chromaticity. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Link: https://lore.kernel.org/r/20230919081054.2050714-7-Basavaraj.Natikar@amd.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support light color temperature. As a result, add support of light color temperature for SFH1.1. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by: Jiri Kosina <jkosina@suse.cz> Link: https://lore.kernel.org/r/20230919081054.2050714-6-Basavaraj.Natikar@amd.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support light color temperature. As a result, add support of light color temperature. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by: Jiri Kosina <jkosina@suse.cz> Link: https://lore.kernel.org/r/20230919081054.2050714-5-Basavaraj.Natikar@amd.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-
Basavaraj Natikar authored
In most cases, ambient color sensors also support light color temperature. As a result, add support of light color temperature. Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Acked-by: Srinivas Pandruvada<srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20230919081054.2050714-4-Basavaraj.Natikar@amd.comSigned-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
-