opensuse:kernel.git
8 years agoLinux 2.6.28.8
Greg Kroah-Hartman [Tue, 17 Mar 2009 00:50:03 +0000 (17:50 -0700)]
Linux 2.6.28.8

8 years agohwmon: (it87) Properly decode -128 degrees C temperature
Jean Delvare [Fri, 13 Mar 2009 12:34:04 +0000 (13:34 +0100)]
hwmon: (it87) Properly decode -128 degrees C temperature

commit e267d25005c861fe6afda343f044536342c9f8b4 upstream

The it87 driver is reporting -128 degrees C as +128 degrees C.
That's not a terribly likely temperature value but let's still
get it right, especially when it simplifies the code.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoMIPS: compat: Implement is_compat_task.
Ralf Baechle [Thu, 5 Mar 2009 10:45:48 +0000 (11:45 +0100)]
MIPS: compat: Implement is_compat_task.

commit 4302e5d53b9166d45317e3ddf0a7a9dab3efd43b upstream.

This is a build fix required after "x86-64: seccomp: fix 32/64 syscall
hole" (commit 5b1017404aea6d2e552e991b3fd814d839e9cd67).  MIPS doesn't
have the issue that was fixed for x86-64 by that patch.

This also doesn't solve the N32 issue which is that N32 seccomp processes
will be treated as non-compat processes thus only have access to N64
syscalls.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agodrm/i915: Add missing userland definitions for gem init/execbuffer.
Eric Anholt [Thu, 18 Dec 2008 06:32:14 +0000 (22:32 -0800)]
drm/i915: Add missing userland definitions for gem init/execbuffer.

commit 8d391aa410ecb230fc4c3147b94eec25b9f3c20f upstream.

fdo bug #19132.

Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agohwmon: (f71882fg) Hide misleading error message
Jean Delvare [Sat, 21 Feb 2009 11:00:20 +0000 (12:00 +0100)]
hwmon: (f71882fg) Hide misleading error message

commit 603eaa1bdd3e0402085e815cc531bb0a32827a9e upstream

If the F71882FG chip is at address 0x4e, then the probe at 0x2e will
fail with the following message in the logs:
f71882fg: Not a Fintek device

This is misleading because there is a Fintek device, just at a
different address. So I propose to degrade this message to a debug
message.

Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
8 years agocrypto: api - Fix algorithm test race that broke aead initialisation
Herbert Xu [Wed, 28 Jan 2009 03:09:59 +0000 (14:09 +1100)]
crypto: api - Fix algorithm test race that broke aead initialisation

commit b8e15992b420d09dae831125a623c474c8637cee upstream.

When we complete a test we'll notify everyone waiting on it, drop
the mutex, and then remove the test larval (after reacquiring the
mutex).  If one of the notified parties tries to register another
algorithm with the same driver name prior to the removal of the
test larval, they will fail with EEXIST as only one algorithm of
a given name can be tested at any time.

This broke the initialisation of aead and givcipher algorithms as
they will register two algorithms with the same driver name, in
sequence.

This patch fixes the problem by marking the larval as dead before
we drop the mutex, and also ignoring all dead or dying algorithms
on the registration path.

Tested-by: Andreas Steffen <andreas.steffen@strongswan.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kerin Millar <kerframil@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoACPI: fix broken usage of acpi_ut_get_node_name()
Henrique de Moraes Holschuh [Tue, 24 Feb 2009 14:48:18 +0000 (11:48 -0300)]
ACPI: fix broken usage of acpi_ut_get_node_name()

This issue was fixed indirectly in mainline by commit
60a4ce7f4148155d3f28eea4a213f7ee47cd57b7.

acpi_ut_get_node_name() returns a four char fixed-size array, not
NULL-terminated.

This is the minimal fix for stable 2.6.28.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: stable@kernel.org
Acked-by: Lin Ming <ming.m.lin@intel.com>
Acked-by: Len Brown <lenb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoACPI: fix broken usage of name.ascii
Henrique de Moraes Holschuh [Tue, 24 Feb 2009 14:48:17 +0000 (11:48 -0300)]
ACPI: fix broken usage of name.ascii

This issue was fixed indirectly in mainline by commit
0175d562a29ad052c510782c7e76bc63d5155b9b.

acpi_namespace_node's name.ascii field is four chars, and not NULL-
terminated except by pure luck.  So, it cannot be used by sscanf() without
a length restriction.

This is the minimal fix for both stable 2.6.27 and 2.6.28.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Lin Ming <ming.m.lin@intel.com>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoi2c: Fix misplaced parentheses
Roel Kluin [Wed, 25 Feb 2009 20:24:40 +0000 (21:24 +0100)]
i2c: Fix misplaced parentheses

commit f29d2e0275a4f03ef2fd158e484508dcb0c64efb upstream

Fix misplaced parentheses.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoi2c: Timeouts reach -1
Roel Kluin [Wed, 25 Feb 2009 20:26:21 +0000 (21:26 +0100)]
i2c: Timeouts reach -1

commit a746b578d8406b2db0e9f0d040061bc1f78433cf upstream

With a postfix decrement these timeouts reach -1 rather than 0, but
after the loop it is tested whether they have become 0.

As pointed out by Jean Delvare, the condition we are waiting for should
also be tested before the timeout. With the current order, you could
exit with a timeout error while the job is actually done.

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoARM: Add i2c_board_info for RiscPC PCF8583
Russell King [Wed, 25 Feb 2009 20:34:07 +0000 (21:34 +0100)]
ARM: Add i2c_board_info for RiscPC PCF8583

commit 531660ef5604c75de6fdead9da1304051af17c09 upstream

Add the necessary i2c_board_info structure to fix the lack of PCF8583
RTC on RiscPC.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoHID: move tmff and zpff devices from ignore_list to blacklist
Anssi Hannula [Mon, 2 Mar 2009 15:16:10 +0000 (16:16 +0100)]
HID: move tmff and zpff devices from ignore_list to blacklist

[ upstream commit daedb3d6a91f9626ab4c921378ac52e44de833d5 ]

From: Anssi Hannula <anssi.hannula@gmail.com>
Subject: HID: move tmff and zpff devices from ignore_list to blacklist

The devices handled by hid-tmff and hid-zpff were added in the
hid_ignore_list[] instead of hid_blacklist[] in hid-core.c, thus
disabling them completely.

hid_ignore_list[] causes hid layer to skip the device, while
hid_blacklist[] indicates there is a specific driver in hid bus.

Re-enable the devices by moving them to the correct list.

Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoide-iops: fix odd-length ATAPI PIO transfers
Sergei Shtylyov [Thu, 5 Mar 2009 15:10:56 +0000 (16:10 +0100)]
ide-iops: fix odd-length ATAPI PIO transfers

commit a509538d4fb4f99cdf0a095213d57cc3b2347615 upstream.

Commit 9567b349f7e7dd7e2483db99ee8e4a6fe0caca38 (ide: merge ->atapi_*put_bytes
and ->ata_*put_data methods) introduced a regression  WRT the odd-length ATAPI
PIO transfers -- the final word didn't get written (causing command timeouts).

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agox86: fix math_emu register frame access
Tejun Heo [Mon, 9 Feb 2009 13:17:39 +0000 (22:17 +0900)]
x86: fix math_emu register frame access

commit d315760ffa261c15ff92699ac6f514112543d7ca upstream.

do_device_not_available() is the handler for #NM and it declares that
it takes a unsigned long and calls math_emu(), which takes a long
argument and surprisingly expects the stack frame starting at the zero
argument would match struct math_emu_info, which isn't true regardless
of configuration in the current code.

This patch makes do_device_not_available() take struct pt_regs like
other exception handlers and initialize struct math_emu_info with
pointer to it and pass pointer to the math_emu_info to math_emulate()
like normal C functions do.  This way, unless gcc makes a copy of
struct pt_regs in do_device_not_available(), the register frame is
correctly accessed regardless of kernel configuration or compiler
used.

This doesn't fix all math_emu problems but it at least gets it
somewhat working.

Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agox86: math_emu info cleanup
Tejun Heo [Mon, 9 Feb 2009 13:17:39 +0000 (22:17 +0900)]
x86: math_emu info cleanup

commit ae6af41f5a4841f06eb92bc86ad020ad44ae2a30 upstream.

Impact: cleanup

* Come on, struct info?  s/struct info/struct math_emu_info/

* Use struct pt_regs and kernel_vm86_regs instead of defining its own
  register frame structure.

Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agox86, hpet: fix for LS21 + HPET = boot hang
john stultz [Fri, 13 Feb 2009 02:48:53 +0000 (18:48 -0800)]
x86, hpet: fix for LS21 + HPET = boot hang

commit b13e24644c138d0ddbc451403c30a96b09bfd556 upstream.

Between 2.6.23 and 2.6.24-rc1 a change was made that broke IBM LS21
systems that had the HPET enabled in the BIOS, resulting in boot hangs
for x86_64.

Specifically commit b8ce33590687888ebb900d09557b8807c4539022, which
merges the i386 and x86_64 HPET code.

Prior to this commit, when we setup the HPET timers in x86_64, we did
the following:

hpet_writel(HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL |
                    HPET_TN_32BIT, HPET_T0_CFG);

However after the i386/x86_64 HPET merge, we do the following:

cfg = hpet_readl(HPET_Tn_CFG(timer));
cfg |= HPET_TN_ENABLE | HPET_TN_PERIODIC |
HPET_TN_SETVAL | HPET_TN_32BIT;
hpet_writel(cfg, HPET_Tn_CFG(timer));

However on LS21s with HPET enabled in the BIOS, the HPET_T0_CFG register
boots with Level triggered interrupts (HPET_TN_LEVEL) enabled. This
causes the periodic interrupt to be not so periodic, and that results in
the boot time hang I reported earlier in the delay calibration.

My fix: Always disable HPET_TN_LEVEL when setting up periodic mode.

Signed-off-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agox86/paravirt: make arch_flush_lazy_mmu/cpu disable preemption
Jeremy Fitzhardinge [Thu, 12 Feb 2009 18:02:56 +0000 (10:02 -0800)]
x86/paravirt: make arch_flush_lazy_mmu/cpu disable preemption

commit d85cf93da66977dbc645352be1b2084a659d8a0b upstream.

Impact: avoid access to percpu vars in preempible context

They are intended to be used whenever there's the possibility
that there's some stale state which is going to be overwritten
with a queued update, or to force a state change when we may be
in lazy mode.  Either way, we could end up calling it with
preemption enabled, so wrap the functions in their own little
preempt-disable section so they can be safely called in any
context (though preemption should never be enabled if we're actually
in a lazy state).

(Move out of line to avoid #include dependencies.)

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoext4: Fix deadlock in ext4_write_begin() and ext4_da_write_begin()
Jan Kara [Thu, 5 Mar 2009 07:35:15 +0000 (02:35 -0500)]
ext4: Fix deadlock in ext4_write_begin() and ext4_da_write_begin()

(cherry picked from commit ebd3610b110bbb18ea6f9f2aeed1e1068c537227)

Functions ext4_write_begin() and ext4_da_write_begin() call
grab_cache_page_write_begin() without AOP_FLAG_NOFS. Thus it
can happen that page reclaim is triggered in that function
and it recurses back into the filesystem (or some other filesystem).
But this can lead to various problems as a transaction is already
started at that point. Add the necessary flag.

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

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoext4: Add fallback for find_group_flex
Theodore Ts'o [Thu, 5 Mar 2009 07:35:14 +0000 (02:35 -0500)]
ext4: Add fallback for find_group_flex

(cherry picked from commit 05bf9e839d9de4e8a094274a0a2fd07beb47eaf1)

This is a workaround for find_group_flex() which badly needs to be
replaced.  One of its problems (besides ignoring the Orlov algorithm)
is that it is a bit hyperactive about returning failure under
suspicious circumstances.  This can lead to spurious ENOSPC failures
even when there are inodes still available.

Work around this for now by retrying the search using
find_group_other() if find_group_flex() returns -1.  If
find_group_other() succeeds when find_group_flex() has failed, log a
warning message.

A better block/inode allocator that will fix this problem for real has
been queued up for the next merge window.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoext4: Fix NULL dereference in ext4_ext_migrate()'s error handling
Dan Carpenter [Tue, 24 Feb 2009 17:14:48 +0000 (12:14 -0500)]
ext4: Fix NULL dereference in ext4_ext_migrate()'s error handling

(cherry picked from commit 090542641de833c6f756895fc2f139f046e298f9)

This was found through a code checker (http://repo.or.cz/w/smatch.git/).
It looks like you might be able to trigger the error by trying to migrate
a readonly file system.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoext4: Implement range_cyclic in ext4_da_writepages instead of write_cache_pages
Aneesh Kumar K.V [Tue, 24 Feb 2009 17:14:47 +0000 (12:14 -0500)]
ext4: Implement range_cyclic in ext4_da_writepages instead of write_cache_pages

(cherry picked from commit 2acf2c261b823d9d9ed954f348b97620297a36b5)

With delayed allocation we lock the page in write_cache_pages() and
try to build an in memory extent of contiguous blocks.  This is needed
so that we can get large contiguous blocks request.  If range_cyclic
mode is enabled, write_cache_pages() will loop back to the 0 index if
no I/O has been done yet, and try to start writing from the beginning
of the range.  That causes an attempt to take the page lock of lower
index page while holding the page lock of higher index page, which can
cause a dead lock with another writeback thread.

The solution is to implement the range_cyclic behavior in
ext4_da_writepages() instead.

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

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoext4: Initialize preallocation list_head's properly
Aneesh Kumar K.V [Tue, 24 Feb 2009 17:14:46 +0000 (12:14 -0500)]
ext4: Initialize preallocation list_head's properly

(cherry picked from commit d794bf8e0936dce45104565cd48c571061f4c1e3)

When creating a new ext4_prealloc_space structure, we have to
initialize its list_head pointers before we add them to any prealloc
lists.  Otherwise, with list debug enabled, we will get list
corruption warnings.

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoext4: Fix lockdep warning
Aneesh Kumar K.V [Tue, 24 Feb 2009 17:14:45 +0000 (12:14 -0500)]
ext4: Fix lockdep warning

(cherry picked from commit ba4439165f0f0d25b2fe065cf0c1ff8130b802eb)

We should not call ext4_mb_add_n_trim while holding alloc_semp.

    =============================================
    [ INFO: possible recursive locking detected ]
    2.6.29-rc4-git1-dirty #124
    ---------------------------------------------
    ffsb/3116 is trying to acquire lock:
     (&meta_group_info[i]->alloc_sem){----}, at: [<ffffffff8035a6e8>]
     ext4_mb_load_buddy+0xd2/0x343

    but task is already holding lock:
     (&meta_group_info[i]->alloc_sem){----}, at: [<ffffffff8035a6e8>]
     ext4_mb_load_buddy+0xd2/0x343

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

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoext4: Fix to read empty directory blocks correctly in 64k
Wei Yongjun [Tue, 24 Feb 2009 17:14:44 +0000 (12:14 -0500)]
ext4: Fix to read empty directory blocks correctly in 64k

(cherry picked from commit 7be2baaa0322c59ba888aa5260a8c130666acd41)

The rec_len field in the directory entry is 16 bits, so there was a
problem representing rec_len for filesystems with a 64k block size in
the case where the directory entry takes the entire 64k block.
Unfortunately, there were two schemes that were proposed; one where
all zeros meant 65536 and one where all ones (65535) meant 65536.
E2fsprogs used 0, whereas the kernel used 65535.  Oops.  Fortunately
this case happens extremely rarely, with the most common case being
the lost+found directory, created by mke2fs.

So we will be liberal in what we accept, and accept both encodings,
but we will continue to encode 65536 as 65535.  This will require a
change in e2fsprogs, but with fortunately ext4 filesystems normally
have the dir_index feature enabled, which precludes having a
completely empty directory block.

Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agojbd2: Avoid possible NULL dereference in jbd2_journal_begin_ordered_truncate()
Jan Kara [Tue, 24 Feb 2009 17:14:43 +0000 (12:14 -0500)]
jbd2: Avoid possible NULL dereference in jbd2_journal_begin_ordered_truncate()

(cherry picked from commit 7f5aa215088b817add9c71914b83650bdd49f8a9)

If we race with commit code setting i_transaction to NULL, we could
possibly dereference it.  Proper locking requires the journal pointer
(to access journal->j_list_lock), which we don't have.  So we have to
change the prototype of the function so that filesystem passes us the
journal pointer.  Also add a more detailed comment about why the
function jbd2_journal_begin_ordered_truncate() does what it does and
how it should be used.

Thanks to Dan Carpenter <error27@gmail.com> for pointing to the
suspitious code.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Acked-by: Joel Becker <joel.becker@oracle.com>
CC: linux-ext4@vger.kernel.org
CC: ocfs2-devel@oss.oracle.com
CC: mfasheh@suse.de
CC: Dan Carpenter <error27@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoRevert "ext4: wait on all pending commits in ext4_sync_fs()"
Jan Kara [Tue, 24 Feb 2009 17:14:42 +0000 (12:14 -0500)]
Revert "ext4: wait on all pending commits in ext4_sync_fs()"

(cherry picked from commit 9eddacf9e9c03578ef2c07c9534423e823d677f8)

This undoes commit 14ce0cb411c88681ab8f3a4c9caa7f42e97a3184.

Since jbd2_journal_start_commit() is now fixed to return 1 when we
started a transaction commit, there's some transaction waiting to be
committed or there's a transaction already committing, we don't
need to call ext4_force_commit() in ext4_sync_fs(). Furthermore
ext4_force_commit() can unnecessarily create sync transaction which is
expensive so it's worthwhile to remove it when we can.

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

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Eric Sandeen <sandeen@redhat.com>
Cc: linux-ext4@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agojbd2: Fix return value of jbd2_journal_start_commit()
Jan Kara [Tue, 24 Feb 2009 17:14:41 +0000 (12:14 -0500)]
jbd2: Fix return value of jbd2_journal_start_commit()

(cherry picked from commit c88ccea3143975294f5a52097546bcbb75975f52)

The function jbd2_journal_start_commit() returns 1 if either a
transaction is committing or the function has queued a transaction
commit. But it returns 0 if we raced with somebody queueing the
transaction commit as well. This resulted in ext4_sync_fs() not
functioning correctly (description from Arthur Jones):

   In the case of a data=ordered umount with pending long symlinks
   which are delayed due to a long list of other I/O on the backing
   block device, this causes the buffer associated with the long
   symlinks to not be moved to the inode dirty list in the second
   phase of fsync_super.  Then, before they can be dirtied again,
   kjournald exits, seeing the UMOUNT flag and the dirty pages are
   never written to the backing block device, causing long symlink
   corruption and exposing new or previously freed block data to
   userspace.

This can be reproduced with a script created by Eric Sandeen
<sandeen@redhat.com>:

        #!/bin/bash

        umount /mnt/test2
        mount /dev/sdb4 /mnt/test2
        rm -f /mnt/test2/*
        dd if=/dev/zero of=/mnt/test2/bigfile bs=1M count=512
        touch /mnt/test2/thisisveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongfilename
        ln -s /mnt/test2/thisisveryveryveryveryveryveryveryveryveryveryveryveryveryveryveryverylongfilename
        /mnt/test2/link
        umount /mnt/test2
        mount /dev/sdb4 /mnt/test2
        ls /mnt/test2/

This patch fixes jbd2_journal_start_commit() to always return 1 when
there's a transaction committing or queued for commit.

Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
CC: Eric Sandeen <sandeen@redhat.com>
CC: linux-ext4@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoV4L: ivtv: fix decoder crash regression
Hans Verkuil [Sat, 14 Feb 2009 22:58:33 +0000 (19:58 -0300)]
V4L: ivtv: fix decoder crash regression

(cherry picked from commit ac9575f75c52bcb455120f8c43376b556acba048)

The video_ioctl2 conversion of ivtv in kernel 2.6.27 introduced a bug
causing decoder commands to crash. The decoder commands should have been
handled from the video_ioctl2 default handler, ensuring correct mapping
of the argument between user and kernel space. Unfortunately they ended
up before the video_ioctl2 call, causing random crashes.

Thanks to hannes@linus.priv.at for testing and helping me track down the
cause!

Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoV4L: saa7127: fix broken S-Video with saa7129
Martin Dauskardt [Thu, 12 Mar 2009 21:43:44 +0000 (17:43 -0400)]
V4L: saa7127: fix broken S-Video with saa7129

(backported from commit 0f3559ef17362a7dd5017521a4dd4cad31263395)

Register 0x2d has to be set differently in the saa7129 compared to the
saa7127. This was not done correctly, so S-Video was broken in certain
circumstances.

This fixes a regression introduced in 2.6.28.

Signed-off-by: Martin Dauskardt <martin.dauskardt@gmx.de>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoV4L: tda8290: fix TDA8290 + TDA18271 initialization
Michael Krufky [Mon, 5 Jan 2009 21:25:04 +0000 (18:25 -0300)]
V4L: tda8290: fix TDA8290 + TDA18271 initialization

(cherry picked from commit 439b72b69e4992e9ec34b74304f0fa95623934eb)

Don't call tda8290_init_tuner unless we have either a TDA8275 or TDA8275A
present. Calling this function will cause a TDA18271 to get sick, so we
should only call it when needed.

Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoDVB: s5h1409: Perform s5h1409 soft reset after tuning
Devin Heitmueller [Mon, 26 Jan 2009 06:07:59 +0000 (03:07 -0300)]
DVB: s5h1409: Perform s5h1409 soft reset after tuning

(cherry picked from commit 67e70baf043cfdcdaf5972bc94be82632071536b)

Just like with the s5h1411, the s5h1409 needs a soft-reset in order for it
to know that the tuner has been told to change frequencies.  This change
changes the behavior from "random tuning times between 500ms to complete
tuning lock failures" to "tuning lock consistently within 700ms".

Thanks to Robert Krakora <rob.krakora@messagenetsystems.com> for doing
initial testing of the patch on the KWorld 330U.

Thanks to Andy Walls <awalls@radix.net> for doing testing of the patch on
the HVR-1600.

Thanks to Michael Krufky <mkrufky@linuxtv.org> for doing additional testing.

Signed-off-by: Devin Heitmueller <dheitmueller@linuxtv.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agopipe_rdwr_fasync: fix the error handling to prevent the leak/crash
Oleg Nesterov [Thu, 12 Mar 2009 21:31:28 +0000 (14:31 -0700)]
pipe_rdwr_fasync: fix the error handling to prevent the leak/crash

commit e5bc49ba7439b9726006d031d440cba96819f0f8 upstream.

If the second fasync_helper() fails, pipe_rdwr_fasync() returns the error
but leaves the file on ->fasync_readers.

This was always wrong, but since 233e70f4228e78eb2f80dc6650f65d3ae3dbf17c
"saner FASYNC handling on file close" we have the new problem.  Because in
this case setfl() doesn't set FASYNC bit, __fput() will not do
->fasync(0), and we leak fasync_struct with ->fa_file pointing to the
freed file.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agosdhci: Add NO_BUSY_IRQ quirk for Marvell CAFE host chip
Andres Salomon [Mon, 2 Mar 2009 20:48:20 +0000 (21:48 +0100)]
sdhci: Add NO_BUSY_IRQ quirk for Marvell CAFE host chip

commit a0874897b1ba106298e4303a25456a473fc40f3d upstream.

As described here: http://lkml.org/lkml/2009/2/20/265

The CAFE chip is broken due to commit e809517f6fa5803a5a1cd5602.
Anton added a quirk here: http://lkml.org/lkml/2009/2/20/279 that fixes
CAFE's problem.  This adds the quirk for CAFE.

Signed-off-by: Andres Salomon <dilinger@debian.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agosdhci: Add quirk for controllers with no end-of-busy IRQ
Ben Dooks [Fri, 20 Feb 2009 17:33:08 +0000 (20:33 +0300)]
sdhci: Add quirk for controllers with no end-of-busy IRQ

commit f945405cdecd9e0ae3e58ff84cabd19b4522965e upstream.

The Samsung SDHCI (and FSL eSDHC) controller block seems to fail
to generate an INT_DATA_END after the transfer has completed and
the bus busy state finished.

Changes in e809517f6fa5803a5a1cd56026f0e2190fc13d5c to use the
new busy method are the cause of the behaviour change.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agopowerpc: Fix load/store float double alignment handler
Michael Neuling [Thu, 19 Feb 2009 18:52:20 +0000 (18:52 +0000)]
powerpc: Fix load/store float double alignment handler

commit 49f297f8df9adb797334155470ea9ca68bdb041e upstream.

When we introduced VSX, we changed the way FPRs are stored in the
thread_struct.  Unfortunately we missed the load/store float double
alignment handler code when updating how we access FPRs in the
thread_struct.

Below fixes this and merges the little/big endian case.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoproc: fix PG_locked reporting in /proc/kpageflags
Helge Bahmann [Fri, 20 Feb 2009 13:24:12 +0000 (16:24 +0300)]
proc: fix PG_locked reporting in /proc/kpageflags

commit e07a4b9217d1e97d2f3a62b6b070efdc61212110 upstream.

Expr always evaluates to zero.

Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agocopy_process: fix CLONE_PARENT && parent_exec_id interaction
Oleg Nesterov [Mon, 2 Mar 2009 21:58:45 +0000 (22:58 +0100)]
copy_process: fix CLONE_PARENT && parent_exec_id interaction

commit 2d5516cbb9daf7d0e342a2e3b0fc6f8c39a81205 upstream.

CLONE_PARENT can fool the ->self_exec_id/parent_exec_id logic. If we
re-use the old parent, we must also re-use ->parent_exec_id to make
sure exit_notify() sees the right ->xxx_exec_id's when the CLONE_PARENT'ed
task exits.

Also, move down the "p->parent_exec_id = p->self_exec_id" thing, to place
two different cases together.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Serge E. Hallyn <serge@hallyn.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoPCI: Add PCI quirk to disable L0s ASPM state for 82575 and 82598
Alexander Duyck [Thu, 5 Mar 2009 18:57:28 +0000 (13:57 -0500)]
PCI: Add PCI quirk to disable L0s ASPM state for 82575 and 82598

commit 649426efcfbc67a8b033497151816cbac9fd0cfa upstream.

This patch is intended to disable L0s ASPM link state for 82598 (ixgbe)
parts due to the fact that it is possible to corrupt TX data when coming
back out of L0s on some systems.  The workaround had been added for 82575
(igb) previously, but did not use the ASPM api.  This quirk uses the ASPM
api to prevent the ASPM subsystem from re-enabling the L0s state.

Instead of adding the fix in igb to the ixgbe driver as well it was
decided to move it into a pci quirk.  It is necessary to move the fix out
of the driver and into a pci quirk in order to prevent the issue from
occuring prior to driver load to handle the possibility of the device being
passed to a VM via direct assignment.

Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agofore200: fix oops on failed firmware load
Meelis Roos [Wed, 11 Feb 2009 01:19:19 +0000 (17:19 -0800)]
fore200: fix oops on failed firmware load

commit fcffd0d8bbddac757cd856e635ac75e8eb4518bc upstream.

Fore 200 ATM driver fails to handle request_firmware failures and oopses
when no firmware file was found. Fix it by checking for the right return
values and propaganting the return value up.

Signed-off-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agozaurus: add usb id for motomagx phones
Dmitriy Taychenachev [Tue, 24 Feb 2009 18:42:48 +0000 (18:42 +0000)]
zaurus: add usb id for motomagx phones

commit 52c0326beaa3cb0049d0f1c51c6ad5d4a04e4430 upstream.

The Motorola MOTOMAGX phones (Z6, E8, Zn5 so far) are providing
combined ACM/BLAN USB configuration. Since it has Vendor Specific
class, the corresponding drivers (cdc-acm, zaurus) can't find it just
by interface info. This patch adds usb id so the zaurus driver can
properly handle this combined device.

Signed-off-by: Dmitriy Taychenachev <dimichxp@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agocdc_ether: add usb id for Ericsson F3507g
Bjørn Mork [Wed, 25 Feb 2009 04:33:58 +0000 (04:33 +0000)]
cdc_ether: add usb id for Ericsson F3507g

commit cac477e8f1038c41b6f29d3161ce351462ef3df7 upstream.

The Ericsson F3507g wireless broadband module provides a CDC Ethernet
compliant interface, but identifies it as a "Mobile Direct Line" CDC
subclass, thereby preventing the CDC Ethernet class driver from picking
it up.  This patch adds the device id to cdc_ether.c as a workaround.

Ericsson has provided a "class" driver for this device:
http://kerneltrap.org/mailarchive/linux-net/2008/10/28/3832094
But closer inspection of that driver reveals that it adds little more
than duplication of code from cdc_ether.c.  See also
http://marc.info/?l=linux-usb&m=123334979706403&w=2

Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoasix: new device ids
Greg Kroah-Hartman [Wed, 25 Feb 2009 07:52:24 +0000 (23:52 -0800)]
asix: new device ids

commit fef7cc0893146550b286b13c0e6e914556142730 upstream.

This patch adds two new device ids to the asix driver.

One comes directly from the asix driver on their web site, the other was
reported by Armani Liao as needed for the MSI X320 to get the driver to
work properly for it.

Reported-by: Armani Liao <aliao@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
8 years agoxen/blkfront: use blk_rq_map_sg to generate ring entries
Jens Axboe [Tue, 24 Feb 2009 07:10:09 +0000 (08:10 +0100)]
xen/blkfront: use blk_rq_map_sg to generate ring entries

commit 9e973e64ac6dc504e6447d52193d4fff1a670156 upstream.

On occasion, the request will apparently have more segments than we
fit into the ring. Jens says:

> The second problem is that the block layer then appears to create one
> too many segments, but from the dump it has rq->nr_phys_segments ==
> BLKIF_MAX_SEGMENTS_PER_REQUEST. I suspect the latter is due to
> xen-blkfront not handling the merging on its own. It should check that
> the new page doesn't form part of the previous page. The
> rq_for_each_segment() iterates all single bits in the request, not dma
> segments. The "easiest" way to do this is to call blk_rq_map_sg() and
> then iterate the mapped sg list. That will give you what you are
> looking for.

> Here's a test patch, compiles but otherwise untested. I spent more
> time figuring out how to enable XEN than to code it up, so YMMV!
> Probably the sg list wants to be put inside the ring and only
> initialized on allocation, then you can get rid of the sg on stack and
> sg_init_table() loop call in the function. I'll leave that, and the
> testing, to you.

[Moved sg array into info structure, and initialize once. -J]

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Sven Köhler <sven.koehler@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoxen: disable interrupts early, as start_kernel expects
Jeremy Fitzhardinge [Wed, 25 Feb 2009 17:42:25 +0000 (09:42 -0800)]
xen: disable interrupts early, as start_kernel expects

commit 55d8085671863fe4ee6a17b7814bd38180a44e1d upstream.

This avoids a lockdep warning from:
if (DEBUG_LOCKS_WARN_ON(unlikely(!early_boot_irqs_enabled)))
return;
in trace_hardirqs_on_caller();

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Mark McLoughlin <markmc@redhat.com>
Cc: Xen-devel <xen-devel@lists.xensource.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agox86-64: syscall-audit: fix 32/64 syscall hole
Roland McGrath [Sat, 28 Feb 2009 03:03:24 +0000 (19:03 -0800)]
x86-64: syscall-audit: fix 32/64 syscall hole

commit ccbe495caa5e604b04d5a31d7459a6f6a76a756c upstream.

On x86-64, a 32-bit process (TIF_IA32) can switch to 64-bit mode with
ljmp, and then use the "syscall" instruction to make a 64-bit system
call.  A 64-bit process make a 32-bit system call with int $0x80.

In both these cases, audit_syscall_entry() will use the wrong system
call number table and the wrong system call argument registers.  This
could be used to circumvent a syscall audit configuration that filters
based on the syscall numbers or argument details.

Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agox86-64: seccomp: fix 32/64 syscall hole
Roland McGrath [Sat, 28 Feb 2009 07:25:54 +0000 (23:25 -0800)]
x86-64: seccomp: fix 32/64 syscall hole

commit 5b1017404aea6d2e552e991b3fd814d839e9cd67 upstream.

On x86-64, a 32-bit process (TIF_IA32) can switch to 64-bit mode with
ljmp, and then use the "syscall" instruction to make a 64-bit system
call.  A 64-bit process make a 32-bit system call with int $0x80.

In both these cases under CONFIG_SECCOMP=y, secure_computing() will use
the wrong system call number table.  The fix is simple: test TS_COMPAT
instead of TIF_IA32.  Here is an example exploit:

/* test case for seccomp circumvention on x86-64

   There are two failure modes: compile with -m64 or compile with -m32.

   The -m64 case is the worst one, because it does "chmod 777 ." (could
   be any chmod call).  The -m32 case demonstrates it was able to do
   stat(), which can glean information but not harm anything directly.

   A buggy kernel will let the test do something, print, and exit 1; a
   fixed kernel will make it exit with SIGKILL before it does anything.
*/

#define _GNU_SOURCE
#include <assert.h>
#include <inttypes.h>
#include <stdio.h>
#include <linux/prctl.h>
#include <sys/stat.h>
#include <unistd.h>
#include <asm/unistd.h>

int
main (int argc, char **argv)
{
  char buf[100];
  static const char dot[] = ".";
  long ret;
  unsigned st[24];

  if (prctl (PR_SET_SECCOMP, 1, 0, 0, 0) != 0)
    perror ("prctl(PR_SET_SECCOMP) -- not compiled into kernel?");

#ifdef __x86_64__
  assert ((uintptr_t) dot < (1UL << 32));
  asm ("int $0x80 # %0 <- %1(%2 %3)"
       : "=a" (ret) : "0" (15), "b" (dot), "c" (0777));
  ret = snprintf (buf, sizeof buf,
  "result %ld (check mode on .!)\n", ret);
#elif defined __i386__
  asm (".code32\n"
       "pushl %%cs\n"
       "pushl $2f\n"
       "ljmpl $0x33, $1f\n"
       ".code64\n"
       "1: syscall # %0 <- %1(%2 %3)\n"
       "lretl\n"
       ".code32\n"
       "2:"
       : "=a" (ret) : "0" (4), "D" (dot), "S" (&st));
  if (ret == 0)
    ret = snprintf (buf, sizeof buf,
    "stat . -> st_uid=%u\n", st[7]);
  else
    ret = snprintf (buf, sizeof buf, "result %ld\n", ret);
#else
# error "not this one"
#endif

  write (1, buf, ret);

  syscall (__NR_exit, 1);
  return 2;
}

Signed-off-by: Roland McGrath <roland@redhat.com>
[ I don't know if anybody actually uses seccomp, but it's enabled in
  at least both Fedora and SuSE kernels, so maybe somebody is. - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agohpilo: new pci device
David Altobelli [Fri, 27 Feb 2009 22:03:09 +0000 (14:03 -0800)]
hpilo: new pci device

commit 31d8b5631f095cb7100cfccc95c801a2547ffe2b upstream.

Future iLO devices will have an HP vendor id.

Signed-off-by: David Altobelli <david.altobelli@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoselinux: Fix the NetLabel glue code for setsockopt()
Paul Moore [Fri, 20 Feb 2009 21:33:02 +0000 (16:33 -0500)]
selinux: Fix the NetLabel glue code for setsockopt()

commit 09c50b4a52c01a1f450b8eec819089e228655bfb upstream.

At some point we (okay, I) managed to break the ability for users to use the
setsockopt() syscall to set IPv4 options when NetLabel was not active on the
socket in question.  The problem was noticed by someone trying to use the
"-R" (record route) option of ping:

 # ping -R 10.0.0.1
 ping: record route: No message of desired type

The solution is relatively simple, we catch the unlabeled socket case and
clear the error code, allowing the operation to succeed.  Please note that we
still deny users the ability to override IPv4 options on socket's which have
NetLabel labeling active; this is done to ensure the labeling remains intact.

Signed-off-by: Paul Moore <paul.moore@hp.com>
Signed-off-by: James Morris <jmorris@namei.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoselinux: Fix a panic in selinux_netlbl_inode_permission()
Paul Moore [Fri, 27 Feb 2009 20:00:03 +0000 (15:00 -0500)]
selinux: Fix a panic in selinux_netlbl_inode_permission()

commit d7f59dc4642ce2fc7b79fcd4ec02ffce7f21eb02 upstream.

Rick McNeal from LSI identified a panic in selinux_netlbl_inode_permission()
caused by a certain sequence of SUNRPC operations.  The problem appears to be
due to the lack of NULL pointer checking in the function; this patch adds the
pointer checks so the function will exit safely in the cases where the socket
is not completely initialized.

Signed-off-by: Paul Moore <paul.moore@hp.com>
Signed-off-by: James Morris <jmorris@namei.org>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agox86-64: fix int $0x80 -ENOSYS return
Roland McGrath [Sat, 7 Feb 2009 02:15:18 +0000 (18:15 -0800)]
x86-64: fix int $0x80 -ENOSYS return

commit c09249f8d1b84344eca882547afdbffee8c09d14 upstream.

One of my past fixes to this code introduced a different new bug.
When using 32-bit "int $0x80" entry for a bogus syscall number,
the return value is not correctly set to -ENOSYS.  This only happens
when neither syscall-audit nor syscall tracing is enabled (i.e., never
seen if auditd ever started).  Test program:

/* gcc -o int80-badsys -m32 -g int80-badsys.c
   Run on x86-64 kernel.
   Note to reproduce the bug you need auditd never to have started.  */

#include <errno.h>
#include <stdio.h>

int
main (void)
{
  long res;
  asm ("int $0x80" : "=a" (res) : "0" (99999));
  printf ("bad syscall returns %ld\n", res);
  return res != -ENOSYS;
}

The fix makes the int $0x80 path match the sysenter and syscall paths.

Reported-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Roland McGrath <roland@redhat.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agox86: tone down mtrr_trim_uncached_memory() warning
Ingo Molnar [Thu, 29 Jan 2009 10:45:35 +0000 (11:45 +0100)]
x86: tone down mtrr_trim_uncached_memory() warning

commit bf3647c44bc76c43c4b2ebb4c37a559e899ac70e upstream.

kerneloops.org is reporting a lot of these warnings that come due to
vmware not setting up any MTRRs for emulated CPUs:

| Reported 709 times (14696 total reports)
| BIOS bug (often in VMWare) where the MTRR's are set up incorrectly
| or not at all
|
| This warning was last seen in version 2.6.29-rc2-git1, and first
| seen in 2.6.24.
|
| More info:
|   http://www.kerneloops.org/searchweek.php?search=mtrr_trim_uncached_memory

Keep a one-liner KERN_INFO about it - so that we have so notice if empty
MTRRs are caused by native hardware/BIOS weirdness.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agommc_test: fix basic read test
Rabin Vincent [Fri, 13 Feb 2009 17:25:26 +0000 (22:55 +0530)]
mmc_test: fix basic read test

commit 58a5dd3e0e77029d3db1f8fa75d0b54b38169d5d upstream.

Due to a typo in the Basic Read test, it's currently identical to the
Basic Write test.  Fix this.

Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoMMC: fix bug - SDHC card capacity not correct
Yi Li [Thu, 5 Feb 2009 07:31:57 +0000 (15:31 +0800)]
MMC: fix bug - SDHC card capacity not correct

commit 444122fd58fdc83c96877a92b3f6288cafddb08d upstream.

Signed-off-by: Yi Li <yi.li@analog.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agommc: s3cmci: fix s3c2410_dma_config() arguments.
Ben Dooks [Thu, 12 Mar 2009 21:31:33 +0000 (14:31 -0700)]
mmc: s3cmci: fix s3c2410_dma_config() arguments.

commit 7c48ed3383bfb2106694807361ec187fe8a4333d upstream.

The s3cmci driver is calling s3c2410_dma_config with incorrect data for
the DCON register.  The S3C2410_DCON_HWTRIG is implicit in the channel
configuration and the device selection of S3C2410_DCON_CH0_SDI is
incorrect as the DMA system may not select channel 0.

Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Acked-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agos3cmci: Fix hangup in do_pio_write()
Yauhen Kharuzhy [Wed, 11 Feb 2009 21:25:52 +0000 (13:25 -0800)]
s3cmci: Fix hangup in do_pio_write()

commit 994244883739e4044bef76d4e5d7a9b66dc6c7b6 upstream.

This commit fixes the regression what was added by commit
088a78af978d0c8e339071a9b2bca1f4cb368f30 "s3cmci: Support transfers
which are not multiple of 32 bits."

fifo_free() now returns amount of available space in FIFO buffer in
bytes.  But do_pio_write() writes to FIFO 32-bit words.  Condition for
return from cycle is (fifo_free() == 0), but when fifo has 1..3 bytes
of free space then this condition will never be true and system hangs.

This patch changes condition in the while() to (fifo_free() > 3).

Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
8 years agommc: fix data timeout for SEND_EXT_CSD
Adrian Hunter [Tue, 10 Feb 2009 14:32:33 +0000 (16:32 +0200)]
mmc: fix data timeout for SEND_EXT_CSD

commit cda56ac29f2d8288d62978272856884d26e0b47b upstream.

Commit 0d3e0460f307e84904968aad6cff97bd688583d8
"MMC: CSD and CID timeout values" inadvertently broke
the timeout for the MMC command SEND_EXT_CSD.

This patch puts it back again.

Depending on the characteristics of the controller,
this bug may prevent the use of MMC cards.

Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agolibata: make sure port is thawed when skipping resets
Tejun Heo [Wed, 4 Mar 2009 06:59:30 +0000 (15:59 +0900)]
libata: make sure port is thawed when skipping resets

commit d6515e6ff4ad3db4bd5ef2dd4e1026a7aca2482e upstream.

When SCR access is available and the link is offline, softreset is
skipped as it only wastes time and some controllers don't respond very
well.  However, the skip path forgot to thaw the port, which not only
blocks further event notification from the port but also causes
repeated EH invocations on the same event on drivers which rely on
->thaw() to clear events if the IRQ is shared with another device or
port.

This problem has always been there but is uncovered by recent sata_nv
nf2/3 change which dropped hardreset support while maintaining SCR
access.  nf2/3 doesn't clear hotplug event mask from the interrupt
handler but relies on ->thaw() to clear them.  When the hardreset was
there, the reset action was never skipped and the port was always
thawed but, with the hardreset gone, ->prereset() determines that
there's no need for softreset and both ->softreset() and ->thaw() are
skipped.  This leads to stuck hotplug event in the IRQ status register
triggering hotplug event whenever IRQ is delieverd on the same IRQ.
As the controller shares the same IRQ for both ports, this happens on
every IO if one port is occpupied and the other isn't.

This patch fixes the problem by making sure that the port is thawed on
reset-skip path.

bko#11615 reports this problem.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Robert Hancock <hancockrwd@gmail.com>
Reported-by: Dan Andresan <danyer@gmail.com>
Reported-by: Arne Woerner <arne_woerner@yahoo.com>
Reported-by: Stefan Lippers-Hollmann <s.L-H@gmx.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agolibata: Don't trust current capacity values in identify words 57-58
Robert Hancock [Tue, 17 Feb 2009 02:15:08 +0000 (20:15 -0600)]
libata: Don't trust current capacity values in identify words 57-58

commit 968e594afdbc40b4270f9d4032ae8350475749d6 upstream.

Hanno Böck reported a problem where an old Conner CP30254 240MB hard drive
was reported as 1.1TB in capacity by libata:

http://lkml.org/lkml/2009/2/13/134

This was caused by libata trusting the drive's reported current capacity in
sectors in identify words 57 and 58 if the drive does not support LBA and the
current CHS translation values appear valid. Unfortunately it seems older
ATA specs were vague about what this field should contain and a number of drives
used values with wrong byte order or that were totally bogus. There's no
unique information that it conveys and so we can just calculate the number
of sectors from the reported current CHS values.

While we're at it, clean up this function to use named constants for the
identify word values.

Signed-off-by: Robert Hancock <hancockrwd@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agojsm: additional device support
Adam Lackorzynski [Wed, 18 Feb 2009 22:48:34 +0000 (14:48 -0800)]
jsm: additional device support

commit ffa7525c13eb3db0fd19a3e1cffe2ce6f561f5f3 upstream.

I have a Digi Neo 8 PCI card (114f:00b1) Serial controller: Digi
International Digi Neo 8 (rev 05)

that works with the jsm driver after using the following patch.

Signed-off-by: Adam Lackorzynski <adam@os.inf.tu-dresden.de>
Cc: Scott H Kilau <Scott_Kilau@digi.com>
Cc: Wendy Xiong <wendyx@us.ibm.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoPCI: Enable PCIe AER only after checking firmware support
Andrew Patterson [Fri, 20 Feb 2009 23:04:59 +0000 (16:04 -0700)]
PCI: Enable PCIe AER only after checking firmware support

commit 1f9f13c8d59c1d8da1a602b71d1ab96d1d37d69e upstream.

The PCIe port driver currently sets the PCIe AER error reporting bits for
any root or switch port without first checking to see if firmware will grant
control. This patch moves setting these bits to the AER service driver
aer_enable_port routine.  The bits are then set for the root port and any
downstream switch ports after the check for firmware support (aer_osc_setup)
is made. The patch also unsets the bits in a similar fashion when the AER
service driver is unloaded.

Reviewed-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Andrew Patterson <andrew.patterson@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@hobbes.lan>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoPCIe: portdrv: call pci_disable_device during remove
Alex Chiang [Sun, 8 Mar 2009 02:35:47 +0000 (19:35 -0700)]
PCIe: portdrv: call pci_disable_device during remove

commit d89987193631bf23d1735c55d13a06d4b8d0e9bd upstream.

The PCIe port driver calls pci_enable_device() during probe but
never calls pci_disable_device() during remove.

Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agofs: new inode i_state corruption fix
Nick Piggin [Thu, 12 Mar 2009 21:31:38 +0000 (14:31 -0700)]
fs: new inode i_state corruption fix

commit 7ef0d7377cb287e08f3ae94cebc919448e1f5dff upstream.

There was a report of a data corruption
http://lkml.org/lkml/2008/11/14/121.  There is a script included to
reproduce the problem.

During testing, I encountered a number of strange things with ext3, so I
tried ext2 to attempt to reduce complexity of the problem.  I found that
fsstress would quickly hang in wait_on_inode, waiting for I_LOCK to be
cleared, even though instrumentation showed that unlock_new_inode had
already been called for that inode.  This points to memory scribble, or
synchronisation problme.

i_state of I_NEW inodes is not protected by inode_lock because other
processes are not supposed to touch them until I_LOCK (and I_NEW) is
cleared.  Adding WARN_ON(inode->i_state & I_NEW) to sites where we modify
i_state revealed that generic_sync_sb_inodes is picking up new inodes from
the inode lists and passing them to __writeback_single_inode without
waiting for I_NEW.  Subsequently modifying i_state causes corruption.  In
my case it would look like this:

CPU0                            CPU1
unlock_new_inode()              __sync_single_inode()
 reg <- inode->i_state
 reg -> reg & ~(I_LOCK|I_NEW)   reg <- inode->i_state
 reg -> inode->i_state          reg -> reg | I_SYNC
                                reg -> inode->i_state

Non-atomic RMW on CPU1 overwrites CPU0 store and sets I_LOCK|I_NEW again.

Fix for this is rather than wait for I_NEW inodes, just skip over them:
inodes concurrently being created are not subject to data integrity
operations, and should not significantly contribute to dirty memory
either.

After this change, I'm unable to reproduce any of the added warnings or
hangs after ~1hour of running.  Previously, the new warnings would start
immediately and hang would happen in under 5 minutes.

I'm also testing on ext3 now, and so far no problems there either.  I
don't know whether this fixes the problem reported above, but it fixes a
real problem for me.

Cc: "Jorge Boncompte [DTI2]" <jorge@dti2.net>
Reported-by: Adrian Hunter <ext-adrian.hunter@nokia.com>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoproc: fix kflags to uflags copying in /proc/kpageflags
Wu Fengguang [Wed, 11 Mar 2009 01:00:04 +0000 (09:00 +0800)]
proc: fix kflags to uflags copying in /proc/kpageflags

commit ad3bdefe877afb47480418fdb05ecd42842de65e upstream.

Fix kpf_copy_bit(src,dst) to be kpf_copy_bit(dst,src) to match the
actual call patterns, e.g. kpf_copy_bit(kflags, KPF_LOCKED, PG_locked).

This misplacement of src/dst only affected reporting of PG_writeback,
PG_reclaim and PG_buddy. For others kflags==uflags so not affected.

Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agomtd_dataflash: fix probing of AT45DB321C chips.
Will Newton [Tue, 10 Mar 2009 19:55:53 +0000 (12:55 -0700)]
mtd_dataflash: fix probing of AT45DB321C chips.

commit 229cc58ba2b5a83b0b55764c6cb98695c106238a upstream.

Commit 771999b65f79264acde4b855e5d35696eca5e80c ("[MTD] DataFlash: bugfix,
binary page sizes now handled") broke support for probing AT45DB321C flash
chips.  These chips do not support the "page size" status bit, so if we
match the JEDEC id return early.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Will Newton <will.newton@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agointel-agp: fix a panic with 1M of shared memory, no GTT entries
Lubomir Rintel [Tue, 10 Mar 2009 19:55:54 +0000 (12:55 -0700)]
intel-agp: fix a panic with 1M of shared memory, no GTT entries

commit 9c1e8a4ebcc04226cb6f3a1bf1d72f4cafd6b089 upstream.

When GTT size is equal to amount of video memory, the amount of GTT
entries is computed lower than zero, which is invalid and leads to
off-by-one error in intel_i915_configure()

Originally posted here:
http://bugzilla.kernel.org/show_bug.cgi?id=12539
http://bugzilla.redhat.com/show_bug.cgi?id=445592

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Cc: Lubomir Rintel <lkundrak@v3.sk>
Cc: Dave Airlie <airlied@linux.ie>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agox86: add Dell XPS710 reboot quirk
Leann Ogasawara [Wed, 4 Mar 2009 19:53:00 +0000 (11:53 -0800)]
x86: add Dell XPS710 reboot quirk

commit dd4124a8a06bca89c077a16437edac010f0bb993 upstream.

Dell XPS710 will hang on reboot.  This is resolved by adding a quirk to
set bios reboot.

Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Cc: "manoj.iyer" <manoj.iyer@canonical.com>
LKML-Reference: <1236196380.3231.89.camel@emiko>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agox86: oprofile: don't set counter width from cpuid on Core2
Tim Blechmann [Thu, 19 Feb 2009 16:34:03 +0000 (17:34 +0100)]
x86: oprofile: don't set counter width from cpuid on Core2

commit 780eef9492b16a1543a3b2ae9f9526a735fc9856 upstream.

Impact: fix stuck NMIs and non-working oprofile on certain CPUs

Resetting the counter width of the performance counters on Intel's
Core2 CPUs, breaks the delivery of NMIs, when running in x86_64 mode.

This should fix bug #12395:

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

Signed-off-by: Tim Blechmann <tim@klingt.org>
Signed-off-by: Robert Richter <robert.richter@amd.com>
LKML-Reference: <20090303100412.GC10085@erda.amd.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agosdhci: fix led naming
Helmut Schaa [Sat, 14 Feb 2009 15:22:39 +0000 (16:22 +0100)]
sdhci: fix led naming

commit 5dbace0c9ba110c1a3810a89fa6bf12b7574b5a3 upstream.

Fix the led device naming for the sdhci driver.

The led class documentation defines the led name to have the
form "devicename:colour:function" while not applicable sections
should be left blank.

To comply with the documentation the led device name is changed
from "mmc*" to "mmc*::".

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoinotify: fix GFP_KERNEL related deadlock
Ingo Molnar [Wed, 18 Feb 2009 22:48:43 +0000 (14:48 -0800)]
inotify: fix GFP_KERNEL related deadlock

commit f04b30de3c82528f1ab4c58b3dd4c975f5341901 upstream.

Enhanced lockdep coverage of __GFP_NOFS turned up this new lockdep
assert:

[ 1093.677775]
[ 1093.677781] =================================
[ 1093.680031] [ INFO: inconsistent lock state ]
[ 1093.680031] 2.6.29-rc5-tip-01504-gb49eca1-dirty #1
[ 1093.680031] ---------------------------------
[ 1093.680031] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
[ 1093.680031] kswapd0/308 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 1093.680031]  (&inode->inotify_mutex){+.+.?.}, at: [<c0205942>] inotify_inode_is_dead+0x20/0x80
[ 1093.680031] {RECLAIM_FS-ON-W} state was registered at:
[ 1093.680031]   [<c01696b9>] mark_held_locks+0x43/0x5b
[ 1093.680031]   [<c016baa4>] lockdep_trace_alloc+0x6c/0x6e
[ 1093.680031]   [<c01cf8b0>] kmem_cache_alloc+0x20/0x150
[ 1093.680031]   [<c040d0ec>] idr_pre_get+0x27/0x6c
[ 1093.680031]   [<c02056e3>] inotify_handle_get_wd+0x25/0xad
[ 1093.680031]   [<c0205f43>] inotify_add_watch+0x7a/0x129
[ 1093.680031]   [<c020679e>] sys_inotify_add_watch+0x20f/0x250
[ 1093.680031]   [<c010389e>] sysenter_do_call+0x12/0x35
[ 1093.680031]   [<ffffffff>] 0xffffffff
[ 1093.680031] irq event stamp: 60417
[ 1093.680031] hardirqs last  enabled at (60417): [<c018d5f5>] call_rcu+0x53/0x59
[ 1093.680031] hardirqs last disabled at (60416): [<c018d5b9>] call_rcu+0x17/0x59
[ 1093.680031] softirqs last  enabled at (59656): [<c0146229>] __do_softirq+0x157/0x16b
[ 1093.680031] softirqs last disabled at (59651): [<c0106293>] do_softirq+0x74/0x15d
[ 1093.680031]
[ 1093.680031] other info that might help us debug this:
[ 1093.680031] 2 locks held by kswapd0/308:
[ 1093.680031]  #0:  (shrinker_rwsem){++++..}, at: [<c01b0502>] shrink_slab+0x36/0x189
[ 1093.680031]  #1:  (&type->s_umount_key#4){+++++.}, at: [<c01e6d77>] shrink_dcache_memory+0x110/0x1fb
[ 1093.680031]
[ 1093.680031] stack backtrace:
[ 1093.680031] Pid: 308, comm: kswapd0 Not tainted 2.6.29-rc5-tip-01504-gb49eca1-dirty #1
[ 1093.680031] Call Trace:
[ 1093.680031]  [<c016947a>] valid_state+0x12a/0x13d
[ 1093.680031]  [<c016954e>] mark_lock+0xc1/0x1e9
[ 1093.680031]  [<c016a5b4>] ? check_usage_forwards+0x0/0x3f
[ 1093.680031]  [<c016ab74>] __lock_acquire+0x2c6/0xac8
[ 1093.680031]  [<c01688d9>] ? register_lock_class+0x17/0x228
[ 1093.680031]  [<c016b3d3>] lock_acquire+0x5d/0x7a
[ 1093.680031]  [<c0205942>] ? inotify_inode_is_dead+0x20/0x80
[ 1093.680031]  [<c08824c4>] __mutex_lock_common+0x3a/0x4cb
[ 1093.680031]  [<c0205942>] ? inotify_inode_is_dead+0x20/0x80
[ 1093.680031]  [<c08829ed>] mutex_lock_nested+0x2e/0x36
[ 1093.680031]  [<c0205942>] ? inotify_inode_is_dead+0x20/0x80
[ 1093.680031]  [<c0205942>] inotify_inode_is_dead+0x20/0x80
[ 1093.680031]  [<c01e6672>] dentry_iput+0x90/0xc2
[ 1093.680031]  [<c01e67a3>] d_kill+0x21/0x45
[ 1093.680031]  [<c01e6a46>] __shrink_dcache_sb+0x27f/0x355
[ 1093.680031]  [<c01e6dc5>] shrink_dcache_memory+0x15e/0x1fb
[ 1093.680031]  [<c01b05ed>] shrink_slab+0x121/0x189
[ 1093.680031]  [<c01b0d12>] kswapd+0x39f/0x561
[ 1093.680031]  [<c01ae499>] ? isolate_pages_global+0x0/0x233
[ 1093.680031]  [<c0157eae>] ? autoremove_wake_function+0x0/0x43
[ 1093.680031]  [<c01b0973>] ? kswapd+0x0/0x561
[ 1093.680031]  [<c0157daf>] kthread+0x41/0x82
[ 1093.680031]  [<c0157d6e>] ? kthread+0x0/0x82
[ 1093.680031]  [<c01043ab>] kernel_thread_helper+0x7/0x10

inotify_handle_get_wd() does idr_pre_get() which does a
kmem_cache_alloc() without __GFP_FS - and is hence deadlockable under
extreme MM pressure.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: MinChan Kim <minchan.kim@gmail.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoHID: fix bus endianity in file2alias
Jiri Slaby [Tue, 17 Feb 2009 11:38:36 +0000 (12:38 +0100)]
HID: fix bus endianity in file2alias

commit 2b639386a2a26c84c8d26c649cf657ebd43a7bc8 upstream.

Fix endianness of bus member of hid_device_id in modpost.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Reported-by: Nye Liu <nyet@mrv.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agox86, vmi: TSC going backwards check in vmi clocksource
Alok N Kataria [Wed, 18 Feb 2009 20:33:55 +0000 (12:33 -0800)]
x86, vmi: TSC going backwards check in vmi clocksource

commit 48ffc70b675aa7798a52a2e92e20f6cce9140b3d upstream.

Impact: fix time warps under vmware

Similar to the check for TSC going backwards in the TSC clocksource,
we also need this check for VMI clocksource.

Signed-off-by: Alok N Kataria <akataria@vmware.com>
Cc: Zachary Amsden <zach@vmware.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years ago8250: fix boot hang with serial console when using with Serial Over Lan port
Mauro Carvalho Chehab [Fri, 20 Feb 2009 23:38:52 +0000 (15:38 -0800)]
8250: fix boot hang with serial console when using with Serial Over Lan port

commit b6adea334c6c89d5e6c94f9196bbf3a279cb53bd upstream.

Intel 8257x Ethernet boards have a feature called Serial Over Lan.

This feature works by emulating a serial port, and it is detected by
kernel as a normal 8250 port.  However, this emulation is not perfect, as
also noticed on changeset 7500b1f602aad75901774a67a687ee985d85893f.

Before this patch, the kernel were trying to check if the serial TX is
capable of work using IRQ's.

This were done with a code similar this:

        serial_outp(up, UART_IER, UART_IER_THRI);
        lsr = serial_in(up, UART_LSR);
        iir = serial_in(up, UART_IIR);
        serial_outp(up, UART_IER, 0);

        if (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT)
up->bugs |= UART_BUG_TXEN;

This works fine for other 8250 ports, but, on 8250-emulated SoL port, the
chip is a little lazy to down UART_IIR_NO_INT at UART_IIR register.

Due to that, UART_BUG_TXEN is sometimes enabled.  However, as TX IRQ keeps
working, and the TX polling is now enabled, the driver miss-interprets the
IRQ received later, hanging up the machine until a key is pressed at the
serial console.

This is the 6 version of this patch.  Previous versions were trying to
introduce a large enough delay between serial_outp and serial_in(up,
UART_IIR), but not taking forever.  However, the needed delay couldn't be
safely determined.

At the experimental tests, a delay of 1us solves most of the cases, but
still hangs sometimes.  Increasing the delay to 5us was better, but still
doesn't solve.  A very high delay of 50 ms seemed to work every time.

However, poking around with delays and pray for it to be enough doesn't
seem to be a good approach, even for a quirk.

So, instead of playing with random large arbitrary delays, let's just
disable UART_BUG_TXEN for all SoL ports.

[akpm@linux-foundation.org: fix warnings]
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoFix fixpoint divide exception in acct_update_integrals
Heiko Carstens [Mon, 9 Mar 2009 12:31:59 +0000 (13:31 +0100)]
Fix fixpoint divide exception in acct_update_integrals

commit 6d5b5acca9e566515ef3f1ed617e7295c4f94345 upstream.

Frans Pop reported the crash below when running an s390 kernel under Hercules:

  Kernel BUG at 000738b4  verbose debug info unavailable!
  fixpoint divide exception: 0009  #1! SMP
  Modules linked in: nfs lockd nfs_acl sunrpc ctcm fsm tape_34xx
     cu3088 tape ccwgroup tape_class ext3 jbd mbcache dm_mirror dm_log dm_snapshot
     dm_mod dasd_eckd_mod dasd_mod
  CPU: 0 Not tainted 2.6.27.19 #13
  Process awk (pid: 2069, task: 0f9ed9b8, ksp: 0f4f7d18)
  Krnl PSW : 070c1000 800738b4 (acct_update_integrals+0x4c/0x118)
             R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:0 CC:1 PM:0
  Krnl GPRS: 00000000 000007d0 7fffffff fffff830
             00000000 ffffffff 00000002 0f9ed9b8
             00000000 00008ca0 00000000 0f9ed9b8
             0f9edda4 8007386e 0f4f7ec8 0f4f7e98
  Krnl Code: 800738aaa71807d0         lhi     %r1,2000
             800738ae8c200001         srdl    %r2,1
             800738b2: 1d21             dr      %r2,%r1
            >800738b45810d10e         l       %r1,270(%r13)
             800738b8: 1823             lr      %r2,%r3
             800738ba4130f060         la      %r3,96(%r15)
             800738be: 0de1             basr    %r14,%r1
             800738c05800f060         l       %r0,96(%r15)
  Call Trace:
  ( <000000000004fdea>! blocking_notifier_call_chain+0x1e/0x2c)
    <0000000000038502>! do_exit+0x106/0x7c0
    <0000000000038c36>! do_group_exit+0x7a/0xb4
    <0000000000038c8e>! SyS_exit_group+0x1e/0x30
    <0000000000021c28>! sysc_do_restart+0x12/0x16
    <0000000077e7e924>! 0x77e7e924

Reason for this is that cpu time accounting usually only happens from
interrupt context, but acct_update_integrals gets also called from
process context with interrupts enabled.

So in acct_update_integrals we may end up with the following scenario:

Between reading tsk->stime/tsk->utime and tsk->acct_timexpd an interrupt
happens which updates accouting values.  This causes acct_timexpd to be
greater than the former stime + utime.  The subsequent calculation of

dtime = cputime_sub(time, tsk->acct_timexpd);

will be negative and the division performed by

cputime_to_jiffies(dtime)

will generate an exception since the result won't fit into a 32 bit
register.

In order to fix this just always disable interrupts while accessing any
of the accounting values.

Reported by: Frans Pop <elendil@planet.nl>
Tested by: Frans Pop <elendil@planet.nl>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agovmalloc: call flush_cache_vunmap() from unmap_kernel_range()
Tejun Heo [Fri, 20 Feb 2009 23:38:48 +0000 (15:38 -0800)]
vmalloc: call flush_cache_vunmap() from unmap_kernel_range()

commit f6fcba7014f9cc535fa75ef98c008b24e49e2212 upstream.

Impact: proper vcache flush on unmap_kernel_range()

flush_cache_vunmap() should be called before pages are unmapped.  Add
a call to it in unmap_kernel_range().

Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Nick Piggin <npiggin@suse.de>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoacer-wmi: fix regression in backlight detection
Michael Spang [Thu, 12 Mar 2009 21:31:34 +0000 (14:31 -0700)]
acer-wmi: fix regression in backlight detection

commit 1ba869ec581fd9078b684c56c399ffe3d2345e27 upstream.

Currently we disable the Acer WMI backlight device if there is no ACPI
backlight device.  As a result, we end up with no backlight device at all.
 We should instead disable it if there is an ACPI device, as the other
laptop drivers do.  This regression was introduced in febf2d9 ("Acer-WMI:
fingers off backlight if video.ko is serving this functionality").

Each laptop driver with backlight support got a similar change around
febf2d9.  The changes to the other drivers look correct; see e.g.
a598c82f for a similar but correct change.  The regression is also in
2.6.28.

Signed-off-by: Michael Spang <mspang@csclub.uwaterloo.ca>
Acked-by: Thomas Renninger <trenn@suse.de>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Carlos Corbacho <carlos@strangeworlds.co.uk>
Cc: Len Brown <len.brown@intel.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoALSA: aw2: do not grab every saa7146 based device
Anssi Hannula [Sun, 22 Feb 2009 12:42:54 +0000 (14:42 +0200)]
ALSA: aw2: do not grab every saa7146 based device

commit e8bf069c419c1dc0657e02636441fe1179a9db14 upstream.

Audiowerk2 driver snd-aw2 is bound to any saa7146 device as it does not
check subsystem ids. Many DVB devices are saa7146 based, so aw2 driver
grabs them as well.

According to http://lkml.org/lkml/2008/10/15/311 aw2 devices have the
subsystem ids set to 0, the saa7146 default.

Fix conflicts with DVB devices by checking for subsystem ids = 0
specifically.

Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoALSA: hda - add another MacBook Pro 3,1 SSID
Luke Yelavich [Mon, 23 Feb 2009 02:00:33 +0000 (13:00 +1100)]
ALSA: hda - add another MacBook Pro 3,1 SSID

commit 2d4663816064fabb68935f920bbd7ccdc7f9392d upstream.

Reference: Ubuntu bug #33245
    https://bugs.launchpad.net/bugs/332456

Signed-off-by: Luke Yelavich <themuso@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoALSA: hda - Fix digital mic on dell-m4-1 and dell-m4-3
Takashi Iwai [Fri, 27 Feb 2009 16:36:33 +0000 (17:36 +0100)]
ALSA: hda - Fix digital mic on dell-m4-1 and dell-m4-3

commit ea18aa464452c3e6550320d247c0306aaa2d156f upstream.

Fix num_dmuxes initialization for dell-m4-1 and dell-m4-3 models
of IDT 92HD71bxx codec, which was wrongly set to zero.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoALSA: fix excessive background noise introduced by OSS emulation rate shrink
Steve Chen [Sat, 21 Feb 2009 14:05:04 +0000 (08:05 -0600)]
ALSA: fix excessive background noise introduced by OSS emulation rate shrink

commit 5370d96f85962769ea3df3a81cc885f257c51589 upstream.

Incorrect variable was used to get the next sample which caused S2
to be stuck with the same value resulting in loud background noise.

Signed-off-by: Steve Chen <schen@mvista.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agosound: usb-audio: fix uninitialized variable with M-Audio MIDI interfaces
Clemens Ladisch [Mon, 16 Feb 2009 14:22:39 +0000 (15:22 +0100)]
sound: usb-audio: fix uninitialized variable with M-Audio MIDI interfaces

commit e156ac4c571e3be741bc411e58820b74a9295c72 upstream.

Fix the snd_usbmidi_create_endpoints_midiman() function, which forgot to
set the out_interval member of the endpoint info structure for Midiman/
M-Audio devices.  Since kernel 2.6.24, any non-zero value makes the
driver use interrupt transfers instead of bulk transfers.  With EHCI
controllers, these random interval values result in unbearably large
latencies for output MIDI transfers.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reported-by: David <devurandom@foobox.com>
Tested-by: David <devurandom@foobox.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoALSA: usb-audio - Workaround for misdetected sample rate with CM6207
Joris van Rantwijk [Mon, 16 Feb 2009 21:58:23 +0000 (22:58 +0100)]
ALSA: usb-audio - Workaround for misdetected sample rate with CM6207

commit 3b03cc5b86e2052295b9b484f37226ee15c87924 upstream.

The CM6207 incorrectly advertises its 96 kHz playback setting as 48 kHz
in its USB device descriptor. This patch extends an existing workaround
in usbaudio.c to also cover the CM6207.

This resolves issue 0004249 in the ALSA bug tracker.

Signed-off-by: Joris van Rantwijk <jorispubl@xs4all.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoALSA: usb-audio - Fix non-continuous rate detection
Takashi Iwai [Mon, 16 Feb 2009 21:48:12 +0000 (22:48 +0100)]
ALSA: usb-audio - Fix non-continuous rate detection

commit 0412558c873f716efe902b397af0653a550f7341 upstream.

The detection of non-continuous rates (given via rate tables) isn't
processed properly (e.g. for type II).

This patch fixes and simplifies the detection code.

Tested-by: Joris van Rantwijk <jorispubl@xs4all.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agosound: virtuoso: revert "do not overwrite EEPROM on Xonar D2/D2X"
Clemens Ladisch [Tue, 17 Feb 2009 08:50:30 +0000 (09:50 +0100)]
sound: virtuoso: revert "do not overwrite EEPROM on Xonar D2/D2X"

commit 6ce6c473a7fd742fdb0db95841e2c4c6b37337c5 upstream.

This reverts commit 7e86c0e6850504ec9516b953f316a47277825e33 ("do not
overwrite EEPROM on Xonar D2/D2X") because it did not actually help with
the problem.

More user reports show that the overwriting of the EEPROM is not
triggered by using this driver but by installing Linux, and that the
installation of any other operating system (even one without any CMI8788
driver) has the same effect.  In other words, the presence of this
driver does not have any effect on the occurrence of the error.  (So
far, the available evidence seems to point to a BIOS bug.)

Furthermore, it turns out that the EEPROM chip is protected against
stray write commands by the command format and by requiring a separate
write-enable command, so the error scenario in the previous commit (that
SPI writes can be misinterpreted as an EEPROM write command) is not even
theoretically possible.

The mixer control that was removed as a consequence of the previous
commit can only be partially emulated in userspace, which also means it
cannot be seen be the in-kernel OSS API emulation, so it is better to
revert that change.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agomd/raid10: Don't skip more than 1 bitmap-chunk at a time during recovery.
NeilBrown [Wed, 25 Feb 2009 02:18:47 +0000 (13:18 +1100)]
md/raid10: Don't skip more than 1 bitmap-chunk at a time during recovery.

commit 09b4068a7fe442efc40e9dcbcf5ff37c3338ab15 upstream.

When doing recovery on a raid10 with a write-intent bitmap, we only
need to recovery chunks that are flagged in the bitmap.

However if we choose to skip a chunk as it isn't flag, the code
currently skips the whole raid10-chunk, thus it might not recovery
some blocks that need recovering.

This patch fixes it.

In case that is confusing, it might help to understand that there
is a 'raid10 chunk size' which guides how data is distributed across
the devices, and a 'bitmap chunk size' which says how much data
corresponds to a single bit in the bitmap.

This bug only affects cases where the bitmap chunk size is smaller
than the raid10 chunk size.

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agomd/raid10: Don't call bitmap_cond_end_sync when we are doing recovery.
NeilBrown [Wed, 25 Feb 2009 02:18:47 +0000 (13:18 +1100)]
md/raid10: Don't call bitmap_cond_end_sync when we are doing recovery.

commit 78200d45cde2a79c0d0ae0407883bb264caa3c18 upstream.

For raid1/4/5/6, resync (fixing inconsistencies between devices) is
very similar to recovery (rebuilding a failed device onto a spare).
The both walk through the device addresses in order.

For raid10 it can be quite different.  resync follows the 'array'
address, and makes sure all copies are the same.  Recover walks
through 'device' addresses and recreates each missing block.

The 'bitmap_cond_end_sync' function allows the write-intent-bitmap
(When present) to be updated to reflect a partially completed resync.
It makes assumptions which mean that it does not work correctly for
raid10 recovery at all.

In particularly, it can cause bitmap-directed recovery of a raid10 to
not recovery some of the blocks that need to be recovered.

So move the call to bitmap_cond_end_sync into the resync path, rather
than being in the common "resync or recovery" path.

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agomd: avoid races when stopping resync.
NeilBrown [Wed, 25 Feb 2009 02:18:47 +0000 (13:18 +1100)]
md: avoid races when stopping resync.

commit 73d5c38a9536142e062c35997b044e89166e063b upstream.

There has been a race in raid10 and raid1 for a long time
which has only recently started showing up due to a scheduler changed.

When a sync_read request finishes, as soon as reschedule_retry
is called, another thread can mark the resync request as having
completed, so md_do_sync can finish, ->stop can be called, and
->conf can be freed.  So using conf after reschedule_retry is not
safe.

Similarly, when finishing a sync_write, calling md_done_sync must be
the last thing we do, as it allows a chain of events which will free
conf and other data structures.

The first of these requires action in raid10.c
The second requires action in raid1.c and raid10.c

Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoUSB: EHCI: slow down ITD reuse
Karsten Wiese [Mon, 9 Feb 2009 00:07:58 +0000 (16:07 -0800)]
USB: EHCI: slow down ITD reuse

commit 9aa09d2f8f4bc440d6db1c3414d4009642875240 upstream.

Currently ITDs are immediately recycled whenever their URB completes.
However, EHCI hardware can sometimes remember some ITD state.  This
means that when the ITD is reused before end-of-frame it may sometimes
cause the hardware to reference bogus state.

This patch defers reusing such ITDs by moving them into a new ehci member
cached_itd_list. ITDs resting in cached_itd_list are moved back into their
stream's free_list once scan_periodic() detects that the active frame has
elapsed.

This makes the snd_usb_us122l driver (in kernel since .28) work right
when it's hooked up through EHCI.

[ dbrownell@users.sourceforge.net: comment fixups ]

Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de>
Tested-by: Philippe Carriere <philippe-f.carriere@wanadoo.fr>
Tested-by: Federico Briata <federicobriata@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoUSB: option: add BenQ 3g modem information
Jesse Sung [Sat, 21 Feb 2009 05:13:45 +0000 (21:13 -0800)]
USB: option: add BenQ 3g modem information

commit 28fb66821f884870987a0b5ab064ef651d9f7c16 upstream.

This patch addes the BenQ 3g modem support to the option driver.

From: Jesse Sung <jsung@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoRDMA/nes: Don't allow userspace QPs to use STag zero
Faisal Latif [Thu, 12 Mar 2009 21:34:59 +0000 (14:34 -0700)]
RDMA/nes: Don't allow userspace QPs to use STag zero

commit c12e56ef6951f4fce1afe9ef6aab9243ea9a9b04 upstream.

STag zero is a special STag that allows consumers to access any bus
address without registering memory.  The nes driver unfortunately
allows STag zero to be used even with QPs created by unprivileged
userspace consumers, which means that any process with direct verbs
access to the nes device can read and write any memory accessible to
the underlying PCI device (usually any memory in the system).  Such
access is usually given for cluster software such as MPI to use, so
this is a local privilege escalation bug on most systems running this
driver.

The driver was using STag zero to receive the last streaming mode
data; to allow STag zero to be disabled for unprivileged QPs, the
driver now registers a special MR for this data.

Signed-off-by: Faisal Latif <faisal.latif@intel.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoWATCHDOG: rc32434_wdt: fix sections
Phil Sutter [Sun, 8 Feb 2009 15:44:42 +0000 (16:44 +0100)]
WATCHDOG: rc32434_wdt: fix sections

commit d9a8798c4bab5ccd40e45e011f668099cfb3eb83 upstream.

Fix init and exit sections.

Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoWATCHDOG: rc32434_wdt: fix watchdog driver
Phil Sutter [Sun, 8 Feb 2009 15:44:42 +0000 (16:44 +0100)]
WATCHDOG: rc32434_wdt: fix watchdog driver

commit 0af98d37e85e6958eb84987b1f60da3b54008317 upstream.

The existing driver code wasn't working. Neither the timeout was set
correctly, nor system reset was being triggered, as the driver seemed
to keep the WDT alive himself. There was also some unnecessary code.

Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoWATCHDOG: ks8695_wdt.c: 'CLOCK_TICK_RATE' undeclared
Alexey Dobriyan [Thu, 12 Feb 2009 10:42:41 +0000 (13:42 +0300)]
WATCHDOG: ks8695_wdt.c: 'CLOCK_TICK_RATE' undeclared

commit b02c387892fc6b3cc59c78ab2f79413d55f50190 upstream.

On arm-acs5k_tiny:

drivers/watchdog/ks8695_wdt.c:68: error: 'CLOCK_TICK_RATE' undeclared
(first use in this function)

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agortl8187: New USB ID's for RTL8187L
Larry Finger [Tue, 17 Feb 2009 20:31:12 +0000 (14:31 -0600)]
rtl8187: New USB ID's for RTL8187L

commit 046ee5d26ac91316a8ac0a29c0b33139dc9da20d upstream.

Add new USB ID codes. These come from two postings on forums and
mailing lists, and four are derived from the .inf that accompanies
the latest Realtek Windows driver for the RTL8187L.

Thanks to Viktor Ilijašić <viktor.ilijasic@gmail.com> and Xose Vazquez
Perez <xose.vazquez@gmail.com> for reporting these new ID's.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoUSB: cdc-acm: add usb id for motomagx phones
Dmitriy Taychenachev [Wed, 25 Feb 2009 04:36:51 +0000 (12:36 +0800)]
USB: cdc-acm: add usb id for motomagx phones

commit 155df65ae11dfc322214c6f887185929c809df1b upstream.

The Motorola MOTOMAGX phones (Z6, E8, Zn5 so far) are providing
combined ACM/BLAN USB configuration. Since it has Vendor Specific
class, the corresponding drivers (cdc-acm, zaurus) can't find it just
by interface info. This patch adds usb id so the cdc-acm driver can
properly handle this combined device.

Signed-off-by: Dmitriy Taychenachev <dimichxp@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoUSB: usb-storage: add IGNORE_RESIDUE flag for Genesys Logic adapters
Alan Stern [Mon, 23 Feb 2009 17:02:05 +0000 (12:02 -0500)]
USB: usb-storage: add IGNORE_RESIDUE flag for Genesys Logic adapters

commit 5126a2674ddac0804450f59da25a058cca629d38 upstream.

This patch (as1219) adds the IGNORE_RESIDUE flag to the unusual_devs
entries for Genesys Logic's USB-IDE adapter.  Although this device
usually gets the residue correct, there is one command crucial to the
operation of CD and DVD drives which it messes up.

Tested-by: Mike Lampard <mike@mtgambier.net>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoUSB: usb_get_string should check the descriptor type
Alan Stern [Fri, 20 Feb 2009 21:33:08 +0000 (16:33 -0500)]
USB: usb_get_string should check the descriptor type

commit 67f5a4ba9741fcef3f4db3509ad03565d9e33af2 upstream.

This patch (as1218) fixes a problem with a radio-control joystick used
in the "walkera 4#3" helicopter.  This device responds to the initial
Get-String-Descriptor request for string 0 (which is really the list
of supported languages) by sending its config descriptor!  The
usb_get_string() routine needs to check whether it got the right
type of descriptor.

Oddly enough, this sort of check is already present in
usb_get_descriptor().  The patch changes the error code from -EPROTO
to -ENODATA, because -EPROTO shows up in so many other contexts to
indicate a hardware failure rather than a firmware error.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Guillermo Jarabo <williamjap@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoSCSI: sd: revive sd_index_lock
Tejun Heo [Sat, 21 Feb 2009 02:04:45 +0000 (11:04 +0900)]
SCSI: sd: revive sd_index_lock

commit 4034cc68157bfa0b6622efe368488d3d3e20f4e6 upstream.

Commit f27bac2761cab5a2e212dea602d22457a9aa6943 which converted sd to
use ida instead of idr incorrectly removed sd_index_lock around id
allocation and free.  idr/ida do have internal locks but they protect
their free object lists not the allocation itself.  The caller is
responsible for that.  This missing synchronization led to the same id
being assigned to multiple devices leading to oops.

Reported and tracked down by Stuart Hayes of Dell.

Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoJFFS2: fix mount crash caused by removed nodes
Thomas Gleixner [Mon, 16 Feb 2009 20:29:31 +0000 (21:29 +0100)]
JFFS2: fix mount crash caused by removed nodes

commit 4c41bd0ec953954158f92bed5d3062645062b98e upstream.

At scan time we observed following scenario:

   node A inserted
   node B inserted
   node C inserted -> sets overlapped flag on node B

   node A is removed due to CRC failure -> overlapped flag on node B remains

   while (tn->overlapped)
     tn = tn_prev(tn);

   ==> crash, when tn_prev(B) is referenced.

When the ultimate node is removed at scan time and the overlapped flag
is set on the penultimate node, then nothing updates the overlapped
flag of that node. The overlapped iterators blindly expect that the
ultimate node does not have the overlapped flag set, which causes the
scan code to crash.

It would be a huge overhead to go through the node chain on node
removal and fix up the overlapped flags, so detecting such a case on
the fly in the overlapped iterators is a simpler and reliable
solution.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoSCSI: hptiop: Add new PCI device ID
HighPoint Linux Team [Thu, 12 Feb 2009 03:28:31 +0000 (11:28 +0800)]
SCSI: hptiop: Add new PCI device ID

commit b73a77494292b930642fbf87de3e3196593f7593 upstream.

Signed-off-by: HighPoint Linux Team <linux@highpoint-tech.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
8 years agoPCI quirk: enable MSI on 8132
Yinghai Lu [Wed, 18 Feb 2009 04:40:09 +0000 (20:40 -0800)]
PCI quirk: enable MSI on 8132

commit e0ae4f5503235ba4449ffb5bcb4189edcef4d584 upstream.

David reported that LSI SAS doesn't work with MSI.  It turns out that
his BIOS doesn't enable it, but the HT MSI 8132 does support HT MSI.
Add quirk to enable it

Reported-by: David Lang <david@lang.hm>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>