All clock management is moved to dss platform driver. clk_get/put APIs use
dss device instead of core platform device.

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So the device name is changed from omapdss to omapdss_dss in 2420, 2430,
3xxx clock database files. Now the core driver "omapdss" only takes care
of panel registration with the custom bus.
core driver also uses the clk_enable() / clk_disable() APIs exposed by DSS for
clock management.
DSS driver would do clock management of clocks needed by DISPC, RFBI, DSI, VENC

TODO:  The clock content would be adapted to omap_hwmod in a seperate series.
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver of DSS is created and init exit methods are moved from core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.

DSS platform driver is registered from inside omap_dss_probe, in the order desired.
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

As part of omap hwmod changes, DSS will not be the only controller of its
clocks. hwmod initialization also enables the interface clocks, and
manages them.
So, when DSS is built as a module, omap_dss_remove doesn't try to disable
all clocks that have a higher usecount.
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Index i was already used in thhe first loop
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes a bug introduced by 807e8e40 ("mmc: Fix sd/sdio/mmc
initialization frequency retries") that prevented SDIO drivers from
performing SDIO commands in their probe routines -- the above patch
called mmc_claim_host() before sdio_add_func(), which causes a deadlock
if an external SDIO driver calls sdio_claim_host().

Fix tested on an OLPC XO-1.75 with libertas on SDIO.
Signed-off-by: NDmitry Shmidt <dimitrysh@google.com>
Reviewed-and-Tested-by: NChris Ball <cjb@laptop.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

The per-vm mutex doesn't prevent this completely, a flush coming from the
BAR VM could potentially happen at the same time as one for the channel
VM.  Not to mention that if/when we get per-client/channel VM, this will
happen far more frequently.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

TTM assumes an error condition from man->func->get_node() means that
something went horribly wrong, and causes it to bail.

The driver is supposed to return 0, and leave mm_node == NULL to
signal that it couldn't allocate any memory.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Early gen3 and gen2 chipset do not have the relaxed per-surface tiling
constraints of the later chipsets, so we need to check that the GTT
alignment is correct for the new tiling. If it is not, we need to
rebind.
Reported-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Andi Kleen narrowed his GPU hangs on his Sugar Bay (SNB desktop) rev 09
down to the use of GPU semaphores, and we already know that they appear
broken up to Huron River (mobile) rev 08. (I'm optimistic that disabling
GPU semaphores is simply hiding another bug by the latency and
side-effects of the additional device interaction it introduces...)

However, use of semaphores is a massive performance improvement... Only
as long as the system remains stable. Enable at your peril.
Reported-by: NAndi Kleen <andi-fd@firstfloor.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33921Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If a virtio-console device gets unplugged while a port is open, a
subsequent close() call on the port accesses vqs to free up buffers.
This can lead to a crash.

The buffers are already freed up as a result of the call to
unplug_ports() from virtcons_remove().  The fix is to simply not access
vq information if port->portdev is NULL.
Reported-by: Njuzhang <juzhang@redhat.com>
CC: stable@kernel.org
Signed-off-by: NAmit Shah <amit.shah@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Whilst the GT is powered down (rc6), writes to MMADDR are placed in a
FIFO by the System Agent. This is a limited resource, only 64 entries, of
which 20 are reserved for Display and PCH writes, and so we must take
care not to queue up too many writes. To avoid this, there is counter
which we can poll to ensure there are sufficient free entries in the
fifo.

"Issuing a write to a full FIFO is not supported; at worst it could
result in corruption or a system hang."
Reported-and-Tested-by: NMatt Turner <mattst88@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34056Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This reverts commit c2e0eb16.

As it turns out, userspace already depends upon being able to enable
tiling on existing bo which it promises to be large enough for its
purposes i.e. it will not access beyond the end of the last full-tile
row.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35016Reported-and-tested-by: NKamal Mostafa <kamal@canonical.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This driver causes hard lockups, when the active clock soure is jiffies.

The reason is that it loops with interrupts disabled waiting for a
timestamp to be reached by polling getnstimeofday().  Though with a
jiffies clocksource, when that code runs on the same CPU which is
responsible for updating jiffies, then we loop in circles for ever
simply because the timer interrupt cannot update jiffies.  So both UP
and SMP can be affected.

There is no easy fix for that problem so make it depend on BROKEN for
now.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Alexander Gordeev <lasaine@lvk.cs.msu.su>
Cc: Rodolfo Giometti <giometti@linux.it>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The device table is required to load modules based on modaliases.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Cc: Shubhrajyoti D <shubhrajyoti@ti.com>
Cc: Christoph Mair <christoph.mair@gmail.com>
Cc: Jonathan Cameron <jic23@cam.ac.uk>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix s3c_rtc_setaie() prototype to eliminate the following compile
warning:

  drivers/rtc/rtc-s3c.c:383: warning: initialization from incompatible pointer type

(akpm: the rtc_class_ops.alarm_irq_enable() handler is being passed two
arguments where it expects just one, presumably with undesired effects)
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The nv30/nv40 3d driver is about to start using DMA_FENCE from the 3D
object which, it turns out, doesn't like its DMA object to not be
aligned to a 4KiB boundary.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

For some time is known that ASPM is causing troubles on r8169, i.e. make
device randomly stop working without any errors in dmesg.

Currently Tomi Leppikangas reports that system with r8169 device hangs
with MCE errors when ASPM is enabled:
https://bugzilla.redhat.com/show_bug.cgi?id=642861#c4

Lets disable ASPM for r8169 devices at all, to avoid problems with
r8169 PCIe devices at least for some users.
Reported-by: NTomi Leppikangas <tomi.leppikangas@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The 34xx and 3590 tape driver uses the system work queue to defer work
from the interrupt function to process context, e.g. a medium sense
after an unsolicited interrupt. The tape commands started by the work
handler need to be asynchronous, otherwise a deadlock on the system
work queue can occur.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

The "ct" variable should be an unsigned int.  Both struct kbdiacrs
->kb_cnt and struct kbd_data ->accent_table_size are unsigned ints.

Making it signed causes a problem in KBDIACRUC because the user could
set the signed bit and cause a buffer overflow.

Cc: <stable@kernel.org>
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

The module parameter 'devs' and 'sizes' are marked as __initdata. The
memory for the parameters are freed after module_init completed. This
can lead to kernel crashes in param_free_charp. Remove the __initdata
attribute to fix the problem.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Following steps lead to deadlock in kernel:

dd if=/dev/zero of=img bs=512 count=1000
losetup -f img
mkfs.ext2 /dev/loop0
mount -t ext2 -o loop /dev/loop0 mnt
umount mnt/

Stacktrace:
[<c102ec04>] irq_exit+0x36/0x59
[<c101502c>] smp_apic_timer_interrupt+0x6b/0x75
[<c127f639>] apic_timer_interrupt+0x31/0x38
[<c101df88>] mutex_spin_on_owner+0x54/0x5b
[<fe2250e9>] lo_release+0x12/0x67 [loop]
[<c10c4eae>] __blkdev_put+0x7c/0x10c
[<c10a4da5>] fput+0xd5/0x1aa
[<fe2250cf>] loop_clr_fd+0x1a9/0x1b1 [loop]
[<fe225110>] lo_release+0x39/0x67 [loop]
[<c10c4eae>] __blkdev_put+0x7c/0x10c
[<c10a59d9>] deactivate_locked_super+0x17/0x36
[<c10b6f37>] sys_umount+0x27e/0x2a5
[<c10b6f69>] sys_oldumount+0xb/0xe
[<c1002897>] sysenter_do_call+0x12/0x26
[<ffffffff>] 0xffffffff

Regression since 2a48fc0a, which introduced the private
loop_mutex as part of the BKL removal process.

As per [1], the mutex can be safely removed.

[1] http://www.gossamer-threads.com/lists/linux/kernel/1341930

Addresses: https://bugzilla.novell.com/show_bug.cgi?id=669394
Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=29172Signed-off-by: NPetr Uzel <petr.uzel@suse.cz>
Cc: stable@kernel.org
Reviewed-by: NNikanth Karthikesan <knikanth@suse.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJens Axboe <jaxboe@fusionio.com>

We service 2 queues (kcq1 and kcq2) in cnic_service_bnx2x_bh().  If
the status block index has changed when servicing the kcq2, we must
go back and check kcq1.  The latest status block index will be used
to acknowledge the interrupt, and without looping back to check kcq1,
we may miss events on kcq1.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The status block index is used to acknowledge interrupt events and must
be read before checking for the interrupt events, so we need to add rmb()
to guarantee that.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit e2f2a93b, "of/promtree: add package-to-path support to pdt"
changed dp->name from using the 'name' property to using
package-to-path.  This fixed /proc/device-tree creation by eliminating
conflicts between names (the 'name' property provides names like
'battery', whereas package-to-path provides names like
'/foo/bar/battery@0', which we stripped to 'battery@0').  However, it
also breaks of_device_id table matching.

The fix that we _really_ wanted was to keep dp->name based upon
the name property ('battery'), but based dp->full_name upon
package-to-path ('battery@0').  This patch does just that.

This changes all users (except SPARC) of promtree to use the full
result from package-to-path for full_name, rather than stripping the
directory out.  In practice, the strings end up being exactly the
same; this change saves time, code, and memory.

SPARC continues to use the existing build_path_component() code.

v2: combine two patches and revert of_pdt_node_name to original version
v3: use dp->phandle instead of passing around node
v4: warn/bail out for non-sparc archs if pkg2path is not set
v5: split of_pdt_build_full_name into sparc & non-sparc versions
v6: Pass NULL to pkg2path before buf gets assigned.
    Drop check for pkg2path hook on each and every node.
v7: Don't BUG() when unable to get the full_path; create a
    known-unique name instead.
Signed-off-by: NAndres Salomon <dilinger@queued.net>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Build log:
In file included from drivers/usb/host/ehci-hcd.c:1208:
drivers/usb/host/ehci-xilinx-of.c: In function 'ehci_hcd_xilinx_of_probe':
drivers/usb/host/ehci-xilinx-of.c:168: error: implicit declaration of function 'of_address_to_resource'
Signed-off-by: NJohn Williams <john.williams@petalogix.com>
Signed-off-by: NMichal Simek <monstr@monstr.eu>
Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

__blk_run_queue() automatically either calls q->request_fn() directly
or schedules kblockd depending on whether the function is recursed.
blk-flush implementation needs to be able to explicitly choose
kblockd.  Add @force_kblockd.

All the current users are converted to specify %false for the
parameter and this patch doesn't introduce any behavior change.

stable: This is prerequisite for fixing ide oops caused by the new
        blk-flush implementation.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Jan Beulich <JBeulich@novell.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: stable@kernel.org
Signed-off-by: NJens Axboe <jaxboe@fusionio.com>

When support for 82577/82578 was added[1] in 2.6.31, PHY wakeup was in-
advertently enabled (even though it does not function properly) on ICH10
LOMs.  This patch makes it so that the ICH10 LOMs use MAC wakeup instead
as was done with the initial support for those devices (i.e. 82567LM-3,
82567LF-3 and 82567V-4).

[1] commit a4f58f54Reported-by: NAurelien Jarno <aurelien@aurel32.net>
Cc: <stable@kernel.org>
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Reported-by: NStephen Hemminger <shemminger@vyatta.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Sparse complains because the e1000 driver is calling ioread on a pointer
not tagged as __iomem.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Reviewed-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: NJeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

tps6586 does not support burst writes. i2c writes have to be
1 byte at a time.

Cc: stable@kernel.org
Signed-off-by: NVarun Wadekar <vwadekar@nvidia.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

ASoC supports keeping the audio subsysetm active over suspend in order
to support use cases such as audio passthrough from a cellular modem
with the main CPU suspended. Ensure that we don't power down the CODEC
when this is happening by checking to see if VMID is up and skipping
suspend and resume when it is. If the CODEC has suspended then it'll
turn VMID off before the core suspend() gets called.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Fix the device name in DaVinci Voice Codec MFD driver to load
davinci-vcif and cq93vc codec client drivers.
Signed-off-by: NManjunathappa, Prakash <prakash.pm@ti.com>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Call input_set_abs_params instead of manually setting absbit only.
This fixes this oops:

Unable to handle kernel NULL pointer dereference at virtual address 00000024
Internal error: Oops: 41b67017 [#1]
CPU: 0    Not tainted  (2.6.37 #4)
pc : [<c016d1fc>]    lr : [<00000000>]    psr: 20000093
sp : c19e5f30  ip : c19e5e6c  fp : c19e5f58
r10: 00000000  r9 : c19e4000  r8 : 00000003
r7 : 000001e4  r6 : 00000001  r5 : c1854400  r4 : 00000003
r3 : 00000018  r2 : 00000018  r1 : 00000018  r0 : c185447c
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: c1b6717f  Table: c1b6717f  DAC: 00000017
Stack: (0xc19e5f30 to 0xc19e6000)
5f20:                                     00000003 00000003 c1854400 00000013
5f40: 00000001 000001e4 000001c5 c19e5f80 c19e5f5c c016d5e8 c016cf5c 000001e4
5f60: c1854400 c18b5860 00000000 00000171 000001e4 c19e5fc4 c19e5f84 c01559a4
5f80: c016d584 c18b5868 00000000 c1bb5c40 c0035afc c18b5868 c18b5868 c1a55d54
5fa0: c18b5860 c0155750 00000013 00000000 00000000 00000000 c19e5ff4 c19e5fc8
5fc0: c0050174 c015575c 00000000 c18b5860 00000000 c19e5fd4 c19e5fd4 c1a55d54
5fe0: c00500f0 c003b464 00000000 c19e5ff8 c003b464 c00500fc 04000400 04000400
Backtrace:
Function entered at [<c016cf50>] from [<c016d5e8>]
Function entered at [<c016d578>] from [<c01559a4>]
 r8:000001e4 r7:00000171 r6:00000000 r5:c18b5860 r4:c1854400
Function entered at [<c0155750>] from [<c0050174>]
Function entered at [<c00500f0>] from [<c003b464>]
 r6:c003b464 r5:c00500f0 r4:c1a55d54
Code: e59520fc e1a03286 e0433186 e0822003 (e592000c)

>>PC;  c016d1fc <input_handle_event+2ac/5a0>   <=====

Trace; c016cf50 <input_handle_event+0/5a0>
Trace; c016d5e8 <input_event+70/88>
Trace; c016d578 <input_event+0/88>
Trace; c01559a4 <ucb1x00_thread+254/2dc>
Trace; c0155750 <ucb1x00_thread+0/2dc>
Trace; c0050174 <kthread+84/8c>
Trace; c00500f0 <kthread+0/8c>
Trace; c003b464 <do_exit+0/624>
Signed-off-by: NJochen Friedrich <jochen@scram.de>
CC: stable@kernel.org
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

Signed-off-by: NLennert Buytenhek <buytenh@secretlab.ca>
Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>

cpufreq_register_driver sets cpufreq_driver to a structure owned (and
placed) in the caller's memory. If cpufreq policy fails in its ->init
function, sysdev_driver_register returns nonzero in
cpufreq_register_driver. Now, cpufreq_register_driver returns an error
without setting cpufreq_driver back to NULL.

Usually cpufreq policy modules are unloaded because they propagate the
error to the module init function and return that.

So a later access to any member of cpufreq_driver causes bugs like:
BUG: unable to handle kernel paging request at ffffffffa00270a0
IP: [<ffffffff8145eca3>] cpufreq_cpu_get+0x53/0xe0
PGD 1805067 PUD 1809063 PMD 1c3f90067 PTE 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/net/tun0/statistics/collisions
CPU 0
Modules linked in: ...
Pid: 5677, comm: thunderbird-bin Tainted: G        W   2.6.38-rc4-mm1_64+ #1389 To be filled by O.E.M./To Be Filled By O.E.M.
RIP: 0010:[<ffffffff8145eca3>]  [<ffffffff8145eca3>] cpufreq_cpu_get+0x53/0xe0
RSP: 0018:ffff8801aec37d98  EFLAGS: 00010086
RAX: 0000000000000202 RBX: 0000000000000000 RCX: 0000000000000001
RDX: ffffffffa00270a0 RSI: 0000000000001000 RDI: ffffffff8199ece8
...
Call Trace:
 [<ffffffff8145f490>] cpufreq_quick_get+0x10/0x30
 [<ffffffff8103f12b>] show_cpuinfo+0x2ab/0x300
 [<ffffffff81136292>] seq_read+0xf2/0x3f0
 [<ffffffff8126c5d3>] ? __strncpy_from_user+0x33/0x60
 [<ffffffff8116850d>] proc_reg_read+0x6d/0xa0
 [<ffffffff81116e53>] vfs_read+0xc3/0x180
 [<ffffffff81116f5c>] sys_read+0x4c/0x90
 [<ffffffff81030dbb>] system_call_fastpath+0x16/0x1b
...

It's all cause by weird fail path handling in cpufreq_register_driver.
To fix that, shuffle the code to do proper handling with gotos.
Signed-off-by: NJiri Slaby <jslaby@suse.cz>
Signed-off-by: NDave Jones <davej@redhat.com>

On a Thinkpad x61s, I noticed some memory corruption when
plugging/unplugging the external VGA connection. The symptoms are that
4 bytes at the beginning of a page get overwritten by zeroes.
The address of the corruption varies when rebooting the machine, but
stays constant while it's running (so it's possible to repeatedly write
some data and then corrupt it again by plugging the cable).

Further investigation revealed that the corrupted address is
(dev_priv->status_page_dmah->busaddr & 0xffffffff), ie. the beginning of
the hardware status page of the i965 graphics card, cut to 32 bits.

So it seems that for some memory access, the hardware uses only 32 bit
addressing. If the hardware status page is located >4GB, this
corrupts unrelated memory.
Signed-off-by: NJan Niehusmann <jan@gondor.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

This reverts commit c4ff4b82.

Ted Ts'o reports:

 "TPM is working for me so I can log into employer's network in 2.6.37.
  It broke when I tried 2.6.38-rc6, with the following relevant lines
  from my dmesg:

  [   11.081627] tpm_tis 00:0b: 1.2 TPM (device-id 0x0, rev-id 78)
  [   25.734114] tpm_tis 00:0b: Operation Timed out
  [   78.040949] tpm_tis 00:0b: Operation Timed out

  This caused me to get suspicious, especially since the _other_ TPM
  commit in 2.6.38 had already been reverted, so I tried reverting
  commit c4ff4b82: "TPM: Long default timeout fix".  With this commit
  reverted, my TPM on my Lenovo T410 is once again working."
Requested-and-tested-by: NTheodore Ts'o <tytso@mit.edu>
Acked-by: NRajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Modifying the device & driver name from "mmci-omap-hs" to
"omap_hsmmc".
Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
Acked-by: Benoit Cousson<b-cousson@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

OMAP2420 platform consists of mmc block as in omap1 and not the
hsmmc block as present in omap2430, omap3, omap4 platforms.
Removing all base address macro defines except keeping one for OMAP2420 and
adapting only hsmmc device registration and driver to hwmod framework.

Changes involves:
1) Remove controller reset in devices.c which is taken care of
   by hwmod framework.
2) Using omap-device layer to register device and utilizing data from
   hwmod data file for base address, dma channel number, Irq_number,
   device attribute.
3) Update the driver to use dev_attr to find whether controller
   supports dual volt cards
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
Reviewed-by: NBalaji T K <balajitk@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
CC: Kevin Hilman <khilman@deeprootsystems.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>