Unexpected signals can disturb the bus-handling and lock it up. Don't use
interruptible in 'wait_event_*' and 'wake_*' as in commits
dc1972d0 (for cpm),
1ab082d7 (for mpc),
b7af349b (for omap).
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Remove the following sparse warnings (see "make C=1"):
 * drivers/i2c/busses/i2c-ali1563.c:91:3: warning: do-while statement
   is not a compound statement
 * drivers/i2c/busses/i2c-ali1563.c:161:3: warning: do-while statement
   is not a compound statement
Signed-off-by: NMárton Németh <nm127@freemail.hu>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

With `while (timeout++ < MAX_TIMEOUT)' timeout reaches MAX_TIMEOUT + 1
after the loop. This is probably unlikely to produce a problem.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The C99 specification states in section 6.11.5:

The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Add a missing iterator variable thus fixing the conditional of the
for-loop in amd64_get_scrub_rate().
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

The sh-sci driver used the wrong fifosize for PORT_SCIFA and PORT_SCIF
ports. If an incorrect size is used, the serial core will enforce an
early shutdown on the port, especially with baudrates < 9600.
Signed-off-by: NMarkus Pietrek <Markus.Pietrek@emtrion.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This patch updates the copyright notice for 2010 and updates the version
number to 3.106.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The B0 revision of the 5717 will not get enough testing by the time
2.6.33 ships.  Since the kernel is already at RC3, serdes support
will require too many patches to fix.  For these reasons, this patch
disables 5717 serdes support and will refuse to attach to all 5717
devices that are later than an A0 revision.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The serdes status bit does not work as intended for the 5717 A0.
This patch implements an alternative detection scheme that will only be
valid for A0 revisions.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are some tg3 devices that require the driver to post new rx
buffers in smaller increments.  Commit
4361935a, "tg3: Consider
rx_std_prod_idx a hw mailbox" changed how the driver tracks the rx
producer ring updates, but it does not make any special considerations
for the above-mentioned devices.  For those devices, it is possible for
the driver to hit the special case path, which updates the hardware
mailbox register but skips updating the shadow software mailbox member.
If the special case path represents the final mailbox update for this
ISR iteration, the hardware and software mailbox values will be out of
sync.  Ultimately, this will cause the driver to use a stale mailbox
value on the next iteration, which will appear to the hardware as a
large rx buffer update.  Bad things ensue.

The fix is to update the software shadow mailbox member when the special
case path is taken.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Reported-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 87668d35, titled "tg3: Don't
touch RCB nic addresses", tried to avoid assigning the nic address of
the standard producer ring.  Unfortunately, the default nic address is
not correct for the 5787, the 5755M, or the 57765.  This patch
reenables the old behavior and opts out of the assignment only
for the 5717.
Signed-off-by: NMatt Carlson <mcarlson@broadcom.com>
Reviewed-by: NMichael Chan <mchan@broadcom.com>
Tested-by: NChow Loong Jin <hyperair@ubuntu.com>
Tested-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The MDIO self-test should not be run on boards without an MDIO PHY,
such as SFN5122F-R3 and later revisions.  It should also not try to
address a specific MMD in an MDIO clause 22 PHY.  Check the
mode_support field to decide which mode to use, if any.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When the interface is down and we are using polled mode for MCDI
operations, we busy-wait for completion for approximately 1 jiffy
using udelay() and then back off to schedule().  But the completion
will not wake the task, since we are using polled mode!  We must use
schedule_timeout_uninterruptible() instead.
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch removes a delay in hardware after every received packet allowing
more time for transmitted packets to go out in between received packets in
half duplex.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A previous 82577 workaround that set the MDIO access speed to slow mode for
every PHY register read/write when the cable is unplugged should instead
set the access mode to always be slow before any PHY register access.
Since the mode bit gets cleared when the PHY is reset, set the mode after
every PHY reset.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NShannon Nelson <shannon.nelson@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch resolves issues seen when running netconsole and rebooting via
reboot -f.  The issue was due to the fact that we were attempting to
perform interrupt actions when the q_vectors and rings had already been
freed via the ixgbe_shutdown routines.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Acked-by: NMallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

It's not obvious that copy_from_user() is called with a sane length
parameter here. Even though it currently seems to be correct better
add a check to prevent stack corruption / exploits.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

...instead of adding a compat ioctl function which would do nothing
as well.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

This is just a complicated construct which always returns -EINVAL.
Just remove it.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Add missing compat ptr conversion including two additional
whitespace changes that aren't worth a separate patch.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Without this patch xf86-input-wacom driver wasn't able to properly recognise
pad button events. It was also causing some problems with button mapping.
Signed-off-by: NPrzemo Firszt <przemo@firszt.eu>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Added device IDs for the new model of the Apple Wireless Keyboard
(November 2009).
Signed-off-by: NChristian Schuerer-Waldheim <csw@xray.at>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This fix is required for xorg driver to recognise 2 pad buttons
Signed-off-by: NPrzemo Firszt <przemo@firszt.eu>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In 65f63384 "xen: improve error handling in do_suspend" I said:
    - xs_suspend()/xs_resume() and dpm_suspend_noirq()/dpm_resume_noirq() were not
      nested in the obvious way.
and changed the ordering of the calls as so:
    BEFORE		AFTER
    xs_suspend		dpm_suspend_noirq
    dpm_suspend_noirq	xs_suspend
    *SUSPEND*		*SUSPEND*
    dpm_resume_noirq	dpm_resume_noirq
    xs_resume		xs_resume
Clearly this is not an improvement and I was talking rubbish.

In particular the new ordering is susceptible to a hang if a xenstore write is
in progress at the point at which the suspend kicks in. When the suspend
process calls xs_suspend it tries to take the request_mutex but if a write is
in progress it could be looping in xenbus_xs.c:read_reply() waiting for
something to arrive on &xs_state.reply_list while holding the request_mutex
(taken in the caller of read_reply).

However if we have done dpm_suspend_noirq before xs_suspend then we won't get
any more xenstore interrupts and process_msg() will never be woken up to add
anything to the reply_list.

Fix this by calling xs_suspend before dpm_suspend_noirq. If dpm_suspend_noirq
fails then make sure we go through the xs_suspend_cancel() code path.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Stable Kernel <stable@kernel.org>

Signed-off-by: NTai-hwa Liang <avatar@sentelic.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Sentelic probes confuse IBM trackpoints so they stop responding to
TP_READ_ID command. See:

	http://bugzilla.kernel.org/show_bug.cgi?id=14970

Let's move FSP detection lower so it is probed after trackpoint and
others, just before we strat probing for Intellimouse Explorer.
Signed-off-by: NTai-hwa Liang <avatar@sentelic.com>
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>

Following drm info repeat 207 times during one hour, it's quite annoying
[ 1266.286747] [drm] TV-19: set mode NTSC 480i 0

Change from DRM_INFO to DRM_DEBUG
Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Toralf Förster pointed out the typo, the fact I forget the if
statement is purely personal fail.
Signed-off-by: NDave Airlie <airlied@redhat.com>

/sys/bus/pci/drivers/megaraid_sas/poll_mode_io defaults to being
world-writable, which seems bad (letting any user affect kernel driver
behavior).

This turns off group and user write permissions, so that on typical
production systems only root can write to it.
Signed-off-by: NBryn M. Reeves <bmr@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There are two copies of list_sort() in the tree already, one in the DRM
code, another in ubifs.  Now XFS needs this as well.  Create a generic
list_sort() function from the ubifs version and convert existing users
to it so we don't end up with yet another copy in the tree.
Signed-off-by: NDave Chinner <david@fromorbit.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArtem Bityutskiy <dedekind@infradead.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Testing GTT ready might be more correct but cp.ready
works fine and has been tested on irc by 2-3 ppl.

fixes bug k.org 15035 and fd.o 25733
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Due to heat issues.  Fixes fdo bug 25992

v2: fix typo noticed by Maarten Maathuis
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Unhandled vectors can be safely ignored, no need
to spam the kernel log by default.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>