configs: Change hostname

Signed-off-by: Rohan Mathur <rohanmathur34@gmail.com>
Change up naming

Signed-off-by: Rohan Mathur <rohanmathur34@gmail.com>
Defaault to ROW (really this time)

Signed-off-by: Rohan Mathur <rohanmathur34@gmail.com>
Enable kernel samepage merging

Signed-off-by: Rohan Mathur <rohanmathur34@gmail.com>
Enable Powersave & Userspace governors

Signed-off-by: Rohan Mathur <rohanmathur34@gmail.com>
Remove some unused variables

Signed-off-by: Rohan Mathur <rohanmathur34@gmail.com>
cpufreq: Manage only online cpus

cpufreq core doesn't manage offline cpus and if driver->init() has returned
mask including offline cpus, it may result in unwanted behavior by cpufreq core
or governors.

We need to get only online cpus in this mask. There are two places to fix this
mask, cpufreq core and cpufreq driver. It makes sense to do this at common place
and hence is done in core.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
transport.c: Fix warning: 'midQ' may be used uninitialized in this function [-Wmaybe-uninitialized]
mmc: sd: Set the card removed if card detect fails

Currently, the card state is not being set as removed, even
when the card is actually removed. We still wait for the
next request to fail and then check the error and set the
card to be removed.

With the new runtime-pm in place, the card device would be
removed on physical removal of card and the corresponding
parent would be suspended as well. Hence, when the queue is
flushed during clean-up, mmc_rpm_hold would be invoked,
which would fail, since the runtime-pm was disabled when the
card device was removed. Thus, it won't resume the card/host/
platform device. The request would continue and since the
controller is in suspended state nasty things would happen.

This patch sets the card as removed during mmc_sd_detect
itself, so that when a clean-up of queue happens during
card removal, it is known that the card has been removed
and the request is errored out there itself.

Change-Id: Id5022f8d7db43750edf137d4293796615b56ae36
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
base: sync: increase size of sync_timeline name

This makes it possible for drivers to use a longer, more descriptive
name for a sync_timeline, which improves the readability of the
sync dump in debugfs.

Change-Id: Ifb83aebf6fd820ebb26aca2ff230ac1116e65ce9
Git-commit: cb63e61b80ec905f01cbe1c21081aa0d1fef082d
Git-repo: https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git
Signed-off-by: Fred Fettinger <fred.fettinger@motorola.com>
Signed-off-by: Harsh Vardhan Dwivedi <hdwivedi@codeaurora.org>
switch: Reset device's drvdata before destroying it

dev_set_drvdata() sets the device specific driver data at
dev->p->driver_data.  However, dev is destroyed and has it's
context memory freed in device_destroy().  As a result, calling
dev_set_drvdata() causes a fault when accessing dev->p.

Change-Id: I4b1e6d17db52d0e31caf9b52e59979ff9cbb0c12
CRs-Fixed: 449732
Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
netfilter: xt_qtaguid: do not look at TCP_TIME_WAIT socket

It is possible that skb->sk may be a TCP_TIME_WAIT socket,
in which case many of the fields will not be valid. Thanks
to Eric Dumazet <edumazet@google.com> for pointing out this
issue and the fix.

http://article.gmane.org/gmane.linux.ports.arm.msm/3400

Change-Id: I1fa955df16f8919ec243d55e6131efb335a7871c
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
netfilter: fix ipv6_find_hdr usage

The semantics of the offset parameter of ipv6_find_hdr
changed recently and it is now an in/out. It is therefore
incorrect to pass it in uninitialized.

Change-Id: I47c1dbd856d89b0369fe4a5a8dab15e776da78d8
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
include: linux: Export santized ioprio header

Export sanitized ioprio.h for userspace.

Change-Id: Ifec6bc6b539c84fcba27751d4ac0de03458cd131
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
ipv6: introdcue __ipv6_addr_needs_scope_id and ipv6_iface_scope_id helper functions

[net-next commit b7ef213ef65256168df83ddfbb8131ed9adc10f9]

__ipv6_addr_needs_scope_id checks if an ipv6 address needs to supply
a 'sin6_scope_id != 0'. 'sin6_scope_id != 0' was enforced in case
of link-local addresses. To support interface-local multicast these
checks had to be enhanced and are now consolidated into these new helper
functions.

v2:
a) migrated to struct ipv6_addr_props

v3:
a) reverted changes for ipv6_addr_props
b) test for address type instead of comparing scope

v4:
a) unchanged

Change-Id: I1788f1f2d3a6bd2b9e6a6afe74992d6d4a1385eb
Suggested-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
net: ipv6: Add IPv6 support to the ping socket.

[backport of net-next 6d0bfe22611602f36617bc7aa2ffa1bbb2f54c67]

This adds the ability to send ICMPv6 echo requests without a
raw socket. The equivalent ability for ICMPv4 was added in
2011.

Instead of having separate code paths for IPv4 and IPv6, make
most of the code in net/ipv4/ping.c dual-stack and only add a
few IPv6-specific bits (like the protocol definition) to a new
net/ipv6/ping.c. Hopefully this will reduce divergence and/or
duplication of bugs in the future.

Caveats:

- Setting options via ancillary data (e.g., using IPV6_PKTINFO
  to specify the outgoing interface) is not yet supported.
- There are no separate security settings for IPv4 and IPv6;
  everything is controlled by /proc/net/ipv4/ping_group_range.
- The proc interface does not yet display IPv6 ping sockets
  properly.

Tested with a patched copy of ping6 and using raw socket calls.
Compiles and works with all of CONFIG_IPV6={n,m,y}.

Change-Id: I0081b4654dd54b12c8f233e00e18943582aa2142
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[lorenzo@google.com: backported to 3.4]
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
ping: always initialize ->sin6_scope_id and ->sin6_flowinfo

[net-next commit c26d6b46da3ee86fa8a864347331e5513ca84c2b]

If we don't need scope id, we should initialize it to zero.
Same for ->sin6_flowinfo.

Change-Id: I74764edf3d0567f5ae094b2e83484cdfe05f6098
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
Acked-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
block: introduce the BFQ-v6r2 I/O sched for 3.4

Add the BFQ-v6r2 I/O scheduler to 3.4.
The general structure is borrowed from CFQ, as much code. A (bfq_)queue is
associated to each task doing I/O on a device, and each time a scheduling
decision has to be made a queue is selected and served until it expires.

    - Slices are given in the service domain: tasks are assigned budgets,
      measured in number of sectors. Once got the disk, a task must
      however consume its assigned budget within a configurable maximum time
      (by default, the maximum possible value of the budgets is automatically
      computed to comply with this timeout). This allows the desired latency
      vs "throughput boosting" tradeoff to be set.

    - Budgets are scheduled according to a variant of WF2Q+, implemented
      using an augmented rb-tree to take eligibility into account while
      preserving an O(log N) overall complexity.

    - A low-latency tunable is provided; if enabled, both interactive and soft
      real-time applications are guaranteed very low latency.

    - Latency guarantees are preserved also in presence of NCQ.

    - Also with flash-based devices, a high throughput is achieved while
      still preserving latency guarantees.

    - Useful features borrowed from CFQ: cooperating-queues merging (with
      some additional optimizations with respect to the original CFQ version),
      static fallback queue for OOM.

    - BFQ supports full hierarchical scheduling, exporting a cgroups
      interface.  Each node has a full scheduler, so each group can
      be assigned its own ioprio (mapped to a weight, see next point)
      and an ioprio_class.

    - If the cgroups interface is used, weights can be explictly assigned,
      otherwise ioprio values are mapped to weights using the relation
      weight = IOPRIO_BE_NR - ioprio.

    - ioprio classes are served in strict priority order, i.e., lower
      priority queues are not served as long as there are higher priority
      queues.  Among queues in the same class the bandwidth is distributed
      in proportion to the weight of each queue. A very thin extra bandwidth
      is however guaranteed to the Idle class, to prevent it from starving.

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
block, bfq: add Early Queue Merge (EQM) to BFQ-v6r2 for 3.4.0

A set of processes may happen  to  perform interleaved reads, i.e., requests
whose union would give rise to a  sequential read  pattern.  There   are two
typical  cases: in the first  case,   processes  read  fixed-size  chunks of
data at a fixed distance from each other, while in the second case processes
may read variable-size chunks at  variable distances. The latter case occurs
for  example with  KVM, which  splits the  I/O generated  by the  guest into
multiple chunks,  and lets these chunks  be served by a  pool of cooperating
processes,  iteratively  assigning  the  next  chunk of  I/O  to  the  first
available  process. CFQ  uses actual  queue merging  for the  first type  of
processes, whereas it  uses preemption to get a sequential  read pattern out
of the read requests  performed by the second type of  processes. In the end
it uses  two different  mechanisms to  achieve the  same goal:  boosting the
throughput with interleaved I/O.

This patch introduces  Early Queue Merge (EQM), a unified mechanism to get a
sequential  read pattern  with both  types of  processes. The  main idea  is
checking newly arrived requests against the next request of the active queue
both in case of actual request insert and in case of request merge. By doing
so, both the types of processes can be handled by just merging their queues.
EQM is  then simpler and  more compact than the  pair of mechanisms  used in
CFQ.

Finally, EQM  also preserves the  typical low-latency properties of  BFQ, by
properly restoring the weight-raising state of  a queue when it gets back to
a non-merged state.

Signed-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Reviewed-by: Paolo Valente <paolo.valente@unimore.it>
PM / QoS: Introduce new classes: DMA-Throughput and DVFS-Latency

1. CPU_DMA_THROUGHPUT

This might look simliar to CPU_DMA_LATENCY. However, there are H/W
blocks that creates QoS requirement based on DMA throughput, not
latency, while their (those QoS requester H/W blocks) services are
short-term bursts that cannot be effectively responsed by DVFS
mechanisms (CPUFreq and Devfreq).

In the Exynos4412 systems that are being tested, such H/W blocks include
MFC (multi-function codec)'s decoding and enconding features, TV-out
(including HDMI), and Cameras. When the display is operated at 60Hz,
each chunk of task should be done within 16ms and the workload on DMA is
not well spread and fluctuates between frames; some frame requires more
and some do not and within a frame, the workload also fluctuates
heavily and the tasks within a frame are usually not parallelized; they
are processed through specific H/W blocks, not CPU cores. They often
have PPMU capabilities; however, they need to be polled very frequently
in order to let DVFS mechanisms react properly. (less than 5ms).

For such specific tasks, allowing them to request QoS requirements seems
adequete because DVFS mechanisms (as long as the polling rate is 5ms or
longer) cannot follow up with them. Besides, the device drivers know
when to request and cancel QoS exactly.

2. DVFS_LATENCY

Both CPUFreq and Devfreq have response latency to a sudden workload
increase. With near-100% (e.g., 95%) up-threshold, the average response
latency is approximately 1.5 x polling-rate.

A specific polling rate (e.g., 100ms) may generally fit for its system;
however, there could be exceptions for that. For example,
- When a user input suddenly starts: typing, clicking, moving cursors, and
  such, the user might need the full performance immediately. However,
  we do not know whether the full performance is actually needed or not
  until we calculate the utilization; thus, we need to calculate it
  faster with user inputs or any similar events. Specifying QoS on CPU
  processing power or Memory bandwidth at every user input is an
  overkill because there are many cases where such speed-up isn't
  necessary.
- When a device driver needs a faster performance response from DVFS
  mechanism. This could be addressed by simply putting QoS requests.
  However, such QoS requests may keep the system running fast
  unnecessary in some cases, especially if a) the device's resource
  usage bursts with some duration (e.g., 100ms-long bursts) and
  b) the driver doesn't know when such burst come. MMC/WiFi often had
  such behaviors although there are possibilities that part (b) might
  be addressed with further efforts.

The cases shown above can be tackled with putting QoS requests on the
response time or latency of DVFS mechanism, which is directly related to
its polling interval (if the DVFS mechanism is polling based).

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

--
Changes from RFC(v1)
- Added omitted part (registering new classes)