“95cd98f9a6dcf112d2abf724ac07c56ec745180f”上不存在“README.md”
  1. 10 11月, 2014 10 次提交
    • A
      mmc: core: Fix error paths and messages in mmc_init_card · 4b75bffc
      Andrew Gabbasov 提交于
      In mmc_init_card function some of the branches in error handling paths
      go to "err" label, which skips removing of newly allocated card structure,
      that will actually not be used. Fix that by using proper "free_card" label.
      
      Also, some messages in these branches are reported as warnings,
      although the operation processing is not continued. Change these
      messages to error level.
      Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      4b75bffc
    • A
      mmc: core: Add debug message for SET_BLOCK_COUNT result · fc75b708
      Andrew Gabbasov 提交于
      The debug messages with commands execution results, that are printed
      after processing the request, do not include results of sbc (set block count)
      part of request. Add the debug message for that part too.
      Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      fc75b708
    • A
      mmc: core: Initialize SET_BLOCK_COUNT request fields · cce411e6
      Andrew Gabbasov 提交于
      Some request fields are initialized just before request processing
      for sanity purposes. This is done for command, data, and stop parts
      of the request, but not for sbc (set block count) part. Add such
      initialization for that part too.
      Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      cce411e6
    • A
      mmc: sdhci: fix error conditions for controller reset · fce9d33f
      Andrew Gabbasov 提交于
      Add the case of SET_BLOCK_COUNT command error to the error conditions
      check for making a controller reset at request handling finish.
      Otherwise, if the SET_BLOCK_COUNT command failed, e.g. with a timeout,
      the controller state was not reset, and the next command failed too.
      
      In the case of data error the controller reset is already done in
      finish_data() function before sending stop command (if present),
      so the finish tasklet should make a reset after data error only
      if no stop command existed in the request.
      
      Also, fix the indentation of this condition check to make it more logical.
      Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      fce9d33f
    • A
      mmc: sdhci: Balance vmmc regulator_disable() · fbfaf032
      Andrew Gabbasov 提交于
      As a follow-up of commit
      "mmc: sdhci: Balance vmmc regulator_enable(), and always enable vqmmc"
      vmmc regulator disable is also not needed in sdhci_remove_host.
      The regulator is completely controlled by mmc_power_up and mmc_power_off
      functions and is already disabled by the time of removing the host.
      Extra regulator_disable call in sdhci_remove_host is unbalanced and
      causes a warning reported by regulator core, so should be removed.
      Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      fbfaf032
    • D
      mmc: sdhci-esdhc-imx: don't exit in case of no pinctrl states · cd529af7
      Dirk Behme 提交于
      The commit ad93220d ("mmc: sdhci-esdhc-imx: change pinctrl state
      according to uhs mode") exits the probe in case there are no valid
      pinctrl states found.
      
      As there are configurations doing the pin mux properly in the boot
      loader, don't exit. Just warn, but go on in case if there are no
      pinctrl states in the device tree.
      Signed-off-by: NDirk Behme <dirk.behme@de.bosch.com>
      Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      cd529af7
    • M
      mmc: mxcmmc: fix the default value for available voltages into mxcmci_probe · 18a09806
      Matteo Facchinetti 提交于
      If available voltages are not given, mmc_regulator_get_supply() function
      returns 0 and mxcmmc driver doesn't set a value for ocr_avail mask.
      
      In accordance with the comment in platform_data/mmc-mxcmmc.h,
      fix it, assuming MMC_VDD_32_33 | MMC_VDD_33_34 as default value.
      Signed-off-by: NMatteo Facchinetti <matteo.facchinetti@sirius-es.it>
      Reviewed-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      18a09806
    • M
      mmc: mxcmmc: fix race condition when dma finish a data transfer · adfa5703
      Matteo Facchinetti 提交于
      During a read of data block using dma, driver might have two ways to finish to read
      and free the resources:
      1) checking STATUS_DATA_TRANS_DONE mask, in the mxcmci_irq() routine
         (pending to mmc irq)
      2) mxmmc driver, registers also a mxcmci_dma_callback() and when transfer is finished,
         dma driver calls this callback. (pending to dma irq)
      Both ways are concurrent with each other.
      
      Race condition happens when following events occur:
      /* (1) mxcmci driver start data transfer */
               158.418970: mpc_dma_execute: mpc_dma_execute(): will_access_peripheral start cid=31
               158.418976: mpc_dma_issue_pending <-mxcmci_request
               158.418983: mxcmci_start_cmd <-mxcmci_request
      /* (2) mxcmci driver receive mmc irq */
               158.419656: mxcmci_irq <-handle_irq_event_percpu
               158.419692: mxcmci_read_response <-mxcmci_irq
      /* (3) mxcmci driver checks that transfer is complete and call mxcmci_finish_data() */
               158.419726: mxcmci_data_done <-mxcmci_irq
               158.419729: mxcmci_finish_data <-mxcmci_data_done
               158.419733: dma_direct_unmap_sg <-mxcmci_finish_data
               158.419736: mxcmci_swap_buffers.isra.24 <-mxcmci_finish_data
               158.419762: mxcmci_read_response <-mxcmci_data_done
      /* (4) mxcmci driver (no dma): send stop command */
               158.419765: mxcmci_start_cmd <-mxcmci_data_done
      /* (5) mxcmci driver (no dma): receive the stop command irq response */
               158.419782: mxcmci_irq <-handle_irq_event_percpu
               158.419812: mxcmci_read_response <-mxcmci_irq
               158.419843: mxcmci_finish_request <-mxcmci_irq
      /* (6) dma driver: receive dma irq (finish data transfer) related by request on step 1 */
               158.419853: mpc_dma_irq <-handle_irq_event_percpu
               158.420001: mpc_dma_irq_process <-mpc_dma_irq
               158.420004: mpc_dma_irq_process <-mpc_dma_irq
      /* (7) dma driver: start dma tasklet to finish the dma irq handling */
               158.420008: mpc_dma_irq_process: mpc_dma_irq_process(): completed ch:31
      /* (8) mxcmci driver: start next data transfer using dma */
               158.420174: mxcmci_request <-mmc_start_req
               158.420182: dma_direct_map_sg <-mxcmci_request
               158.420192: mpc_dma_prep_slave_sg <-mxcmci_request
      /* (9) dma driver: schedule irq tasklet and execute mxcmci dma driver callback */
               158.420250: mpc_dma_tasklet <-tasklet_action
               158.420254: mpc_dma_process_completed <-tasklet_action
               158.420267: mxcmci_dma_callback <-mpc_dma_process_completed
      /* ERROR!!! (10) mxcmci driver callback works on dma data related to the step 1
                       that is already finished */
               158.420271: mxcmci_data_done <-mpc_dma_process_completed
               158.420273: mxcmci_finish_data <-mxcmci_data_done
      /* ERROR!!! (11) mxcmci driver: clear data that should be used by step 8 and
                       send an other mmc stop command (already sended on step 4) */
               158.420276: dma_direct_unmap_sg <-mxcmci_finish_data
               158.420279: mxcmci_swap_buffers.isra.24 <-mxcmci_finish_data
               158.420330: mxcmci_read_response <-mxcmci_data_done
               158.420333: mxcmci_start_cmd <-mxcmci_data_done
               158.420338: dma_run_dependencies <-mpc_dma_process_completed
      ...
      ...
      ...
               168.474223: mxcmci_watchdog <-call_timer_fn
               168.474236: mxcmci_watchdog: mxcmci_watchdog
               168.474397: mpc_dma_device_control <-mxcmci_watchdog
      
      In accordance with the other drivers that using the dma engine,
      fix it, leaving *only* to dma driver the complete control to
      ending the read operation.
      
      Removing STATUS_READ_OP_DONE event activation, has as effect
      to force mxcmci driver to handle the finish data transfer only
      by mxcmci dma callback.
      Signed-off-by: NMatteo Facchinetti <matteo.facchinetti@sirius-es.it>
      Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      adfa5703
    • P
      mmc: sdhci-pci-o2micro: Fix Dell E5440 issue · 6380ea09
      Peter Guo 提交于
      Fix Dell E5440 when reboot Linux, can't find o2micro sd host chip issue.
      
      Fixes: 01acf691 (mmc: sdhci-pci: add support of O2Micro/BayHubTech SD hosts)
      Signed-off-by: NPeter Guo <peter.guo@bayhubtech.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      6380ea09
    • B
      mmc: block: add newline to sysfs display of force_ro · 0031a98a
      Baruch Siach 提交于
      Make force_ro consistent with other sysfs entries.
      
      Fixes: 371a689f ('mmc: MMC boot partitions support')
      Cc: Andrei Warkentin <andrey.warkentin@gmail.com>
      Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      0031a98a
  2. 05 11月, 2014 1 次提交
    • K
      mmc: core: fix card detection regression · a31b0c6c
      Kristina Martsenko 提交于
      Since commit 89168b48 ("mmc: core: restore detect line inversion
      semantics"), the SD card on i.MX28 (and possibly other) devices isn't
      detected and booting stops at:
      
      [    4.120617] Waiting for root device /dev/mmcblk0p3...
      
      This is caused by the MMC_CAP2_CD_ACTIVE_HIGH flag being set incorrectly
      when the host controller doesn't use a GPIO for card detection (but
      instead uses a dedicated pin). In this case mmc_gpiod_request_cd() will
      return before assigning to the gpio_invert variable, leaving the
      variable uninitialized. The variable then gets used to set the flag.
      This patch fixes the issue by making sure gpio_invert is set to false
      when a GPIO isn't used. After this patch, i.MX28 boots fine.
      
      The MMC_CAP2_RO_ACTIVE_HIGH (write protect) flag is also set incorrectly
      for the exact same reason (it uses the same uninitialized variable), so
      this patch fixes that too.
      
      Fixes: 89168b48 ("mmc: core: restore detect line inversion semantics")
      Reported-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NKristina Martšenko <kristina.martsenko@gmail.com>
      Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      a31b0c6c
  3. 06 10月, 2014 3 次提交
  4. 05 10月, 2014 1 次提交
    • M
      block: disable entropy contributions for nonrot devices · b277da0a
      Mike Snitzer 提交于
      Clear QUEUE_FLAG_ADD_RANDOM in all block drivers that set
      QUEUE_FLAG_NONROT.
      
      Historically, all block devices have automatically made entropy
      contributions.  But as previously stated in commit e2e1a148 ("block: add
      sysfs knob for turning off disk entropy contributions"):
          - On SSD disks, the completion times aren't as random as they
            are for rotational drives. So it's questionable whether they
            should contribute to the random pool in the first place.
          - Calling add_disk_randomness() has a lot of overhead.
      
      There are more reliable sources for randomness than non-rotational block
      devices.  From a security perspective it is better to err on the side of
      caution than to allow entropy contributions from unreliable "random"
      sources.
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      b277da0a
  5. 03 10月, 2014 8 次提交
  6. 02 10月, 2014 1 次提交
  7. 30 9月, 2014 1 次提交
  8. 29 9月, 2014 3 次提交
  9. 24 9月, 2014 6 次提交
  10. 23 9月, 2014 3 次提交
    • S
      mmc: Consolidate emmc tuning blocks · 48d11e06
      Stephen Boyd 提交于
      The same tuning block exists in the dw_mmc h.c and sdhci-msm.c
      files. Move these into mmc.c so that they can be shared across
      drivers.
      Reported-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      48d11e06
    • S
      mmc: sdhci-msm: Make tuning block table endian agnostic · ffed1b94
      Stephen Boyd 提交于
      If we're tuning on a big-endian CPU we'll never determine we properly
      tuned the device because we compare the data we received from the
      controller with a table that assumes the CPU is little-endian.
      Change the table to be an array of bytes instead of 32-bit words
      so we can use memcmp() without needing to byte-swap every word
      depending on the endianess of the CPU.
      
      Cc: Asutosh Das <asutoshd@codeaurora.org>
      Cc: Venkat Gopalakrishnan <venkatg@codeaurora.org>
      Reviewed-by: NGeorgi Djakov <gdjakov@mm-sol.com>
      Fixes: 415b5a75 "mmc: sdhci-msm: Add platform_execute_tuning implementation"
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      ffed1b94
    • S
      mmc: don't request CD IRQ until mmc_start_host() · d4d11449
      Stephen Warren 提交于
      As soon as the CD IRQ is requested, it can trigger, since it's an
      externally controlled event. If it does, delayed_work host->detect will
      be scheduled.
      
      Many host controller probe()s are roughly structured as:
      
      *_probe() {
          host = sdhci_pltfm_init();
          mmc_of_parse(host->mmc);
          rc = sdhci_add_host(host);
          if (rc) {
              sdhci_pltfm_free();
              return rc;
          }
      
      In 3.17, CD IRQs can are enabled quite early via *_probe() ->
      mmc_of_parse() -> mmc_gpio_request_cd() -> mmc_gpiod_request_cd_irq().
      
      Note that in linux-next, mmc_of_parse() calls mmc_gpio*d*_request_cd()
      rather than mmc_gpio_request_cd(), and mmc_gpio*d*_request_cd() doesn't
      call mmc_gpiod_request_cd_irq(). However, this issue still exists if
      mmc_gpio_request_cd() is called directly before mmc_start_host().
      
      sdhci_add_host() may fail part way through (e.g. due to deferred
      probe for a vmmc regulator), and sdhci_pltfm_free() does nothing to
      unrequest the CD IRQ nor cancel the delayed_work. sdhci_pltfm_free() is
      coded to assume that if sdhci_add_host() failed, then the delayed_work
      cannot (or should not) have been triggered.
      
      This can lead to the following with CONFIG_DEBUG_OBJECTS_* enabled, when
      kfree(host) is eventually called inside sdhci_pltfm_free():
      
      WARNING: CPU: 2 PID: 6 at lib/debugobjects.c:263 debug_print_object+0x8c/0xb4()
      ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x18
      
      The object being complained about is host->detect.
      
      There's no need to request the CD IRQ so early; mmc_start_host() already
      requests it. For most SDHCI hosts at least, the typical call path that
      does this is: *_probe() -> sdhci_add_host() -> mmc_add_host() ->
      mmc_start_host(). Therefore, remove the call to mmc_gpiod_request_cd_irq()
      from mmc_gpio_request_cd(). This also matches mmc_gpio*d*_request_cd(),
      which already doesn't call mmc_gpiod_request_cd_irq().
      
      However, some host controller drivers call mmc_gpio_request_cd() after
      mmc_start_host() has already been called, and assume that this will also
      call mmc_gpiod_request_cd_irq(). Update those drivers to explicitly call
      mmc_gpiod_request_cd_irq() themselves. Ideally, these drivers should be
      modified to move their call to mmc_gpio_request_cd() before their call
      to mmc_add_host(). However that's too large a change for stable.
      
      This solves the problem (eliminates the kernel error message above),
      since it guarantees that the IRQ can't trigger before mmc_start_host()
      is called.
      
      The critical point here is that once sdhci_add_host() calls
      mmc_add_host() -> mmc_start_host(), sdhci_add_host() is coded not to
      fail. In other words, if there's a chance that mmc_start_host() may have
      been called, and CD IRQs triggered, and the delayed_work scheduled,
      sdhci_add_host() won't fail, and so cleanup is no longer via
      sdhci_pltfm_free() (which doesn't free the IRQ or cancel the work queue)
      but instead must be via sdhci_remove_host(), which calls mmc_remove_host()
      -> mmc_stop_host(), which does free the IRQ and cancel the work queue.
      
      CC: Russell King <linux@arm.linux.org.uk>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexandre Courbot <acourbot@nvidia.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: <stable@vger.kernel.org> # v3.15+
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      d4d11449
  11. 22 9月, 2014 1 次提交
  12. 20 9月, 2014 2 次提交
新手
引导
客服 返回
顶部