backports: backport drvdata = NULL core driver fixes

The Linux kernel had tons of code which at times cleared the
drvdata upon probe failure or release. There are however a bunch
of drivers that didn't clear this.

Commit 0998d063 implmented clearing this upon device_release_driver()
and dealt with probe failure on driver_probe_device(). After this the
kernel was cleaned up separately with *tons* of patches to remove all
these driver specific settings given that the clearing is now done
internally by the device core.

Instead of ifdef'ing code back in for older code where it was properly
in place backport this by piggy backing the new required code upon the
calls used in place. There is a small race here upon device_release_driver()
but we can live with that theoretical race.

Due to the way we hack this backport we can't use a separate namespace
as we have with other symbols.

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains \
	0998d0631001288a5974afc0b2a5f568bcdecb4d
v3.6-rc1~99^2~14^2~17

I count 65 patches implemented after this:

mcgrof@frijol ~/linux-stable (git::master)$ git format-patch \
	--grep="device-core: Ensure drvdata = NULL when no driver is bound" \
	 -o null-drv-fix v3.6-rc1~99^2~14^2~17..

  TL;DR

Alan Stern argued that perhaps applying this to backports wasn't a good
idea given that evidence shows that the original patch actually exposed
tons of bugs in driver code where they were doing the wrong thing.
While this may be true if the original patch was a bad idea it should
be reverted, and if a bug is found upstream, then by all means
finding it through backports will only accelerate the pace at which
we fix these exposed bugs. That is, if a bug is found due to this on
backports then a respective fix for it should go upstream, not to
backports. This is the benefit of providing backports releases: keep
your users engaged on upstream fixes.

Furthermore I am in hopes that perhaps we can SmPL'ify the bugs
instead and in the future perhaps require SmPL to proove that
the what the original patch was doing won't affect the inverse
of what the patch was trying to do -- that is drivers doing the
wrong thing.

commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed May 23 00:09:34 2012 +0200

    device-core: Ensure drvdata = NULL when no driver is bound

    1) drvdata is for a driver to store a pointer to driver specific data
    2) If no driver is bound, there is no driver specific data associated with
       the device
    3) Thus logically drvdata should be NULL if no driver is bound.

    But many drivers don't clear drvdata on device_release, or set drvdata
    early on in probe and leave it set on probe error. Both of which results
    in a dangling pointer in drvdata.

    This patch enforce for drvdata to be NULL after device_release or on probe
    failure.

    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Tested with ckmake against next-20130618:

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.79              [  OK  ]
18  3.1.10              [  OK  ]
19  3.10-rc1            [  OK  ]
20  3.2.45              [  OK  ]
21  3.3.8               [  OK  ]
22  3.4.46              [  OK  ]
23  3.5.7               [  OK  ]
24  3.6.11              [  OK  ]
25  3.7.10              [  OK  ]
26  3.8.13              [  OK  ]
27  3.9.3               [  OK  ]

real    32m2.332s
user    860m23.688s
sys     121m20.840s

Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backport: backport sprintf-style workqueue naming

Since kernel version 3.3, workqueue names could be
sprintf'ed instead of just pointing to a name. This
wasn't used a lot so never needed to be backported,
but now it's used everywhere. Backport this API.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
[mcgrof: add WQ_HIGHPRI and WQ_MEM_RECLAIM defines]
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: fix patches required for next-20130627

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: refresh patches for next-20130627

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: simplify swiotlb_nr_tbl() backport

swiotlb_nr_tbl() was available since 3.2 but was exported since 3.3.
Since it uses an internal global state variable, it is impossible
to backport it to. Instead of reverting the changes added just
let this return 0 as the code will not do anything. This simplifies
the backport.

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: copy the max77693-private.h header file

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: revert DMI_EXACT_MATCH() for older kernels

struct dmi_strmatch was modified on v3.11 with a
exact_match member. The DMI_EXACT_MATCH() macro was
added as a mod version of DMI_MATCH() to account for
dmi strings that look closely like each other. An
example is D510MO Vs D510MOV.

Since exact_match is is not available on older kernels
we can't use it and must revert to the old DMI_MATCH().
Addressing the desired behaviour will require a separate
change to deal with addressing the difference
in the behaviour.

Chris Wilson recommends that if we can't use this we should
also rever the DMI related fixes. I believe these are:

dcf6d294830d46b0e6901477fb4bf455281d90c8 - drm/i915: quirk away phantom LVDS on Intel's D525MW mainboard
e5614f0c2d0f4d7f0b8ef745d34593baf2c5dbf8 - drm/i915: quirk away phantom LVDS on Intel's D510MO mainboard

Once we get confirmation we can do that.

Proof of why we can't backport DMI_EXACT_MATCH():

DMI_EXACT_MATCH uses struct dmi_strmatch's new
member exact_match:

	@@ -456,7 +456,8 @@ enum dmi_field {
	 };

	 struct dmi_strmatch {
	-       unsigned char slot;
	+       unsigned char slot:7;
	+       unsigned char exact_match:1;
		char substr[79];
	 };

Prior to 5017b285 we only had slot member so to use
DMI_EXACT_MATCH() with its intent we'd have to do something
like:
	slot |= 1

if its called. This however assumes though that older code has
the sanity check as changed in 5017b285 on drivers/firmware/dmi_scan.c.
dmi_scan.o gets linked with CONFIG_DMI. At least for x86 that gets
objects sprinkled on arch/x86/, but more importantly CONFIG_DMI is
bool. I've argued how I envision us being able to backport core
components before (see 0935deab for the hint) but as it is right
now we can't. We only backport things we can throw in as modular.

mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains 5017b285
v3.11-rc1~99^2~254

commit 5017b2851373ee15c7035151853bb1448800cae2
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Jul 3 15:05:02 2013 -0700

    dmi: add support for exact DMI matches in addition to substring matching

    dmi_match() considers a substring match to be a successful match.  This is
    not always sufficient to distinguish between DMI data for different
    systems.  Add support for exact string matching using strcmp() in addition
    to the substring matching using strstr().

    The specific use case in the i915 driver is to allow us to use an exact
    match for D510MO, without also incorrectly matching D510MOV:

      {
        .ident = "Intel D510MO",
        .matches = {
                DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
                DMI_EXACT_MATCH(DMI_BOARD_NAME, "D510MO"),
        },
      }

    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Cc: <annndddrr@gmail.com>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Cornel Panceac <cpanceac@gmail.com>
    Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Greg KH <greg@kroah.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Cc: jani.nikula@intel.com
Cc: annndddrr@gmail.com
Cc: chris@chris-wilson.co.uk
Cc: cpanceac@gmail.com
Cc: daniel.vetter@ffwll.ch
Cc: greg@kroah.com
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: add clock enable/disable on soc_camera_power_[on|off]()

v4l2-core now supports enabling and disabling its own clock
on turning the camera on / off. We backport v4l2-core fully
so just backport the soc calls appropriately to let SOC cameras
to turn the clock on / off when the v4l2-core clock ops are
implemented on a device driver.

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: enable REGULATOR_MAX77693 on >= 3.6

There is a symbol missing otherwise that is currently
only provided by the core, ie, non modular.

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
backports: lib/kconfig.py - fix src line regexp

The source line can be prefixed by spaces and tabs. Without
this a slew of kconfig options were not being parsed for
dependency checking and at compile time they'd obviously
fail.

Tested with ckmake against next-20130627

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.79              [  OK  ]
18  3.1.10              [  OK  ]
19  3.10-rc1            [  OK  ]
20  3.2.45              [  OK  ]
21  3.3.8               [  OK  ]
22  3.4.46              [  OK  ]
23  3.5.7               [  OK  ]
24  3.6.11              [  OK  ]
25  3.7.10              [  OK  ]
26  3.8.13              [  OK  ]
27  3.9.3               [  OK  ]

real    34m5.379s
user    921m5.112s
sys     128m8.156s

Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>