| Age | Commit message (Collapse) | Author |
|---|
|
[ Upstream commit 85821c906cf3563a00a3d98fa380a2581a7a5ff1 ]
As there's no point in adding a fixed-fudge value (originally 5
seconds), honor the user settings only. We also remove the
driver's dead-callback get_rport_dev_loss_tmo function
(qla2x00_get_rport_loss_tmo()).
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit 5f3a9a207f1fccde476dd31b4c63ead2967d934f ]
Signed-off-by: Seokmann Ju <seokmann.ju@qlogic.com>
Signed-off-by: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Already in Linus' tree:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b25b791b13aaa336b56c4f9bd417ff126363f80b
Fix a NULL pointer dereference that happened when calling
i2c_new_probed_device on one of the addresses for which we use byte
reads instead of quick write for detection purpose (that is: 0x30-0x37
and 0x50-0x5f).
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 77332894c21165404496c56763d7df6c15c4bb09 upstream
The magic write to register 0x82 will often cause PCI config space on
my 8168 (PCI ID 10ec:8168, revision 2. mounted in an LG P300 laptop)
to be filled with ones during driver load, and thus breaking NIC
operation until reboot. If it does not happen on first driver load it
can easily be reproduced by unloading and loading the driver a few
times.
The magic write was added long ago by this commit:
Author: François Romieu <romieu@fr.zoreil.com>
Date: Sat Jan 10 06:00:46 2004 -0500
[netdrvr r8169] Merge of changes done by Realtek to rtl8169_init_one():
- phy capability settings allows lower or equal capability as suggested
in Realtek's changes;
- I/O voodoo;
- no need to s/mdio_write/RTL8169_WRITE_GMII_REG/;
- s/rtl8169_hw_PHY_config/rtl8169_hw_phy_config/;
- rtl8169_hw_phy_config(): ad-hoc struct "phy_magic" to limit duplication
of code (yep, the u16 -> int conversions should work as expected);
- variable renames and whitepace changes ignored.
As the 8168 wasn't supported by that version this patch simply removes
the bogus write from mac versions <= RTL_GIGA_MAC_VER_06.
[The change above makes sense for the 8101/8102 too -- Ueimor]
Signed-off-by: Marcus Sundberg <marcus@ingate.com>
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Karsten Keil <kkeil@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Commit efc491814308f89d5ef6c4fe19ae4552a67d4132 upstream
radeon: misc corrections
I have a new PCI-E radeon RV380 series card (PCI device ID 5b64) that
hangs in my sparc64 boxes when the init scripts set the font. The problem
goes away if I disable acceleration.
I haven't figured out that bug yet, but along the way I found some
corrections to make based upon some auditing.
1) The RB2D_DC_FLUSH_ALL value used by the kernel fb driver
and the XORG video driver differ. I've made the kernel
match what XORG is using.
2) In radeonfb_engine_reset() we have top-level code structure
that roughly looks like:
if (family is 300, 350, or V350)
do this;
else
do that;
...
if (family is NOT 300, OR
family is NOT 350, OR
family is NOT V350)
do another thing;
this last conditional makes no sense, is always true,
and obviously was likely meant to be "family is NOT
300, 350, or V350". So I've made the code match the
intent.
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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>
|
|
commit 5c742b45dd5fbbb6cf74d3378341704f4b23c5e8 upstream
In the old acer_acpi, I discovered that on some of the newer AMW0 laptops
that supported the WMID methods, they don't work properly for setting the
wireless and bluetooth values.
So for the AMW0 V2 laptops, we want to use both the 'old' AMW0 and the
'new' WMID methods for setting wireless & bluetooth to guarantee we always
enable it.
This was fixed in acer_acpi some time ago, but I forgot to port the patch
over to acer-wmi when it was merged.
(Without this patch, early AMW0 V2 laptops such as the Aspire 5040 won't
work with acer-wmi, where-as they did with the old acer_acpi).
AK: fix compilation
Signed-off-by: Carlos Corbacho <carlos@strangeworlds.co.uk>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 938bb03d188a1e688fb0bcae49788f540193e80a uptream
Aesthetic regards aside, commit e8e7b9eb11c34ee18bde8b7011af41938d1ad667
still leaves a bug in the error message, because it uses the unconverted
big-endian value for printk.
Fix this by using a local variable in machine byte order. The result is
correct, more readable, and also produces slightly shorter code on i386.
Signed-off-by: Petr Tesarik <ptesarik@suse.cz>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@kernel.org>
Acked-by: Borislav Petkov <petkovbb@gmail.com>
[bart: __u32 -> u32]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 5ede40f87957c6ededf9284c8339722a97b9dfb6 upstream
I broke an error path with d03c21ec0be7787ff6b75dcf56c0e96209ccbfbd,
sorry about that.
The machine will crash if the i2c_attach_client() or maven_init_client()
calls fail, although nobody has yet reported this happening.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Petr Vandrovec <VANDROVE@vc.cvut.cz>
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>
|
|
commit 969830b2fedf8336c41d6195f49d250b1e166ff8 upstream
Some chips appear to have the 2D engine hang during screen redraw,
typically in a sequence of copyarea operations. This appear to be
solved by adding a flush of the engine destination pixel cache
and waiting for the engine to be idle before issuing the accel
operation. The performance impact seems to be fairly small.
Here is a trace on an RV370 (PCI device ID 0x5b64), it records the
RBBM_STATUS register, then the source x/y, destination x/y, and
width/height used for the copy:
----------------------------------------
radeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10]
radeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10]
radeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10]
radeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10]
radeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10]
radeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10]
radeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10]
radeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10]
radeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10]
radeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10]
radeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10]
----------------------------------------
When things are going fine the copies complete before the next ROP is
even issued, but all of a sudden the 2D unit becomes active (bit 17 in
RBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit
14) are set as well. The FIFO begins to backup until it becomes full.
What happens next is the radeon_fifo_wait() times out, and we access
the chip illegally leading to a bus error which usually wedges the
box. None of this makes it to the console screen, of course :-)
radeon_fifo_wait() should be modified to reset the accelerator when
this timeout happens instead of programming the chip anyways.
----------------------------------------
radeonfb: FIFO Timeout !
ERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0)
ERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601]
ERROR(0): TPC<radeonfb_copyarea+0xfc/0x248>
ERROR(0): M_SYND(0), E_SYND(0), Privileged
ERROR(0): Highest priority error (0000080000000000) "Bus error response from system bus"
ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000]
ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000]
ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\
ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000]
ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000]
ERROR(0): E-cache idx[800e40] tag[000000000e049f4c]
ERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000]
Ker:xnel panic - not syncing: Irrecoverable deferred error trap.
----------------------------------------
Another quirk is that these copyarea calls will not happen until the
first drivers/char/vt.c:redraw_screen() occurs. This will only happen
if you 1) VC switch or 2) run "consolechars" or 3) unblank the screen.
This seems to happen because until a redraw_screen() the screen scrolling
method used by fbcon is not finalized yet. I've seen this with other fb
drivers too.
So if all you do is boot straight into X you will never see this bug on
the relevant chips.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
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>
|
|
commit dd07428b44944b42f699408fe31af47977f1e733 upstream
Add PCI device ID for new adapter models.
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>
|
|
commit e8bac9e0647dd04c83fd0bfe7cdfe2f6dfb100d0 upstream
The class_device->device conversion is causing an oops in revalidate
because it's assuming that the device_for_each_child iterator will only
return struct scsi_device children. The conversion made all former
class_devices children of the device as well, so this assumption is
broken. Fix it.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 671a99c8eb2f1dde08ac5538d8cd912047c61ddf upstream
There are a few kerneloops.org reports like this one:
http://www.kerneloops.org/search.php?search=ses_match_to_enclosure
That seem to imply we're running off the end of the VPD inquiry data
(although at 512 bytes, it should be long enough for just about
anything). we should be using correctly sized buffers anyway, so put
those in and hope this oops goes away.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a00c3cadc2bf50b3c925acdb3d0e5789b1650498 upstream
The Patch adds support for Luminance Stellaris Evaluation/Development
Kits (FTDI 2232C based).
The PIDs were missing.
Successfully tested with a Stellaris LM3S8962 Evaluation kit.
Signed-off-by: Frederik Kriewitz <frederik@kriewitz.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit b5894a500127fce1db1309db5f9ca8b77a2ac266 upstream
USB product id registration for the ELV HS485 USB adapter (www.elv.de) to
their home automation bus system. Applies to 2.6.26.
Signed-off-by: Andre Schenk <andre@melior.s.bawue.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 8c809681ba0289afd0ed7bbb63679a0568dd441d upstream
USB ID 4348:5523 is handled by the ch341 driver. Remove it from the
pl2023 driver.
Reverts 002e8f2c80c6be76bb312940bc278fc10b2b2487.
Signed-off-by: Tollef Fog Heen <tfheen@err.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 0282b7f2a874e72c18fcd5a112ccf67f71ba7f5c upstream
This patch (as1121) fixes a bug in the USB serial core. When a device
is unregistered, the core will give back its minors -- even if the
device hasn't been assigned any!
The patch reserves the highest minor value (255) to mean that no minor
was assigned. It also removes some dead code and does a small style
fixup.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 368ee6469c327364ea10082a348f91c1f5ba47f7 upstream
This patch (as1115) adds unusual_devs entries with the IGNORE_RESIDE
flag for the iRiver T10 and the Simple Tech/Datafab CF+SM card
reader. Apparently these devices provide reasonable residue values
for READ and WRITE operations, but not for others like INQUIRY or READ
CAPACITY.
This fixes the iRiver T10 problem reported in Bugzilla #11125.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit b9a097f26e55968cbc52e30a4a2e73d32d7604ce upstream
usb-storage: quirk around v1.11 firmware on Nikon D40
https://bugzilla.redhat.com/show_bug.cgi?id=454028
Just as in earlier firmware versions, we need to perform this
quirk for the latest version too.
Speculatively do the entry for the D80 too, as they seem to
have the same firmware problems historically.
Signed-off-by: Dave Jones <davej@redhat.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 66d715c95a39e84cd25204a665915621457d9691 upstream
It seems VT3336 can't do msi either as with its bro 3351. Disable it.
Reported in the following SUSE bug.
https://bugzilla.novell.com/show_bug.cgi?id=300001
Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
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>
|
|
commit d1f114d12bb4db3147e1b1342ae31083c5a79c84 upstream
This patch (as1097) fixes a bug in the remote-wakeup handling in
ehci-hcd. The driver currently does not keep track of whether the
change-suspend feature is enabled for each port; the feature is
automatically reset the first time it is read. But recent changes to
the hub driver require that the feature be read at least twice in
order to work properly.
A bit-vector is added for storing the change-suspend feature values.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 90d95ef617a535a8832bdcb8dee07bf591e5dd82 upstream
On some boxes the touchpad needs to be reinitialized after resume to make
it function again. This fixes bugzilla #10825.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2 upstream
Fix the problem that thermal_get_temp returns the cached value,
which causes the temperature in generic thermal never updates.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a39a2d7c72b358c6253a2ec28e17b023b7f6f41c upstream
My laptop thinks that it's a good idea to give -73C as the critical
CPU temperature.... which isn't the best thing since it causes a shutdown
right at bootup.
Temperatures below freezing are clearly invalid critical thresholds
so just reject these as such.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Commit 6844e63a9458d15b4437aa467c99128d994b0f6c
Hardware encryption doesn't work yet so lets use software
encryption for now.
Changes-licensed-under: 3-Clause-BSD
Signed-off-by: Luis R. Rodriguez <mcgrof@winlab.rutgers.edu>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Jiri Benc <jbenc@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 7efd52a407bed6a2b02015b8ebbff7beba155392 upstream
If acpi_install_notify_handler() for a bay device fails, the bay driver is
superfluous. Most likely, another driver (like libata) is already caring
about this device anyway. Furthermore,
register_hotplug_dock_device(acpi_handle) from the dock driver must not be
called twice with the same handler. This would result in an endless loop
consuming 100% of CPU. So clean up and exit.
Signed-off-by: Holger Macht <hmacht@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 0376bce7b0659fe1e80d045860087072583ab93f upstream.
Acer Aspire 1360 needs to be added to nomux blacklist, otherwise its
touchpad misbehaves.
Reported-by: Clark Tompsett <clarkt@cnsp.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 3f79b1e94002791a42837a46b5817e87a0ac0873 upstream
Reported-by: Hans Aschauer <Hans.Aschauer@web.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Commit efd5184646d5d400fc538d093e9a0bec22a75551 upstream
Fujitsu Siemens Amilo Pro V2030 needs nomux table entry, in addition to
already existing entry for V2010 model (note that Fujitsu-Siemens changed
the capitalization in the DMI data for product).
Tested-by: Jiri Mleziva <jmleziva@tiscali.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 5b5b43d0b32ea586036638288c31179f00de5443 upstream
Gericom Bellagio needs to be added to nomux blacklist, otherwise its
touchpad misbehaves.
Reported-by: Roland Kletzing <roland.kletzing@materna.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit c3a34f4390396a4bede3f8b7bcc5153f50b974bb upstream
This patch introduces i8042_dmi_nopnp_table to make it possible to perform
DMI matches for systems that need 'i8042.nopnp' to work correctly, and
introduces such an entry for Intel D845PESV -- this system doesn't
detect PS2 mouse reliably without this option, as reported by Robert
Lewis.
[dtor@mail.ru - make it compile if CONFIG_PNP is off - reported
by Randy Dunlap]
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 2f6a77d56523c14651236bc401a99b0e2aca2fdd upstream
There are systems that fail in i8042_resume() with
i8042: Can't write CTR to resume
as i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR) fails even though the
controller claimed itself to be ready before.
One retry after failing write fixes the problems on the failing systems.
Reported-by: Helmut Schaa <hschaa@novell.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 483d8876f75aa5707a646442377051f1b90db206 upstream
Add an include <asm/time.h> statement for get_tb().
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Cc: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 69cd39e94669e2994277a29249b6ef93b088ddbb upstream
Newer Dell CERC firmware (>= 6.62) implement a random deletion handling
compatible with the legacy megaraid driver. The legacy handling shifted
the target ID by 0x80 only for I/O commands (READ/WRITE/etc), whereas
megaraid_mbox shifts the target ID always if random deletion is supported.
The resulted in megaraid_mbox sending an INQUIRY to the wrong channel, and
not finding any devices, obviously.
So we disable the random deletion support if the offending firmware is
found.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=6695
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Bo Yang <Bo.Yang@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 256b152b005e319f985f50f2a910a75ba0def74f upstream
MSI is a nice thing, but we cannot enable it without changing the
interrupt handler. If we do it, we break MSI capable hardware,
specifically AR5006 chipset.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 4104863fb4a724723d1d5f3cba9d3c5084087e45 upstream
The mutex is released on a successful return, so it would seem that it
should be released on an error return as well.
The semantic patch finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
expression l;
@@
mutex_lock(l);
.. when != mutex_unlock(l)
when any
when strict
(
if (...) { ... when != mutex_unlock(l)
+ mutex_unlock(l);
return ...;
}
|
mutex_unlock(l);
)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a1531acd43310a7e4571d52e8846640667f4c74b upstream
Ingo Molnar provided a fix to not call _PPC at processor driver
initialization time in "[PATCH] ACPI: fix cpufreq regression" (git
commit e4233dec749a3519069d9390561b5636a75c7579)
But it can still happen that _PPC is called at processor driver
initialization time.
This patch should make sure that this is not possible anymore.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.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>
|
|
commit bb5d10ac8cc315d53306963001fe650d88a1cbb2 upstream
The ixgbe driver was untested with device ID 8086:10c8 but still advertises
support. Currently if this device is present in the system when the driver
is loaded, the system will panic.
Remove this device ID until full support can be tested with available
hardware. This patch is necessary for 2.6.24, 2.6.25 and 2.6.26
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 9a7867e1b34c3575e7e76a05c0c54c6edbdae2a4 upstream
The block transfer routine in the mpc52xx psc spi driver misinterpret
the datasheet. According to the processor datasheet the chipselect is
held as long as the EOF is not written.
Theoretically blocks of any sizes can be transferred in this way. The
old routine however writes an EOF after every word, which has the size
of size_of_word. This makes the transfer slow.
Also fixed some duplicate code.
Signed-off-by: Luotao Fu <l.fu@pengutronix.de>
Signed-off-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>
|
|
commit 15fe982e429e0e6b7466719acb6cfd9dbfe47f0c upstream
ahci: retry enabling AHCI a few times before spitting out WARN_ON()
Some chips need AHCI_EN set more than once to actually set it. Try a
few times before giving up and spitting out WARN_ON().
Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Peer Chen <pchen@nvidia.com>
Cc: Volker Armin Hemmann <volker.armin.hemmann@tu-clausthal.de>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit e8e7b9eb11c34ee18bde8b7011af41938d1ad667 upstream
cdrom_read_capacity() will blindly return the capacity from the device
without sanity-checking it. This later causes code in fs/buffer.c to
oops.
Fix this by checking that the device is telling us sensible things.
From: Jens Axboe <jens.axboe@oracle.com>
Cc: Michael Buesch <mb@bu3sch.de>
Cc: Jan Kara <jack@suse.cz>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Borislav Petkov <petkovbb@googlemail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
[bart: print device name instead of driver name]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
[harvey: blocklen is a big-endian value]
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Commit 05177f178efe1459d2d0ac05430027ba201889a4 upstream
pata_atiixp: Don't disable
A couple of distributions (Fedora, Ubuntu) were having weird problems with the
ATI IXP series PATA controllers being reported as simplex. At the heart of
the problem is that both distros ignored the recommendations to load pata_acpi
and ata_generic *AFTER* specific host drivers.
The underlying cause however is that if you D3 and then D0 an ATI IXP it
helpfully throws away some configuration and won't let you rewrite it.
Add checks to ata_generic and pata_acpi to pin ATIIXP devices. Possibly the
real answer here is to quirk them and pin them, but right now we can't do that
before they've been pcim_enable()'d by a driver.
I'm indebted to David Gero for this. His bug report not only reported the
problem but identified the cause correctly and he had tested the right values
to prove what was going on
[If you backport this for 2.6.24 you will need to pull in the 2.6.25
removal of the bogus WARN_ON() in pcim_enagle]
Signed-off-by: Alan Cox <alan@redhat.com>
Tested-by: David Gero <davidg@havidave.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
|
|
[ Upstream commit bc6cffd177f9266af38dba96a2cea06c1e7ff932 ]
We need to unshare the skb first as otherwise pskb_may_pull may
write to a shared skb which could be bad.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit 392fdb0e35055b96faa9c1cd6ab537805337cdce ]
The length field in the PPPOE header wasn't checked completely.
This patch causes all packets shorter than the declared length
to be dropped.
It also changes the memcpy_toiovec call to skb_copy_datagram_iovec
so that paged packets (rare for PPPOE) are handled properly.
Thanks to Ilja of the Netric Security Team for discovering and
reporting this bug, and Chris Wright for the total_len check.
[ Incorporate warning fix from Stephen Hemminger. -DaveM ]
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit 6b6707a50c7598a83820077393f8823ab791abf8 ]
This patch fixes a potential memory corruption in
pppol2tp_recvmsg(). If skb->len is bigger than the caller's buffer
length, memcpy_toiovec() will go into unintialized data on the kernel
heap, interpret it as an iovec and start modifying memory.
The fix is to change the memcpy_toiovec() call to
skb_copy_datagram_iovec() so that paged packets (rare for PPPOL2TP)
are handled properly. Also check that the caller's buffer is big
enough for the data and set the MSG_TRUNC flag if it is not so.
Reported-by: Ilja <ilja@netric.org>
Signed-off-by: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit ae6134bdf3197206fba95563d755d2fa50d90ddd ]
This is a trivial patch against the hdlcdrv module that fixes its CRC
calculation. The finished CRC was overwriting the first two bytes of
each packet rather than being appended to the end.
I've tested this with 2.6.8 and 2.6.10-rc1, but hdlcdrv hasn't changed
much recently so it should work with many other kernel versions.
Signed-off-by: Micah Dowty <micah@navi.cx>
Acked-by: Thomas Sailer <t.sailer@alumni.ethz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit dc88807ed61ed0fc0d57bd80a92508b9de638f5d upstream.
Alexander Simon found out that the Terratec Cinergy T USB XXS is just a
clone of another DiB7070P-based device.
Signed-off-by: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Ludwig Nussel <lnussel@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit bf5b1935d8e42b36a34645788eb261461fe07f2e upstream.
Even the newer ENE controllers have bugs in their DMA engine that make
it too dangerous to use. Disable it until someone has figured out under
which conditions it corrupts data.
This has caused problems at least once, and can be found as bug report
10925 in the kernel bugzilla.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 4fe16897c59882420d66f2d503106653d026ed6c upstream
Signed-off-by: Karl Beldan <karl.beldan@gmail.com>
Acked-by: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 97f8571e663c808ad2d01a396627235167291556 upstream
The pxa27x DMA controller defaults to 64-bit alignment. This caused
the SCR reads to fail (and, depending on card type, error out) when
card->raw_scr was not aligned on a 8-byte boundary.
For performance reasons all scatter-gather addresses passed to
pxamci_request should be aligned on 8-byte boundaries, but if
this can't be guaranteed, byte aligned DMA transfers in the
have to be enabled in the controller to get correct behaviour.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 081a5bcb39b455405d58f79bb3c9398a9d4477ed upstream
The problem here is that if the ioc faults too early in the bring up
sequence (as it usually does for an irq routing problem), ioc_reset gets
called before the scsi host is even allocated. This causes an oops when
it later schedules a renegotiation. Fix this by checking ioc->sh before
trying to renegotiate.
Cc: Eric Moore <Eric.Moore@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
