backports: fix compilation with CONFIG_OF

There are two users of of_find_property_value_of_size() which is
originally static in the kernel, but we need it exposed (but not
exported) so that multiple backport files can use it; do that.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: add crypto/ccm backport

This seems to commonly be missing in the random kernels
people use, so just provide a backport.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: ifdef some pci functions

struct msix_entry entry is defined only when CONFIG_PCI
is defined, resulting in warnings like:

backport-include/linux/pci.h:256:16: warning: 'struct msix_entry' declared inside parameter list [enabled by default]
backport-include/linux/pci.h:256:16: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]

wrap (also the mock function) with appropriate ifdef CONFIG_PCI.

Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: backport MPLS support

This simply the files that define the structures and
defines used to decode MPLS on the skb. For an example
usage see 960d97f95. The headers were added first via
f3baa393ff.

commit f3baa393ffc9a7aefc0bf767729382085e81f606
Author: Simon Wunderlich <sw@simonwunderlich.de>
Date:   Mon Mar 3 17:23:11 2014 +0100

    UAPI: add MPLS label stack definition

    Labels for the Multiprotocol Label Switching are defined in RFC 3032
    which was superseded by RFC 5462. Add the definition to UAPI and a stub
    header for include/linux.

    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 960d97f9518ef6fb8ff87450d6b0c88ce5df9532
Author: Simon Wunderlich <sw@simonwunderlich.de>
Date:   Mon Mar 3 17:23:12 2014 +0100

    cfg80211: add MPLS and 802.21 classification

    MPLS labels may contain traffic control information, which should be
    evaluated and used by the wireless subsystem if present.

    Also check for IEEE 802.21 which is always network control traffic.

    Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
    Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
    Acked-by: Johannes Berg <johannes@sipsolutions.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: make WL1251_SPI depend on >= 3.5

The WL1251_SPI driver now depends on EPROBE_DEFER and others which
we canot backports that pushes it to require 3.4 but since it also
relies on devm_gpio_request_one() we bump it to 3.5. The gpio layer
has received quite a bit of updates and it doesn't make sense to
backport them separately.

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: bump kernel reqs for WL1251_SDIO and WLCORE_SDIO

There has been quite a bit of updates to the gpio driver library,
and while we can backport some of this it doesn't make much sense
as folks using this driver are expected to be carrying over the
required architecture changes. In particular the GPIO_DEVRES has
been tucked under GPIO_LIB and later removed from depending on it
(see b69ac5244 and 6a89a314a)

mcgrof@ergon ~/linux-next (git::master)$ git describe --contains 6a89a314a
v3.9-rc1~76^2~12^2~13

mcgrof@ergon ~/linux-next (git::master)$ git describe --contains b69ac5244
v3.13-rc1~120^2~7

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: bump drivers dependency that require I2C bus classes

Drivers that depend on I2C bus segments behind multiplexers to
have a class require quite a bit of collateral changes that I
don't have time to address. For those interested in trying to backport
this see commit eee543e8. This bumps the drivers that depend on this
that we carry to require at least v3.7 when this collateral evolution
was introduced. One driver is affected, rtl2832 -- defined under
CONFIG_DVB_RTL2832.

mcgrof@ergon ~/linux (git::master)$ git describe --contains eee543e82481
v3.7-rc1~92^2~14

commit eee543e8248150e8fb833943c71f40c7b1724600
Author: Jean Delvare <khali@linux-fr.org>
Date:   Fri Oct 5 22:23:51 2012 +0200

    i2c-mux: Add support for device auto-detection

    Let I2C bus segments behind multiplexers have a class. This allows for
    device auto-detection on these segments. As long as parent segments
    don't share the same class, it should be fine.

    I implemented support in drivers i2c-mux-gpio and i2c-mux-pca954x. I
    left i2c-mux-pca9541 and i2c-mux-pinctrl alone for the moment as I
    don't know if this feature makes sense for the use cases of these
    drivers.

    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Cc: Peter Korsgaard <peter.korsgaard@barco.com>
    Cc: David Daney <david.daney@cavium.com>
    Cc: Michael Lawnick <ml.lawnick@gmx.de>
    Cc: Rodolfo Giometti <giometti@linux.it>

Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: define ETH_P_80221

This is used by the bluetooth and ieee802154 subsystems later
and added via commit b62faf3c available on next-20140311.

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: backport definition of struct frag_queue

Commit b836c99f by Amerigo which got added on v3.7 generalized
the conntrack struct frag_queue while unifying the conntrack
reassembly expire code with a standard one. Although we won't
use the expiry code, another subsystem which we backport, the
ieee802154 6lowpan subsystem, makes use of this structure for
its own reassembly code. This makes that structure available
for older kernels.

mcgrof@ergon ~/linux-next (git::master)$ git describe --contains b836c99f
v3.7-rc1~145^2~136

Cc: Amerigo Wang <amwang@redhat.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: backport skb_unclone()

Pravin added this via commit 14bbd6a565 through v3.9. This is
a straight forward backport using the LINUX_BACKPORT() namespace.

mcgrof@ergon ~/linux-next (git::master)$ git describe --contains 14bbd6a565
v3.9-rc1~139^2~56

commit 14bbd6a565e1bcdc240d44687edb93f721cfdf99
Author: Pravin B Shelar <pshelar@nicira.com>
Date:   Thu Feb 14 09:44:49 2013 +0000

    net: Add skb_unclone() helper function.

    This function will be used in next GRE_GSO patch. This patch does
    not change any functionality.

    Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
    Acked-by: Eric Dumazet <edumazet@google.com>

Cc: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: backport frag helper functions for mem limit tracking

Jesper added frag helper functions through commit d433673e5f
added on. This is a straight forward backport using the LINUX_BACKPORT()
namespace.

mcgrof@ergon ~/linux-next (git::master)$ git describe --contains d433673e5f
v3.9-rc1~139^2~232^2~2

commit d433673e5f9180e05a770c4b2ab18c08ad51cc21
Author: Jesper Dangaard Brouer <brouer@redhat.com>
Date:   Mon Jan 28 23:45:12 2013 +0000

    net: frag helper functions for mem limit tracking

    This change is primarily a preparation to ease the extension of memory
    limit tracking.

    The change does reduce the number atomic operation, during freeing of
    a frag queue.  This does introduce a some performance improvement, as
    these atomic operations are at the core of the performance problems
    seen on NUMA systems.

    Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: backport inet_frag_maybe_warn_overflow()

This is used by the ieee802154 reassembly code. This is
a straight forward backport.

mcgrof@ergon ~/linux-next (git::master)$ git describe --contains 5a3da1fe95
v3.9-rc4~27^2

commit 5a3da1fe9561828d0ca7eca664b16ec2b9bf0055
Author: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date:   Fri Mar 15 11:32:30 2013 +0000

    inet: limit length of fragment queue hash table bucket lists

    This patch introduces a constant limit of the fragment queue hash
    table bucket list lengths. Currently the limit 128 is choosen somewhat
    arbitrary and just ensures that we can fill up the fragment cache with
    empty packets up to the default ip_frag_high_thresh limits. It should
    just protect from list iteration eating considerable amounts of cpu.

    If we reach the maximum length in one hash bucket a warning is printed.
    This is implemented on the caller side of inet_frag_find to distinguish
    between the different users of inet_fragment.c.

    I dropped the out of memory warning in the ipv4 fragment lookup path,
    because we already get a warning by the slab allocator.

    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Cc: Jesper Dangaard Brouer <jbrouer@redhat.com>
    Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: add threaded Coccinelle spatch support

Turns out Coccinelle has threaded support, it lets you
break down the target code you need to parse for a spatch
file into separate buckets, each bucket handling a subset of
the target files needed to be evaluated. This adds support
for that and shaves down the amount of time it gets to
generate target code by 97.19%.

Using:

mcgrof@drvbp1 ~/backports (git::master)$ time \
	./gentree.py	--verbose \
			--clean \
			--refresh \
			/home/mcgrof/linux-next/ \
			/home/mcgrof/build/next-20140311

Before this patch:

real    19m34.867s
user    18m43.492s
sys     0m21.244s

After this patch by using num_cpus threads:

real    2m42.012s
user    21m53.616s
sys     0m22.748s

After this patch by using 3 * num_cpus threads:

real    1m33.316s
user    24m6.080s
sys     0m28.264s

Using num_cpus threads alone was giving 2m42.012s, its why I
experimented in increasing this. I also experimented with
6 * num_cpus threads as well but the amount of time spent
running didn't reduce, lets keep this at 3 * num_cpus for now
and we can experiment and empirically find the best setting for
any system or just make this configurable.

We had SmPL patch integration first committed via
86d99c9d4 back then we were able to scale to a reasonable
similar time:

mcgrof@drvbp1 ~/backports (git::cocci-added)$ time \
	./gentree.py --verbsose \
		     --clean \
		     --refresh \
		     /home/mcgrof/linux-next
		     /home/mcgrof/build/next-20131113
real    1m1.967s
user    0m49.304s
sys     0m11.880s

For history's purpose here's our run time without Coccinelle on
commit 338c4388cc:

mcgrof@drvbp1 ~/backports (git::before-smpl)$ time \
        ./gentree.py --verbose \
                     --clean \
                     --refresh \
                     /home/mcgrof/linux-next/ \
                     /home/mcgrof/build/next-20131029
real    0m29.639s
user    0m17.508s
sys     0m11.568s

This new changes sets us back on track with the timing for when we first
introduced Coccinelle support we just have a lot 5 Coccinelle patches
now. I hope this shows we should be able to scale with Coccinelle much more
efficiently for collateral evolutions that sprinkle through tons of
files.

Screenshots available using htop before [0] and after the patch [1]
while coccinelle is running, this shows how the system is using
resources much more efficiently when doing spatch evaluation for
patch generation on target code.

[0] http://drvbp1.linux-foundation.org/~mcgrof/images/coccinelle-backports/before-threaded-cocci.png
[1] http://drvbp1.linux-foundation.org/~mcgrof/images/coccinelle-backports/after-threaded-cocci.png

Cc: Peter Senna <peter.senna@gmail.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Gilles Muller <Gilles.Muller@lip6.fr>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: use --ignore-removal for git add

As of git 2.0 --ignore-removal is no longer default so just
make it default tool, without which git will warn us about
this change.

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: add git diff support to lib/bpgit.py

This will be used later for proving SmPL patches against
legacy patch series.

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: add support for testing only a single Coccinelle SmPL patch

You can just pass now one cocci file with the --test-cocci to test
only that single Coccinelle SmPL patch. If you are not sure what
an SmPL patch produces and you only want to study the results of
applying only a single SmPL patch you can use this flag to trigger
enabling git on the target directory, a commit will be done before
applying the SmPL patch and then another commit will be performed
after the SmPL patch is applied. You can then use git show as you'd
expect to inspect the results.

Note that if you don't use --test-cocci and run gentree.py regularly
you can always still use --git-debug to see atomically what is happening
after each patch, including Coccinelle patches.

This modifies the coccinelle library to use 10 * num_cpus threads
for when in testing Coccinelle mode.

$ time ./gentree.py --clean --verbose --test-cocci 11-dev-pm-ops.cocci \
        /home/mcgrof/linux-next/ \
        /home/mcgrof/build/next-20140311

real    0m28.964s
user    6m57.848s
sys     0m25.124s

Note that you can pass either a full path or the file name alone
of the target Coccinelle SmPL patch you want to test.

Cc: Peter Senna <peter.senna@gmail.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Gilles Muller <Gilles.Muller@lip6.fr>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: add Coccinelle SmPL profiling support to gentree.py

This adds support to let you pass --profile when running Coccinelle.
This will skip all patches, rewriting Makefiles, Kconfigs, etc, and
it will also keep a copy of the original src directory prior to
applying the spatch. You pass the spatch file as an argument when
using this.

Screenshot of relevant output on 11-dev-pm-ops.cocci:

$ time ./gentree.py --clean --verbose --profile-cocci 11-dev-pm-ops.cocci \
        /home/mcgrof/linux-next/ \
        /home/mcgrof/build/backports-20140311

Copy original source files ...
Apply patches ...
Profiling Coccinelle SmPL patch: 11-dev-pm-ops.cocci
Applying SmPL patch collateral-evolutions/network/11-dev-pm-ops.cocci
> init_defs_builtins: /usr/local/share/coccinelle/standard.h
> warning: line 15: should pci be a metavariable?
> (ONCE) Expected tokens pm pci_driver driver pci SIMPLE_DEV_PM_OPS
> MODULE_DEVICE_TABLE
> Skipping:./net/mac802154/ieee802154_dev.c
> Skipping:./net/mac802154/mac_cmd.c
> Skipping:./net/mac802154/mib.c
> Skipping:./net/mac802154/monitor.c
> Skipping:./net/mac802154/rx.c
> Skipping:./net/mac802154/tx.c
> Skipping:./net/mac802154/wpan.c
> starting: Common.group_assoc_bykey_eff
> ending: Common.group_assoc_bykey_eff, 0.000114s
> ---------------------
> profiling result
> ---------------------
> Main total                               :      0.584 sec          1 count
> parse cocci                              :      0.422 sec          1 count
> pre_engine                               :      0.422 sec          1 count
> Main.infiles computation                 :      0.156 sec          1 count
> HACK                                     :      0.069 sec          1 count
> C parsing.tokens                         :      0.043 sec          1 count
> C parsing.fix_define                     :      0.022 sec          1 count
> get_glimpse_constants                    :      0.021 sec          1 count
> C parsing.lex_ident                      :      0.006 sec        673 count
> Common.full_charpos_to_pos_large         :      0.006 sec          1 count
> Main.outfiles computation                :      0.004 sec          1 count
> worth_trying                             :      0.004 sec          7 count
> Common.full_charpos_to_pos               :      0.003 sec          2 count
> Common.=~                                :      0.000 sec          4 count
> check_duplicate                          :      0.000 sec          1 count
> Main.result analysis                     :      0.000 sec          1 count
> Common.group_assoc_bykey_eff             :      0.000 sec          1 count
> asttoctl2                                :      0.000 sec          1 count
> post_engine                              :      0.000 sec          1 count
> show_xxx                                 :      0.000 sec          2 count

This goes on... and a page per thread spawned and the results will be
specific to the files tha the thread worked on. On the above results
we can see Coccinelle spent little to no time working on the above
files as it determined it had nothing to do there.

On big iron backports server:

real    0m31.226s
user    7m25.712s
sys     0m34.492s

Cc: Peter Senna <peter.senna@gmail.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: Gilles Muller <Gilles.Muller@lip6.fr>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: add include/net/6lowpan.h to copy-list

We backport both the bluetooth and ieee802154 subsystems
and commit cefc8c8a7c moved the 6lowpan it out under from
net/ieee802154/6lowpan.h to include/net/6lowpan.h as bluetooth
now uses it. Since we backport both subsystems just copy the
header over.

commit cefc8c8a7c9e4867c45407f7f9a44fe80c5ea58a
Author: Alexander Aring <alex.aring@gmail.com>
Date:   Wed Mar 5 14:29:05 2014 +0100

    6lowpan: move 6lowpan header to include/net

    This header is used by bluetooth and ieee802154 branch. This patch
    move this header to the include/net directory to avoid a use of a
    relative path in include.

    Signed-off-by: Alexander Aring <alex.aring@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Cc: Alexander Aring <alex.aring@gmail.com>
Cc: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: linux-zigbee-devel@lists.sourceforge.net
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: address move of 6lowpan.c to 6lowpan_rtnl.c

Commit 01348b3448 moved 6lowpan.c to 6lowpan_rtnl.c
which means we have to adjust the respective backport
patches.

commit 01348b34485eceace5d9ca9756ba40679cf22ac6
Author: Alexander Aring <alex.aring@gmail.com>
Date:   Fri Feb 28 07:32:47 2014 +0100

    6lowpan: move 6lowpan.c to 6lowpan_rtnl.c

    We have a 6lowpan.c file and 6lowpan.ko file. To avoid confusing we
    should move 6lowpan.c to 6lowpan_rtnl.c. Then we can support multiple
    source files for 6lowpan module.

    Signed-off-by: Alexander Aring <alex.aring@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Cc: Alexander Aring <alex.aring@gmail.com>
Cc: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: linux-zigbee-devel@lists.sourceforge.net
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: address jump label and static key support

The ieee802154 subsystem, which we backport, makes use of
net_get_random_once() through net/ieee802154/reassembly.c
and this in turn makes use of the static keys. Static keys
were split out from the jump label support via commit c5905afb
by Ingo through kernel v3.3 -- note that git describe --contains
will disagree and say its v3.5. Jump label support was added by
Jason via commit bf5438fc through kernel v2.6.37 but later
Jason provided static branch optimizations via commit d430d3d7e
added through v3.0. static_key_initialized and STATIC_KEY_CHECK_USE()
were last added by Hannes through kernel v3.13 throughy c4b2c0c5f.

In order to backport static keys and jump label we need to
provide name mapping for kernels that only had jump label support,
but due to the static branch optimizations and since these are
architecture specific we cannot backport them unless we start carrying
around architecture replacement code -- or do some other trickery.
For kernels that lacked jump label support and that don't have the
static branch optimizations we simply carry in the kernel implmentation
that assumes you have no architecture support for jump label which
treats the labels as simply atomic drivers for branches. For older
kernels then we don't backport usage of static_key_initialized and
usage of STATIC_KEY_CHECK_USE().

This does leave a gap of kernels without static key / jump label
support, I tried backporting it but ran into issues quickly. Those
daring to continue to embark on this journey can pick up where
I left off:

[0] drvbp1.linux-foundation.org/~mcgrof/examples/2014/04/01/backport-static-keys.patch

I will note that properly backporting this can have implications on how
we backport tracing support as that is the main usage for jump labels.
Real enthusiasts can go ahead an extend this with architecture / kernel
revision specific changes -- but be warned -- we will have hard litmus
test for compilation on backports using ckmake --allyesconfig on all
supported kernels we carry.

This is a long way of saying -- we require at least 3.5 for static
key support, we also support kernels older than 2.6.37 but this goes
untested.

mcgrof@ergon ~/linux (git::master)$ git describe --contains bf5438fc
v2.6.37-rc1~214^2~33^2~8

mcgrof@ergon ~/linux (git::master)$ git describe --contains d430d3d7e
v3.0-rc1~404^2~18^2~2

mcgrof@ergon ~/linux (git::master)$ git describe --contains c5905afb
v3.5-rc1~120^3~76^2 -- wrong! Its actually v3.3 try:
  git checkout -b static-changes c5905afb; git describe

mcgrof@ergon ~/linux (git::master)$ git describe --contains c4b2c0c5f
v3.13-rc1~105^2~157^2~6

Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jason Baron <jbaron@redhat.com>
CC: Jason Baron <jbaron@redhat.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: linux-zigbee-devel@lists.sourceforge.net
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>