1. 01 11月, 2016 2 次提交
  2. 13 9月, 2016 1 次提交
    • J
      ASoC: constify snd_pcm_ops structures · 115c7254
      Julia Lawall 提交于
      Check for snd_pcm_ops structures that are only stored in the ops field of a
      snd_soc_platform_driver structure or passed as the third argument to
      snd_pcm_set_ops.  The corresponding field or parameter is declared const,
      so snd_pcm_ops structures that have this property can be declared as const
      also.
      
      The semantic patch that makes this change is as follows:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @r disable optional_qualifier@
      identifier i;
      position p;
      @@
      static struct snd_pcm_ops i@p = { ... };
      
      @ok1@
      identifier r.i;
      struct snd_soc_platform_driver e;
      position p;
      @@
      e.ops = &i@p;
      
      @ok2@
      identifier r.i;
      expression e1, e2;
      position p;
      @@
      snd_pcm_set_ops(e1, e2, &i@p)
      
      @bad@
      position p != {r.p,ok1.p,ok2.p};
      identifier r.i;
      struct snd_pcm_ops e;
      @@
      e@i@p
      
      @depends on !bad disable optional_qualifier@
      identifier r.i;
      @@
      static
      +const
       struct snd_pcm_ops i = { ... };
      // </smpl>
      Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      115c7254
  3. 06 9月, 2016 2 次提交
  4. 09 8月, 2016 1 次提交
  5. 28 5月, 2016 1 次提交
    • A
      remove lots of IS_ERR_VALUE abuses · 287980e4
      Arnd Bergmann 提交于
      Most users of IS_ERR_VALUE() in the kernel are wrong, as they
      pass an 'int' into a function that takes an 'unsigned long'
      argument. This happens to work because the type is sign-extended
      on 64-bit architectures before it gets converted into an
      unsigned type.
      
      However, anything that passes an 'unsigned short' or 'unsigned int'
      argument into IS_ERR_VALUE() is guaranteed to be broken, as are
      8-bit integers and types that are wider than 'unsigned long'.
      
      Andrzej Hajda has already fixed a lot of the worst abusers that
      were causing actual bugs, but it would be nice to prevent any
      users that are not passing 'unsigned long' arguments.
      
      This patch changes all users of IS_ERR_VALUE() that I could find
      on 32-bit ARM randconfig builds and x86 allmodconfig. For the
      moment, this doesn't change the definition of IS_ERR_VALUE()
      because there are probably still architecture specific users
      elsewhere.
      
      Almost all the warnings I got are for files that are better off
      using 'if (err)' or 'if (err < 0)'.
      The only legitimate user I could find that we get a warning for
      is the (32-bit only) freescale fman driver, so I did not remove
      the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
      For 9pfs, I just worked around one user whose calling conventions
      are so obscure that I did not dare change the behavior.
      
      I was using this definition for testing:
      
       #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
             unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
      
      which ends up making all 16-bit or wider types work correctly with
      the most plausible interpretation of what IS_ERR_VALUE() was supposed
      to return according to its users, but also causes a compile-time
      warning for any users that do not pass an 'unsigned long' argument.
      
      I suggested this approach earlier this year, but back then we ended
      up deciding to just fix the users that are obviously broken. After
      the initial warning that caused me to get involved in the discussion
      (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
      asked me to send the whole thing again.
      
      [ Updated the 9p parts as per Al Viro  - Linus ]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: https://lkml.org/lkml/2016/1/7/363
      Link: https://lkml.org/lkml/2016/5/27/486
      Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      287980e4
  6. 01 4月, 2016 2 次提交
  7. 12 3月, 2016 1 次提交
    • S
      ASoC: qcom: fix build error · 568cecf4
      Sudip Mukherjee 提交于
      While building m32r allmodconfig the build failed with:
      ERROR: "bad_dma_ops" [sound/soc/qcom/snd-soc-lpass-platform.ko] undefined!
      ERROR: "dma_common_mmap" [sound/soc/qcom/snd-soc-lpass-platform.ko] undefined!
      
      To satisfy the dependency CONFIG_SND_SOC_LPASS_PLATFORM should depend
      on HAS_DMA.
      Some other configs also needs the dependency on HAS_DMA as they are
      directly or indirectly selecting SND_SOC_LPASS_PLATFORM.
      Signed-off-by: NSudip Mukherjee <sudip.mukherjee@codethink.co.uk>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      568cecf4
  8. 20 2月, 2016 14 次提交
  9. 13 2月, 2016 2 次提交
    • S
      ASoC: qcom: Don't specify LE device endianness · a947b724
      Stephen Boyd 提交于
      This reverts commit 18560a4e (ASoC: qcom: Specify LE device
      endianness).
      
      The commit that caused us to specify LE device endianness here,
      29bb45f2 (regmap-mmio: Use native endianness for read/write,
      2015-10-29), has been reverted in mainline so now when we specify
      LE it actively breaks big endian kernels because the byte
      swapping in regmap-mmio is incorrect. Let's revert this change
      because it will 1) fix the big endian kernels and 2) be redundant
      to specify LE because that will become the default soon.
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      a947b724
    • S
      ASoC: qcom: Don't specify LE device endianness · 8faa268a
      Stephen Boyd 提交于
      This reverts commit 18560a4e (ASoC: qcom: Specify LE device
      endianness).
      
      The commit that caused us to specify LE device endianness here,
      29bb45f2 (regmap-mmio: Use native endianness for read/write,
      2015-10-29), has been reverted in mainline so now when we specify
      LE it actively breaks big endian kernels because the byte
      swapping in regmap-mmio is incorrect. Let's revert this change
      because it will 1) fix the big endian kernels and 2) be redundant
      to specify LE because that will become the default soon.
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      8faa268a
  10. 11 1月, 2016 1 次提交
    • S
      ASoC: qcom: use correct device pointer in dma allocation · f5f76ea7
      Srinivas Kandagatla 提交于
      dev pointer in struct snd_soc_pcm_runtime does not have dma_ops set. In
      v4.4 kernel dma_ops would end up pointing to dummy_dma_ops in such cases.
      So attempting to use such device in allocating coherent memory on aarch64
      would fail.
      
      According to commit 1dccb598 ("arm64:
      simplify dma_get_ops") The current behavior of dma_get_ops is to fall
      back to the global dma_ops when a device has not set its own dma_ops,
      but only for DT based systems.
      
      So, this patch fixes the driver to use correct device pointer while
      allocating coherent memory, and also deletes un-necessary dma_mask setup
      on soc_runtime->dev.
      
      Without this patch lpass driver would fail with below log:
      ...
      [    6.541542]  ADV7533: lpass_platform_alloc_buffer: Could not allocate DMA buffer
      [    6.541914] apq8016-lpass-cpu 7708000.lpass-cpu: ASoC: pcm constructor failed: -12
      [    6.548216] qcom-apq8016-sbc 7702000.sound: ASoC: can't create pcm ADV7533 :-12
      [    6.555581] qcom-apq8016-sbc 7702000.sound: ASoC: failed to instantiate card -12
      [    6.566072] qcom-apq8016-sbc: probe of 7702000.sound failed with error -12
      ...
      Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      f5f76ea7
  11. 21 11月, 2015 1 次提交
    • S
      ASoC: qcom: Specify LE device endianness · 18560a4e
      Stephen Boyd 提交于
      This is a little endian device, but so far we've been relying on
      the regmap mmio bus handling this for us without explicitly
      stating that fact. After commit 4a98da2164cf (regmap-mmio: Use
      native endianness for read/write, 2015-10-29), the regmap mmio
      bus will read/write with the __raw_*() IO accessors, instead of
      using the readl/writel() APIs that do proper byte swapping for
      little endian devices.
      
      So if we're running on a big endian processor and haven't
      specified the endianness explicitly in the regmap config or in
      DT, we're going to switch from doing little endian byte swapping
      to big endian accesses without byte swapping, leading to some
      confusing results. Specify the endianness explicitly so that the
      regmap core properly byte swaps the accesses for us.
      
      Cc: Kenneth Westfield <kwestfie@codeaurora.org>
      Cc: Kevin Hilman <khilman@linaro.org>
      Cc: Tyler Baker <tyler.baker@linaro.org>
      Cc: Simon Arlott <simon@fire.lp0.eu>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      18560a4e
  12. 17 9月, 2015 1 次提交
  13. 29 8月, 2015 1 次提交
  14. 29 7月, 2015 1 次提交
  15. 07 7月, 2015 2 次提交
  16. 11 6月, 2015 1 次提交
  17. 10 6月, 2015 2 次提交
  18. 03 6月, 2015 1 次提交
  19. 25 5月, 2015 1 次提交
  20. 22 5月, 2015 2 次提交