1. 25 7月, 2016 3 次提交
  2. 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
  3. 23 5月, 2016 1 次提交
  4. 02 5月, 2016 2 次提交
  5. 29 2月, 2016 7 次提交
  6. 06 1月, 2016 1 次提交
  7. 22 12月, 2015 1 次提交
    • A
      mmc: dw_mmc: use resource_size_t to store physical address · 260b3164
      Arnd Bergmann 提交于
      The dw_mmc driver stores the physical address of the MMIO registers
      in a pointer, which requires the use of type casts, and is actually
      broken if anyone ever has this device on a 32-bit SoC in registers
      above 4GB. Gcc warns about this possibility when the driver is built
      with ARM LPAE enabled:
      
      mmc/host/dw_mmc.c: In function 'dw_mci_edmac_start_dma':
      mmc/host/dw_mmc.c:702:17: warning: cast from pointer to integer of different size
        cfg.dst_addr = (dma_addr_t)(host->phy_regs + fifo_offset);
                       ^
      mmc/host/dw_mmc-pltfm.c: In function 'dw_mci_pltfm_register':
      mmc/host/dw_mmc-pltfm.c:63:19: warning: cast to pointer from integer of different size
        host->phy_regs = (void *)(regs->start);
      
      This changes the code to use resource_size_t, which gets rid of the
      warning, the bug and the useless casts.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      260b3164
  8. 29 10月, 2015 2 次提交
  9. 27 10月, 2015 1 次提交
    • C
      mmc: mmc: extend the mmc_send_tuning() · 9979dbe5
      Chaotian Jing 提交于
      The mmc_execute_tuning() has already prepared the opcode,
      there is no need to prepare it again at mmc_send_tuning(),
      and, there is a BUG of mmc_send_tuning() to determine the opcode
      by bus width, assume eMMC was running at HS200, 4bit mode,
      then the mmc_send_tuning() will overwrite the opcode from CMD21
      to CMD19, then got error.
      
      in addition, extend an argument of "cmd_error" to allow getting
      if there was cmd error when tune response.
      Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
      [Ulf: Rebased patch]
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      9979dbe5
  10. 26 10月, 2015 3 次提交
  11. 17 8月, 2015 7 次提交
    • A
      mmc: dw_mmc: add quirk for broken data transfer over scheme · 57e10486
      Addy Ke 提交于
      This patch add a new quirk to add a s/w timer to notify the driver
      to terminate current transfer and report a data timeout to the core,
      if DTO interrupt does NOT come within the given time.
      
      dw_mmc call mmc_request_done func to finish transfer depends on
      DTO interrupt. If DTO interrupt does not come in sending data state,
      the current transfer will be blocked.
      
      We got the reply from synopsys:
      There are two counters but both use the same value of [31:8] bits.
      Data timeout counter doesn't wait for stop clock and you should get
      DRTO even when the clock is not stopped.
      Host Starvation timeout counter is triggered with stop clock condition.
      
      This means that host should get DRTO and DTO interrupt.
      
      But this case really exists, when driver reads tuning data from
      card on RK3288-pink2 board. I measured waveforms by oscilloscope
      and found that card clock was always on and data lines were always
      holded high level in sending data state.
      
      There are two possibility that data over interrupt doesn't come in
      reading data state on RK3X SoCs:
      - get command done interrupt, but doesn't get any data-related interrupt.
      - get data error interrupt, but doesn't get data over interrupt.
      Signed-off-by: NAddy Ke <addy.ke@rock-chips.com>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      57e10486
    • J
      mmc: dw_mmc: print the message for deprecated property · 40a7a463
      Jaehoon Chung 提交于
      supports-highspeed was deprecated.
      If someone use it, we need to notice information for it.
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      40a7a463
    • J
      mmc: dw_mmc: remove the unused blk_setting · 2b708df2
      Jaehoon Chung 提交于
      "blk_setting" doesn't use anywhere.
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      2b708df2
    • J
      mmc: dw_mmc: fix the wrong condition checking · 9e747b7e
      Jaehoon Chung 提交于
      When num-slots is lower than 1, it's right that should be returned -ENODEV.
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      9e747b7e
    • H
      mmc: dw_mmc: fix pio mode when internal dmac is enabled · 575c319d
      Heiko Stuebner 提交于
      The dw_mci_init_dma() may decide to not use dma, but pio instead, caused
      by things like wrong dma settings in the system.
      
      Till now the code dw_mci_init_slot() always assumed that dma is available
      when CONFIG_MMC_DW_IDMAC was defined, ignoring the host->use_dma var
      set during dma init.
      
      So when now the dma init failed for whatever reason, the transfer sizes
      would still be set for dma transfers, especially including the maximum
      block-count calculated from host->ring_size and resulting in a
      
      [    4.991109] ------------[ cut here ]------------
      [    4.991111] kernel BUG at drivers/mmc/core/core.c:256!
      [    4.991113] Internal error: Oops - BUG: 0 [#1] SMP ARM
      
      because host->ring_size is 0 in this case and the slot init code uses
      the wrong code to calculate the values.
      
      Fix this by selecting the correct calculations using the host->use_dma
      variable instead of the CONFIG_MMC_DW_IDMAC config option.
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      575c319d
    • S
      mmc: dw_mmc: Fix coding style issues · 0e3a22c0
      Shawn Lin 提交于
      This patch fixes the following issues reported by checkpatch.pl:
      - use -EINVAL instead of -ENOSYS, to fix warning message:
         "ENOSYS means 'invalid syscall nr' and nothing else"
      - split lines whose length is greater than 80 characters
      - avoid quoted string split across lines
      - use min_t instead of min, to fix warning message:
         "min() should probably be min_t(int, cnt, host->part_buf_count)"
      - fix missing a blank line after declarations
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      0e3a22c0
    • A
      mmc: dw_mmc: handle data blocks > than 4kB if IDMAC is used · 5959b32e
      Alexey Brodkin 提交于
      As per DW MobileStorage databook "each descriptor can transfer up to 4kB
      of data in chained mode", moreover buffer size that is put in "des1" is
      limited to 13 bits, i.e. for example on attempt to
      IDMAC_SET_BUFFER1_SIZE(desc, 8192) size value that's effectively written
      will be 0.
      
      On the platform with 8kB PAGE_SIZE I see dw_mmc gets data blocks in
      SG-list of 8kB size and that leads to unpredictable behavior of the
      SD/MMC controller.
      
      In particular on write to FAT partition of SD-card the controller will
      stuck in the middle of DMA transaction.
      
      Solution to the problem is simple - we need to pass large (> 4kB) data
      buffers to the controller via multiple descriptors. And that's what
      that change does.
      
      What's interesting I did try original driver on same platform but
      configured with 4kB PAGE_SIZE and may confirm that data blocks passed
      in SG-list to dw_mmc never exeed 4kB limit - that explains why nobody
      ever faced a problem I did.
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Seungwon Jeon <tgih.jun@samsung.com>
      Cc: Jaehoon Chung <jh80.chung@samsung.com>
      Cc: Ulf Hansson <ulf.hansson@linaro.org>
      Cc: arc-linux-dev@synopsys.com
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      5959b32e
  12. 12 6月, 2015 1 次提交
  13. 01 6月, 2015 2 次提交
  14. 08 5月, 2015 2 次提交
  15. 09 4月, 2015 5 次提交
  16. 31 3月, 2015 1 次提交
    • D
      mmc: dw_mmc: Don't try to enable the CD until we're sure we're not deferring · b793f658
      Doug Anderson 提交于
      If dw_mci_init_slot() returns that we got a probe deferral then it may
      leave slot->mmc as NULL.  That will cause dw_mci_enable_cd() to crash
      when it calls mmc_gpio_get_cd().
      
      Fix this by moving the call of dw_mci_enable_cd() until we're sure
      that we're good.  Note that if we have more than one slot and one
      defers (but the others don't) things won't work so well.  ...but
      that's not a new thing and everyone has already agreed that multislot
      support ought to be removed from dw_mmc eventually anyway since it is
      unused, untested, and you can see several bugs like this by inspecting
      the code.
      
      Fixes: bcafaf5470f0 ("mmc: dw_mmc: Only enable CD after setup and only if needed")
      Signed-off-by: NDoug Anderson <dianders@chromium.org>
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      b793f658