The staging driver rt2860sta is replaced by mainline driver rt2800pci, and
rt2870sta is replaced by rt2800usb. As a result, the staging drivers are
deleted.
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
---

Since 1c48a5c9 (dt: Eliminate of_platform_{,un}register_driver)
mpc8xxx_wdt no longer builds as it tries to refer to a 'match' variable
rather than ofdev->dev.of_match that it checks just before.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NWim Van Sebroeck <wim@iguana.be>

Fix build failure issue for hv_mouse
When build 2.6.39-rc1 kernel, it will be blocked at build hv_mouse.

  drivers/staging/hv/hv_mouse.c: In function ‘ReleaseInputDevice’:
  drivers/staging/hv/hv_mouse.c:293: error: implicit declaration of function ‘udelay’
Signed-off-by: NYouquan Song <youquan.song@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit f44f7f96 ("RTC: Initialize kernel state from RTC") caused a
boot regression on the MRST platform.

The reason is that rtc_device_register() calls rtc_read_alarm() after
that change, which function does not have all driver data set up yet.

The rtc-mrst driver needs to call dev_set_drvdata() before rtc_device_register()
gets called.
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Acked-by: NJohn Stultz <john.stultz@linaro.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1302140384-27571-1-git-send-email-feng.tang@intel.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

For isochronous packets the actual_length is the sum of the actual
length of each of the packets, however between the packets might be
padding, so it is not sufficient to just send the first actual_length
bytes of the buffer. To fix this and simultanesouly optimize the
bandwidth the content of the isochronous packets are send without the
padding, the padding is restored on the receiving end.
Signed-off-by: NArjan Mels <arjan.mels@gmx.net>
Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>
Cc: Max Vozeler <max@vozeler.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The number_of_packets was not transmitted for RET_SUBMIT packets. The
linux client used the stored number_of_packet from the submitted
request. The windows userland client does not do this however and needs
to know the number_of_packets to determine the size of the transmission.
Signed-off-by: NArjan Mels <arjan.mels@gmx.net>
Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>
Cc: Max Vozeler <max@vozeler.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When doing a usb port reset do a queued reset instead to prevent a
deadlock: the reset will cause the driver to unbind, causing the
usb_driver_lock_for_reset to stall.
Signed-off-by: NArjan Mels <arjan.mels@gmx.net>
Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>
Cc: Max Vozeler <max@vozeler.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

When shuting down the tcp_rx and tcp_tx threads first check if they are
not closed already (maybe because an error caused them to return).
Signed-off-by: NArjan Mels <arjan.mels@gmx.net>
Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>
Cc: Max Vozeler <max@vozeler.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

After Quick Migration, the network is not immediately operational in the
current context when receiving RNDIS_STATUS_MEDIA_CONNECT event. So, I added
another netif_notify_peers() into a scheduled work, otherwise GARP packet will
not be sent after quick migration, and cause network disconnection.

Thanks to Mike Surcouf <mike@surcouf.co.uk> for reporting the bug and
testing the patch.
Reported-by: NMike Surcouf <mike@surcouf.co.uk>
Tested-by: NMike Surcouf <mike@surcouf.co.uk>
Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: NHank Janssen <hjanssen@microsoft.com>
Signed-off-by: NAbhishek Kane <v-abkane@microsoft.com>
Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The 11" Macbook Air appears to claim that its stride is 1366, when it's
actually 2048. Override it.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NPeter Jones <pjones@redhat.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Some machines apparently give us bogus linelength/stride/pitch data, so
we need to support letting the DMI table override the supplied data.

I bet you can't guess whose machines I'm talking about.
Signed-off-by: NPeter Jones <pjones@redhat.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

It's expected that efifb will conflict with a native driver, so the
handover message should be informational rather than an error.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

The else clause was not needed after the cleanup in commit
b8901b09Signed-off-by: NTormod Volden <debian.tormod@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

In practice this means enabling I2C (for DDC2) on all prosavage cards,
like the xorg ddx does. The savage4 and savage2000 families have only
one member each, so there is no change for those.

Tested on TwisterK.
Signed-off-by: NTormod Volden <debian.tormod@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

MM_SERIAL1 was already defined, but not used.
Signed-off-by: NTormod Volden <debian.tormod@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Error handling code following a kmalloc should free the allocated data.

The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@

x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
     when != if (...) { <+...x...+> }
(
x->f1 = E
|
 (x->f1 == NULL || ...)
|
 f(...,x->f1,...)
)
...>
(
 return \(0\|<+...x...+>\|ptr\);
|
 return@p2 ...;
)

@script:python@
p1 << r.p1;
p2 << r.p2;
@@

print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Acked-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This patch fixes the checkpatch errors listed below:

ERROR: space required before the open parenthesis '('
ERROR: need consistent spacing around '+' (ctx:WxV)
ERROR: space prohibited before that close parenthesis ')'

Also, following warning is fixed by adding 'platid' variable
which can reduce number of lines exceeding 80 characters.

WARNING: line over 80 characters
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

CH Pro Throttle needs NOGET the same way as other products from
the same vendor require.
Reported-by: NUnavowed <unavowed@vexillium.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The evdev buffer isn't big enough when you get many fingers on the
device. Bump up the buffer to a reasonable size, matching what other
multitouch devices use. Without this change, events may be discarded in
the evdev buffer before they are read.
Reported-by: NSimon Budig <simon@budig.de>
Cc: Henrik Rydberg <rydberg@euromail.se>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: stable@kernel.org
Signed-off-by: NChase Douglas <chase.douglas@canonical.com>
Acked-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Just because we are not requeuing a request does not mean that
some aren't pending. So always issue a blk_delay_queue() if
either we are requeueing OR there's pending IO.

This fixes a boot problem for some IDE boxes.
Signed-off-by: NJens Axboe <jaxboe@fusionio.com>

The current block integrity (DIF/DIX) support in DM is verifying that
all devices' integrity profiles match during DM device resume (which
is past the point of no return).  To some degree that is unavoidable
(stacked DM devices force this late checking).  But for most DM
devices (which aren't stacking on other DM devices) the ideal time to
verify all integrity profiles match is during table load.

Introduce the notion of an "initialized" integrity profile: a profile
that was blk_integrity_register()'d with a non-NULL 'blk_integrity'
template.  Add blk_integrity_is_initialized() to allow checking if a
profile was initialized.

Update DM integrity support to:
- check all devices with _initialized_ integrity profiles match
  during table load; uninitialized profiles (e.g. for underlying DM
  device(s) of a stacked DM device) are ignored.
- disallow a table load that would result in an integrity profile that
  conflicts with a DM device's existing (in-use) integrity profile
- avoid clearing an existing integrity profile
- validate all integrity profiles match during resume; but if they
  don't all we can do is report the mismatch (during resume we're past
  the point of no return)
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NJens Axboe <jaxboe@fusionio.com>

We see stalls if we don't always ensure that the queue gets run
again. Even if rq == NULL, we could have other pending requests
in the queue.
Signed-off-by: NJens Axboe <jaxboe@fusionio.com>

Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
CC: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
CC: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Add delay after self test to satisfy timing requirements.
Increase start-up delay.
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
CC: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

cs_change must not be set in the last transfer of a spi message
Signed-off-by: NMichael Hennerich <michael.hennerich@analog.com>
Acked-by: NJonathan Cameron <jic23@cam.ac.uk>
CC: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This is a revert of 428d2e82.

This is broken in the same manner as for VGA: trying to write to an
invalid address on the (currently 7-bit) i2c bus.

One notable failure appears to be for MacBooks. The scary part was that
it gave the appearance of working (i.e. reporting the absence of the
panel) on various all-in-one machines with ghost LVDS panels and not
failing for laptops.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NKeith Packard <keithp@keithp.com>

This is a moral revert of 6ec3d0c0.

Following the fix to reset the GMBUS controller after a NAK, we finally
utilize the 0xa0 probe for a CRT connection. And discover that the code
is broken. Shock.

There are a number of issues, but following a key insight from Dave
Airlie, that 0xA0 is an invalid address on a 7-bit bus (though not if we
were to enable 10-bit addressing), and would look like the EDID port
0x50, it is possible to see where the confusion starts.

In short, a write to 0xA0 is accepted by the GMBUS controller which we
interpreted as meaning the existence of a connection (a slave on the
other end of the wire ACKing the write). That was false.

During testing with a broken GMBUS implementation, which never reset an
earlier NAK, this test always reported a NAK and so we proceeded on to
the next test.
Reported-and-tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35904Reported-and-tested-by: NRiccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32612Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NKeith Packard <keithp@keithp.com>

All UBI needs is to make sure we stacktraces when UBI debugging
is enabled. It is enough to select KALLSYMS for this, KALLSYMS_ALL
is not necessary.

And the current Kconfig line we have:

select KALLSYMS_ALL if KALLSYMS && DEBUG_KERNEL

is just too complex to be sane and right. But this "if" part there
is needed to prevent "unmet direct dependency" warnings, because
KALLSYMS_ALL depends on KALLSYMS and DEBUG_KERNEL, so we cannot
just select KALLSYMS_ALL.

Anyway, this feels messy, and we do not seem to really need KALLSYMS_ALL,
so select KALLSYMS instead.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>

Coverity spotted that UBI debugging code tries to compare
an array and NULL, which obviously makes little sense. Kill
this check.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

'do_sync_erase()' has to check whether we are in R/O mode before
erasing the PEB. This patch adds the check and while on it, adds an
assertion which validates the 'pnum' argument, as well as removes
a check which is always true because it has already been done
few lines before.
Signed-off-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>

These 3 drivers contain much duplicated (triplicated) code, so
building them as built-in results in many errors like:

(.text+0x1b160): multiple definition of `ieee80211_sta_ps_sleep'

Prevent this configuration by making them all buildable only as
loadable modules (similar to the vt665[56] patch last week).
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Issue reported by Larry Finger. Log message was removed.
Signed-off-by: NRoland Vossen <rvossen@broadcom.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Larry Finger reported this issue. Under certain conditions the log
file would be spammed with 'Short CCK' messages. Since this does
not indicate an error condition, the log message was simply
deleted. Also, the RX_FLAG_SHORTPRE flag in rx_status->flag, on
CCK reception, is now only set on short preamble reception (it used
to be set both CCK short and long preambles).
Signed-off-by: NRoland Vossen <rvossen@broadcom.com>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Larry Finger reported this issue. The driver, under certain
conditions, spews log messages like this:

wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen 159/256
 dur 1778/1504

These log messages turned out to be false alarms. Root cause was
that the AC was derived from the sk_buff::priority field. Fix was
to derive the AC from the sk_buff using skb_get_queue_mapping()
Signed-off-by: NRoland Vossen <rvossen@broadcom.com>
Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

It's no longer needed at all.

Cc: Ossama Othman <ossama.othman@intel.com>
Cc: Eugene Epshteyn <eugene.epshteyn@intel.com>
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

So we can drop the memrar staging driver
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Fix hv_mouse.c build, it needs delay.h:

drivers/staging/hv/hv_mouse.c:293: error: implicit declaration of function 'udelay'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Hank Janssen <hjanssen@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>