08 Mar, 2020

1 commit

  • Merge Linux stable release v5.4.24 into imx_5.4.y

    * tag 'v5.4.24': (3306 commits)
    Linux 5.4.24
    blktrace: Protect q->blk_trace with RCU
    kvm: nVMX: VMWRITE checks unsupported field before read-only field
    ...

    Signed-off-by: Jason Liu

    Conflicts:
    arch/arm/boot/dts/imx6sll-evk.dts
    arch/arm/boot/dts/imx7ulp.dtsi
    arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
    drivers/clk/imx/clk-composite-8m.c
    drivers/gpio/gpio-mxc.c
    drivers/irqchip/Kconfig
    drivers/mmc/host/sdhci-of-esdhc.c
    drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
    drivers/net/can/flexcan.c
    drivers/net/ethernet/freescale/dpaa/dpaa_eth.c
    drivers/net/ethernet/mscc/ocelot.c
    drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
    drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
    drivers/net/phy/realtek.c
    drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
    drivers/perf/fsl_imx8_ddr_perf.c
    drivers/tee/optee/shm_pool.c
    drivers/usb/cdns3/gadget.c
    kernel/sched/cpufreq.c
    net/core/xdp.c
    sound/soc/fsl/fsl_esai.c
    sound/soc/fsl/fsl_sai.c
    sound/soc/sof/core.c
    sound/soc/sof/imx/Kconfig
    sound/soc/sof/loader.c

    Jason Liu
     

01 Feb, 2020

2 commits

  • commit e825070f697abddf3b9b0a675ed0ff1884114818 upstream.

    The commit 41c128cb25ce ("iio: st_gyro: Add lsm9ds0-gyro support")
    assumes that gyro in LSM9DS0 is the same as others with 0xd4 WAI ID,
    but datasheet tells slight different story, i.e. the first scale factor
    for the chip is 245 dps, and not 250 dps.

    Correct this by introducing a separate settings for LSM9DS0.

    Fixes: 41c128cb25ce ("iio: st_gyro: Add lsm9ds0-gyro support")
    Depends-on: 45a4e4220bf4 ("iio: gyro: st_gyro: fix L3GD20H support")
    Cc: Leonard Crestez
    Cc: Lorenzo Bianconi
    Cc:
    Signed-off-by: Andy Shevchenko
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Andy Shevchenko
     
  • commit dc26935fb60e8da8d59655dd2ec0de47b20d7d8f upstream.

    Apply data formatting to single conversion,
    as this is already done in continuous and trigger modes.

    Fixes: 102afde62937 ("iio: adc: stm32-dfsdm: manage data resolution in trigger mode")

    Signed-off-by: Olivier Moysan
    Cc:
    Acked-by: Fabrice Gasnier
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Olivier Moysan
     

23 Jan, 2020

5 commits

  • commit 883f616530692d81cb70f8a32d85c0d2afc05f69 upstream.

    Previous versions of `iio_compute_scan_bytes` only aligned each element
    to its own length (i.e. its own natural alignment). Because multiple
    consecutive sets of scan elements are buffered this does not work in
    case the computed scan bytes do not align with the natural alignment of
    the first scan element in the set.

    This commit fixes this by aligning the scan bytes to the natural
    alignment of the largest scan element in the set.

    Fixes: 959d2952d124 ("staging:iio: make iio_sw_buffer_preenable much more general.")
    Signed-off-by: Lars Möllendorf
    Reviewed-by: Lars-Peter Clausen
    Cc:
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Lars Möllendorf
     
  • commit 217afe63ccf445fc220e5ef480683607b05c0aa5 upstream.

    IIO triggered buffer depends on IIO buffer which is missing from Kconfig
    file. This should go unnoticed most of the time because there's a
    chance something else has already enabled buffers. In some rare cases
    though one might experience kbuild warnings about unmet direct
    dependencies and build failures due to missing symbols.

    Fix this by selecting IIO_BUFFER explicitly.

    Signed-off-by: Tomasz Duszynski
    Fixes: a1d642266c14 ("iio: chemical: add support for Plantower PMS7003 sensor")
    Cc:
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Tomasz Duszynski
     
  • commit bc80573ea25bb033a58da81b3ce27205b97c088e upstream.

    According to the data sheet the ambient sensor's scale is 0.12 lux/step
    (not 0.024 lux/step as used by vcnl4200) when the integration time is
    80ms. The integration time is currently hardcoded in the driver to that
    value.

    See p. 8 in https://www.vishay.com/docs/84307/designingvcnl4040.pdf

    Fixes: 5a441aade5b3 ("iio: light: vcnl4000 add support for the VCNL4040 proximity and light sensor")
    Signed-off-by: Guido Günther
    Reviewed-by: Marco Felsch
    Cc:
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Guido Günther
     
  • commit fb4fbc8904e786537e29329d791147389e1465a2 upstream.

    At the moment, attempting to probe a device with ST_LSM6DS3_ID
    (e.g. using the st,lsm6ds3 compatible) fails with:

    st_lsm6dsx_i2c 1-006b: unsupported whoami [69]

    ... even though 0x69 is the whoami listed for ST_LSM6DS3_ID.

    This happens because st_lsm6dsx_check_whoami() also attempts
    to match unspecified (zero-initialized) entries in the "id" array.
    ST_LSM6DS3_ID = 0 will therefore match any entry in
    st_lsm6dsx_sensor_settings (here: the first), because none of them
    actually have all 12 entries listed in the "id" array.

    Avoid this by additionally checking if "name" is set,
    which is only set for valid entries in the "id" array.

    Note: Although the problem was introduced earlier it did not surface until
    commit 52f4b1f19679 ("iio: imu: st_lsm6dsx: add support for accel/gyro unit of lsm9ds1")
    because ST_LSM6DS3_ID was the first entry in st_lsm6dsx_sensor_settings.

    Fixes: d068e4a0f921 ("iio: imu: st_lsm6dsx: add support to multiple devices with the same settings")
    Cc: # 5.4
    Acked-by: Lorenzo Bianconi
    Signed-off-by: Stephan Gerhold
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Stephan Gerhold
     
  • commit d7857e4ee1ba69732b16c73b2f2dde83ecd78ee4 upstream.

    This patch fixes device tree channel configuration.

    ad7124 driver reads channels configuration from the device tree.
    It expects to find channel specifications as child nodes.
    Before this patch ad7124 driver assumed that the child nodes are parsed
    by for_each_available_child_of_node in the order 0,1,2,3...

    This is wrong and the real order of the children can be seen by running:
    dtc -I fs /sys/firmware/devicetree/base on the machine.

    For example, running this on an rpi 3B+ yields the real
    children order: 4,2,0,7,5,3,1,6

    Before this patch the driver assigned the channel configuration
    like this:
    - 0
    Cc:
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Alexandru Tachici
     

18 Jan, 2020

2 commits

  • commit 9b742763d9d4195e823ae6ece760c9ed0500c1dc upstream.

    This was found only after the whole thing with the inline functions, but
    the compiler actually found something. The value of the `bias` (in
    adis16480_get_calibbias()) should only be set if the read operation was
    successful.

    No actual known problem occurs as users of this function all
    ultimately check the return value. Hence probably not stable material.

    Fixes: 2f3abe6cbb6c9 ("iio:imu: Add support for the ADIS16480 and similar IMUs")
    Signed-off-by: Alexandru Ardelean
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Alexandru Ardelean
     
  • commit 1b3751017e09f0857bc38f9b1be08dce38f3d92c upstream.

    Fix typos in gyro gain definitions for LSM9DS1 sensor

    Fixes: 52f4b1f19679 ("iio: imu: st_lsm6dsx: add support for accel/gyro unit of lsm9ds1")
    Signed-off-by: Lorenzo Bianconi
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Lorenzo Bianconi
     

09 Jan, 2020

2 commits

  • [ Upstream commit 9fd229c478fbf77c41c8528aa757ef14210365f6 ]

    As of commit b9ddd5091160793e ("iio: adc: max9611: Fix temperature
    reading in probe"), max9611 initialization sometimes fails on the
    Salvator-X(S) development board with:

    max9611 4-007f: Invalid value received from ADC 0x8000: aborting
    max9611: probe of 4-007f failed with error -5

    The max9611 driver tests communications with the chip by reading the die
    temperature during the probe function, which returns an invalid value.

    According to the datasheet, the typical ADC conversion time is 2 ms, but
    no minimum or maximum values are provided. Maxim Technical Support
    confirmed this was tested with temperature Ta=25 degreeC, and promised
    to inform me if a maximum/minimum value is available (they didn't get
    back to me, so I assume it is not).

    However, the driver assumes a 1 ms conversion time. Usually the
    usleep_range() call returns after more than 1.8 ms, hence it succeeds.
    When it returns earlier, the data register may be read too early, and
    the previous measurement value will be returned. After boot, this is
    the temperature POR (power-on reset) value, causing the failure above.

    Fix this by increasing the delay from 1000-2000 µs to 3000-3300 µs.

    Note that this issue has always been present, but it was exposed by the
    aformentioned commit.

    Fixes: 69780a3bbc0b1e7e ("iio: adc: Add Maxim max9611 ADC driver")
    Signed-off-by: Geert Uytterhoeven
    Reviewed-by: Jacopo Mondi
    Reviewed-by: Wolfram Sang
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Sasha Levin

    Geert Uytterhoeven
     
  • [ Upstream commit 0163c1c521ff8b09cd8ca395003cc00178161d77 ]

    drivers/iio/accel/st_accel_core.c:1005:44: warning:
    mount_matrix_ext_info defined but not used [-Wunused-const-variable=]

    Using stub helper while CONFIG_ACPI is disabled to fix it.

    Suggested-by: Ladislav Michl
    Signed-off-by: YueHaibing
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Sasha Levin

    YueHaibing
     

31 Dec, 2019

6 commits

  • [ Upstream commit 6376cbe549fffb378403cee78efd26b8a2c8e450 ]

    The AD5600 is a single channel, 16-bit resolution, voltage output digital
    to analog converter (DAC). The AD5600 uses a 3-wire SPI interface. It is
    part of the AD5541 family of DACs.

    The ad5446 IIO driver implements support for some of these DACs (in the
    AD5441 family), so the change is a simple entry in this driver.

    Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD5600.pdf

    Signed-off-by: Stefan Popa
    Signed-off-by: Alexandru Ardelean
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Sasha Levin

    Stefan Popa
     
  • [ Upstream commit e9a4cbcaaa391ef44d623d548ee715e77265030c ]

    Field was already set for light/proximity and
    accelerometer/gyroscope/magnetometer sensors.

    Fixes: ae7b02ad2f32 ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs")
    Signed-off-by: Gwendal Grignou
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Sasha Levin

    Gwendal Grignou
     
  • [ Upstream commit a7bddfe2dfce1d8859422124abe1964e0ecd386e ]

    The iio_triggered_buffer_postenable() hook should be called first to
    attach the poll function. The iio_triggered_buffer_predisable() hook is
    called last (as is it should).

    This change moves iio_triggered_buffer_postenable() to be called first. It
    adds iio_triggered_buffer_predisable() on the error paths of the postenable
    hook.
    For the predisable hook, some code-paths have been changed to make sure
    that the iio_triggered_buffer_predisable() hook gets called in case there
    is an error before it.

    Signed-off-by: Alexandru Ardelean
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Sasha Levin

    Alexandru Ardelean
     
  • [ Upstream commit db033831b4f5589f9fcbadb837614a7c4eac0308 ]

    All the registers are configured by the driver, let's reset the chip
    at probe time, avoiding any conflict with a possible earlier
    configuration.

    Signed-off-by: Miquel Raynal
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Sasha Levin

    Miquel Raynal
     
  • [ Upstream commit f552fde983d378e7339f9ea74a25f918563bf0d3 ]

    Separate the declaration of struct bh1750_chip_info from definition
    of bh1750_chip_info_tbl[] in a single statement as it makes the code
    hard to read, and with the extra newline it makes it look as if the
    bh1750_chip_info_tbl[] had no explicit type.

    This change also resolves the following compiler warning about the
    unusual position of the static keyword that can be seen when building
    with warnings enabled (W=1):

    drivers/iio/light/bh1750.c:64:1: warning:
    ‘static’ is not at beginning of declaration [-Wold-style-declaration]

    Related to commit 3a11fbb037a1 ("iio: light: add support for ROHM
    BH1710/BH1715/BH1721/BH1750/BH1751 ambient light sensors").

    Signed-off-by: Krzysztof Wilczynski
    Acked-by: Uwe Kleine-König
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Sasha Levin

    Krzysztof Wilczynski
     
  • [ Upstream commit 505ea3ada665c466d0064b11b6e611b7f995517d ]

    Adding missing indio_dev->dev.of_node references so that, in case multiple
    max31856 are present, users can get some clues to being able to distinguish
    each of them. While at it, add also the missing parent reference.

    Signed-off-by: Andrea Merello
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Sasha Levin

    Andrea Merello
     

18 Dec, 2019

9 commits

  • [ Upstream commit 3b71f6b59508b1c9befcb43de434866aafc76520 ]

    Each time we need to read a sample (from the sysfs interface, since the
    driver supports only it) the driver writes the configuration register
    with the proper settings needed to perform the said read, then it runs
    another xfer to actually read the resulting value. Most notably the
    configuration register is updated to set the ADC internal MUX depending by
    which channel the read targets.

    Unfortunately this seems not enough to ensure correct operation because
    the ADC works in a pipelined-like fashion and the new configuration isn't
    applied in time.

    The ADC alternates two phases: acquisition and conversion. During the
    acquisition phase the ADC samples the analog signal in an internal
    capacitor; in the conversion phase the ADC performs the actual analog to
    digital conversion of the stored voltage. Note that of course the MUX
    needs to be set to the proper channel when the acquisition phase is
    performed.

    Once the conversion phase has been completed, the device automatically
    switches back to a new acquisition; on the other hand the device switches
    from acquisition to conversion on the rising edge of SPI cs signal (that
    is when the xfer finishes).

    Only after both two phases have been completed (with the proper settings
    already written in the configuration register since the beginning) it is
    possible to read the outcome from SPI bus.

    With the current driver implementation, we end up in the following
    situation:

    _______ 1st xfer ____________ 2nd xfer ___________________
    SPI cs.. \_________/ \_________/
    SPI rd.. idle |(val N-2)+ idle | val N-1 + idle ...
    SPI wr.. idle | cfg N + idle | (X) + idle ...
    ------------------------ + -------------------- + ------------------
    AD .. acq N-1 + cnv N-1 | acq N + cnv N | acq N+1

    As shown in the diagram above, the value we read in the Nth read belongs
    to configuration setting N-1.

    In case the configuration is not changed (config[N] == config[N-1]), then
    we still get correct data, but in case the configuration changes (i.e.
    switching the MUX on another channel), we get wrong data (data from the
    previously selected channel).

    This patch fixes this by performing one more "dummy" transfer in order to
    ending up in reading the data when it's really ready, as per the following
    timing diagram.

    _______ 1st xfer ____________ 2nd xfer ___________ 3rd xfer ___
    SPI cs.. \_________/ \_________/ \_________/
    SPI rd.. idle |(val N-2)+ idle |(val N-1)+ idle | val N + ..
    SPI wr.. idle | cfg N + idle | (X) + idle | (X) + ..
    ------------------------ + -------------------- + ------------------- + --
    AD .. acq N-1 + cnv N-1 | acq N + cnv N | acq N+1 | ..

    NOTE: in the latter case (cfg changes), the acquisition phase for the
    value to be read begins after the 1st xfer, that is after the read request
    has been issued on sysfs. On the other hand, if the cfg doesn't change,
    then we can refer to the fist diagram assuming N == (N - 1); the
    acquisition phase _begins_ before the 1st xfer (potentially a lot of time
    before the read has been issued via sysfs, but it _ends_ after the 1st
    xfer, that is _after_ the read has started. This should guarantee a
    reasonably fresh data, which value represents the voltage that the sampled
    signal has after the read start or maybe just around it.

    Signed-off-by: Andrea Merello
    Reviewed-by: Charles-Antoine Couret
    Cc:
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Sasha Levin

    Andrea Merello
     
  • [ Upstream commit c270bbf7bb9ddc4e2a51b3c56557c377c9ac79bc ]

    The device could be configured to spit out also the configuration word
    while reading the AD result value (in the same SPI xfer) - this is called
    "readback" in the device datasheet.

    The driver checks if readback is enabled and it eventually adjusts the SPI
    xfer length and it applies proper shifts to still get the data, discarding
    the configuration word.

    The readback option is actually never enabled (the driver disables it), so
    the said checks do not serve for any purpose.

    Since enabling the readback option seems not to provide any advantage (the
    driver entirely sets the configuration word without relying on any default
    value), just kill the said, unused, code.

    Signed-off-by: Andrea Merello
    Reviewed-by: Alexandru Ardelean
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Sasha Levin

    Andrea Merello
     
  • commit 11d7c8d3b1259c303fb52789febed58f0bc35ad1 upstream.

    When the internal reference was selected by a channel it was not enabled.
    This patch fixes that and enables it.

    Fixes: b3af341bbd96 ("iio: adc: Add ad7124 support")
    Signed-off-by: Mircea Caprioru
    Cc:
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Mircea Caprioru
     
  • commit 341826a065660d1b77d89e6335b6095cd654271c upstream.

    When a conversion result is being read from ADC, the driver reads the
    number of channels + 1 because it thinks that IIO_CHAN_SOFT_TIMESTAMP
    is also a physical channel. This patch fixes this issue.

    Fixes: 2985a5d88455 ("staging: iio: adc: ad7606: Move out of staging")
    Reported-by: Robert Wörle
    Signed-off-by: Beniamin Bia
    Cc:
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Beniamin Bia
     
  • commit 53eaa9c27fdc01b4f4d885223e29f97393409e7e upstream.

    Temperature should be reported in milli-degrees, not degrees. Fix
    scale and offset values to use the correct unit.

    This is a fix for an issue that has been present for a long time.
    The fixes tag reflects the point at which the code last changed in a
    fashion that would make this fix patch no longer apply. Backports
    will be necessary to fix those elements that predate that patch.

    Fixes: 1615fe41a195 ("iio: imu: mpu6050: Fix FIFO layout for ICM20602")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jean-Baptiste Maneyrol
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Jean-Baptiste Maneyrol
     
  • commit 342a6928bd5017edbdae376042d8ad6af3d3b943 upstream.

    The IIO_HUMIDITYRELATIVE channel was being incorrectly reported back
    as percent when it should have been milli percent. This is via an
    incorrect scale value being returned to userspace.

    Signed-off-by: Chris Lesiak
    Acked-by: Matt Ranostay
    Cc:
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Chris Lesiak
     
  • commit 49549cb23a2926eba70bb634e361daea0f319794 upstream.

    This patch fixes the scales for the gyroscope, accelerometer and
    barometer. The pressure scale was just wrong. For the others, the scale
    factors were not taking into account that a 32bit word is being read
    from the device.

    Fixes: 7abad1063deb ("iio: adis16480: Fix scale factors")
    Fixes: 82e7a1b25017 ("iio: imu: adis16480: Add support for ADIS1649x family of devices")
    Signed-off-by: Nuno Sá
    Cc:
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Nuno Sá
     
  • commit fc3f6ad7f5dc6c899fbda0255865737bac88c2e0 upstream.

    Since st_lsm6dsx i2c master controller relies on accel device as trigger
    and slave devices can run at different ODRs we must select an accel_odr >=
    slave_odr. Report real accel ODR in st_lsm6dsx_check_odr() in order to
    properly set sensor frequency in st_lsm6dsx_write_raw and avoid to
    report unsupported frequency

    Fixes: 6ffb55e5009ff ("iio: imu: st_lsm6dsx: introduce ST_LSM6DSX_ID_EXT sensor ids")
    Signed-off-by: Lorenzo Bianconi
    Cc:
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Lorenzo Bianconi
     
  • commit 4c35b7a51e2f291471f7221d112c6a45c63e83bc upstream.

    The driver is defining debugfs entries by calling
    `adis16480_debugfs_init()`. However, those entries are attached to the
    iio_dev debugfs entry which won't exist if no debugfs_reg_access
    callback is provided.

    Fixes: 2f3abe6cbb6c ("iio:imu: Add support for the ADIS16480 and similar IMUs")
    Signed-off-by: Nuno Sá
    Cc:
    Signed-off-by: Jonathan Cameron
    Signed-off-by: Greg Kroah-Hartman

    Nuno Sá
     

25 Nov, 2019

2 commits


27 Oct, 2019

1 commit

  • There maybe a race when using dmaengine_terminate_all(). The predisable
    routine may call iio_triggered_buffer_predisable() prior to a pending DMA
    callback.
    Adopt dmaengine_terminate_sync() to ensure there's no pending DMA request
    before calling iio_triggered_buffer_predisable().

    Fixes: 2763ea0585c9 ("iio: adc: stm32: add optional dma support")

    Signed-off-by: Fabrice Gasnier
    Cc:
    Signed-off-by: Jonathan Cameron

    Fabrice Gasnier
     

22 Oct, 2019

1 commit

  • Some chips have a fifo overflow bit issue where the bit is always
    set. The result is that every data is dropped.

    Change fifo overflow management by checking fifo count against
    a maximum value.

    Add fifo size in chip hardware set of values.

    Fixes: f5057e7b2dba ("iio: imu: inv_mpu6050: better fifo overflow handling")
    Cc: stable@vger.kernel.org
    Signed-off-by: Jean-Baptiste Maneyrol
    Signed-off-by: Jonathan Cameron

    Jean-Baptiste Maneyrol
     

12 Oct, 2019

2 commits

  • The measured time value in the driver is limited to the maximum distance
    which can be read by the sensor. This limitation was wrong and is fixed
    by this patch.

    It also takes into account that we are supporting a variety of sensors
    today and that the recently added sensors have a higher maximum
    distance range.

    Changes in v2:
    - Added a Tested-by

    Suggested-by: Zbyněk Kocur
    Tested-by: Zbyněk Kocur
    Signed-off-by: Andreas Klinger
    Cc:
    Signed-off-by: Jonathan Cameron

    Andreas Klinger
     
  • It could happen that either `val` or `val2` [provided from userspace] is
    negative. In that case the computed frequency could get a weird value.

    Fix this by checking that neither of the 2 variables is negative, and check
    that the computed result is not-zero.

    Fixes: e4f959390178 ("iio: imu: adis16480 switch sampling frequency attr to core support")
    Signed-off-by: Alexandru Ardelean
    Cc:
    Signed-off-by: Jonathan Cameron

    Alexandru Ardelean
     

10 Oct, 2019

7 commits

  • …t/jic23/iio into staging-linus

    Jonathan writes:

    First set of IIO fixes for the 5.4 cycle.

    * adis16400
    - Make sure to free memory on a few failure paths.
    * adxl372
    - Fix wrong fifo depth
    - Fix wrong indexing of data from the fifo.
    - Perform a reset at startup to avoid a problem with inconsistent state.
    * axp288
    - This is a fix for a fix. The original fix made sure we kept the
    configuration from some firmwares to preserve a bias current.
    Unfortunately it appears the previous behaviour was working around
    a buggy firmware by overwriting the wrong value it had. Hence
    a regression was seen.
    * bmc150
    - Fix the centre temperature. This was due to an error in one of the
    datasheets.
    * hx711
    - Fix an issue where a badly timed interrupt could lead to a control
    line being high long enough to put the device into a low power state.
    * meson_sar_adc
    - Fix a case where the irq was enabled before everything it uses was
    allocated.
    * st_lsm6dsx
    - Ensure we don't set the sensor sensitivity to 0 as it will force
    all readings to 0.
    - Fix a wait time for the slave i2c controller when the accelerometer
    is not enabled.
    * stm32-adc
    - Precursor for fix. Move a set of register definitions to a header.
    - Fix a race when several ADCs are in use with some using interrupts
    to control the dataflow and some using DMA.
    * vcnl4000
    - Fix a garbage of_match_table in which a string was passed instead
    of the intended enum.

    * tag 'iio-fixes-for-5.4a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio:
    iio: Fix an undefied reference error in noa1305_probe
    iio: light: opt3001: fix mutex unlock race
    iio: adc: ad799x: fix probe error handling
    iio: light: add missing vcnl4040 of_compatible
    iio: light: fix vcnl4000 devicetree hooks
    iio: imu: st_lsm6dsx: fix waitime for st_lsm6dsx i2c controller
    iio: adc: axp288: Override TS pin bias current for some models
    iio: imu: adis16400: fix memory leak
    iio: imu: adis16400: release allocated memory on failure
    iio: adc: stm32-adc: fix a race when using several adcs with dma and irq
    iio: adc: stm32-adc: move registers definitions
    iio: accel: adxl372: Perform a reset at start up
    iio: accel: adxl372: Fix push to buffers lost samples
    iio: accel: adxl372: Fix/remove limitation for FIFO samples
    iio: adc: hx711: fix bug in sampling of data
    iio: fix center temperature of bmc150-accel-core
    iio: imu: st_lsm6dsx: forbid 0 sensor sensitivity
    iio: adc: meson_saradc: Fix memory allocation order

    Greg Kroah-Hartman
     
  • I hit the following error when compile the kernel.

    drivers/iio/light/noa1305.o: In function `noa1305_probe':
    noa1305.c:(.text+0x65): undefined reference to `__devm_regmap_init_i2c'
    make: *** [vmlinux] Error 1

    Signed-off-by: zhong jiang
    Cc:
    Signed-off-by: Jonathan Cameron

    zhong jiang
     
  • When an end-of-conversion interrupt is received after performing a
    single-shot reading of the light sensor, the driver was waking up the
    result ready queue before checking opt->ok_to_ignore_lock to determine
    if it should unlock the mutex. The problem occurred in the case where
    the other thread woke up and changed the value of opt->ok_to_ignore_lock
    to false prior to the interrupt thread performing its read of the
    variable. In this case, the mutex would be unlocked twice.

    Signed-off-by: David Frey
    Reviewed-by: Andreas Dannenberg
    Fixes: 94a9b7b1809f ("iio: light: add support for TI's opt3001 light sensor")
    Cc:
    Signed-off-by: Jonathan Cameron

    David Frey
     
  • Since commit 0f7ddcc1bff1 ("iio:adc:ad799x: Write default config on probe
    and reset alert status on probe") the error path is wrong since it
    leaves the vref regulator on. Fix this by disabling both regulators.

    Fixes: 0f7ddcc1bff1 ("iio:adc:ad799x: Write default config on probe and reset alert status on probe")
    Signed-off-by: Marco Felsch
    Reviewed-by: Alexandru Ardelean
    Cc:
    Signed-off-by: Jonathan Cameron

    Marco Felsch
     
  • Commit 5a441aade5b3 ("iio: light: vcnl4000 add support for the VCNL4040
    proximity and light sensor") added the support for the vcnl4040 but
    forgot to add the of_compatible. Fix this by adding it now.

    Signed-off-by: Marco Felsch
    Fixes: 5a441aade5b3 ("iio: light: vcnl4000 add support for the VCNL4040 proximity and light sensor")
    Reviewed-by: Angus Ainslie (Purism) angus@akkea.ca
    Cc:
    Signed-off-by: Jonathan Cameron

    Marco Felsch
     
  • Since commit ebd457d55911 ("iio: light: vcnl4000 add devicetree hooks")
    the of_match_table is supported but the data shouldn't be a string.
    Instead it shall be one of 'enum vcnl4000_device_ids'. Also the matching
    logic for the vcnl4020 was wrong. Since the data retrieve mechanism is
    still based on the i2c_device_id no failures did appeared till now.

    Fixes: ebd457d55911 ("iio: light: vcnl4000 add devicetree hooks")
    Signed-off-by: Marco Felsch
    Reviewed-by: Angus Ainslie (Purism) angus@akkea.ca
    Cc:
    Signed-off-by: Jonathan Cameron

    Marco Felsch
     
  • i2c controller available in st_lsm6dsx series performs i2c slave
    configuration using accel clock as trigger.
    st_lsm6dsx_shub_wait_complete routine is used to wait the controller has
    carried out the requested configuration. However if the accel sensor is not
    enabled we should not use its configured odr to estimate a proper timeout

    Fixes: c91c1c844ebd ("iio: imu: st_lsm6dsx: add i2c embedded controller support")
    Signed-off-by: Lorenzo Bianconi
    Signed-off-by: Jonathan Cameron

    Lorenzo Bianconi