backport omap_ehci_ulpi_{read,write} from p-android-omap-3.4

These functions are needed for bugfixes from p-android-omap-3.4.

Change-Id: I1c9fdc6774715172d1111d27f45737c83a02106c
usb: ehci-omap: configure default PHY settings on boot

usb: ehci-omap: configure default PHY settings on boot

[backported from p-android-omap-3.4]

On Blaze Tablet, USB PHY doesn't have ability to be
reset because its /RESET line is soldered to Vcc.

As a workaround, during OMAP EHCI initialization we
reset it using [Function Control].Reset=1 bit.
As per datasheet, this resets transceiver but not
the ULPI interface or register set. This means,
that PHY may store previous registers settings.

It is OK if we do 'cold' power ON of board because the PHY
is in its default state after that. However if we do reset
of the board by pressing the 'reset' button or as
result of kernel panic, PHY do not loose its power so PHY's
registers will hold old values that may be incorrect
and an USB device, connected to the PHY may be not enumerated
for example. In Blaze Tablet particular case, devices
are not enumerated after 'reset' button or kernel panic
till power OFF-ON sequence.

In this patch we configure default PHY settings after its
soft reset so EHCI controller will expect correct behavior.

Change-Id: I7747c0a39eb8e51d499bd62c3ac0d311d19a924d
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
mfd: Move omap-usb-host usbhs init before allocing child dev

mfd: Move omap-usb-host usbhs init before allocing child dev

[backported from p-android-omap-3.4]

There could be possible race condition where the host dev's
are alloced and added to platform dev just before usbhs_init.
Just move usbhs_init before adding child dev.

Change-Id: I3c54db97f39c7714427e738560fba8076283e66d
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
omap4-common: improve HDMI video-mode selection

Change-Id: If0fa25f8be2e629bf9ad3b7b79b4ed37747d7bfd
omap4-common: fix wake on unplug

Don't allow the device to enter deep sleep right after unplugging
an usb power-source. This allows userspace to wake the system up
if the corresponding option has been set.

Change-Id: I7a21fe7c438394cfbb923a3dc925287f292704b3
Revert "omap4-common: fix wake on unplug"

This seems to cause SODs.

This reverts commit 9805968b21d58023668553219a50931900c567b6.

Change-Id: I2cfbf44311dbe8b275679f976c592cb66667b2ae
omap4-common: fix the power-key

Add handling of a missing powerkey-state when the phone is in
deep sleep which could result in the key-press to be partially
ignored. Additionally increase wakelock-timeouts for the powerkey-
wakelock.

Change-Id: Ibccfdbc866610f067cbb563cf7fc9ecf7a7e9a03
Fix memory leak in cpufreq stats.

commit e37736777254ce1abc85493a5cacbefe5983b896 upstream.

When system enters sleep, non-boot CPUs will be disabled.
Cpufreq stats sysfs is created when the CPU is up, but it is not
freed when the CPU is going down. This will cause memory leak.

Signed-off-by: xiaobing tu <xiaobing.tu@intel.com>
Signed-off-by: guifang tang <guifang.tang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Colin Cross <ccross@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cpufreq: interactive: allow arbitrary speed / delay mappings

Accept a string of delays and speeds at which to apply the delay before
raising each step above hispeed. For example, "80000 1300000:200000
1500000:40000" means that the delay at or above 1GHz, until 1.3GHz is 80 msecs,
the delay until 1.5GHz is 200 msecs and the delay at or above 1.5GHz is 40
msecs when hispeed_freq is 1GHz.

[toddpoynor@google.com: add documentation]
Change-Id: Ifeebede8b1acbdd0a53e5c6916bccbf764dc854f
Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
cpufreq: interactive: fix race on cpufreq TRANSITION notifier

The cpufreq TRANSTION notifier callback does not check the
governor_enabled state on affected CPUS, which will case
kernel panic in update_load because the policy object maybe
NULL or invalid when governor_enabled is false.

Change-Id: Ie0f1718124f61e2f9b5da57abc6981ada5b83908
Signed-off-by: Lianwei Wang <a22439@motorola.com>
cpufreq: interactive: resched timer if max freq raised

When the policy max freq is raised, and before the timer is
rescheduled in idle callback, the cpu freq may stuck at a
lower freq.

The target_freq shall be updated too, else on a high load
situation, the new_freq is always equal to target_freq and
which will cause freq stuck at a lower freq too.

Reschedule the timer on gov limits callback.

Change-Id: I6c187001ab43e859731429b64f75a74eebc37a24
Signed-off-by: Lianwei Wang <a22439@motorola.com>
cpufreq: interactive: fix show_target_loads and show_above_hispeed_delay

Remove a trailing whitespace from target_loads and above_hispeed_delay. Problem
happens when user-space program tried to restore parameters that saved before
changing parameters. In this case was returned error(EINVAL).

Change-Id: I5a74e3824602cd6f2b74651adda5ec1b627e61e9
Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
cpufreq: interactive: fix compiling warnings

The gcc warns like:

  cpufreq_interactive.c:745:6: warning: operation on 'ret' may be
undefined [-Wsequence-point]

It was introduced by commit cf0fad49d17cb8273ce555dd5b7afab67d7923bf.

Since sprintf(...) just return 1 (one character) in this case, ret
should not changed.
Just discarding the result of sprintf(...) leads to the result that
the committer of cf0fad49d17cb8273ce555dd5b7afab67d7923bf wants.

Change-Id: Ifed1cef6d6a31c3ed23dad03a567b3b9eddf3a57
Signed-off-by: Chih-Wei Huang <cwhuang@android-x86.org>
Signed-off-by: Dave Daynard <nardholio@gmail.com>
cpufreq: interactive: restructure CPUFREQ_GOV_LIMITS

The cpufreq_interactive_timer gets cancelled and rescheduled
whenever the cpufreq_policy is changed. When the cpufreq policy is
changed at a rate faster than the sampling_rate of the interactive
governor, then the governor misses to change the target frequency
for long duration. The patch removes the need of cancelling the
timers when policy->min is changed.

Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
Change-Id: I7862f1c8022a3b98a890e7537f93d02010e86764
cpufreq: interactive: turn boost_pulse off on boost off

Change-Id: I36fe217fa047d68ea90e78b12c7db4537ea8010b
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
n_tty: Fix n_tty_write crash when echoing in raw mode

commit 4291086b1f081b869c6d79e5b7441633dc3ace00 upstream.

The tty atomic_write_lock does not provide an exclusion guarantee for
the tty driver if the termios settings are LECHO & !OPOST.  And since
it is unexpected and not allowed to call TTY buffer helpers like
tty_insert_flip_string concurrently, this may lead to crashes when
concurrect writers call pty_write. In that case the following two
writers:
* the ECHOing from a workqueue and
* pty_write from the process
race and can overflow the corresponding TTY buffer like follows.

If we look into tty_insert_flip_string_fixed_flag, there is:
  int space = __tty_buffer_request_room(port, goal, flags);
  struct tty_buffer *tb = port->buf.tail;
  ...
  memcpy(char_buf_ptr(tb, tb->used), chars, space);
  ...
  tb->used += space;

so the race of the two can result in something like this:
              A                                B
__tty_buffer_request_room
                                  __tty_buffer_request_room
memcpy(buf(tb->used), ...)
tb->used += space;
                                  memcpy(buf(tb->used), ...) ->BOOM

B's memcpy is past the tty_buffer due to the previous A's tb->used
increment.

Since the N_TTY line discipline input processing can output
concurrently with a tty write, obtain the N_TTY ldisc output_lock to
serialize echo output with normal tty writes.  This ensures the tty
buffer helper tty_insert_flip_string is not called concurrently and
everything is fine.

Note that this is nicely reproducible by an ordinary user using
forkpty and some setup around that (raw termios + ECHO). And it is
present in kernels at least after commit
d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to
use the normal buffering logic) in 2.6.31-rc3.

js: add more info to the commit log
js: switch to bool
js: lock unconditionally
js: lock only the tty->ops->write call

References: CVE-2014-0196
Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[steven@steven676.net: backport to 3.0: ldata->output_lock is
tty->output_lock in older kernels]

Change-Id: I956c16ac1a183dda89f290ff03aca0684ec3dc00
omap4-common: allow mediaserver to open a CAIF socket

Change-Id: Idf4f6a03d1a8ef72e233b3f806e7471cc29b7752
Revert "Merge omapzoom-changes into drivers/video/omap2/dss/dispc.c"

This seems to be the real cause for the rare SODs, revert it for now.

This reverts commit 0313c87cd8ea16810d7a9239045160e093bbce70.

Conflicts:
	drivers/video/omap2/dss/dispc.c

Change-Id: I6a889b39a73afb742ae05a06deb37db30d6454e9
Revert "Revert "omap4-common: fix wake on unplug""

This commit did not cause SODs, let's get it back.

This reverts commit c41b94fe5d135e9ef49dc4e69aca751d4b0e2367.

Change-Id: I73aced42568d0bc830345c28198e06de41767114