Age | Commit message (Collapse) | Author | Files | Lines |
|
Commit 6bfff31e77cfa1b13490337e5a4dbaa3407e83ac (libata: kill probe_ent
and related helpers) killed ata_device_add() but didn't remove references
to it from the libata developer's guide.
Commits 9363c3825ea9ad76561eb48a395349dd29211ed6 (libata: rename SFF
functions) and 5682ed33aae05d10a25c95633ef9d9c062825888 (libata: rename
SFF port ops) renamed the taskfile access methods but didn't update the
developer's guide. Commit c9f75b04ed5ed65a058d18a8a8dda50632a96de8
(libata: kill ata_noop_dev_select()) didn't update the developer's
guide as well.
The guide also refers to the long gone ata_pio_data_xfer_noirq(),
ata_pio_data_xfer(), and ata_mmio_data_xfer() -- replace those by
the modern ata_sff_data_xfer_noirq(), ata_sff_data_xfer(), and
ata_sff_data_xfer32().
Also, remove the reference to non-existant ata_port_stop()...
Signed-off-by: Sergei Shtylyov <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6
* 'slab-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6:
slub: Fix bad boundary check in init_kmem_cache_nodes()
|
|
Function init_kmem_cache_nodes is incorrect when checking upper limitation of
kmalloc_caches. The breakage was introduced by commit
91efd773c74bb26b5409c85ad755d536448e229c ("dma kmalloc handling fixes").
Acked-by: Christoph Lameter <[email protected]>
Signed-off-by: Pekka Enberg <[email protected]>
|
|
By setting "reset_type" to one of the following values, the default
software reset mechanism may be overidden. Here the possible values of
"reset_type":
1 - PPC4xx core reset
2 - PPC4xx chip reset
3 - PPC4xx system reset (default)
This will be used by a new PPC440SPe board port, which needs a "chip
reset" instead of the default "system reset" to be asserted.
Signed-off-by: Stefan Roese <[email protected]>
Cc: Josh Boyer <[email protected]>
Cc: Benjamin Herrenschmidt <[email protected]>
Acked-by: Josh Boyer <[email protected]>
Signed-off-by: Josh Boyer <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
KEYS: call_sbin_request_key() must write lock keyrings before modifying them
KEYS: Use RCU dereference wrappers in keyring key type code
KEYS: find_keyring_by_name() can gain access to a freed keyring
|
|
A defconfig for the IBM ISS 476 simulator
Signed-off-by: Dave Kleikamp <[email protected]>
Signed-off-by: Josh Boyer <[email protected]>
|
|
This is a trivial 4xx plaform that uses the new simple bsp from
Josh and is handy to use in simulators such as ISS or even Mambo
who don't properly implement most of the actual devices in the
SoC but really only the core.
Signed-off-by: Torez Smith <[email protected]>
Signed-off-by: Dave Kleikamp <[email protected]>
Signed-off-by: Josh Boyer <[email protected]>
|
|
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
workqueue: flush_delayed_work: keep the original workqueue for re-queueing
|
|
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6:
FEC: Fix kernel panic in fec_set_mac_address.
ipv6: Fix default multicast hops setting.
net: ep93xx_eth stops receiving packets
drivers/net/phy: micrel phy driver
dm9601: fix phy/eeprom write routine
ppp_generic: handle non-linear skbs when passing them to pppd
ppp_generic: pull 2 bytes so that PPP_PROTO(skb) is valid
net: fix compile error due to double return type in SOCK_DEBUG
net/usb: initiate sync sequence in sierra_net.c driver
net/usb: remove default in Kconfig for sierra_net driver
r8169: Fix rtl8169_rx_interrupt()
e1000e: Fix oops caused by ASPM patch.
net/sb1250: register mdio bus in probe
sctp: Fix skb_over_panic resulting from multiple invalid parameter errors (CVE-2010-1173) (v4)
p54pci: fix bugs in p54p_check_tx_ring
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
ALSA: hda: Fix 0 dB for Packard Bell models using Conexant CX20549 (Venice)
ALSA: hda - Add quirk for Dell Inspiron 19T using a Conexant CX20582
ALSA: take tu->qlock with irqs disabled
ALSA: hda: Use olpc-xo-1_5 quirk for Toshiba Satellite P500-PSPGSC-01800T
ALSA: hda: Use olpc-xo-1_5 quirk for Toshiba Satellite Pro T130-15F
ALSA: hda - fix array indexing while creating inputs for Cirrus codecs
ALSA: es968: fix wrong PnP dma index
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: joydev - allow binding to button-only devices
Input: elantech - ignore high bits in the position coordinates
Input: elantech - allow forcing Elantech protocol
Input: elantech - fix firmware version check
Input: ati_remote - add some missing devices from lirc_atiusb
Input: eeti_ts - cancel pending work when going to suspend
Input: Add support of Synaptics Clickpad device
Revert "Input: ALPS - add signature for HP Pavilion dm3 laptops"
Input: psmouse - ignore parity error for basic protocols
|
|
The raid6 recovery code should immediately drop back to the optimized
synchronous path when a p+q dma resource is not available. Otherwise we
run the non-optimized/multi-pass async code in sync mode.
Verified with raid6test (NDISKS=255)
Applies to kernels >= 2.6.32.
Cc: <[email protected]>
Acked-by: NeilBrown <[email protected]>
Reported-by: H. Peter Anvin <[email protected]>
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
476 requires an isync after loading MMU and debug related SPR's. Some of
these are in performance-critical paths and may need to be optimized, but
initially, we're playing it safe.
Signed-off-by: Torez Smith <[email protected]>
Signed-off-by: Dave Kleikamp <[email protected]>
Signed-off-by: Josh Boyer <[email protected]>
|
|
call_sbin_request_key() creates a keyring and then attempts to insert a link to
the authorisation key into that keyring, but does so without holding a write
lock on the keyring semaphore.
It will normally get away with this because it hasn't told anyone that the
keyring exists yet. The new keyring, however, has had its serial number
published, which means it can be accessed directly by that handle.
This was found by a previous patch that adds RCU lockdep checks to the code
that reads the keyring payload pointer, which includes a check that the keyring
semaphore is actually locked.
Without this patch, the following command:
keyctl request2 user b a @s
will provoke the following lockdep warning is displayed in dmesg:
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
security/keys/keyring.c:727 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
2 locks held by keyctl/2076:
#0: (key_types_sem){.+.+.+}, at: [<ffffffff811a5b29>] key_type_lookup+0x1c/0x71
#1: (keyring_serialise_link_sem){+.+.+.}, at: [<ffffffff811a6d1e>] __key_link+0x4d/0x3c5
stack backtrace:
Pid: 2076, comm: keyctl Not tainted 2.6.34-rc6-cachefs #54
Call Trace:
[<ffffffff81051fdc>] lockdep_rcu_dereference+0xaa/0xb2
[<ffffffff811a6d1e>] ? __key_link+0x4d/0x3c5
[<ffffffff811a6e6f>] __key_link+0x19e/0x3c5
[<ffffffff811a5952>] ? __key_instantiate_and_link+0xb1/0xdc
[<ffffffff811a59bf>] ? key_instantiate_and_link+0x42/0x5f
[<ffffffff811aa0dc>] call_sbin_request_key+0xe7/0x33b
[<ffffffff8139376a>] ? mutex_unlock+0x9/0xb
[<ffffffff811a5952>] ? __key_instantiate_and_link+0xb1/0xdc
[<ffffffff811a59bf>] ? key_instantiate_and_link+0x42/0x5f
[<ffffffff811aa6fa>] ? request_key_auth_new+0x1c2/0x23c
[<ffffffff810aaf15>] ? cache_alloc_debugcheck_after+0x108/0x173
[<ffffffff811a9d00>] ? request_key_and_link+0x146/0x300
[<ffffffff810ac568>] ? kmem_cache_alloc+0xe1/0x118
[<ffffffff811a9e45>] request_key_and_link+0x28b/0x300
[<ffffffff811a89ac>] sys_request_key+0xf7/0x14a
[<ffffffff81052c0b>] ? trace_hardirqs_on_caller+0x10c/0x130
[<ffffffff81394fb9>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
Signed-off-by: David Howells <[email protected]>
Signed-off-by: James Morris <[email protected]>
|
|
The keyring key type code should use RCU dereference wrappers, even when it
holds the keyring's key semaphore.
Reported-by: Vegard Nossum <[email protected]>
Signed-off-by: David Howells <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Signed-off-by: James Morris <[email protected]>
|
|
find_keyring_by_name() can gain access to a keyring that has had its reference
count reduced to zero, and is thus ready to be freed. This then allows the
dead keyring to be brought back into use whilst it is being destroyed.
The following timeline illustrates the process:
|(cleaner) (user)
|
| free_user(user) sys_keyctl()
| | |
| key_put(user->session_keyring) keyctl_get_keyring_ID()
| || //=> keyring->usage = 0 |
| |schedule_work(&key_cleanup_task) lookup_user_key()
| || |
| kmem_cache_free(,user) |
| . |[KEY_SPEC_USER_KEYRING]
| . install_user_keyrings()
| . ||
| key_cleanup() [<= worker_thread()] ||
| | ||
| [spin_lock(&key_serial_lock)] |[mutex_lock(&key_user_keyr..mutex)]
| | ||
| atomic_read() == 0 ||
| |{ rb_ease(&key->serial_node,) } ||
| | ||
| [spin_unlock(&key_serial_lock)] |find_keyring_by_name()
| | |||
| keyring_destroy(keyring) ||[read_lock(&keyring_name_lock)]
| || |||
| |[write_lock(&keyring_name_lock)] ||atomic_inc(&keyring->usage)
| |. ||| *** GET freeing keyring ***
| |. ||[read_unlock(&keyring_name_lock)]
| || ||
| |list_del() |[mutex_unlock(&key_user_k..mutex)]
| || |
| |[write_unlock(&keyring_name_lock)] ** INVALID keyring is returned **
| | .
| kmem_cache_free(,keyring) .
| .
| atomic_dec(&keyring->usage)
v *** DESTROYED ***
TIME
If CONFIG_SLUB_DEBUG=y then we may see the following message generated:
=============================================================================
BUG key_jar: Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xffff880197a7e200-0xffff880197a7e200. First byte 0x6a instead of 0x6b
INFO: Allocated in key_alloc+0x10b/0x35f age=25 cpu=1 pid=5086
INFO: Freed in key_cleanup+0xd0/0xd5 age=12 cpu=1 pid=10
INFO: Slab 0xffffea000592cb90 objects=16 used=2 fp=0xffff880197a7e200 flags=0x200000000000c3
INFO: Object 0xffff880197a7e200 @offset=512 fp=0xffff880197a7e300
Bytes b4 0xffff880197a7e1f0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
Object 0xffff880197a7e200: 6a 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b jkkkkkkkkkkkkkkk
Alternatively, we may see a system panic happen, such as:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000001
IP: [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
PGD 6b2b4067 PUD 6a80d067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/kernel/kexec_crash_loaded
CPU 1
...
Pid: 31245, comm: su Not tainted 2.6.34-rc5-nofixed-nodebug #2 D2089/PRIMERGY
RIP: 0010:[<ffffffff810e61a3>] [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
RSP: 0018:ffff88006af3bd98 EFLAGS: 00010002
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88007d19900b
RDX: 0000000100000000 RSI: 00000000000080d0 RDI: ffffffff81828430
RBP: ffffffff81828430 R08: ffff88000a293750 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000100000 R12: 00000000000080d0
R13: 00000000000080d0 R14: 0000000000000296 R15: ffffffff810f20ce
FS: 00007f97116bc700(0000) GS:ffff88000a280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000001 CR3: 000000006a91c000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process su (pid: 31245, threadinfo ffff88006af3a000, task ffff8800374414c0)
Stack:
0000000512e0958e 0000000000008000 ffff880037f8d180 0000000000000001
0000000000000000 0000000000008001 ffff88007d199000 ffffffff810f20ce
0000000000008000 ffff88006af3be48 0000000000000024 ffffffff810face3
Call Trace:
[<ffffffff810f20ce>] ? get_empty_filp+0x70/0x12f
[<ffffffff810face3>] ? do_filp_open+0x145/0x590
[<ffffffff810ce208>] ? tlb_finish_mmu+0x2a/0x33
[<ffffffff810ce43c>] ? unmap_region+0xd3/0xe2
[<ffffffff810e4393>] ? virt_to_head_page+0x9/0x2d
[<ffffffff81103916>] ? alloc_fd+0x69/0x10e
[<ffffffff810ef4ed>] ? do_sys_open+0x56/0xfc
[<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
Code: 0f 1f 44 00 00 49 89 c6 fa 66 0f 1f 44 00 00 65 4c 8b 04 25 60 e8 00 00 48 8b 45 00 49 01 c0 49 8b 18 48 85 db 74 0d 48 63 45 18 <48> 8b 04 03 49 89 00 eb 14 4c 89 f9 83 ca ff 44 89 e6 48 89 ef
RIP [<ffffffff810e61a3>] kmem_cache_alloc+0x5b/0xe9
This problem is that find_keyring_by_name does not confirm that the keyring is
valid before accepting it.
Skipping keyrings that have been reduced to a zero count seems the way to go.
To this end, use atomic_inc_not_zero() to increment the usage count and skip
the candidate keyring if that returns false.
The following script _may_ cause the bug to happen, but there's no guarantee
as the window of opportunity is small:
#!/bin/sh
LOOP=100000
USER=dummy_user
/bin/su -c "exit;" $USER || { /usr/sbin/adduser -m $USER; add=1; }
for ((i=0; i<LOOP; i++))
do
/bin/su -c "echo '$i' > /dev/null" $USER
done
(( add == 1 )) && /usr/sbin/userdel -r $USER
exit
Note that the nominated user must not be in use.
An alternative way of testing this may be:
for ((i=0; i<100000; i++))
do
keyctl session foo /bin/true || break
done >&/dev/null
as that uses a keyring named "foo" rather than relying on the user and
user-session named keyrings.
Reported-by: Toshiyuki Okajima <[email protected]>
Signed-off-by: David Howells <[email protected]>
Tested-by: Toshiyuki Okajima <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Signed-off-by: James Morris <[email protected]>
|
|
The 47x core's MCSR varies from 44x, so it needs it's own machine check
handler.
Signed-off-by: Dave Kleikamp <[email protected]>
Signed-off-by: Josh Boyer <[email protected]>
|
|
This patch adds the base support for the 476 processor. The code was
primarily written by Ben Herrenschmidt and Torez Smith, but I've been
maintaining it for a while.
The goal is to have a single binary that will run on 44x and 47x, but
we still have some details to work out. The biggest is that the L1 cache
line size differs on the two platforms, but it's currently a compile-time
option.
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Torez Smith <[email protected]>
Signed-off-by: Dave Kleikamp <[email protected]>
Signed-off-by: Josh Boyer <[email protected]>
|
|
The 47x platform supports multiple cores and shares code with 44x.
Break out code that is common for initializing the primary and secondary
cpus into a function which can be called for both.
Signed-off-by: Dave Kleikamp <[email protected]>
Signed-off-by: Josh Boyer <[email protected]>
|
|
This patch adds a marker to the exception stack frame to aid in debugging.
It's already inserted on other platforms and xmon recognizes it and
identifies exception frames when showing stack traces.
Signed-off-by: Torez Smith <[email protected]>
Signed-off-by: Dave Kleikamp <[email protected]>
Signed-off-by: Josh Boyer <[email protected]>
|
|
|
|
BugLink: https://launchpad.net/bugs/541802
The OR's hardware distorts at PCM 100% because it does not correspond to
0 dB. Fix this in patch_cxt5045() for all Packard Bell models.
Reported-by: Valombre
Cc: <[email protected]>
Signed-off-by: Daniel T Chen <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
Add a quirk for all-in-one computer Dell Inspiron One 19 Touch to have proper
HP and Mic support.
Signed-off-by: Anisse Astier <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
We should disable irqs when we take the tu->qlock because it is used in
the irq handler. The only place that doesn't is
snd_timer_user_ccallback(). Most of the time snd_timer_user_ccallback()
is called with interrupts disabled but the the first ti->ccallback()
call in snd_timer_notify1() has interrupts enabled.
This was caught by lockdep which generates the following message:
> =================================
> [ INFO: inconsistent lock state ]
> 2.6.34-rc5 #5
> ---------------------------------
> inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> dolphin/4003 [HC1[1]:SC0[0]:HE0:SE1] takes:
> (&(&tu->qlock)->rlock){?.+...}, at: [<f84ec472>] snd_timer_user_tinterrupt+0x28/0x132 [snd_timer]
> {HARDIRQ-ON-W} state was registered at:
> [<c1048de9>] __lock_acquire+0x654/0x1482
> [<c1049c73>] lock_acquire+0x5c/0x73
> [<c125ac3e>] _raw_spin_lock+0x25/0x34
> [<f84ec370>] snd_timer_user_ccallback+0x55/0x95 [snd_timer]
> [<f84ecc4b>] snd_timer_notify1+0x53/0xca [snd_timer]
Reported-by: Stefan Richter <[email protected]>
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
Fix memory corruption that sometimes result in kernel panic.
Signed-off-by: Mattias Walström <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
BugLink: https://launchpad.net/bugs/549267
The OR verified that using the olpc-xo-1_5 model quirk allows the
headphones to be audible when inserted into the jack. Capture was
also verified to work correctly.
Reported-by: Richard Gagne
Tested-by: Richard Gagne
Cc: <[email protected]>
Signed-off-by: Daniel T Chen <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
BugLink: https://launchpad.net/bugs/573284
The OR verified that using the olpc-xo-1_5 model quirk allows the
headphones to be audible when inserted into the jack. Capture was
also verified to work correctly.
Reported-by: Andy Couldrake <[email protected]>
Tested-by: Andy Couldrake <[email protected]>
Cc: <[email protected]>
Signed-off-by: Daniel T Chen <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
This fixes a problem where cards show up as only having a single mixer
element, suppressing all sound output.
Signed-off-by: Brian J. Tarricone <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
* 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/radeon/kms/legacy: only enable load detection property on DVI-I
drm/radeon/kms: fix panel scaling adjusted mode setup
drivers/gpu/drm/drm_sysfs.c: sysfs files error handling
drivers/gpu/drm/radeon/radeon_atombios.c: range check issues
gpu: vga_switcheroo, fix lock imbalance
drivers/gpu/drm/drm_memory.c: fix check for end of loop
drivers/gpu/drm/via/via_video.c: fix off by one issue
drm/radeon/kms/agp The wrong AGP chipset can cause a NULL pointer dereference
drm/radeon/kms: r300 fix CS checker to allow zbuffer-only fastfill
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip:
powernow-k8: Fix frequency reporting
x86: Fix parse_reservetop() build failure on certain configs
x86: Fix NULL pointer access in irq_force_complete_move() for Xen guests
x86: Fix 'reservetop=' functionality
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
KEYS: Fix RCU handling in key_gc_keyring()
KEYS: Fix an RCU warning in the reading of user keys
|
|
key_gc_keyring() needs to either hold the RCU read lock or hold the keyring
semaphore if it's going to scan the keyring's list. Given that it only needs
to read the key list, and it's doing so under a spinlock, the RCU read lock is
the thing to use.
Furthermore, the RCU check added in e7b0a61b7929632d36cf052d9e2820ef0a9c1bfe is
incorrect as holding the spinlock on key_serial_lock is not grounds for
assuming a keyring's pointer list can be read safely. Instead, a simple
rcu_dereference() inside of the previously mentioned RCU read lock is what we
want.
Reported-by: Serge E. Hallyn <[email protected]>
Signed-off-by: David Howells <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Acked-by: "Paul E. McKenney" <[email protected]>
Signed-off-by: James Morris <[email protected]>
|
|
Fix an RCU warning in the reading of user keys:
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
security/keys/user_defined.c:202 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by keyctl/3637:
#0: (&key->sem){+++++.}, at: [<ffffffff811a80ae>] keyctl_read_key+0x9c/0xcf
stack backtrace:
Pid: 3637, comm: keyctl Not tainted 2.6.34-rc5-cachefs #18
Call Trace:
[<ffffffff81051f6c>] lockdep_rcu_dereference+0xaa/0xb2
[<ffffffff811aa55f>] user_read+0x47/0x91
[<ffffffff811a80be>] keyctl_read_key+0xac/0xcf
[<ffffffff811a8a06>] sys_keyctl+0x75/0xb7
[<ffffffff81001eeb>] system_call_fastpath+0x16/0x1b
Signed-off-by: David Howells <[email protected]>
Acked-by: Serge Hallyn <[email protected]>
Signed-off-by: James Morris <[email protected]>
|
|
DVI-D doesn't have analog. This matches the avivo behavior.
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
This should duplicate exactly what the ddx does for both
legacy and avivo.
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jlbec/ocfs2:
ocfs2: Avoid a gcc warning in ocfs2_wipe_inode().
ocfs2: Avoid direct write if we fall back to buffered I/O
ocfs2_dlmfs: Fix math error when reading LVB.
ocfs2: Update VFS inode's id info after reflink.
ocfs2: potential ERR_PTR dereference on error paths
ocfs2: Add directory entry later in ocfs2_symlink() and ocfs2_mknod()
ocfs2: use OCFS2_INODE_SKIP_ORPHAN_DIR in ocfs2_mknod error path
ocfs2: use OCFS2_INODE_SKIP_ORPHAN_DIR in ocfs2_symlink error path
ocfs2: add OCFS2_INODE_SKIP_ORPHAN_DIR flag and honor it in the inode wipe code
ocfs2: Reset status if we want to restart file extension.
ocfs2: Compute metaecc for superblocks during online resize.
ocfs2: Check the owner of a lockres inside the spinlock
ocfs2: one more warning fix in ocfs2_file_aio_write(), v2
ocfs2_dlmfs: User DLM_* when decoding file open flags.
|
|
The x86_64 call_rwsem_wait() treats the active state counter part of the
R/W semaphore state as being 16-bit when it's actually 32-bit (it's half
of the 64-bit state). It should do "decl %edx" not "decw %dx".
Signed-off-by: David Howells <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging
* 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
i2c-core: Use per-adapter userspace device lists
i2c: Fix probing of FSC hardware monitoring chips
i2c-core: Erase pointer to clientdata on removal
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
perf: Fix resource leak in failure path of perf_event_open()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
* 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
rcu: Fix RCU lockdep splat on freezer_fork path
rcu: Fix RCU lockdep splat in set_task_cpu on fork path
mutex: Don't spin when the owner CPU is offline or other weird cases
|
|
Using a single list for all userspace devices leads to a dead lock
on multiplexed buses in some circumstances (mux chip instantiated
from userspace). This is solved by using a separate list for each
bus segment.
Signed-off-by: Jean Delvare <[email protected]>
Acked-by: Michael Lawnick <[email protected]>
|
|
Some FSC hardware monitoring chips (Syleus at least) doesn't like
quick writes we typically use to probe for I2C chips. Use a regular
byte read instead for the address they live at (0x73). These are the
only known chips living at this address on PC systems.
For clarity, this fix should not be needed for kernels 2.6.30 and
later, as we started instantiating the hwmon devices explicitly based
on DMI data. Still, this fix is valuable in the following two cases:
* Support for recent FSC chips on older kernels. The DMI-based device
instantiation is more difficult to backport than the device support
itself.
* Case where the DMI-based device instantiation fails, whatever the
reason. We fall back to probing in that case, so it should work.
This fixes kernel bug #15634:
https://bugzilla.kernel.org/show_bug.cgi?id=15634
Signed-off-by: Jean Delvare <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Cc: [email protected]
|
|
After discovering that a lot of i2c-drivers leave the pointer to their
clientdata dangling, it was decided to let the core handle this issue.
It is assumed that the core may access the private data after remove()
as there are no guarantees for the lifetime of such pointers anyhow (see
thread starting at http://lkml.org/lkml/2010/3/21/68)
Signed-off-by: Wolfram Sang <[email protected]>
Signed-off-by: Jean Delvare <[email protected]>
|
|
Dance pads don't have an axis, so allow this kind of controllers
to be used via legacy joystick interface.
Signed-off-by: Christoph Fritz <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
As per RFC 3493 the default multicast hops setting
for a socket should be "1" just like ipv4.
Ironically we have a IPV6_DEFAULT_MCASTHOPS macro
it just wasn't being used.
Reported-by: Elliot Hughes <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
In older versions of the elantech hardware/firmware those bits always
were unset, so it didn't actually matter, but newer versions seem to
use those high bits for something else, screwing up the coordinates
we report to the input layer for those devices.
Signed-off-by: Florian Ragwitz <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Apparently hardware vendors now ship elantech touchpads with different version
magic. This options allows for them to be tested easier with the current driver
in order to add their magic to the whitelist later.
Signed-off-by: Florian Ragwitz <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
The check determining whether device should use 4- or 6-byte packets
was trying to compare firmware with 2.48, but was failing on majors
greater than 2. The new check ensures that versions like 4.1 are
checked properly.
Signed-off-by: Florian Ragwitz <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
The (out-of-tree) lirc_atiusb driver has a much longer list of devices
it supports. Some of them look like they may just be guesses at possible
device IDs, but a few are definitely confirmed devices. This adds the
nVidia-branded RF receiver and the X10 Lola Wireless Video Sender device
(which contains an RF receiver) to the list of devices in ati_remote.
Signed-off-by: Jarod Wilson <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
|
|
Receiving small packet(s) in a fast pace leads to not receiving any
packets at all after some time.
After ethernet packet(s) arrived the receive descriptor is incremented
by the number of frames processed. If another packet arrives while
processing, this is processed in another call of ep93xx_rx. This
second call leads that too many receive descriptors getting released.
This fix increments, even in these case, the right number of processed
receive descriptors.
Signed-off-by: Stefan Agner <[email protected]>
Acked-by: Lennert Buytenhek <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|