1. 10 11月, 2014 12 次提交
    • S
      mmc: sdhci-pxav3: Remove unused clk_enable from sdhci_pxa · ff8878fd
      Sebastian Hesselbarth 提交于
      clk_enable from struct sdhci_pxa is unused, remove it from the private
      driver data.
      Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      ff8878fd
    • S
      mmc: sdhci-pxav3: Move private driver data to driver source · cc9571e8
      Sebastian Hesselbarth 提交于
      struct sdhci_pxa is only used in sdhci_pxa driver itself, so move it
      there.
      Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      cc9571e8
    • S
      mmc: sdhci-pxav3: Respect MMC_DDR52 timing on uhs signaling · 668e84b2
      Sebastian Hesselbarth 提交于
      commit bb8175a8
        ("mmc: sdhci: clarify DDR timing mode between SD-UHS and eMMC")
      added MMC_DDR52 as eMMC's DDR mode to be distinguished from SD-UHS.
      
      While the differentation may be useful, pxav3 SDHCI controller lacks
      a corresponding check in its custom .set_uhs_signaling callback for
      MMC_DDR52. This patch adds a new switch case for MMC_TIMING_MMC_DDR52
      to MMC_TIMING_UHS_DDR50 case.
      Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      668e84b2
    • S
      mmc: sdhci-pxav2: Drop unused struct sdhci_pxa · 6a686c31
      Sebastian Hesselbarth 提交于
      struct sdhci_pxa is private data of PXA SDHCI driver, but not used in
      sdhci-pxav2 at all. Drop unused references to struct sdhci_pxa.
      Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      6a686c31
    • T
    • S
      mmc: mmci: fix mmci_post_request · b5c16a60
      Srinivas Kandagatla 提交于
      If the post request is cancelling the channel and descriptor and which are
      equal to host->dma_current and host->dma_desc_current respectively, then it
      makes sense to reset these pointers to NULL, so that the driver does not
      reference it.
      
      Also the host_cookie can be reset to 0 in cases of error, so that the
      core could reissue the same mmc_request.
      
      This patch was tested with 'mmc: core: fix prepared requests while doing
      bkops' to fix the below issue.
      
      mmci-pl18x 12400000.sdcc: error during DMA transfer!
      Unable to handle kernel paging request at virtual address 40000000
      pgd = c0204000
      [40000000] *pgd=00000000
      Internal error: Oops: 805 [#1] SMP ARM
      Modules linked in: ipv6 ath6kl_sdio ath6kl_core
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W      3.17.0-rc7-linaro-multi-v7 #1
      task: c0c9d7e0 ti: c0c92000 task.ti: c0c92000
      PC is at v7_dma_inv_range+0x34/0x4c
      LR is at __dma_page_dev_to_cpu+0x80/0x100
      pc : [<c021efc0>]    lr : [<c021af18>]    psr: 400f0193
      sp : c0c93e20  ip : c0c9a478  fp : c08ea538
      r10: c0c9f548  r9 : 00000002  r8 : e97d9000
      r7 : 00000200  r6 : c0c9d504  r5 : c0db0880  r4 : 00000000
      r3 : 0000003f  r2 : 00000040  r1 : 40000200  r0 : 40000000
      Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c5787d  Table: a9ef406a  DAC: 00000015
      Process swapper/0 (pid: 0, stack limit = 0xc0c92250)
      Stack: (0xc0c93e20 to 0xc0c94000)
      3e20: c021f058 e9a17178 e9a171bc e99dfd6c 00000001 00000001 e995de10 00000002
      3e40: 00000000 c021b574 00000000 c04bc4a4 00000000 e9b49ac0 c0ce6e6c e99dfda4
      3e60: 00000088 e9810780 c0d8291c c072ea58 00000000 c072d3fc 00000000 c072f534
      3e80: 00000000 e9b49ac0 00000100 c0c9a444 00000088 c072f6b4 c072f5d4 e9d40080
      3ea0: e98107dc 00000000 00000000 c0280a60 00000000 7d55bf61 e9810780 e98107dc
      3ec0: 00000000 f0002000 c0d460e8 c0d460e8 c0c92000 c0280b60 e9810780 c0ce7190
      3ee0: 00000000 c028369c c02835f4 00000088 00000088 c0280278 c0c8ec70 c020f080
      3f00: f000200c c0c9a958 c0c93f28 c02088e4 c04bd630 c04bd5bc 200f0013 ffffffff
      3f20: c0c93f5c c0212800 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b
      3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70
      3f60: c04bd630 c04bd5bc 200f0013 ffffffff c04bd574 c071bd24 7d50c9b4 c0719a44
      3f80: 7d50c9b4 0000015b c0c9a498 c0c92028 c0c9a498 c0c9a4fc ea7a0e40 c0c8ee38
      3fa0: c0d460e8 c0276198 00000000 c0d8291a 00000000 c0c9a400 00000000 c0be0bc4
      3fc0: ffffffff ffffffff c0be05f8 00000000 00000000 c0c533d8 c0d82ed4 c0c9a47c
      3fe0: c0c533d4 c0c9e870 8020406a 511f06f0 00000000 80208074 00000000 00000000
      [<c021efc0>] (v7_dma_inv_range) from [<c021af18>] (__dma_page_dev_to_cpu+0x80/0x100)
      [<c021af18>] (__dma_page_dev_to_cpu) from [<c021b574>] (arm_dma_unmap_sg+0x5c/0x84)
      [<c021b574>] (arm_dma_unmap_sg) from [<c072ea58>] (mmci_dma_unmap.isra.16+0x60/0x74)
      [<c072ea58>] (mmci_dma_unmap.isra.16) from [<c072f534>] (mmci_data_irq+0x1fc/0x29c)
      [<c072f534>] (mmci_data_irq) from [<c072f6b4>] (mmci_irq+0xe0/0x114)
      [<c072f6b4>] (mmci_irq) from [<c0280a60>] (handle_irq_event_percpu+0x78/0x134)
      [<c0280a60>] (handle_irq_event_percpu) from [<c0280b60>] (handle_irq_event+0x44/0x64)
      [<c0280b60>] (handle_irq_event) from [<c028369c>] (handle_fasteoi_irq+0xa8/0x1a8)
      [<c028369c>] (handle_fasteoi_irq) from [<c0280278>] (generic_handle_irq+0x2c/0x3c)
      [<c0280278>] (generic_handle_irq) from [<c020f080>] (handle_IRQ+0x40/0x90)
      [<c020f080>] (handle_IRQ) from [<c02088e4>] (gic_handle_irq+0x38/0x68)
      [<c02088e4>] (gic_handle_irq) from [<c0212800>] (__irq_svc+0x40/0x54)
      Exception stack(0xc0c93f28 to 0xc0c93f70)
      3f20:                   00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b
      3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70
      3f60: c04bd630 c04bd5bc 200f0013 ffffffff
      [<c0212800>] (__irq_svc) from [<c04bd5bc>] (msm_cpu_pm_enter_sleep+0x48/0x4c)
      [<c04bd5bc>] (msm_cpu_pm_enter_sleep) from [<c071bd24>] (qcom_lpm_enter_spc+0x20/0x2c)
      [<c071bd24>] (qcom_lpm_enter_spc) from [<c0719a44>] (cpuidle_enter_state+0x44/0xf0)
      [<c0719a44>] (cpuidle_enter_state) from [<c0276198>] (cpu_startup_entry+0x1f4/0x238)
      [<c0276198>] (cpu_startup_entry) from [<c0be0bc4>] (start_kernel+0x384/0x390)
      Code: 1e070f3e e1110003 e1c11003 1e071f3e (ee070f36)
      ---[ end trace cf6cb3f6432c9834 ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      b5c16a60
    • 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
  2. 06 10月, 2014 3 次提交
  3. 03 10月, 2014 8 次提交
  4. 02 10月, 2014 1 次提交
  5. 29 9月, 2014 1 次提交
    • A
      mmc: atmel-mci: fix mismatched section on atmci_cleanup_slot · 5fef365b
      Arnd Bergmann 提交于
      As of 528bc780 ("mmc: atmel-mci: Release mmc resources on failure in probe"),
      the atmci_probe() function calls atmci_cleanup_slot in the failure path.
      
      This causes a new warning whenever the driver is built:
      
      WARNING: drivers/mmc/host/built-in.o(.init.text+0xa04): Section mismatch in reference from the function atmci_probe() to the function .exit.text:atmci_cleanup_slot()
      The function __init atmci_probe() references
      a function __exit atmci_cleanup_slot().
      
      Gcc correctly warns about this function getting dropped in the link stage
      for the built-in case, which would cause undefined behavior when this error
      path is hit. The solution is to simply drop the __exit annotation.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Fixes: 528bc780 ("mmc: atmel-mci: Release mmc resources on failure in probe")
      Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      5fef365b
  6. 24 9月, 2014 5 次提交
  7. 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
  8. 20 9月, 2014 2 次提交
  9. 19 9月, 2014 1 次提交
  10. 10 9月, 2014 3 次提交
  11. 09 9月, 2014 1 次提交
    • L
      mmc: mmci: augment driver to handle gpio descriptors · ce437aa4
      Linus Walleij 提交于
      Currently the MMCI driver will only handle GPIO descriptors
      implicitly through the device tree probe glue in mmc_of_init(),
      but devices instatiated other ways such as through board files
      and passing descriptors using the GPIO descriptor table will
      not be able to exploit descriptors.
      
      Augment the driver to look for a GPIO descriptor if device
      tree is not used for the device, and if that doesn't work,
      fall back to platform data GPIO assignment using the old
      API. The end goal is to get rid of the platform data integer
      GPIO assingments from the kernel.
      
      This enable the MMCI-embedding platforms to be converted to
      GPIO descritor tables.
      
      Cc: Alexandre Courbot <gnurou@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      ce437aa4