1. 03 7月, 2016 9 次提交
    • L
      iio: pressure: bmp280: read calibration data once · b33b7d5a
      Linus Walleij 提交于
      The calibration data is described as coming from an E2PROM and that
      means it does not change. Just read it once at probe time and store
      it in the device state container. Also toss the calibration data
      into the entropy pool since it is device unique.
      Reviewed-by: NVlad Dogaru <vlad.dogaru@intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      b33b7d5a
    • L
      iio: pressure: bmp280: add power management · 3d838118
      Linus Walleij 提交于
      The PM280 has an internal standby-mode, but to really save power
      we should shut the sensor down and disconnect the power. With
      the proper .pm hooks we can enable both runtime and system power
      management of the sensor. We use the *force callbacks from the
      system PM hooks. When the sensor comes back we always reconfigure
      it to make sure it is ready to roll as expected.
      
      Cc: Ulf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      3d838118
    • L
      iio: pressure: bmp280: add support for BMP085 EOC interrupt · aae95394
      Linus Walleij 提交于
      The first version of this sensor, BMP085, supports sending an
      End-of-Conversion (EOC) interrupt. Add code to support this using
      a completion, in a similar vein as drivers/misc/bmp085.c does.
      
      Make sure to check that we are given a rising edge, because the
      EOC line goes from low-to-high when the conversion is ready.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      aae95394
    • L
      iio: pressure: bmp280: add SPI interface driver · b26b4e91
      Linus Walleij 提交于
      This patch mimics the SPI functionality found in the misc driver in
      drivers/misc/bh085-spi.c to make it possible to reuse the existing
      BMP280/BMP180/BMP085 driver with all clients of the other driver.
      The adoption is straight-forward since like the other driver, it is
      a simple matter of using regmap.
      
      This driver is also so obviously inspired/copied from the old misc
      driver in drivers/misc/bmp085.c that I just took the liberty to
      add in the authors of the other drivers + self in the core driver
      file.
      
      The MISC driver also supports a variant named "BMP181" so include
      that here to be complete in comparison to the old driver.
      
      The bus mapping code for SPI was written by Akinobu Mita.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Tested-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      b26b4e91
    • L
      iio: pressure: bmp280: split off an I2C Kconfig entry · 17118843
      Linus Walleij 提交于
      This creates a separate BMP280_I2C Kconfig entry that gets selected
      by BMP280 for I2C transport. As we currently only support I2C
      transport there is not much practical change other than getting
      a separate object file (or module) for the I2C driver part. The
      old Kconfig symbol BMP280 will still select the stuff we need so
      that oldconfig and old defconfigs works fine.
      Tested-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      17118843
    • L
      iio: pressure: bmp280: split driver in logical parts · 14e8015f
      Linus Walleij 提交于
      This splits the BMP280 driver in three logical parts: the core driver
      bmp280-core that only operated on a struct device * and a struct regmap *,
      the regmap driver bmp280-regmap that can be shared between I2C and other
      transports and the I2C module driver bmp280-i2c.
      
      Cleverly bake all functionality into a single object bmp280.o so that
      we still get the same module binary built for the device in the end,
      without any fuzz exporting symbols to the left and right.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      14e8015f
    • L
      iio: pressure: bmp280: support supply regulators · bd525e6c
      Linus Walleij 提交于
      The BMP085/BMP180/BMP280 is supplied with two power sources:
      VDDA (analog power) and VDDD (digital power). As these may come
      from regulators (as on the APQ8060 Dragonboard) we need the driver
      to attempt to fetch and enable these regulators.
      
      We FAIL if we cannot: boards should either define:
      - Proper regulators if present
      - Define fixed regulators if power is hardwired to the component
      - Rely on dummy regulators (will be present on all DT systems and
        any boardfile system that calls regulator_has_full_constraints().
      
      Cc: Mark Brown <broonie@kernel.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      bd525e6c
    • B
      drivers:iio:light:isl29125: added macros for sensing range · 60b1addb
      Bijosh Thykkoottathil 提交于
      Added macros for sensing range as the corresponding magic numbers
      were used at multiple places.
         - ISL29125_SENSING_RANGE_0 for 375 lux full range
         - ISL29125_SENSING_RANGE_1 for 10k lux full range
      Signed-off-by: NBijosh Thykkoottathil <bijosh.t@hotmail.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      60b1addb
    • L
      iio: st_sensors: harden interrupt handling · 90efe055
      Linus Walleij 提交于
      Leonard Crestez observed the following phenomenon: when using
      hard interrupt triggers (the DRDY line coming out of an ST
      sensor) sometimes a new value would arrive while reading the
      previous value, due to latencies in the system.
      
      We discovered that the ST hardware as far as can be observed
      is designed for level interrupts: the DRDY line will be held
      asserted as long as there are new values coming. The interrupt
      handler should be re-entered until we're out of values to
      handle from the sensor.
      
      If interrupts were handled as occurring on the edges (usually
      low-to-high) new values could appear and the line be held
      asserted after that, and these values would be missed, the
      interrupt handler would also lock up as new data was
      available, but as no new edges occurs on the DRDY signal,
      nothing happens: the edge detector only detects edges.
      
      To counter this, do the following:
      
      - Accept interrupt lines to be flagged as level interrupts
        using IRQF_TRIGGER_HIGH and IRQF_TRIGGER_LOW. If the line
        is marked like this (in the device tree node or ACPI
        table or similar) it will be utilized as a level IRQ.
        We mark the line with IRQF_ONESHOT and mask the IRQ
        while processing a sample, then the top half will be
        entered again if new values are available.
      
      - If we are flagged as using edge interrupts with
        IRQF_TRIGGER_RISING or IRQF_TRIGGER_FALLING: remove
        IRQF_ONESHOT so that the interrupt line is not
        masked while running the thread part of the interrupt.
        This way we will never miss an interrupt, then introduce
        a loop that polls the data ready registers repeatedly
        until no new samples are available, then exit the
        interrupt handler. This way we know no new values are
        available when the interrupt handler exits and
        new (edge) interrupts will be triggered when data arrives.
        Take some extra care to update the timestamp in the poll
        loop if this happens. The timestamp will not be 100%
        perfect, but it will at least be closer to the actual
        events. Usually the extra poll loop will handle the new
        samples, but once in a blue moon, we get a new IRQ
        while exiting the loop, before returning from the
        thread IRQ bottom half with IRQ_HANDLED. On these rare
        occasions, the removal of IRQF_ONESHOT means the
        interrupt will immediately fire again.
      
      - If no interrupt type is indicated from the DT/ACPI,
        choose IRQF_TRIGGER_RISING as default, as this is necessary
        for legacy boards.
      
      Tested successfully on the LIS331DL and L3G4200D by setting
      sampling frequency to 400Hz/800Hz and stressing the system:
      extra reads in the threaded interrupt handler occurs.
      
      Cc: Giuseppe Barba <giuseppe.barba@st.com>
      Cc: Denis Ciocca <denis.ciocca@st.com>
      Tested-by: NCrestez Dan Leonard <cdleonard@gmail.com>
      Reported-by: NCrestez Dan Leonard <cdleonard@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      90efe055
  2. 01 7月, 2016 9 次提交
  3. 28 6月, 2016 9 次提交
  4. 27 6月, 2016 11 次提交
  5. 26 6月, 2016 2 次提交
    • W
      staging: wilc1000: fix return value check in wlan_initialize_threads() · b3e6916d
      Wei Yongjun 提交于
      In case of error, the function kthread_run() returns ERR_PTR()
      and never returns NULL. The NULL test in the return value check
      should be replaced with IS_ERR().
      Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Reviewed-by: NJulian Calaby <julian.calaby@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3e6916d
    • L
      staging: wilc1000: arrays can't be NULL · 4562d224
      Luis de Bethencourt 提交于
      hif_drv->usr_scan_req.net.net_info[i] contains found_net_info structs
      which have the following element:
      u8 bssid[6];
      
      pstrNetworkInfo, of type network_info, also contains an u8 array named
      bssid.
      
      request->ssids is an array of cfg80211_ssid structs. Making ssid:
      u8 ssid[IEEE80211_MAX_SSID_LEN];
      
      In these 3 cases the arrays are being checked against NULL, which can't
      happen. Removing the checks since they will always be true.
      
      Found with smatch:
      drivers/staging/wilc1000/host_interface.c:1234 Handle_RcvdNtwrkInfo() warn: this array is probably non-NULL. 'hif_drv->usr_scan_req.net_info[i].bssid'
      drivers/staging/wilc1000/host_interface.c:1235 Handle_RcvdNtwrkInfo() warn: this array is probably non-NULL. 'pstrNetworkInfo->bssid'
      drivers/staging/wilc1000/host_interface.c:1253 Handle_RcvdNtwrkInfo() warn: this array is probably non-NULL. 'hif_drv->usr_scan_req.net_info[hif_drv->usr_scan_req.rcvd_ch_cnt].bssid'
      drivers/staging/wilc1000/host_interface.c:1254 Handle_RcvdNtwrkInfo() warn: this array is probably non-NULL. 'pstrNetworkInfo->bssid'
      Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4562d224