1. 17 10月, 2016 1 次提交
  2. 10 10月, 2016 2 次提交
    • A
      mmc: sdhci: Rename sdhci_set_power() to sdhci_set_power_noreg() · 606d3131
      Adrian Hunter 提交于
      Unlike other cases, sdhci_set_power() does not reflect the default
      implementation of the ->set_power() callback. Rename it and create
      sdhci_set_power() that is the default implementation.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jisheng Zhang <jszhang@marvell.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      606d3131
    • A
      mmc: sdhci: Fix SDHCI_QUIRK2_STOP_WITH_TC · fc605f1d
      Adrian Hunter 提交于
      Multi-block data transfers can specify the number of blocks either using a
      Set Block Count command (CMD23) or by sending a STOP command (CMD12) after
      the required number of blocks has transferred. CMD23 is preferred, but some
      cards don't support it. CMD12 with R1b response is used for writes, and
      R1 response for reads.
      
      Some SDHCI host controllers give a Transfer Complete (TC) interrupt for the
      STOP command (CMD12) whether or not a R1b response has been specified. The
      quirk SDHCI_QUIRK2_STOP_WITH_TC identifies those host controllers, but the
      implementation only considers the case where the TC interrupt arrives at
      the same time as the Command Complete (CC) interrupt. However,
      occasionally TC arrives before CC. That is harmless, but does generate an
      error message "Got data interrupt 0x00000002 even though no data operation
      was in progress".
      
      A simpler approach is to force R1b response onto all STOP commands, because
      SDHCI will handle TC before CC in the general case, so do that.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      fc605f1d
  3. 27 9月, 2016 2 次提交
  4. 25 7月, 2016 32 次提交
  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. 16 5月, 2016 1 次提交
  7. 02 5月, 2016 1 次提交