gentree: refuse patches creating files

This doesn't make sense since we'd have no way of knowing
when such a patch should be applied. Right now the patch
would be ignored, but make it extra obvious and error out
on such patches.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: fix rfkill sparse warning

The new backport rfkill approach caused a sparse warning:
linux/rfkill.h:70:43: warning: mixing different enum types
linux/rfkill.h:70:43:     int enum rfkill_type  versus
linux/rfkill.h:70:43:     int enum old_rfkill_type

Fix it by adding a cast.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: refresh patches for next-20130426

== ckmake-report.log ==

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.76              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.44              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.43              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.10              [  OK  ]
25  3.8.11              [  OK  ]
26  3.9.0               [  OK  ]

real    30m52.106s
user    816m17.749s
sys     127m27.702s

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

backports: refresh patches for next-20130424

== ckmake-report.log ==

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.76              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.44              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.43              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.10              [  OK  ]
25  3.8.11              [  OK  ]
26  3.9.0               [  OK  ]

real    30m48.012s
user    814m18.301s
sys     127m38.575s

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

backports: add support for regulator_map_voltage_ascend()

This is required by some drivers as of next-20130424.

commit fcf371ee5624cc87abac205cd0dad2432d7f0346
Author: Axel Lin <axel.lin@ingics.com>
Date:   Thu Apr 18 10:34:49 2013 +0800

    regulator: core: Add regulator_map_voltage_ascend() API

    A lot of regulator hardware has ascendant voltage list.
    This patch adds regulator_map_voltage_ascend() and export it.

    Drivers that have ascendant voltage list can use this as their map_voltage()
    operation, this is more efficient than default regulator_map_voltage_iterate()
    function.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: refresh patches for next-20130423

== ckmake-report.log ==

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.76              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.44              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.43              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.10              [  OK  ]
25  3.8.11              [  OK  ]
26  3.9.0               [  OK  ]

real    30m53.044s
user    815m38.362s
sys     127m50.187s

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

backports: address vlan ethernet driver changes

This addresses the last remaining components to
backport the ethernet vlan changes introduced by
9356b8fc d314774c and f646968f8f on next-20130423.

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

backports: backport vlan ethernet changes

This backports 9356b8fc d314774c and f646968f8f
all added in next-20130423. Soome driver changes are
still required and will be addressed separately.

commit 9356b8fc07dc126cd91d2b12f314d760ab48996e
Author: Eric Dumazet <dada1@cosmosbay.com>
Date:   Tue Sep 27 15:23:16 2005 -0700

    [NET]: Reorder some hot fields of struct net_device

    Place them on separate cache lines in SMP to lower memory bouncing
    between multiple CPU accessing the device.

         - One part is mostly used on receive path (including
           eth_type_trans()) (poll_list, poll, quota, weight, last_rx,
           dev_addr, broadcast)

         - One part is mostly used on queue transmit path (qdisc)
          (queue_lock, qdisc, qdisc_sleeping, qdisc_list, tx_queue_len)

         - One part is mostly used on xmit path (device)
          (xmit_lock, xmit_lock_owner, priv, hard_start_xmit, trans_start)

    'features' is placed outside of these hot points, in a location that
    may be shared by all cpus (because mostly read)

    name_hlist is moved close to name[IFNAMSIZ] to speedup __dev_get_by_name()

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit d314774cf2cd5dfeb39a00d37deee65d4c627927
Author: Stephen Hemminger <shemminger@vyatta.com>
Date:   Wed Nov 19 21:32:24 2008 -0800

    netdev: network device operations infrastructure

    This patch changes the network device internal API to move adminstrative
    operations out of the network device structure and into a separate structure.

    This patch involves some hackery to maintain compatablity between the
    new and old model, so all 300+ drivers don't have to be changed at once.
    For drivers that aren't converted yet, the netdevice_ops virt function list
    still resides in the net_device structure. For old protocols, the new
    net_device_ops are copied out to the old net_device pointers.

    After the transistion is completed the nag message can be changed to
    an WARN_ON, and the compatiablity code can be made configurable.

    Some function pointers aren't moved:
    * destructor can't be in net_device_ops because
      it may need to be referenced after the module is unloaded.
    * neighbor setup is manipulated in a couple of places that need special
      consideration
    * hard_start_xmit is in the fast path for transmit.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit f646968f8f7c624587de729115d802372b9063dd
Author: Patrick McHardy <kaber@trash.net>
Date:   Fri Apr 19 02:04:27 2013 +0000

    net: vlan: rename NETIF_F_HW_VLAN_* feature flags to NETIF_F_HW_VLAN_CTAG_*

    Rename the hardware VLAN acceleration features to include "CTAG" to indicate
    that they only support CTAGs. Follow up patches will introduce 802.1ad
    server provider tagging (STAGs) and require the distinction for hardware not
    supporting acclerating both.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: adjust snd_portid patch for nl80211 update

The new code for the "critical protocol indication" uses
snd_portid and must be adjusted in the backport patches.
This is required as of next-20130423.

commit 5de17984898c5758fc6ebe08eccea9f4b6548914
Author: Arend van Spriel <arend@broadcom.com>
Date:   Thu Apr 18 15:49:00 2013 +0200

    cfg80211: introduce critical protocol indication from user-space

    Some protocols need a more reliable connection to complete
    successful in reasonable time. This patch adds a user-space
    API to indicate the wireless driver that a critical protocol
    is about to commence and when it is done, using nl80211 primitives
    NL80211_CMD_CRIT_PROTOCOL_START and NL80211_CRIT_PROTOCOL_STOP.

    There can be only on critical protocol session started per
    registered cfg80211 device.

    The driver can support this by implementing the cfg80211 callbacks
    .crit_proto_start() and .crit_proto_stop(). Examples of protocols
    that can benefit from this are DHCP, EAPOL, APIPA. Exactly how the
    link can/should be made more reliable is up to the driver. Things
    to consider are avoid scanning, no multi-channel operations, and
    alter coexistence schemes.

Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
[mcgrof@do-not-panic.com]: Required as of next-20130423
 and provided commit log message that introduced this
 change.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: move vb2_mmap_pfn_range into patch

There's only a single user of vb2_mmap_pfn_range() and
at least on 3.2 having the function in compat-3.9.c is
problematic if CPTCFG_BACKPORT_BUILD_DMA_SHARED_BUFFER
isn't set, because on that kernel there's no dma-buf.h
and then compilation can fail.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: don't backport rfkill, only API

There's not much point in backporting rfkill, if the base kernel
doesn't have it then providing the it as /dev/rfkill_backport
won't be picked up by any apps, and if the base kernel has it
then it would cause odd behaviour as the base kernel's platform
drivers using the rfkill API would not talk to the backported
modules rfkill.

An unusable backported rfkill isn't much better than not having
it at all, so change the way we backport rfkill and don't carry
the code but simply provide the API as wrappers.

If the base kernel is 3.10 or higher (the current version) then
don't change anything at all.

If the base kernel is 2.6.33 or higher (with the new rfkill API)
then just wrap the API and disable rfkill registrations for any
types that the base kernel doesn't know about.

For all other kernels, provide only static inlines that behave
like the rfkill API when rfkill isn't compiled in.

The downside is that we need to copy the rfkill API. This is,
however, very very stable (it essentially hasn't changed since
2.6.33), so that's not a problem.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: provide modules_install target

Just as an alias for 'install'.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: make compat module use subsys_initcall()

This is a no-op for the modular use case of the
backports project but by enabling this it allows
for developers a way to embed the backports releases
onto a target source Linux directory, with obvious
pending modifications, by adding our backport_init()
onto the target kernel's init/main.c start_kernel().

Enable this theoretical use case. Hackers welcome to
go play on this theoretical integration strategy now.

Cc: pstew@chromium.org
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: refresh patches for next-20130419

== ckmake-report.log ==

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.76              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.44              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.43              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.10              [  OK  ]
25  3.8.11              [  OK  ]
26  3.9.0               [  OK  ]

real    30m44.234s
user    813m54.992s
sys     126m44.115s

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

backports: backport new bluetooth hidp session-management

Commit b4f34d8d9 on next-20130419 added new bluetooth hidp
session-management helper, then commit 520518 also on
next-20130419 replaced the old management code with
the new one. Thanks to David Herrmann for his review and
his changes for this backport.

commit b4f34d8d9d26b2428fa7cf7c8f97690a297978e6
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Sat Apr 6 20:28:46 2013 +0200

    Bluetooth: hidp: add new session-management helpers

    This is a rewrite of the HIDP session management. It implements HIDP as an
    l2cap_user sub-module so we get proper notification when the underlying
    connection goes away.

    The helpers are not yet used but only added in this commit. The old
    session management is still used and will be removed in a following patch.

    The old session-management was flawed. Hotplugging is horribly broken and
    we have no way of getting notified when the underlying connection goes
    down. The whole idea of removing the HID/input sub-devices from within the
    session itself is broken and suffers from major dead-locks. We never can
    guarantee that the session can unregister itself as long as we use
    synchronous shutdowns. This can only work with asynchronous shutdowns.
    However, in this case we _must_ be able to unregister the session from the
    outside as otherwise the l2cap_conn object might be unlinked before we
    are.

    The new session-management is based on l2cap_user. There is only one
    way how to add a session and how to delete a session: "probe" and "remove"
    callbacks from l2cap_user.
    This guarantees that the session can be registered and unregistered at
    _any_ time without any synchronous shutdown.
    On the other hand, much work has been put into proper session-refcounting.
    We can unregister/unlink the session only if we can guarantee that it will
    stay alive. But for asynchronous shutdowns we never know when the last
    user goes away so we must use proper ref-counting.

    The old ->conn field has been renamed to ->hconn so we can reuse ->conn in
    the new session management. No other existing HIDP code is modified.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
commit 5205185d461d5902325e457ca80bd421127b7308
Author: David Herrmann <dh.herrmann@gmail.com>
Date:   Sat Apr 6 20:28:47 2013 +0200

    Bluetooth: hidp: remove old session-management

    We have the full new session-management now available so lets switch over
    and remove all the old code. Few semantics changed, so we need to adjust
    the sock.c callers a bit. But this mostly simplifies the logic.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: fix atl1.c dev-pm-ops patch

As of next-20130419 the atl1.c driver uses
atl1_pm_ops directly instead of the ATL1_PM_OPS
macro. This fixes that hunk.

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

backports: refresh patches for next-20130415

== ckmake-report.log ==

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.76              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.44              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.43              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.10              [  OK  ]
25  3.8.11              [  OK  ]
26  3.9.0               [  OK  ]

real    30m38.595s
user    808m49.549s
sys     127m31.602s

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

backports: enable REGULATOR_WM8994 only on >= 3.8

Compilation is failing and we need to move forward,
I can't look at this right now.

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

backports: enable the CONFIG_DRM_QXL driver on >= v3.3

This provides a requirement of the new qxl DRM driver to
be available only on kernels >= 3.3. The requirement
comes from the usage of radix_tree_for_each_slot() that
this uses the new radix bit-optimized iterator added
via 78c1d7848 on 3.4. We backport this via the compat
module but only for v3.3 given that addressing this
backport for v3.2 requires addressing e2bdb933 which
changes the radix_tree_node.

qxl was added on next-20130415.

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 78c1d7848
v3.4-rc2~15^2~26

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains e2bdb933
v3.3-rc1~81^2~8

Someone wishing to #ifdef this to enable qxl support on
v3.2 by using the old radix_tree_gang_lookup_slot()
can look at 0fc9d1040313047edf6a39fd4d7c7defdca97c62
as an example collateral evolution change.

commit f64122c1f6ade301585569863b4b3b18f6e4e332
Author: Dave Airlie <airlied@gmail.com>
Date:   Mon Feb 25 14:47:55 2013 +1000

    drm: add new QXL driver. (v1.4)

    QXL is a paravirtual graphics device used by the Spice virtual desktop
    interface.

    The drivers uses GEM and TTM to manage memory, the qxl hw fencing however
    is quite different than normal TTM expects, we have to keep track of a number
    of non-linear fence ids per bo that we need to have released by the hardware.

    The releases are freed from a workqueue that wakes up and processes the
    release ring.

    releases are suballocated from a BO, there are 3 release categories, drawables,
    surfaces and cursor cmds. The hw also has 3 rings for commands, cursor and release handling.

    The hardware also have a surface id tracking mechnaism and the driver
    encapsulates it completely inside the kernel, userspace never sees the actual hw sur
    ids.

    This requires a newer version of the QXL userspace driver, so shouldn't be
    enabled until that has been placed into your distro of choice.

    Authors: Dave Airlie, Alon Levy

    v1.1: fixup some issues in the ioctl interface with padding
    v1.2: add module device table
    v1.3: fix nomodeset, fbcon leak, dumb bo create, release ring irq,
          don't try flush release ring (broken hw), fix -modesetting.
    v1.4: fbcon cpu usage reduction + suitable accel flags.

Signed-off-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: remove ath5k trace fix patch

This is no longer required thanks to commit cc5569f6
present on next-20130415.

commit cc5569f63ecb82965f3fe2fde5e60bf1689d107a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Apr 11 16:22:08 2013 +0200

    ath5k: use more idiomatic tracing include style

    Pretty much everywhere that uses a trace definition
    header that's not in include/trace/events/ uses the
    make system for the include path rather than putting
    it into the sources, so do that in ath5k as well.

    This came up during backporting work (where this is
    required), but since all other drivers do it this
    way upstream it seemed applicable.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: remove brcmsmac / brcmutil Makefile patches

These are now upstream thanks to commit 8e8d4ff0 on
next-20130415.

commit 8e8d4ff051672d4a2939e7d6925c4acd234b0220
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Apr 11 16:15:28 2013 +0200

    brcm80211: simplify makefiles

    This came up during my backporting work but it seems
    perfectly appropriate for the kernel as well.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: copy brcmfmac-sdio.h

On next-20130415 commit 668761ac0 added platform
specific data for brcmfmac for SDIO. Copy that
over. This is the first in a series of changes
required for next-20130415.

commit 668761ac01d6f5a36b8e5a24d4e154550e2c4c3b
Author: Hante Meuleman <meuleman@broadcom.com>
Date:   Fri Apr 12 10:55:55 2013 +0200

    brcmfmac: define and use platform specific data for SDIO.

    This patch adds support for platform specific data for SDIO
    fullmac devices. Currently OOB interrupts are configured by Kconfig
    BRCMFMAC_SDIO_OOB but that is now determined dynamically by checking
    availibility of platform data.

Cc: Hauke Mehrtens <hauke@hauke-m.de>
Reviewed-by: Arend Van Spriel <arend@broadcom.com>
Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Piotr Haber <phaber@broadcom.com>
Signed-off-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

compat: backport radix-tree bit optimized iterator

This backport's Konstantin's radix-tree bit optimized
iterator, 78c1d7848, added on v3.4. This is used by a new
drivers in the future. The new bit optimized iterator relies
on the stack optimization introduced via e2bdb933 added as of
v3.3. Backporting the bit optimized iterator requires
adjusting it to the old v3.2 radix_tree_node which is not
implemented here. For kernels v3.3 - v3.3 we can backport
the bit optimized iterator given that the radix_tree_node
did not changed between v3.3 - v3.4, in fact it hasn't
changed even up to v3.10. The backport relies on the same
helpers and inlines present on v3.3-v3.10 to implement
radix_tree_next_chunk().

This was tested as of next-20130410.

Throw the helper into compat config build option
CPTCFG_BACKPORT_BUILD_RADIX_HELPERS only to be built
on v3.3 right now unless someone really wants to
backport 78c1d7848 support onto v3.2.

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 78c1d7848
v3.4-rc2~15^2~26

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains e2bdb933
v3.3-rc1~81^2~8

ckmake below, and then the commit log references above.

== ckmake-report.log ==

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.76              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.44              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.43              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.10              [  OK  ]
25  3.8.11              [  OK  ]
26  3.9.0               [  OK  ]

real    30m37.773s
user    809m37.644s
sys     126m30.806s

commit 78c1d78488a3c45685d993130c9f17102dc79a54
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date:   Wed Mar 28 14:42:53 2012 -0700

    radix-tree: introduce bit-optimized iterator

    A series of radix tree cleanups, and usage of them in the core pagecache
    code.

    Micro-benchmark:

    lookup 14 slots (typical page-vector size)
    in radix-tree there earch <step> slot filled and tagged
    before/after - nsec per full scan through tree

    * Intel Sandy Bridge i7-2620M 4Mb L3
    New code always faster

    * AMD Athlon 6000+ 2x1Mb L2, without L3
    New code generally faster,
    Minor degradation (marked with "*") for huge sparse trees

    * i386 on Sandy Bridge
    New code faster for common cases: tagged and dense trees.
    Some degradations for non-tagged lookup on sparse trees.

    Ideally, there might help __ffs() analog for searching first non-zero
    long element in array, gcc sometimes cannot optimize this loop corretly.

    Numbers:

    CPU: Intel Sandy Bridge i7-2620M 4Mb L3

    radix-tree with 1024 slots:

    tagged lookup

    step  1      before  7156        after  3613
    step  2      before  5399        after  2696
    step  3      before  4779        after  1928
    step  4      before  4456        after  1429
    step  5      before  4292        after  1213
    step  6      before  4183        after  1052
    step  7      before  4157        after  951
    step  8      before  4016        after  812
    step  9      before  3952        after  851
    step  10     before  3937        after  732
    step  11     before  4023        after  709
    step  12     before  3872        after  657
    step  13     before  3892        after  633
    step  14     before  3720        after  591
    step  15     before  3879        after  578
    step  16     before  3561        after  513

    normal lookup

    step  1      before  4266       after  3301
    step  2      before  2695       after  2129
    step  3      before  2083       after  1712
    step  4      before  1801       after  1534
    step  5      before  1628       after  1313
    step  6      before  1551       after  1263
    step  7      before  1475       after  1185
    step  8      before  1432       after  1167
    step  9      before  1373       after  1092
    step  10     before  1339       after  1134
    step  11     before  1292       after  1056
    step  12     before  1319       after  1030
    step  13     before  1276       after  1004
    step  14     before  1256       after  987
    step  15     before  1228       after  992
    step  16     before  1247       after  999

    radix-tree with 1024*1024*128 slots:

    tagged lookup

commit e2bdb933ab8b7db71c318a4ddcf78a9fffd61ecb
Author: Hugh Dickins <hughd@google.com>
Date:   Thu Jan 12 17:20:41 2012 -0800

    radix_tree: take radix_tree_path off stack

    Down, down in the deepest depths of GFP_NOIO page reclaim, we have
    shrink_page_list() calling __remove_mapping() calling __delete_from_
    swap_cache() or __delete_from_page_cache().

    You would not expect those to need much stack, but in fact they call
    radix_tree_delete(): which declares a 192-byte radix_tree_path array on
    its stack (to record the node,offsets it visits when descending, in case
    it needs to ascend to update them).  And if any tag is still set [1],
    that calls radix_tree_tag_clear(), which declares a further such
    192-byte radix_tree_path array on the stack.  (At least we have
    interrupts disabled here, so won't then be pushing registers too.)

    That was probably a good choice when most users were 32-bit (array of
    half the size), and adding fields to radix_tree_node would have bloated
    it unnecessarily.  But nowadays many are 64-bit, and each
    radix_tree_node contains a struct rcu_head, which is only used when
    freeing; whereas the radix_tree_path info is only used for updating the
    tree (deleting, clearing tags or setting tags if tagged) when a lock
    must be held, of no interest when accessing the tree locklessly.

    So add a parent pointer to the radix_tree_node, in union with the
    rcu_head, and remove all uses of the radix_tree_path.  There would be
    space in that union to save the offset when descending as before (we can
    argue that a lock must already be held to exclude other users), but
    recalculating it when ascending is both easy (a constant shift and a
    constant mask) and uncommon, so it seems better just to do that.

    Two little optimizations: no need to decrement height when descending,
    adjusting shift is enough; and once radix_tree_tag_if_tagged() has set
    tag on a node and its ancestors, it need not ascend from that node
    again.

    perf on the radix tree test harness reports radix_tree_insert() as 2%
    slower (now having to set parent), but radix_tree_delete() 24% faster.
    Surely that's an exaggeration from rtth's artificially low map shift 3,
    but forcing it back to 6 still rates radix_tree_delete() 8% faster.

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

backports: backport dma-buf debugfs support

Commit 5a753a4 on next-20130410 extended the
dma-buf implementation to add debugfs support.
We backport support for this by adding its own
subsys_init() call as a helper to the backport
module (still called compat) respective subsys_init()
call, backport_init(). For kernels where this is
already supported this is a no-op.

This didn't make it to v3.9 but I see Linus has
already merged this as part of the merge window
what will be v3.10.

This also refreshes patches for next-20130410 and
I supply the refresh as part of this same patch
given that the only patch refreshed was the one
modifyin the drivers/base/dma-buf.c.

commit 5a753a49fb7e17fa83ea9cf39c7b1a902363d828
Author: Sumit Semwal <sumit.semwal@linaro.org>
Date:   Thu Apr 4 11:44:37 2013 +0530

    dma-buf: Add debugfs support

    Add debugfs support to make it easier to print debug information
    about the dma-buf buffers.

Cc: Dave Airlie <airlied@redhat.com>
     [minor fixes on init and warning fix]
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
$ ckmake --allyesconfig

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.76              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.44              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.43              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.10              [  OK  ]
25  3.8.11              [  OK  ]
26  3.9.0               [  OK  ]

real    30m10.328s
user    797m1.841s
sys     125m15.978s

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

gentree.py: keep patch headers for patch refresh

Without this change we were removing patch headers
when refreshing patches.

Cc: techtonik@gmail.com
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

lib/patch.py: add top header parsing support

Add a top_header for cases where a patchset might have a
full header that we may want users to keep around.

Cc: techtonik@gmail.com
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: update patch Python library

This updates the backports project up to synch with the
latest patch.py from svn trunk.

Cc: techtonik@gmail.com
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
[remove HG/GIT patch path detection as we used to]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

gentree: use git library to speed up --git-revision

If the git library is available (on many distros, just
install python-git or similar) then use it to read the
git blobs from disk if --git-revision is used.

On my system (with an SSD) this speeds up the entire
backport generation process significantly (when using
--git-revision):

before:
real 0m39.280s
user 0m13.464s
sys 0m16.644s

after:
real 0m22.554s
user 0m16.404s
sys 0m5.724s

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

python support: rename git library to bpgit

There's a python git library, and our name conflicts
with it since it's also just called "git". I want to
use the python library (optionally) to speed up the
git accesses so this is now relevant.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: refresh patches for next-20130409

== ckmake-report.log ==

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.76              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.44              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.43              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.10              [  OK  ]
25  3.8.11              [  OK  ]
26  3.9.0               [  OK  ]

real    30m38.751s
user    810m14.462s
sys     126m48.932s

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

backports: refresh patches for next-20130408

== ckmake-report.log ==

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.76              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.44              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.43              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.10              [  OK  ]
25  3.8.11              [  OK  ]
26  3.9.0               [  OK  ]

real    30m33.717s
user    809m9.794s
sys     125m18.510s

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

backports: refresh patches for next-20130405

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

backports: add pm patch for rtl8188ee

Some day we will use SmPL for this...

== ckmake-report.log ==

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  FAIL  ]
16  2.6.39              [  OK  ]
17  3.0.76              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.44              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.43              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.10              [  OK  ]
25  3.8.11              [  OK  ]
26  3.9.0               [  OK  ]

real    30m33.959s
user    809m11.262s
sys     126m15.477s

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
[Luis says the "FAIL" was due to a test setup issue only]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

get-compat-kernels: update all kernels

Update to the latest available set. You'll need 3.9 updated
if you want to test against next-20130403 due to fffe01f7.

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

ckmake: add support for kernel ranges

At times you may only want to test with ckmake a specific
kernel range or target kernels. You can do that now. ckmake
will use this list against what it finds on your system.

Examples:

  * ckmake --revs 3.3..3.4
  * ckmake --revs 2.6.24,2.6.30,2.6.32..3.2,3.4

The base kernels revisions is what is expected. The base kernel
revision of say 3.4.5 is 3.4, the base revision of say 2.6.24.2
is 2.6.24.

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

ckmake: rename get_rel_spec() to get_rel_spec_ubuntu()

Vanilla Linux kernels are being used but the directory
file naming for for the kernels are Ubuntu specific,
clarify that.

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

ckmake: make --check-exports default

Remove --check-exports as an option and now just enable it by default.

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
[fix typo]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: disable some regulator drivers on 3.4 and 3.5

We enabled regulator subsystem support as of 3.4 but given that
the regulator subsystem has advanced quite a bit on 3.5 and 3.6
and that we cannot backport the regulator as its part of the
core kernel we have no option but to only enable drivers on their
kernels if they don't depend on the new regulator features.

$ time ckmake --check-exports --allyesconfig

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.65              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.38              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.32              [  OK  ]
22  3.5.7               [  OK  ]
23  3.6.11              [  OK  ]
24  3.7.9               [  OK  ]
25  3.8.0               [  OK  ]
26  3.9-rc1             [  OK  ]

real    30m12.875s
user    797m38.663s
sys     126m56.572s

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

compat: backport soc_camera_power_[on|off] for 3.3

We are only backporting CONFIG_SOC_CAMERA for kernels >= 3.4
but there is an exported symbol from there that some media
drivers that we do support on 3.3 need. Handle this special
case.

SOC_CAMERA is only enabled on 3.4 as it depends on some
newer regulator functionality, however there are some SOC
cameras that can rely on the 3.3 regulatory built-in core
and the 3.3 SOC_CAMERA module however two routines are
not exported in that version of SOC_CAMERA that newer
SOC cameras do require. Backport that functionality.

Technically this should go into <media/soc_camera.h>
given that is where its where its exported on linux-next
but in practice only placing it on <linux/v4l2-mediabus.h>
actually fixes linking errors for 3.3 for all SOC camera
drivers we make available for 3.3:

  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/imx074.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/mt9m001.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/mt9m111.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/mt9t031.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/mt9t112.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/mt9v022.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/ov2640.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/ov5642.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/ov6650.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/ov772x.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/ov9640.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/ov9740.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/rj54n1cb0c.ko
  LD [M]  /home/mcgrof/build/drivers/media/i2c/soc_camera/tw9910.ko

This fixes all pending linking errors on 3.3.

$ time ckmake --check-exports --allyesconfig

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.65              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.38              [  OK  ]
20  3.3.8               [  OK  ]
21  3.4.32              [  LINK  ]
22  3.5.7               [  LINK  ]
23  3.6.11              [  OK  ]
24  3.7.9               [  OK  ]
25  3.8.0               [  OK  ]
26  3.9-rc1             [  OK  ]

real    30m14.581s
user    796m34.495s
sys     126m46.807s

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

compat: fix dma_common_get_sgtable() backport placements

We added dma_common_get_sgtable() assuming it should only
be available to older kernels as of 3.6 but it was only
up to 3.8 where it was detangled from depending on
CONFIG_HAVE_GENERIC_DMA_COHERENT. Its a mess to express
this on compat files so just word it via kconfig and throw this
onto its own files given that there may be other helpers
we may need to backport later with the same circumstances.

One last hack was required for 3.3-3.6 and that is due
to header changes between kernels.

$ time ckmake --check-exports --allyesconfig

1   2.6.24              [  OK  ]
2   2.6.25              [  OK  ]
3   2.6.26              [  OK  ]
4   2.6.27              [  OK  ]
5   2.6.28              [  OK  ]
6   2.6.29              [  OK  ]
7   2.6.30              [  OK  ]
8   2.6.31              [  OK  ]
9   2.6.32              [  OK  ]
10  2.6.33              [  OK  ]
11  2.6.34              [  OK  ]
12  2.6.35              [  OK  ]
13  2.6.36              [  OK  ]
14  2.6.37              [  OK  ]
15  2.6.38              [  OK  ]
16  2.6.39              [  OK  ]
17  3.0.65              [  OK  ]
18  3.1.10              [  OK  ]
19  3.2.38              [  OK  ]
20  3.3.8               [  LINK  ]
21  3.4.32              [  LINK  ]
22  3.5.7               [  LINK  ]
23  3.6.11              [  OK  ]
24  3.7.9               [  OK  ]
25  3.8.0               [  OK  ]
26  3.9-rc1             [  OK  ]

real    30m3.120s
user    795m40.684s
sys     123m29.995s

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

backports: kref_get_unless_zero was merged to stable

Mask the symbol so no matter where it was backported we can
compile against that kernel tree.

Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Dor Shaish <dor.shaish@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: support make clean/mrproper

The kernel's "make clean" will recurse into subdirectories, even
into those that aren't enabled in Kconfig. Thus, the previous
trick of changing symbols from CONFIG_* to IMPOSSIBLE_* doesn't
work any more. Change this to comment out the lines instead and
then support "make clean" and "make mrproper".

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

git-tracker: fix multi-commit tracking

Fix a bug with multiple commits: the first commit in
a series was always treated as "multiple" because it
had no correct parent recorded in the dictionary.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: update-initramfs: change/reformat message

Change the "severity" of the message, it doesn't have to
be prefixed with "Warning:" since for many modules it'll
work without updating initramfs. Also reformat it so it's
aligned more nicely.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: fix install script return code

My "test ... && ..." trick won't work with set -e since
then the script will fail, use a proper if.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: mask hid_match_id() since it's present already

On some kernels, hid_match_id() exists, so mask it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: fix a few sparse warnings

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

git-tracker: clarify configuration a bit

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

gentree: fix typo in ignore list handling

We don't want to compare the second-to-last letter with a
two-character string, that'll never be true anyway ... It
should compare the last two letters.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

patch library: fix previous patch

I accidentally removed one line too many ...

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: protect vb2_mmap_pfn_range with LINUX_BACKPORT

Some kernels apparently have this backported, and it doesn't
hurt to protect the symbol since we patch it in anyway for
those files needing it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

patch library: don't use -p1 for git patches

For git patches, the patch library will automatically use
-p1 and strip the a/ b/ filename prefix, while for other
patches it uses -p0 and doesn't strip anything. We usually
use a/ b/ prefixes even when the patches aren't in the git
format and strip a path in gentree, so remove this from
the library.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backport build system: don't pipe yes '' to defconfig

There's no need to pipe yes '' to make defconfig since
it will not ask for anything anyway, and even if it did
the user should probably be asked ...

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: remove iwlwifi dev_dbg() patch

This is no longer needed since now the compat headers
don't pre-include half the world any more.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: include asm/unaligned.h into etherdevice.h

New kernels do this, and some users rely on it.
This allows getting rid of the cfg80211 and ath6kl
patches to include it directly.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: remove unnecessary patches

The files these patch already include the headers
that are patched in, so the patches are entirely
unnecessary.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: declare struct inet6_dev in netdevice.h

This allows us to get rid of the mac80211.h patch to
include net/if_inet6.h to get that declaration. Newer
kernels implicitly declare the struct by using it for
a pointer in struct net_device.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: protect eth_hw_addr_random with LINUX_BACKPORT

debian kernel 3.2 backports eth_hw_addr_random and this collides with
our backport without this patch.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Revert "backports: remove header file patches"

This reverts commit 41a5d256482183aed7b863bc0bdbf95955cdf23b.

These still seem to be needed ... need to fix first.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

devel: add back scripts for fetching kernels

These scripts are copied from compats bin directory.

I updated the kernels referenced in get-compat-kernels.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: backport class_find_device properly

Instead of patching, make a macro that casts the const out
from the function pointer arguments to avoid the warning.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: remove header file patches

All that should be handled by the new header files in
the backports, if not we need to fix those.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: remove useless netdev_tx_t patch

The type netdev_tx_t already gets a typedef to int on old
kernels, so the ifdef in bluetooth code isn't necessary.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: remove change_mtu patches

netdev_attach_ops() will already set everything (to NULL unless
the driver has the callback) so these patches aren't needed.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: remove network namespace patches

The network namespace support was ifdef'ed out for
kernels < 2.6.24, but we don't support those any
more so remove the patches.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: remove SET_NETDEV_DEVTYPE patches

There's no need to have those patches as struct device_type,
with its name field, has been available since kernel 2.6.22.
We can thus make the macro SET_NETDEV_DEVTYPE() an inline
instead (to avoid "unused variable" warnings) and thus get
rid of the patches for it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backport build system: warn if kernel headers aren't there

When the kernel build system/configuration isn't present, warn
verbosely instead of later failing with crypting errors.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backport build system: make autoconf header depend on Kconfig

If the kernel's configuration changes for some reason or you
change the KLIB path then the Kconfig.kernel file is rebuilt
correctly, but the .config and autoconf header may be left
in inconsistent state. Make the autoconf header make target
depend on the Kconfig.kernel and Kconfig.versions file, this
fixes the issue since then oldconfig will run and the header
will be rebuilt.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Revert "backports: fix netdev_set_default_ethtool_ops code"

This reverts commit 91bf647c3a157688ce8e94c0df512cde1b3f5a87.

Also fix the #ifdef for netdev_set_default_ethtool_ops() as
it was backported into kernel 3.7.8.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: fix typo in rndis fix

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backport: allow using backported drivers w/o LEDs

When the base kernel has LED support (partially) disabled,
currently many drivers cannot be built. Since LED support
is hardy critical, work around this by providing API stubs
for the LED support code to still compile (but not work.)

This passes allyesconfig (except for some stupid rtlwifi
issue) with next-20130405 against a 3.8 kernel that has
all the LED options disabled.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: fix ifdef in compat-2.6.37.c

That ifdef got misplaced, vzalloc() shouldn't be inside.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: fix dma-mapping header

The contents of our asm-generic/dma-mapping-common.h should really be
in asm/dma-mapping.h as that gets included by linux/dma-mapping.h and
the other one is just a helper header that arches *may* include.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: WL1251 depends on kernel 3.0

It requires irq_modify_status() which wasn't previously available.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: fix netdev_set_default_ethtool_ops code

This needs to be included for kernel 3.7.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: fix rndis-wlan usb dependencies

I included that file always, but then when the copy-list
doesn't contain the drivers/net/usb/ directory it would
fail to build ... fix that by including that directory
only conditionally when USB_NET_RNDIS_WLAN is selected.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: fix pci_platform_rom backport

pci_platform_rom() actually made it into 3.9, so
only provide it for kernels before that.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: disable drivers needing I2C_CLIENT_SCCB

As we can't backport I2C_CLIENT_SCCB easily (it would
require backporting smbus transfers), disable the two
drivers requiring that constant.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: override pm_wakeup_event() on 2.6.36

This may not be the right thing to do, but it resolves
linking the TI driver on 2.6.36 where pm_wakeup_event()
is declared but not always exported.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: automatically backport EWMA lib

Use the scripting to always copy the latest version.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: add vgaarb.h

This is needed as old versions of it didn't properly
declare struct pci_dev.

Additionally, not all versions included video/vga.h
which causes issues as that pulls in some required
definitions.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: include hardirq into netdevice.h

On newer kernels this is included (indirectly) and
unfortunately some drivers rely on it.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: avoid vfree() const warning

On newer kernels const pointers can be passed to vfree()
and vunmap(), doing so on old kernels causes warnings
that we can suppress with a cast.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: avoid module parameter warnings

On old kernels, boolean module parameters had to be int.
When we backport, they're bool, and thus cause warnings.
Suppress the warnings by redefining the parameter check,
it's not entirely clear that it'll do the right thing
though?

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: fix USB PM in case of !CONFIG_USB_SUSPEND

Even in this case, the variable is an int on old kernels.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: avoid pr_fmt warning from our export.h

On old kernels, linux/export.h didn't exist and we need
to include linux/module.h instead. That includes a lot
though and thus defines pr_fmt already. Avoid redefine
warnings by checking if it's defined before and if not
undefining it afterwards.

However, to then avoid issues with kernel.h/printk.h
not defining it again, we need to override there.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: improve SIMPLE_DEV_PM_OPS macro

To avoid warnings on old kernels, improve the macro
and give it some content rather than nothing.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.26.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.27.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.28.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.29.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.30.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.31.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.32.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.33.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.34.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.35.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.36.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.37.h

Signed-off-by: Johannes Berg <johannes.berg@intel.com>

backports: dissolve compat-2.6.38.h

While at it, fix the SDIO backport because the
max_hw_segs,max_phys_segs -> max_segs change
was really done in 2.6.37, not 2.6.38.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>