1. 15 3月, 2016 1 次提交
    • A
      ASoC: cs35l32: avoid uninitialized variable access · dd5dc001
      Arnd Bergmann 提交于
      gcc warns about the possibilty of accessing a property read from
      devicetree in cs35l32_i2c_probe() when it has not been initialized
      because CONFIG_OF is disabled:
      
      sound/soc/codecs/cs35l32.c: In function 'cs35l32_i2c_probe':
      sound/soc/codecs/cs35l32.c:278:2: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      The code is actually correct because it checks the dev->of_node
      variable first and we know this is NULL here when CONFIG_OF
      is disabled, but Russell King noticed that it's broken when
      we probe the device using DT, and the properties are absent.
      
      The code already has some checking for incorrect values, and
      I keep that checking unchanged here, but add an additional
      check for an error returned by the property accessor functions
      that now gets handled the same way as incorrect data in the
      properties.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NBrian Austin <brian.austin@cirrus.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      dd5dc001
  2. 15 8月, 2015 1 次提交
  3. 23 7月, 2015 1 次提交
  4. 17 7月, 2015 1 次提交
  5. 15 7月, 2015 1 次提交
  6. 27 4月, 2015 1 次提交
  7. 24 2月, 2015 1 次提交
    • U
      ASoC: improve usage of gpiod API · 34d7c390
      Uwe Kleine-König 提交于
      Since 39b2bbe3 (gpio: add flags argument to gpiod_get*() functions)
      which appeared in v3.17-rc1, the gpiod_get* functions take an additional
      parameter that allows to specify direction and initial value for
      output. Simplify drivers accordingly.
      
      Also there is an *_optional variant that serves well here. The sematics
      is slightly changed here by using it as error checking is more strict
      now: If GPIOLIB is not enabled an error is returned instead of just
      ignoring the gpio. On one hand this is bad for devices that don't "have"
      the respective gpio as the driver is failing now. On the other hand
      there is no means to assert that this gpio is really not needed or if
      only the driver to control it is not available. The latter is a real
      reason to fail and so it's defensive to fail here, too.
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      34d7c390
  8. 06 1月, 2015 1 次提交
  9. 13 12月, 2014 1 次提交
  10. 17 9月, 2014 1 次提交
  11. 29 8月, 2014 3 次提交
  12. 17 8月, 2014 2 次提交