omap4+: common sar ram layout fixes

Changed the scratch pad memory offsets on bank1 so that the same offsets
can be used for both omap4 and omap5. Also added omap5 gic offsets, as
they are different compared to omap4.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
[girishsg@ti.com: Merged conflicts fix]
Signed-off-by: Girish S G  <girishsg@ti.com>
mm: fix faulty initialization in vmalloc_init()

The transfer of ->flags causes some of the static mapping virtual
addresses to be prematurely freed (before the mapping is removed) because
VM_LAZY_FREE gets "set" if tmp->flags has VM_IOREMAP set.  This might
cause subsequent vmalloc/ioremap calls to fail because it might allocate
one of the freed virtual address ranges that aren't unmapped.

va->flags has different types of flags from tmp->flags.  If a region with
VM_IOREMAP set is registered with vm_area_add_early(), it will be removed
by __purge_vmap_area_lazy().

Fix vmalloc_init() to correctly initialize vmap_area for the given
vm_struct.

Also initialise va->vm.  If it is not set, find_vm_area() for the early
vm regions will always fail.

Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
Cc: "Olav Haugan" <ohaugan@codeaurora.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
OMAP5: PM: Skip secure L1 cache clean on CPU0 since it doesn't use it.

There should not be any functional change but as recommended by security
team, there is no need to secure L1 on CPU1 since it doesn't use any secure data.

So skip the same.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
OMAP4+: PM: Save the entire stack-frame to safeguard CPU offmode entry failures.

CPU hotplug path assumes that, CPU is guaranteed to enter to OFF state and then
restart with initial setup. In that case everything seems to be fine.

But for the case where, it fails to enter the OFF mode, it will try to
unwind the CPU hotplug path via omap*_finish_suspend() function. Since
omap*_finish_suspend() doesn't save entire stack-frame, it can lead to
the stack corruption in case of OFF mode entry failue cases.

To safe guard it, save entire stack-frame.

Reported-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
ARM: OMAP3: PM: correct enable/disable of daisy io chain

Currently the enabling and disabling of IO Daisy chain is not
according to the TRM. The below steps are followed to enable/
disable the IO chain, based loosely on the "Sec 3.5.7.2.2
I/O Wake-Up Mechanism" section in OMAP3630 Public TRM[1].

Steps to enable IO chain:
[a] Set PM_WKEN_WKUP.EN_IO bit
[b] Set the PM_WKEN_WKUP.EN_IO_CHAIN bit
[c] Poll for PM_WKST_WKUP.ST_IO_CHAIN.
[d] When ST_IO_CHAIN bit set to 1, clear PM_WKEN_WKUP.EN_IO_CHAIN
[e] Clear ST_IO_CHAIN bit.

Steps to disable IO chain:
[a] Clear PM_WKEN_WKUP.EN_IO_CHAIN bit
[b] Clear PM_WKEN_WKUP.EN_IO bit
[c] Clear PM_WKST_WKUP.ST_IO bit by writing 1 to it.

Step [e] & [c] in each case can be skipped, as these are handled
by the PRCM interrupt handler later.

[1] http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zip

Change-Id: Idf9f27624d4fc5370b226f3f97d401e080c20a72
Signed-off-by: Mohan V <mohanv@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
[paul@pwsan.com: modified commit message to clarify that these steps are
 based loosely on the TRM section, rather than documented exactly]
Reviewed-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP3: PM: Move IO Daisychain function to omap3 prm file

Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File. Also changed the timeout value for IO chain enable to
100us and added a wait for status disable at the end.

Thanks to Nishanth Menon <nm@ti.com> for contributing a fix to the
timeout code waiting for WUCLKOUT to go high.

Change-Id: Id40055f4ffb530f1f3c8babb6723e0c8a6f0439c
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Nishanth Menon <nm@ti.com>
[paul@pwsan.com: renamed omap3_trigger_io_chain() to better describe the
 end result and to match other PRM functions; removed
 omap3_disable_io_chain(); moved MAX_IOPAD_LATCH_TIME to prcm-common as it
 will also be used by the OMAP4 code; removed unnecessary barrier;
 added kerneldoc; added credit for fix from Nishanth]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP4: PRM: Add IO Daisychain support

IO daisychain is a mechanism that allows individual IO pads to generate
wakeup events on their own based on a switch of an input signal level.
This allows the hardware module behind the pad to be powered down, but
still have device level capability to detect IO events, and once this
happens the module can be powered back up to resume IO. See section
3.9.4 in OMAP4430 Public TRM for details.

Change-Id: Icbadab4de59f895a12c0b5d26370f242e889cb3a
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: removed MAX_IOPAD_LATCH_TIME declaration; renamed
 omap4_trigger_io_chain() to conform to other PRM function names;
 added kerneldoc]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP3+: PRM: Enable IO wake up

Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been
managed in cpuidle path which is not the right place. Subsequent patch
will remove IO Daisy chain handling in cpuidle path once daisy chain is
handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup
enable code from the trigger function to init time setup.

Change-Id: I2fcae9a2c10ac0311af3d5877e804b37fc35a41e
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: harmonize function names with other PRM functions; add
 kerneldoc]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
[ambresh@ti.com: Enable IO Daisy based on chain handler registration.
Signed-off-by: Ambresh K <ambresh@ti.com>
ARM: OMAP3PLUS: hwmod: reconfigure IO Daisychain during hwmod mux

IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).

Now devices can idle independent of the powerdomain, there can be a
window where device is idled and corresponding powerdomain can be
ON/INACTIVE state. In such situations, since both module wake up is
enabled at padlevel as well as io daisychain sequence is triggered,
there will be 2 PRCM interrupts (Module async wake up via swakeup and
IO Pad interrupt). But as PRCM Interrupt handler clears the Module
Padlevel WKST bit in the first interrupt, module specific interrupt
handler will not triggered for the second time

Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html

Change-Id: I6ef501d3865e1b96841419f024d8590a74d2310a
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: remove dependency on pm.c & pm.h; add kerneldoc]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle

As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
control it from cpuidle path for OMAP3.

Also as omap3_disable_io_chain is no longer being used, just remove the
function.

Change-Id: I541aad5f3b1c4ecaef371b80736bf631ae544628
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
[girishsg@ti.com: Fix merge conflicts]
Signed-off-by: Girish S G <girishsg@ti.com>
ARM: OMAP4+: Reuse prm read_inst/write_inst work for omap5

Change-Id: I4bd6497294701e75179a37b9c21a286e7ca3b277
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Girish S G <girishsg@ti.com>
[ambresh@ti.com: Rephrased commit message]
Signed-off-by: Ambresh K <ambresh@ti.com>
ARM: OMAP5: PRM: Enable IO chain for OMAP5

OMAP4 prm_reconfigure_io_chain is same for OMAP5 as well.
Enable it for OMAP5.

Change-Id: I4b2307c1ec0657734ae49d11437ed4563f088c77
Signed-off-by: Girish S G <girishsg@ti.com>
[ambresh@ti.com: Fixed review comment]
Signed-off-by: Ambresh K <ambresh@ti.com>
input: keypad: smsc ece1099: remove sparse warnings

Remove the following sparse warnings:

warning: symbol 'smsc_write_data' was not declared. Should it be static?
warning: symbol 'smsc_read_data' was not declared. Should it be static?

Change-Id: Ic8f2bd06004fdd84069e0939bd3781dc8657e6fb
Signed-off-by: Leed Aguilar <leed.aguilar@ti.com>
ARM: OMAP4: PRM: Fix IRQ enable register save

Save IRQENABLE register instead of IRQSTATUS, using
OMAP4_PRM_IRQENABLE_MPU_OFFSET instead of
OMAP4_PRM_IRQSTATUS_MPU_OFFSET.

Change-Id: I72e00e7c20ffa3b847437448985b6dcfa1161fd5
Signed-off-by: Cedric Poignet <c-poignet@ti.com>
Merge branch 'p-linux-omap-3.4' into p-android-omap-3.4

* p-linux-omap-3.4:
  ARM: OMAP4: PRM: Fix IRQ enable register save
  ARM: OMAP5: PRM: Enable IO chain for OMAP5
  ARM: OMAP4+: Reuse prm read_inst/write_inst work for omap5
  ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle
  ARM: OMAP3PLUS: hwmod: reconfigure IO Daisychain during hwmod mux
  ARM: OMAP3+: PRM: Enable IO wake up
  ARM: OMAP4: PRM: Add IO Daisychain support
  ARM: OMAP3: PM: Move IO Daisychain function to omap3 prm file
  ARM: OMAP3: PM: correct enable/disable of daisy io chain
Tools: hv: verify origin of netlink connector message

commit bcc2c9c3fff859e0eb019fe6fec26f9b8eba795c upstream.

The SuSE security team suggested to use recvfrom instead of recv to be
certain that the connector message is originated from kernel.

CVE-2012-2669

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Marcus Meissner <meissner@suse.de>
Signed-off-by: Sebastian Krahmer <krahmer@suse.de>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: tegra: make tegra_cpu_reset_handler_enable() __init

commit 6355f25ed965421725d92cf719fc63008690ca1c upstream.

This solves a section mismatch warning. I hadn't noticed this before,
because my compiler was inlining tegra_cpu_reset_handler_enable() inside
tegra_cpu_reset_handler_init(), which is already __init, but I switched
compilers and it stopped doing that.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda - Add Realtek ALC280 codec support

commit befae82e2906cb7155020876a531b0b8c6c8d8c8 upstream.

This chip looks very similar to ALC269 and ALC27* variants. The bug reporter
has verified that sound was working after this patch had been applied.

BugLink: https://bugs.launchpad.net/bugs/1017017
Tested-by: Richard Crossley <richardcrossley@o2.co.uk>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda - Fix memory leaks at module unload

commit 59cad16bc6deb85bd2a464da92bbaae289f0286f upstream.

Some caches aren't released properly at module unloading time.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda - Fix power-map regression for HP dv6 & co

commit 6e1c39c6b00d9141a82c231ba7c5e5b1716974b2 upstream.

The recent fix for power-map controls (commit b0791dda813) caused
regressions on some other HP laptops.  They have fixed pins but these
pins are exposed as jack-detectable.  Thus the driver tries to control
the power-map dynamically per jack detection where it never gets on.

This patch corrects the condition check for fixed pins so that the
power-map is set always for these pins.

NOTE: this is no simple backport from 3.5 kernel.  Since 3.5 kernel
had significant code change in the relevant part, I fixed this
differently.

BugLink: http://bugs.launchpad.net/bugs/1013183
Reported-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>