linux/drivers/mmc, branch v3.5

mmc: cd-gpio: pass IRQF_ONESHOT to request_threaded_irq()

2012-07-11T03:03:57Z

Fix a boot regression on Mackerel boards with sh_mobile_sdhi in existing kernels causing: genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq XXX caused by 1c6c6952 (genirq: Reject bogus threaded irq requests). This is backported from Guennadi's patch: "mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions" Reported-by: Rafael J. Wysocki Signed-off-by: Guennadi Liakhovetski Signed-off-by: Chris Ball

mmc: core: Revert "skip card initialization if power class selection fails"

2012-07-11T02:47:13Z

This reverts commit 3d93576e(skip card initialization if power class selection fails). Problem has been reported when this is used with eMMC4.41 card with Tegra Platform. Till the issue is root caused, bus width selection failure should not be treated as fatal. Reported-by: Marc Dietrich Signed-Off-by: Venkatraman S CC: Ulf Hansson CC: Subhash Jadavani CC: Saugata Das Signed-off-by: Chris Ball

Revert "mmc: omap_hsmmc: Enable Auto CMD12"

2012-06-26T20:10:30Z

This patch reverts the commit dba3c29ea4a1d5d544. After bisecting, this commit dba3c29 is found to ruin micro-SD card data (writing incorrect file, or fs is corrupt after several times mount) on the beagle-xm revB, and reverting the commit will fix the problem. Also from TRM of OMAP3/OMAP4/DM37x, the below is mentioned about the Auto CMD12 Enable bit. - SDIO does not support this feature. - SD card only. Looks it is not suitable to always enable Auto CMD12 in host controller driver. Considered that the commit is not mature enough, so ask to revert it first. Cc: Balaji T K Cc: Venkatraman S Buglink: https://lkml.org/lkml/2012/6/10/225 Reported-by: Paolo Pisati Reported-bisected-and-tested-by: Ming Lei Signed-off-by: Ming Lei Acked-by: Venkatraman S Signed-off-by: Chris Ball

mmc: block: fix the data timeout issue with ACMD22

2012-06-26T20:10:29Z

If multi block write operation fails for SD card, during error handling we send the SD_APP_SEND_NUM_WR_BLKS (ACMD22) to know how many blocks were already programmed by card. But mmc_sd_num_wr_blocks() function which sends the ACMD22 calculates the data timeout value from csd.tacc_ns and csd.tacc_clks parameters which will be 0 for block addressed (>2GB cards) SD card. This would result in timeout_ns and timeout_clks being 0 in the mmc_request passed to host driver. This means host controller would program its data timeout timer value with 0 which could result in DATA TIMEOUT errors from controller. To fix this issue, mmc_sd_num_wr_blocks() should instead just call the mmc_set_data_timeout() to calculate the data timeout value. mmc_set_data_timeout() function ensures that non zero timeout value is set even for block addressed SD cards. Signed-off-by: Subhash Jadavani Reviewed-by: Venkatraman S Signed-off-by: Chris Ball

Merge branch 'akpm' (Andrew's patch-bomb)

2012-06-20T21:41:57Z

* emailed from Andrew Morton : (21 patches) mm/memblock: fix overlapping allocation when doubling reserved array c/r: prctl: Move PR_GET_TID_ADDRESS to a proper place pidns: find_new_reaper() can no longer switch to init_pid_ns.child_reaper pidns: guarantee that the pidns init will be the last pidns process reaped fault-inject: avoid call to random32() if fault injection is disabled Viresh has moved get_maintainer: Fix --help warning mm/memory.c: fix kernel-doc warnings mm: fix kernel-doc warnings mm: correctly synchronize rss-counters at exit/exec mm, thp: print useful information when mmap_sem is unlocked in zap_pmd_range h8300: use the declarations provided by h8300: fix use of extinct _sbss and _ebss xtensa: use the declarations provided by xtensa: use "test -e" instead of bashism "test -a" xtensa: replace xtensa-specific _f{data,text} by _s{data,text} memcg: fix use_hierarchy css_is_ancestor oops regression mm, oom: fix and cleanup oom score calculations nilfs2: ensure proper cache clearing for gc-inodes thp: avoid atomic64_read in pmd_read_atomic for 32bit PAE ...

Viresh has moved

2012-06-20T21:39:36Z

viresh.kumar@st.com email-id doesn't exist anymore as I have left the company. Replace ST's id with viresh.linux@gmail.com. It also updates .mailmap file to fix address for 'git shortlog' Signed-off-by: Viresh Kumar Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm

2012-06-20T16:42:09Z

Pull ARM fixes from Russell King: "This includes three MMCI changes - one to fix up the wrong version of the DT support patch which was merged, and two to make deferred probing work. It also includes a fix to the OMAP SPI driver which is causing a boot time warning. The remainder are very minor ARM fixes." * 'fixes' of git://git.linaro.org/people/rmk/linux-arm: SPI: fix over-eager devm_xxx() conversion ARM: 7427/1: mmc: mmci: Defer probe() in case of yet uninitialized GPIOs ARM: 7426/1: mmc: mmci: Remove wrong error handling of gpio 0 ARM: 7425/1: extable: ensure fixup entries are 4-byte aligned ARM: 7421/1: bpf_jit: BPF_S_ANC_ALU_XOR_X support ARM: 7423/1: kprobes: run t32_simulate_ldr_literal() without insn slot ARM: 7422/1: mmc: mmci: Allocate platform memory during Device Tree boot

ARM: 7427/1: mmc: mmci: Defer probe() in case of yet uninitialized GPIOs

2012-06-17T21:24:36Z

If the GPIOs used by the MMCI driver are not registered yet when the driver is probe()d, they can't be used. This happens if the mmci driver is probed before the respective GPIO controller (e.g. on the LPC32xx EA3250 board, the PCA9532 GPIO controller would be initialized via DT after mmci). Therefore, we defer mmci in this case. Signed-off-by: Roland Stigge Acked-by: Linus Walleij Signed-off-by: Russell King

ARM: 7426/1: mmc: mmci: Remove wrong error handling of gpio 0

2012-06-17T21:24:32Z

Zero is a valid GPIO and shouldn't be handled as an error return code from of_get_named_gpio(). It was a leftover from old code before getting pdata->gpio_*() was modified. Signed-off-by: Roland Stigge Acked-by: Linus Walleij Signed-off-by: Russell King

ARM: 7422/1: mmc: mmci: Allocate platform memory during Device Tree boot

2012-06-14T14:11:05Z

When booting with Device Tree enabled, platform specific information is gathered by parsing the DT binary. Platform data is subsequently populated with the result. The memory required for this is not automatically allocated during Device Tree boot, so we'll do it here instead. Acked-by: Linus Walleij Signed-off-by: Lee Jones Signed-off-by: Russell King