Kernel Upgrade: 3.4.98 -> 3.4.99
config: *update*
acpuclock-7627.c: fixing table selection in select_freq_plan()

In the function 'select_freq_plan()' there's a check to select
the correct table for 1008Mhz CPU's, because there's a conflict
between 7627AA and 8625 chips.

However this check is wrong:
	if (pll_mhz[ACPU_PLL_2] == 245)

It should be:
	if (pll_mhz[ACPU_PLL_1] == 245)

We don't want to check PLL_2 but PLL_1 being '245' or not.

Due of this bug the wrong frequency table is getting selected
for 1GHz 8625 chips with PLL_2=245.

Previously-detected-by: Peter Jung <peter.jung@lge.com>
Signed-off-by: moddingg33k <moddingg33k@t-online.de>
lockdep, rwsem: provide down_write_nest_lock()

      down_write_nest_lock() provides a means to annotate locking scenario
      where an outer lock is guaranteed to serialize the order nested locks
      are being acquired.

      This is analogoue to already existing mutex_lock_nest_lock() and
      spin_lock_nest_lock().

      Signed-off-by: Jiri Kosina <jkosina@suse.cz>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

lockdep, rwsem: fix down_write_nest_lock() if !CONFIG_DEBUG_LOCK_ALLOC

      Commit 1b963c81b145 ("lockdep, rwsem: provide down_write_nest_lock()")
      contains a bug in a codepath when CONFIG_DEBUG_LOCK_ALLOC is disabled,
      which causes down_read() to be called instead of down_write() by mistake
      on such configurations.  Fix that.

      Reported-and-tested-by: Andrew Clayton <andrew@digital-domain.net>
      Reported-and-tested-by: Zlatko Calusic <zlatko.calusic@iskon.hr>
      Signed-off-by: Jiri Kosina <jkosina@suse.cz>
      Reviewed-by: Rik van Riel <riel@redhat.com>
      Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Revert "USB: ensure parent device is resumed for child's system-resume"

This reverts commit de86e6482897db0006151ae9154f181e75f5ab2c.

Commit 7c8527ce ("PM: Prevent runtime suspend during system resume")
fixes the general issue of a parent device being prematurely
runtime suspended before a child device is resumed. It does so
by moving the pm_runtime_put_sync() call from the device_resume()
stage to device_complete(), which happens to act on the devices
in reverse (children before parent) order.

Thus when usb_resume() is called by device_resume(), we know its
parent will be runtime PM enabled and its usage counter is still
non-zero. This obviates the need to do an additional
pm_runtime_get_sync() before calling usb_resume_both() as the
device and its interfaces now have the opportunity to increment
the parent's power.child_count if necessary without fear of
having a runtime suspended parent.

CRs-fixed: 396041
Change-Id: I793ddfbb9bd88634f45f0c1e570a5d616248e3a8
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Revert "Optimized ARM RWSEM algorithm"
Revert: genirq: explicitly mask a freed irq

This reverts:

      When an interrupt is freed, the shutdown or the disable callback
      is called for that interrupt. These calls might not be implemented
      or even if they were, might not mask the interrupt.

      Explicitly mask the interrupt when it is freed. If not masked, the
      interrupt could trigger, set the pending bit in the irq controller
      and cause unnecessary wakeup or exits from idle power collapse.

      Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Revert: genirq: chip: set pending only for edge interrupts

This reverts:

      The IRQS_PENDING flag is meant to record an edge interrupt trigger event
      when that interrupt is disabled.

      When an edge triggered interrupt is enabled, check_irq_resend() retriggers
      that irq and resets the flag to zero if set. Note that check_irq_resend()
      only does this for edge triggered interrupts.

      For level triggered interrupts it is expected that the interrupt remains
      active and doesn't need this PENDING flag assistance from software for
      re-triggering it.

      However, handle_fasteoi_irq flow handler sets the PENDING flag even for
      a disabled level interrupt. This causes an adverse effect if that level
      interrupt is marked wakeup. The suspend code sees the pending flag on a
      wakeup interrupt and aborts suspend whereas check_irq_resend does not reset
      it to 0 (as it is a level interrupt). The end result is that the PENDING
      flag on this level triggered wakeup interrupt never clears and the system
      keeps aborting suspend.

      Fix this by setting IRQS_PENDING flag only for edge interrupts in the
      handle_fasteoi_irq.

      CRs-Fixed: 314344
      Change-Id: I775d40f434f9309fd9672bae372b0f0fb5b91627
      Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Revert: genirq: fix handle_nested_irq for lazy disable

This reverts:

      When lazy disabling is implemented and an interrupt is disabled the
      genirq code ends up marking it as IRQ_DISABLED in the descriptor.
      The interrupt stays enabled in the controller.  If the interrupt
      fires after disabling, the flow handlers namely handle_level_irq and
      handle_edge_irq mask the interrupt in the controller.

      This is not the case with handle_nested_irq. The interrupt stays enabled in
      the controller and if it were a level interrupt it keeps firing only to be
      ignored by handle_nested_irq.

      Update handle_nested_irq to mask such an interrupt.

      CRs-Fixed: 300931
      Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Revert "rw_semaphore: remove up/down_read_non_owner"

This reverts commit 11b80f459adaf91a712f95e7734a17655a36bf30.

Bcache needs rw semaphores for cache coherency in writeback mode -
writes have to take a read lock on a per cache device rw sem, and
release it when the bio completes.

But since this is for bios it's naturally not in the context of the
process that originally took the lock.

Signed-off-by: Kent Overstreet <koverstreet@google.com>
CC: Christoph Hellwig <hch@infradead.org>
CC: David Howells <dhowells@redhat.com>
REVERT: PM: wakelock: Abort task freezing if a wake lock is held.

This reverts a Google commit of 2008:

      Avoids a problem where the device sometimes hangs for 20 seconds
      before the screen is turned on.
ext4: revert Huawei changes to ialloc

This is causing disasters in 4.3 and especially while SELinux
is enabled. System files are getting deleted and data is getting
remounted as read only. It seems to be the same files getting
deleted every time, common examples are:
- /system/app/Phonesky.apk (!)
- /system/media/bootanimation.zip (uses AOSP animation instead)
- /system/media/video/
- /system/wifi/ (!)

This is also present in the 3.0.8 kernel, but I'm not really
sure why it was changed in the first place - system remounting
seems to be working fine for me...

Not sure if recoveries will need to be rebuilt with this.
lib/genalloc.c: revert Huawei KGSL 'fix'

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
base/core.c: remove huawei debug code
usb/core: disable 'usb_hnp_polling_work' function of AU_LINUX_ANDROID_ICS.04.00.04.00.126 (CAF)

The kernel doesn't compile with CONFIG_USB_OTG being enabled otherwise.

I'm too lazy at the moment to fix this function which's
use is currently unknown to me.

It's not part of Linux's 3.4 mainline neither.

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
FIX: driver core: move the deferred probe pointer into the private area

(moddingg33k): 'INIT_LIST_HEAD(&dev->deferred_probe);' should not exist
		any longer in 'void device_initialize()' after this patch.

		--> So let's remove it.

Nothing outside of the driver core needs to get to the deferred probe
pointer, so move it inside the private area of 'struct device' so no one
tries to mess around with it.

Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kernel/exit.c: remove Huawei kernel log spam

Signed-off-by: moddingg33k <moddingg33k@t-online.de>
sched: Notify hrtimer users of switches to NOHZ mode

When NOHZ=y and high res timers are disabled (via cmdline or
Kconfig) tick_nohz_switch_to_nohz() will notify the user about
switching into NOHZ mode. Nothing is printed for the case where
HIGH_RES_TIMERS=y. Fix this for the HIGH_RES_TIMERS=y case by
duplicating the printk from the low res NOHZ path in the high res
NOHZ path.

Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
changing some prinkt's/pr_info's to pr_debug's
PM / tracing: remove deprecated power trace API

The text in Documentation said it would be removed in 2.6.41;
the text in the Kconfig said removal in the 3.1 release.  Either
way you look at it, we are well past both, so push it off a cliff.

Note that the POWER_CSTATE and the POWER_PSTATE are part of the
legacy tracing API.  Remove all tracepoints which use these flags.
As can be seen from context, most already have a trace entry via
trace_cpu_idle anyways.

Also, the cpufreq/cpufreq.c PSTATE one is actually unpaired, as
compared to the CSTATE ones which all have a clear start/stop.
As part of this, the trace_power_frequency also becomes orphaned,
so it too is deleted.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>