Minor changes to fix compile on fresh download

The mfc_fw.bin file was not in the repo due to missing
excludes in .gitignore

Change-Id: I8430232dbf001455902b4ee5d69ffc053868ac9c
Revert "exynos4: more cleanup"

This reverts commit 79632044d88fff3fc8f4e4859975270988f2106b.

Prep for renaming mach-exynos4 back to mach-exynos for the purposes of commonality
with other trees.  (Mainline Exynos patches will never apply to this tree no matter
what it is named.)

Signed-off-by: Andrew Dodd <atd7@cornell.edu>
Revert "exynos4: cleanup"

This reverts commit af3ed174f304d9fab6bd01a4a539300f7e991046.

Prep for renaming mach-exynos4 back to mach-exynos for the purposes of commonality
with other trees.  (Mainline Exynos patches will never apply to this tree no matter
what it is named.)

Signed-off-by: Andrew Dodd <atd7@cornell.edu>
Revert "exynos4: path fixes"

This reverts commit 08565793efd66797eeceafdc822571a0de549b25.

Prep for renaming mach-exynos4 back to mach-exynos for the purposes of commonality
with other trees.  (Mainline Exynos patches will never apply to this tree no matter
what it is named.)

Signed-off-by: Andrew Dodd <atd7@cornell.edu>
arm/mach-exynos(4): Rename mach-exynos4 back to mach-exynos

mach-exynos in the Samsung GT-I9100 source tree drop contained a tree
significantly ahead of the mainline kernel, and even farther ahead
of the 3.0.x Linux series, which has not seen an update to mach-exynos(4)
since July 2011.

The mach-exynos tree was improperly renamed from the source drop prior to
committing to git, causing the original rename to not show in git history.
The rename was done in an attempt to improve mainline commonality, however:
1)  Even with the rename, any mainline patches that touch mach-exynos(4) have
no chance of cleanly applying to the Exynos tree due to significant differences
in the directory contents
2)  It just doesn't matter - see above, this tree has not seen a mainline commit
since August 2011, and it is now March 2012.  The rename fragments this tree
from ones that actually will have active development on mach-exynos, compared
to mainline which has had none since 2011 on 3.0.x
3)  It causes any patches coming from other I9100 community development to
fail to apply to this source tree.

For the above reasons, the benefits of mach-exynos outweigh those of mach-exynos4
and similarly, the disadvantages of mach-exynos4 outweigh those of mach-exynos,
and the tree should be renamed.

Signed-off-by: Andrew Dodd <atd7@cornell.edu>
mach-exynos: Remove mainline cruft

This causes conflicts with the much newer mach-exynos code.

Signed-off-by: Andrew Dodd <atd7@cornell.edu>
config: Regenerate for mach-exynos4->mach-exynos rename

This also regenerates the i777 defconfig from the i9100 defconfig,
instead of from the (rather nonfunctional) u1_usa_att_defconfig

Signed-off-by: Andrew Dodd <atd7@cornell.edu>
Merge pull request #3 from r0m30/buildfixes

Minor changes to fix compile on fresh download
Renamed galaxys2att to i777 for initramfs

Change-Id: I3e15861c74dd14103d18dc9b2999290951d80c09
Merge branch 'exynos_rename' of https://github.com/Entropy512/android_kernel_samsung_smdk4210 into Entropy512-exynos_rename

Conflicts:
	arch/arm/configs/android_i777_defconfig
galaxys2: ondemand by default
Merge https://github.com/teamhacksung/android_kernel_samsung_smdk4210 into teamhacksung
ARM: OMAP: rx51: fix USB

commit e5fe29c7198a1f6616286dfc8602a69da165cb3f upstream.

Commit 10299e2e4e3ed3b16503d4e04edd48b33083f4e2 (ARM: RX-51:
Enable isp1704 power on/off) added power management for isp1704.

However, the transceiver should be powered on by default,
otherwise USB doesn't work at all for networking during
boot.

All kernels after v3.0 are affected.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Reviewed-by: Sebastian Reichel <sre@debian.org>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
ipip, sit: copy parms.name after register_netdevice

commit 72b36015ba43a3cca5303f5534d2c3e1899eae29 upstream.

Same fix as 731abb9cb2 for ipip and sit tunnel.
Commit 1c5cae815d removed an explicit call to dev_alloc_name in
ipip_tunnel_locate and ipip6_tunnel_locate, because register_netdevice
will now create a valid name, however the tunnel keeps a copy of the
name in the private parms structure. Fix this by copying the name back
after register_netdevice has successfully returned.

This shows up if you do a simple tunnel add, followed by a tunnel show:

$ sudo ip tunnel add mode ipip remote 10.2.20.211
$ ip tunnel
tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc
tunl%d: ip/ip  remote 10.2.20.211  local any  ttl inherit
$ sudo ip tunnel add mode sit remote 10.2.20.212
$ ip tunnel
sit0: ipv6/ip  remote any  local any  ttl 64  nopmtudisc 6rd-prefix 2002::/16
sit%d: ioctl 89f8 failed: No such device
sit%d: ipv6/ip  remote 10.2.20.212  local any  ttl inherit

Signed-off-by: Ted Feng <artisdom@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
rtc: m41t80: Workaround broken alarm functionality

commit c3b79770e51ab1fd4201f3b54edf30113b9ce74f upstream.

The m41t80 driver can read and set the alarm, but it doesn't
seem to have a functional alarm irq.

This causes failures when the generic core sees alarm functions,
but then cannot use them properly for things like UIE mode.

Disabling the alarm functions allows proper error reporting,
and possible fallback to emulated modes. Once someone fixes
the alarm irq functionality, this can be restored.

CC: Matt Turner <mattst88@gmail.com>
CC: Nico Macrionitis <acrux@cruxppc.org>
CC: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Reported-by: Matt Turner <mattst88@gmail.com>
Reported-by: Nico Macrionitis <acrux@cruxppc.org>
Tested-by: Nico Macrionitis <acrux@cruxppc.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drm/i915: prevent division by zero when asking for chipset power

commit 4ed0b577457eb6aeb7cdc7e7316576e63d15abb2 upstream.

This prevents an in-kernel division by zero which happens when we are
asking for i915_chipset_val too quickly, or within a race condition
between the power monitoring thread and userspace accesses via debugfs.

The issue can be reproduced easily via the following command:
while ``; do cat /sys/kernel/debug/dri/0/i915_emon_status; done

This is particularly dangerous because it can be triggered by
a non-privileged user by just reading the debugfs entry.

This issue was also found independently by Konstantin Belousov
<kostikbel@gmail.com>, who proposed a similar patch.

Reported-by: Konstantin Belousov <kostikbel@gmail.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cfq-iosched: free cic_index if blkio_alloc_blkg_stats fails

commit 2984ff38ccf6cbc02a7a996a36c7d6f69f3c6146 upstream.

If we fail allocating the blkpg stats, we free cfqd and cfgq.
But we need to free the IDA cfqd->cic_index as well.

Signed-off-by: majianpeng <majianpeng@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
cfq-iosched: fix cfq_cic_link() race confition

commit 5eb46851de3904cd1be9192fdacb8d34deadc1fc upstream.

cfq_cic_link() has race condition. When some processes which shared ioc
issue I/O to same block device simultaneously, cfq_cic_link() returns -EEXIST
sometimes. The race condition might stop I/O by following steps:

step  1: Process A: Issue an I/O to /dev/sda
step  2: Process A: Get an ioc (iocA here) in get_io_context() which does not
		    linked with a cic for the device
step  3: Process A: Get a new cic for the device (cicA here) in
		    cfq_alloc_io_context()

step  4: Process B: Issue an I/O to /dev/sda
step  5: Process B: Get iocA in get_io_context() since process A and B share the
		    same ioc
step  6: Process B: Get a new cic for the device (cicB here) in
		    cfq_alloc_io_context() since iocA has not been linked with a
		    cic for the device yet

step  7: Process A: Link cicA to iocA in cfq_cic_link()
step  8: Process A: Dispatch I/O to driver and finish it

step  9: Process B: Try to link cicB to iocA in cfq_cic_link()
		    But it fails with showing "cfq: cic link failed!" kernel
		    message, since iocA has already linked with cicA at step 7.
step 10: Process B: Wait for finishig I/O in get_request_wait()
		    The function does not wake up, when there is no I/O to the
		    device.

When cfq_cic_link() returns -EEXIST, it means ioc has already linked with cic.
So when cfq_cic_link() return -EEXIST, retry cfq_cic_lookup().

Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
SCSI: zfcp: return early from slave_destroy if slave_alloc returned early

commit 44f747fff6e9f027a4866c1a6864e26ae7c510c8 upstream.

zfcp_scsi_slave_destroy erroneously always tried to finish its task
even if the corresponding previous zfcp_scsi_slave_alloc returned
early. This can lead to kernel page faults on accessing uninitialized
fields of struct zfcp_scsi_dev in zfcp_erp_lun_shutdown_wait. Take the
port field of the struct to determine if slave_alloc returned early.

This zfcp bug is exposed by 4e6c82b (in turn fixing f7c9c6b to be
compatible with 21208ae) which can call slave_destroy for a
corresponding previous slave_alloc that did not finish.

This patch is based on James Bottomley's fix suggestion in
http://www.spinics.net/lists/linux-scsi/msg55449.html.

Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
SCSI: mpt2sas: _scsih_smart_predicted_fault uses GFP_KERNEL in interrupt context

commit f6a290b419a2675c4b77a6b0731cd2a64332365e upstream.

_scsih_smart_predicted_fault is called in an interrupt and therefore
must allocate memory using GFP_ATOMIC.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>