1. 21 1月, 2021 1 次提交
  2. 17 12月, 2020 2 次提交
  3. 24 11月, 2020 1 次提交
  4. 17 11月, 2020 1 次提交
  5. 09 10月, 2020 4 次提交
  6. 29 9月, 2020 1 次提交
  7. 17 8月, 2020 4 次提交
  8. 24 7月, 2020 1 次提交
  9. 27 3月, 2020 1 次提交
  10. 19 2月, 2020 1 次提交
  11. 11 12月, 2019 1 次提交
  12. 08 10月, 2019 1 次提交
  13. 02 8月, 2019 1 次提交
    • S
      ASoC: Remove dev_err() usage after platform_get_irq() · cf9441ad
      Stephen Boyd 提交于
      We don't need dev_err() messages when platform_get_irq() fails now that
      platform_get_irq() prints an error message itself when something goes
      wrong. Let's remove these prints with a simple semantic patch.
      
      // <smpl>
      @@
      expression ret;
      struct platform_device *E;
      @@
      
      ret =
      (
      platform_get_irq(E, ...)
      |
      platform_get_irq_byname(E, ...)
      );
      
      if ( \( ret < 0 \| ret <= 0 \) )
      {
      (
      -if (ret != -EPROBE_DEFER)
      -{ ...
      -dev_err(...);
      -... }
      |
      ...
      -dev_err(...);
      )
      ...
      }
      // </smpl>
      
      While we're here, remove braces on if statements that only have one
      statement (manually).
      
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.com>
      Cc: alsa-devel@alsa-project.org
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NStephen Boyd <swboyd@chromium.org>
      Link: https://lore.kernel.org/r/20190730181557.90391-50-swboyd@chromium.orgSigned-off-by: NMark Brown <broonie@kernel.org>
      cf9441ad
  14. 05 6月, 2019 1 次提交
  15. 17 11月, 2018 1 次提交
  16. 04 7月, 2018 1 次提交
  17. 12 2月, 2018 1 次提交
  18. 19 9月, 2017 1 次提交
  19. 18 8月, 2017 1 次提交
  20. 15 8月, 2017 1 次提交
  21. 01 2月, 2017 1 次提交
  22. 15 11月, 2016 1 次提交
    • L
      ASoC: lpass-platform: fix uninitialized variable · ee2bd216
      Linus Torvalds 提交于
      In commit 022d00ee ("ASoC: lpass-platform: Fix broken pcm data
      usage") the stream specific information initialization was broken, with
      the dma channel information not being initialized if there was no
      alloc_dma_channel() helper function.
      
      Before that, the DMA channel number was implicitly initialized to zero
      because the backing store was allocated with devm_kzalloc().  When the
      init code was rewritten, that implicit initialization was lost, and gcc
      rightfully complains about an uninitialized variable being used.
      
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Cc: Mark Brown <broonie@kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ee2bd216
  23. 09 11月, 2016 1 次提交
  24. 01 11月, 2016 2 次提交
  25. 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
  26. 09 8月, 2016 1 次提交
  27. 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
  28. 01 4月, 2016 2 次提交
  29. 20 2月, 2016 3 次提交