cpufreq: Update interactive governor

Originally for crespo (Iba70ed3580dd04704b0d7b4acde178df7a843b5f)

This is a squashed commit of the following:

cpufreq: interactive: add show_boost sysfs entry
  Signed-off-by: jt1134 <jt1134@gmail.com>

cpufreq: interactive: take idle notifications only when active
Register an idle notifier only when the governor is active.  Also
short-circuit work of idle end if the governor is not enabled.
  Signed-off-by: Sam Leffler <sleffler@chromium.org>

cpufreq: interactive: keep freezer happy when not current governor
Fix a problem where the hung task mechanism was deeming the interactive
clock boost thread as hung.  This was because the thread is created at
module init but never run/woken up until needed.  If the governor is not
being used this can be forever.  To workaround this explicitly wake up
the thread once all the necessary data structures are initialized.  The
latter required some minor code shuffle.
  Signed-off-by: Sam Leffler <sleffler@chromium.org>

cpufreq: interactive: handle speed up and down in the realtime task
Not useful to have a separate, non-realtime workqueue for speed down
events, avoid priority inversion for speed up events.
  Signed-off-by: Todd Poynor <toddpoynor@google.com>

cpufreq: interactive: remove input_boost handling
Now handled in userspace Power HAL instead.
  Signed-off-by: Todd Poynor <toddpoynor@google.com>

cpufreq: fix interactive bug during hotplug
When a new cpu is added and if does not enter idle
for long, the interactive timer is not started and hence
the cpu remains at lowest frequecny, despite the system
load. This impacts mainly benchmarks. Starting a timer
at governor start to handle low frequency.
  Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>

cpufreq: interactive: always limit initial speed bump to hispeed
First bump speed up to hispeed_freq whenever the current speed is below
hispeed_freq, instead of only when the current speed is the minimum speed.
The previous code made it too difficult to use hispeed_freq as a common
intermediate speed on systems that frequently run at speeds between
minimum and hispeed_freq.
  Signed-off-by: Todd Poynor <toddpoynor@google.com>

cpufreq: interactive: run at fraction of hispeed_freq when load is low
When load is below go_hispeed_load, apply the percentage of CPU load to
a max frequency of hispeed_freq instead of the max speed.  This avoids
jumping too quickly to hispeed_freq when it is a relatively low
percentage of max speed.  This also allows go_hispeed_load to be set to
a high percentage relative to hispeed_freq (as a percentage of max speed,
again useful when hispeed_freq is a low fraction of max speed), to cap
larger loads at hispeed_freq.  For example, a load of 60% will typically
move to 60% of hispeed_freq, not 60% of max speed.  This causes the
governor to apply two different speed caps, depending on whether load is
below or above go_hispeed_load.

Also fix the type of hispeed_freq, which was u64, to match other
speed data types (and avoid overhead and allow division).
  Signed-off-by: Todd Poynor <toddpoynor@google.com>

Change-Id: I11646ce80158bf198c0ced4e006f0f7f983904d3
net: ipv6: ip6_fib.c: Flush dead neighbour and L2 cache on GC

Neighbour entry and hh cache pointed from dst_entry in IPv6 FIB
is not flushed on NETDEV_CHANGE_ADDR while neighbour is marked
dead. This causes the next hop of IPv6 destination pointing
an obsolete neighbour/L2 cache, causing IP packget drops or
packets sent out with wrong L2 source address.

Signed-off-by: Kazuhiro Ondo <kazuhiro.ondo@motorola.com>
bridge: notifier called with the wrong device

If a new device is added to a bridge, the ethernet address of the
bridge network device may change. When the address changes, the
appropriate callback is called, but with the wrong device argument.
The address of the bridge device (ie br0) changes not the address
of the device being passed to add_if (ie eth0).

Change-Id: Idf106c889f34e06e2d47462dd883f30caad26eb8
Original-author: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
bridge: Always send NETDEV_CHANGEADDR up on br MAC change.

This ensures the neighbor entries associated with the bridge
dev are flushed, also invalidating the associated cached L2 headers.

This means we br_add_if/br_del_if ports to implement hand-over and
not wind up with bridge packets going out with stale MAC.

This means we can also change MAC of port device and also not wind
up with bridge packets going out with stale MAC.

This builds on Stephen Hemminger's patch, also handling the br_del_if
case, port MAC change case, and bridge MAC manual assignment case.

Change-Id: I6039ba021006f854e0e7e83dd1c4261c500aeab7
Cc: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Andrei Warkentin <andreiw@motorola.com>